I had a similar thought process (but luckily without spending time implementing something). I want to write a game. I thought, "None of the current languages works quite the way I want. I know! I'll write a language specifically for my game and just keep implementing the bits I need".
Then I thought, "Wait. If I do that, I'll spend 90% of my time writing a language and 10% of my time writing a game".
So I was saved. Except I still haven't even started writing the game, so I suppose it's completely moot :-D
One's name is one's brand, and where practical I recommend that people buy yourname.com and own your brand, rather than relying on the vagaries of what others may say about you.
Sure, it's fine to own your own brand–but personally (being blessed to not have a brand image), I tend to put more weight on what other people have to say about someone than what they say about themselves. Though, of course, it's often interesting to see what people tend to put on their personal pages; often what they're proud about differs significantly from what they're famous about.
Games are still in need of a better language. I have some skepticism and hope for Jai. I really wish D as better C worked better in that realm, but it's missing a few crucial things. Rust asserts too much control over memory. I'm all ears for anything that's somewhere between C and C++ as an alternative to write games in.
Most new languages just don't get the things right that C++ did, which is why despite it having a ton of deficiencies when it comes to game development, it's still what everyone in AAA is using. Companies in AAA spend so much money on software to even just somewhat improve places where C++ has gaping flaws. A better language should have been developed by now and I don't even want to think about how much money C++ has cost the industry as a whole, even just purely on iteration speed.
I was almost like OP for a while. Working on game, fed up with existing languages (even C), wanted a better C. I was excited about Jai, but as time goes on I'm finding it looks less and less what I want from a language. Seriously considered making my own.
Then I started working with Zig[0]. It's about 90% the language I want and even though it's still immature and the syntax, std lib, and semantics are in flux, I still find the quality of life improvement so huge that all my current projects are in Zig.
Zig is a better C to Jai's better C++, I think. It's a small language, it favors simplicity and explicitness, it has entirely manual memory management to the point that there isn't even a default allocator (we pass one in to anything that requires one). It even lets you import C headers directly to interface with C libraries.
Zig is on my "must follow" list right now. It's still early enough in the going that I don't want to maintain code in it, but it's developing in a promising direction and making the kind of commitments that are reasonable to keep.
A lot of language devs want to play with semantics but aren't into the whole "let's do the hard work of actually getting off of C as the baseline" idea so it's nice to have a project that does and has a fairly explicit goal of absorbing and replacing the existing infrastructure step by step.
Zig is Linux-first, though. I don't think they have any dev who runs Windows. For games especially, you don't want Windows to be an afterthought. Maybe they'll get to it eventually, but it doesn't seem a priority.
I pretty much exclusively dev on Windows, and the only thing that's a problem for me is the lack of error and assert traces. Someone started implementing the support for it, but never finished it. It is complicated by the fact that Microsoft does not distribute DIA with Windows and Zig can't include it in its own distribution.
Here is a direction if you are all ears : instead of a new language, add a new layer.
I tried creating my own languages before, some 15 years ago. While I had fun writing compilers, I missed a lot more writing actual programs. One day I suddenly realized I don't really need new language, what I needed is simply context dependent syntax and code block organization, which can easily implemented on the spot. It become MyDef and I have been programing with it entirely for more than 10 years now and wondering how others don't go down the same path.
Actually in a broad sense, Knuth's literate programing adventure is very similar to mine. He also wondered how others were not as excited as he was.
So rather than a new language, try a new dimension.
Just share with coworkers the C (or whichever) code that MyDef translated. MyDef is not a language, it only dresses the code. So if coworkers don't like to work with the dresses, simply remove the dress.
Because when using MyDef, you are still thinking in the end language -- how the function, variable, type, stack works are all defined by the end language. With MyDef, you are just changing the way of expressing them -- just like giving creatures different clothes, but they are not new creatures.
Here is a short example:
page: test, basic_frame
module: c
$local int A[3]
$for i=0:3
A[i] = i
$dump A[0], A[1], A[2]
Despite the look, if you know c, you recognize it as c. And as you get familiar, you see it exactly as C. `basic_frame` is merely a custom template so one doesn't have to always write the main function signature. $for is shorthand for `for-loop`, `$dump` is simply printf with simple type translations.
Now that you had this meta layer, there is no limit on how you want to dress up your code. Examples:
$local A[3]: int
$sumcode(3) A[i]=i+3
$foreach A
$dump $(t)
There are lots of idioms and conventions, but it is not a problem as long as you recognize them only as clothing.
Lastly, when dressing up the code makes little sense or you simply don't know better way of dressing them, you can simply write vanila C (or any languages that you are writing). MyDef never tried to compile your language.
3, 4, and 5 are all pretty sore points. 2 would be as well if it weren't extremely likely that for any game you create roll some sort of reflection system. It would be a sore spot for small projects.
3 - No access to classes and polymorphism is a bit of a downer. Although I'm a big believer of data-oriented design, I think there are still many cases where modelling things as objects is the best way to go, especially for things like scene actors and game objects.
4 - No built in threading (core.thread) puts a hamper on any sort of distributed updating or performance optimizations you'd want to do. I'd imagine the workaround is external multi-threaded dlls or something, but it sounds like a pain to manage and deal with in a workflow.
5 - No dynamic arrays. This container is used abundantly in game development. It shows up 5 or more times for every heap/stack/queue. This may not be an issue if you want to write a special memory environment and your own containers, which is common in game development, but not having access to a standard one certainly hurts when it comes to smaller projects or graphics programming experiments.
I may be somewhat off base here since what happened is that I read about those being missing and decided not to try it.
Another note is that a big thing I'm looking for is massively improved compile times, which is one of the biggest things Jai looks to have over C++ in addition to its compiler hooks and #run.
I have a smallish D game on Steam and trust me, you can absolutely use the D runtime instead of -betterC. -betterC is a work in progress and not representative of D.
You will say that you don't want a GC but in reality the GC can be optimized as much as you wan't, and in the mean time you'll get precious _developement time_ to optimize further.
If you can afford the D runtime by all means take it ; for some products I'm doing without the D runtime, and the surprise was that it did't make things any faster _at all_ without the runtime (we did it for other reasons). The only real gain is memory consumption of GC vs manual and that is achievable without going through extreme coercitive measures like -betterC.
It seems to me like you should just be using D, not "Better C-style D"? All those features are not in BetterC because they need a garbage collector, but they are of course in D proper. For smaller projects, I'd recommend just ignoring the GC until you run into actual issues with it, then optimizing for the specific issues.
That's easy to say, but as long as C++ and other languages can do those things without a garbage collector, D seems somewhat less attractive. (I'm not the OP but I've had a similar experience with D.)
As I understand it, garbage collection is kind of a non-starter for games programming because it leads to unpredictable pauses in what should be a low-latency, interactive application.
Infognition has found that if you keep the D GC heap under 100k the max pauses will be about 1 ms.
The means to reduce GC usage have only grown more diverse in recent years:
- std.experimental.allocator
- @nogc to ensure, well, no GC usage
- various things built on placement new (`emplace`)
- GC profiling with -profile=gc, will display number of allocations and size
None of this existed when people were already making high-performance systems with D...
I used `scope` with `new` to allocate on the stack, but `emplace` should just work as well to "placement new" a class in malloc'ed memory.
#4 is annoying but one could always use the OS threading API. It's doable to write a library solution to do that akin to boost or Qt before C++11. You do it once and it's there.
#5 No dynamic arrays are also annoying. But... writing a clone of std::vector isn't hard, and there's a unique array in my automem library that _should_ be usable in betterC (but I haven't checked): https://github.com/atilaneves/automem/blob/master/source/aut...
> Another note is that a big thing I'm looking for is massively improved compile times
I feel like with languages (in games or anything else), it all boils down to "where there's a will, there's a way". People come up with a lot of reasons Language X won't be suitable for a project, but in the end it's the people who use whatever tools are at hand, who get the job done while the perfectionists are stuck at the starting line. Classic Tortoise vs. Hare situation.
If you want to write games, use your favorite language, and just START. All limitations can be circumvented somehow.
The AAA company I work for has tried everything possible to work around C++, and let me tell you, had they not started any such efforts, they'd have been way better off. Seeing the results of it all makes me super sceptical of any C++-killers.
C++ is not pure OOP. you can write functional stuff quite well. the more recent C++ standard you are willing/are able to adopt the better it gets ;) C++17 is quite awesome.
Use regular C, but write the code in literate programming files which can be rendered into a portable design document describing the implementation and interaction of every subsystem in the codebase. 'Standard written English' is the best language available for modeling abstractions.
I find Swift to be the best so far, its strong ties to the Apple ecosystem notwithstanding.
Having tinkered with various environments since the Sinclair Spectrum's BASIC (though back then I had no idea what I was doing) I've successively fallen in love with Visual Basic (6.0, not the .NET impostor) and then C#, and now I'm smitten with Swift.
In Microsoft land I was let down by their usual dichotomies that did not allow you full access to all their APIs (or hardware performance) from anything but C++ (though I did manage to make playable DirectX games in VB6). I don't know how that has changed in the last decade since I jumped ship to Apple, but .NET was treated as a second-class citizen for too long.
With Swift, not only do I have access to everything that Apple's operating systems offer, it's also a modern language which feels naturally suited to game design patterns. Although until Swift 2 I often had to fight the language, since Swift 3 and especially now in Swift 4.2 I find it effortless to reason about most game architectures while sticking to the language's idioms.
I also appreciate it for enforcing good practices and getting rid of most sources of ambiguity (such as the ++/-- operators and the legacy `for` syntax, or being specific about %/modulo and so on), even if it may feel annoying in the beginning if you're coming from "looser" languages. It also compiles to native code and can easily interop with C [0], but best of all: I am glad to be able to finally leave semicolons behind. C# honestly feels archaic in comparison now.
As for the elephant in the room – that Swift is only good for iOS, macOS, tvOS and watchOS – well, those platforms have a combined userbase of over a billion users, and the most successful app market [1]; I don't feel that it's such a downside to be limited to those platforms. I do wish that the Apple TV came with a proper gamepad so we could only target that without losing users. It could be a serious contender to existing game consoles if Apple took that route.
If you're in love with Swift too, I'm writing an open-source game engine which offers an Entity-Component-System architecture on top of Apple's APIs [2].
Ah. My crankiness towards MS may no longer be justified.
I’m too deeply entrenched in Swift though and disgusted by the sight of semicolons in a language anymore :P (maybe I’ll dip into VB.NET and see how it’s doing.)
Language Syndrome sounds like Engine Syndrome in hard mode. You want to write a game, so you start working on a game engine, only to realise that a game engine is a never-ending project and you'll never have spare energy to actually write the game. I fell prey to this a couple of times back in the day.
I hit a similar roadblock for a long time, always spending time writing low level graphics utilities (which I do rather enjoy) but never getting around to writing a game.
If you find yourself in a similar situation and want to get around it I would suggest trying unity, which I was hesitant to do since:
1. It felt like giving up and cheating, and
2. I don't like how unity interfaces with the developer, since I mostly wanted to implement games without using the world editor that seems to be the focus of unity.
But I've enjoyed using it so far and would suggest giving it a shot.
Re the second point did you manage to get around this? Played with it a bit and it felt almost like flash back in the day where you could eschew the timeline and do everything programmatically. In the end ran into a problem where I wanted to move the universe around the player and couldn’t get the particle engine to cope..
You can do anything programmatically in unity. I think professionals tend towards this. You use the world editor only for artistic expression, the spatial layout and tuning etc. where previewing layout really saves time.
For very specific effects like universe turning, you have to do a lot of code work in a niche area, but it's still quicker than building a particle engine from scratch. Sometimes you can cheat the effect in shaders or camera tranform manipulation. Or skip the effect altogether if the volume of custom code is not worth it and you are prioritizing shipping. Ask yourself, does it make or break your game?
I started our my games development career as a low level programmer and moved to a lead programmer in the technology department and then founded a games studio where we wrote our own engine and released several games.
My role meant I had to make the correct business decisions using my technological knowledge and as much as writing engines and technology ran through my blood, the right answer was to switch to Unity. The man cost of constantly writing all the technology we need and then maintain it was too great compared to the ever diminishing wins we got from it.
One scary part of this decision was then hiring Unity programmers and initially having these new hires knowing more about Unity than I did. I needed to make calls about what is possible, time frames, performance, meeting client requirements etc without being an expert of the most important part of our development process. Luckily we made the right hires and it didn't take so long until I had been converted to the Unity mindset. Initially I would always be saying "oh well I would normally tackle this in this way" and wanted to coerce Unity to work in a familiar way. But overtime this disappeared and I became increasingly interested in working out the best way to achieve things in the "Unity way" which ultimately returns much greater dividends.
The first game we released, called Bloody Zombies came out last year on Steam, Oculus, Xbox One, PS4 and Nintendo Switch. It can be played in VR (on supporting platforms) and non VR. It is multiplayer, both in the sense of multiple people on one machine (you can do things like 1 VR player and 3 TV players or 4 TV players) but also online multiplayer (where you can do one player per machine or any combinations say one tv player on one machine playing with 1 VR players and 2 tv players on another machine).
VR meant we had to maintain a constant frame rate (60 or 90 depending on platforms). We used stereoscopic rendering, offloaded graphics work to a special job system. We used custom shaders (the game is like a graphical novel so outline shaded characters) we have spherical fog, lightmaps, FXAA, colour post processing etc.
Online multiplayer meant a packet system, ability to establish connections, matchmake, a system for making parts of the game world communicate, handling so many error cases, etc.
For variety of platforms meant lots of variety on the rendering, controller input etc.
For Switch it meant the ability to play on Switches close to each other on a different protocol to online multiplayer.
I shudder to think how much time and effort this would have been without Unity. I suspect we would have needed several new hires working on platform specific tech, full time network engineers, at least one full time graphics dev, at least one full time audio dev, one full time physics dev, the list goes on. Instead we had 3 programmers (which includes me where my time was heavily comprised being a founder/MD/Tech Director/coffee maker) and whilst the other programmers were very good they had both only graduated a few years prior.
Did Unity solve everything? Absolutely not. We hit loads of huge problems with Unity. Without help of their engineers some problems we would never have been able to solve. We helped Unity fix lots of issues at their end. We found issues that could have been solved trivially without Unity. We felt the strain of waiting days for an answer to a mission critical Unity issue. But in the grand scheme, the pain was less than 10% of what we would have experienced doing it with our own engine.
My big worry was not doing "tech" anymore, but that simply isn't true. But instead of having to write loads of architecture and code to even be able to write the "real" tech, instead you can write the more interesting stuff. For shaders you just write the shaders, not the system for passing in shader constants and setting up vertex streams. Post effects is similar. Coming from a strong engine/Tech background has been massively helpful, whilst unity trained hires are amazing it has been really useful for our studio for me to be able to get into the lower level to add feature, fix stuff, debug stuff, etc.
> We felt the strain of waiting days for an answer to a mission critical Unity issue. But in the grand scheme, the pain was less than 10% of what we would have experienced doing it with our own engine.
Wouldn't that make you feel nervous ? To totally depend on unity's merit to ship a game when you cannot address blocker bugs yourself ?
Yes, but not unusual, as well as Unity we have similar blocks from MS, Sony, Oculus, Nintendo.
One good thing is that rather than us hitting lots of blocks with the hardware manufacturers with regards to the engine, Unity handles this instead and Unity is in a much better position to resolve issues due to their relationship with the hardware manufacturers but also the size of the dev team.
We still had several issues we had to deal directly with Sony/MS/Nintendo. Some issues they could resolve and others they could not (meaning we had to find elaborate workarounds or key changes to the game we didn't ideally want to make).
Perhaps I'm missing something here, but you should just need to move the player in the opposite direction of the world's desired movement? No game system I'm aware does it the other way around, as it requires changing all the other models transforms.
But yes, I am dealing with the interface, primarily by ignoring it. I'm still trying to get down the right way to organize my code, but it's making sense.
Once your game world size crosses a specific threshold, you need to move the world instead of the player because numerical accuracy starts to become troublesome (most engine code runs with floats, which gives about 6 decimal digits of precision). The first engine that I am aware of that did that was that of Dungeon Siege. There's an excellent post mortem around about the challenges of this approach.
I'm in the same, but get the opposite idea. I procastinate in build the language I want (a relational engine, not a DB, a language) always thinking "Is better to let that to pros".
But more time I do the same things over and over, more I'm convinved I could abstract my main tasks (around data manipulation) in a simple language:
I expect the language to be a glorified DSL that is just about data, parsing, loading data, moving data, converting from this to that and a way better (I hope!) than ORM for interfacing to RDBMS.
This isn't my area per se but have you considered Lisp/Haskell (even Ruby) or one of the other languages with good metaprogramming/DSL creation facilities?
Or perhaps making a small extension to one of the above, I know many languages have the ability to be extended through modules added at compile (meaning when you compile the interpreter/compiler/runtime itself, not the program) time, or used as a target for a preprocessor. That makes it so it's at least a little easier to get a userbase going, maybe some existing libraries can work with your language.
If that's not possible, I'd be curious to learn what makes it not feasible. Fresh approaches to data processing are really desirable right now, since so many of us are working with data that is different from what language designers intended.
>If that's not possible, I'd be curious to learn what makes it not feasible. Fresh approaches to data processing are really desirable right now, since so many of us are working with data that is different from what language designers intended.
I wish to use instead swift, that hit a sweet spot. Using other lang (like python, that I loved!) make hard to target iOS/Android. This is the main crux of mine. This mean that I need to re-code a lot of stuff across platforms and targets, because nothing is good enough. I also use xamarin/F# and the integration with android/ios is not as good as I imagine (ie: xamarin.forms sucks. And is damm hard to integrate yourself anything (ie: ios/android libraries) outside it).
I also try with nim but is too crude and lack a lot of libraries I will need. I'm also thinking on using pascal, that I also like much, so now is just looking how good could be the use of rust...
C++ have a lot of nice stuff now, but anyway soon or later need to take from the old mess. If I wanna suffer, I prefer something with a more consistence...
10% for writing the game? you maybe too optimistic :D
I found myself having the same problem, luckily I don't know how to write a language.
I'm currently working on a part-time project in Go, it involve a HTTP service.
As you may already knew, there is a built-in HTTP server that came with Go, so I COULD just took it and go ahead directly start to implement my service logic.
But hell no, it's too slow. So instead, I made my own HTTP/1.1 server, which is bit faster than Go's.
It was pretty fun to write that server indeed, but I don't think it's worth the trouble. In fact, I really really hope somebody stopped me when I was creating that `http.go` file.
Now, I'm wandering around, thinking the `html/template` is too slow ...
I did end up going the way of writing that compiler and never writing the thing I wanted to write the compiler for, even forgot what it was.
But it was and is a good experience, the last 13 years of writing a compiler. Especially if you like solving problems with no or few searchable solutions.
Some people seem to be objecting to this as a fluff piece, but it speaks to me on a deep level.
I develop free software because I like to learn and create; because good tools make work a joy; because I like to make useful things.
And I've parted ways with several projects, some of them mine and some of them from others. It's painful each time I leave a useful project unmaintained. And yet, I don't find long term project maintenance sustainable as a hobby when my personal use declines.
I suppose the best outcome is handing useful things off to a new caring maintainer. How do other people deal with this?
I think handing it off to a maintainer when your own usage declines is a very good idea. One of the problems with maintaining something that you don't use a lot is that you get out of touch with how it is being used and the direction of the community. If you are at the head of the community, it is helpful to be an active participant; so appointing another maintainer who has an active usage, passion, and is "in-touch" with what is going on could be very fruitful. Eat your own dog-food
I worked for years on a game engine so I could develop a game I had an idea for. In doing this, I learned C, Lua, 3d graphics, threading in Linux, and a lot more. I never finished my game, only getting as far as some demos, but I'm still greatful for the learning experience.
Perhaps that did not come across in the article well. When I set out to do Leaf that was the goal of the work. It's wasn't a diversion to some other goals. Over time my priorities changed, and I was trying to force myself to follow Leaf to follow them.
Had I wanted to make a game from the start I would most certainly not have made a language first! That would be crazy. And that's my comments about sunk costs -- just because I have Leaf, it'd still be crazy to do this other projects in it.
You could also call it a partial success. Your A and B may help others write their C and D.
Also, hobbyists should have the motto “the journey is the reward”. If you had fun or learned doing A and B, it’s not a failure, even if all the learning was “if you want a D, it’s not worth it spending time writing a slightly better A and B”.
This is sad, and I feel for you. Your experiences I think mirror in the macro what many of us have in the micro - a side project becomes a love affair becomes something that has to be left aside as the rest of life takes over.
I hope it is merely a hiatus - and I hope too find your next great passion. Keep writing about it - we will follow ...
It's a depressing feeling but the key point is that it's not motivating you any longer and motivation was the driving force of the project. When I face situations like that I usually raise the requirement bar up until it feels hard and fun again. So I suggest that instead of just doing what needs to be done with your project, invent a novel solution to the problem that is useful enough but most importantly - motivating you to do it
I wonder if Rust could become used as a standard library for other languages in the future. It seems well fitted for this role due to it's safety, relatively easy ffi, and speed next to languages with similarly large standard libraries.
I believe rust can compile down to a shared object and thus trivially used via any CFFI. Sure you lose the expressivness of the rust language APIs but that's a nightmare for interop anyways.
Really curious, is there much of a usecase for a stable rust ABI? There is no ecosystem of "rusty shared objects" to support and cargo tends to build things fine without it.
As an outside observer it looks like an unnecessary complication.
Plugin systems and distributing dynamic libraries are the two big use-cases.
For the second use-case, distributions can handle that somewhat okay by simply enforcing that all packages are compiled with the same rustc version. That works okay, but it means that, as an external user, you can't really depend on those libraries for your own executables, as you'll need to recompile when the distribution updates.
It is possible though to build your own stack from the ground up (hard part is to be smart about what exactly "the ground" is). Look at Knuth and TeX. And today we have even better tools to write programs, and much better turn around times in terms of compiling etc. Obviously, there is some added complexity for there are API's like Apple Metal you will need to learn, but I think that more than evens out in total.
I think it is important to have a big goal though (like TeX) to keep you motivated and moving forward.
> "And would I want to work on yet another language, knowing I’ve already solved the interesting problems?"
Sometimes this happens to me too, where I want to scratch an itch, and I try to do it by writing real software and using it. In general I have found that to be a bad idea. For those I prefer writing throw-away software, and only writing real software when it's "boring" but useful work.
When I started Leaf it was to scratch an itch. It was really only when the motivation dropped that I tried to find ways to use it, to renew my interest in pursuing it.
C is a perfect language for writing games into; C++ has some extra sauce that makes some things easier, faster to write and more correct.
There is no actual need for a new language for writing games; that's why so many, including the author, give up. C/C++ has the 90% of what is needed to write any application, and the rest 10% is simply elusive and might not even exist.
Problem with C/C++ is maintaining and writing code. I am sure you are well aware of Jonathan Blow's efforts in writing Jai programming language. If not take a look at his Youtube channel. Pretty eye opening. (I am no game dev btw)
For my language, instead of targeting LLVM, I targeted C. That made me take off fast, because everything in C is available from day 1. What I did is build an extra layer over C to make it behave more like a scripting language.
I chose LLVM from the start since I knew some of the challenges that interested me couldn't be done at the C level -- or rather it'd be more complicated at that level than at the LLVM level.
What he is experiencing is the reality of most people's lives. The boredom and drudgery of doing the hard yards every day. Most people do not have the luxury of doing what is interesting to them. It is a case of just having to knuckle down and complete what has been started.
From my personal perspective, it's nice to have side projects that are interesting and learning exercises. The reality is that if these side projects are actually worth it then they need to be completed. Otherwise they are just a fad and not really worth the effort that might be put into them.
If something is worth starting then it is worth finishing.
This post seems to be just a collection of generalities judging the way that someone else has chosen to spend his time. You seem both to be saying that he shouldn't have started and that, since he started, he shouldn't stop. Well, presumably the author once got some value out of the effort, so that it was worth starting; and found that he was now no longer getting enough value out of it, so that it was worth stopping. Do you really think that it's valid (or even important) for you to judge either of those decisions by someone else?
For a private endeavour, whether he finishes or not is completely up to him. When he puts it out for all to see, this then changes the dynamic under which he is moving forward.
If he had said he was stopping due to life commitments or family situations, etc, then these kinds of things take priority, as they should. No problems or issues should arise from that. But he has stated that he is giving up because it now involves doing the hard yards to complete the project - this does not show him in a good light.
In essence, he is saying that once something has become non-interesting in whatever way, then he will give up and move onto something else that will hold his interest. In other words, he is committed to a course of action only when it holds his focus, but that he will happily drop it when it becomes hard work.
I really don't think that he was intentionally going out to say that he is undependable. This is what he has said though.
A more charitable explanation is (in his words), "it’s no longer fulfilling my goals, and it’s not as fun as it once was."
When I look at it from his point of view, I feel quite sorry for him. The language's forum has 9 posts in the last calendar year. 4 of those are him solving a problem using Leaf. Then, I check out the status page and realize that, for all the work he has done, Leaf is still in a very primitive state.
I'd equate it to being like a startup. At some point, it stops making sense. Then, you can either ride the ship down into the depths, or hop out when the going is as good as it will get.
As for his dependability, I've got to tell you that, from my perspective, anyone who can pull this off is more than impressive enough.
I think he should be awfully impressed with what he did. And, I don't think it's even remotely fair to judge him as being undependable. Based on what I've seen, I think he should have pulled the plug last year, when he first wanted to quit.
Maybe it is a change of times, but when he got into the detail of why he was quitting, it was about the hard work ahead, which is rarely fun for most people.
I don't feel sorry for him at all. He found something that was of interest to him and he decided to head down a path towards that interest. Good on him. Kudos to him for giving it a go. However, the problem he has made for himself is that he went public far too soon and is now publicly saying he is quitting because there is too much hard work ahead for him.
Startups have a low rate of success and is about testing an idea that has a good likelihood of failure. Different proposition to start with. The more appropriate comparison is making some item that can be useful to you but has a lot of tedious and fiddly work to be done. In his case it was a computer language which always comes with implementation problems to do deal with. One knows this up front, or at least, should know this.
The problem is, he hasn't pulled it off - there is still a long way to go. One of my areas of interest is language design, compiler construction of virtual machine implementation. This subject matter is highly complex, tedious in many ways and requires a great deal of patience and perseverance. For each problem you solve, more arise to be solved.
For an individual, this can be daunting when you finally realise that you have undertaken a massive project. It is especially so, if the language that you have designed doesn't strike a cord in other people. But if you have a goal in mind, then continue on even through the tedium that will come.
Things will always get in the way of you completing side projects, that's life, but you can still keep chipping away as the years go on.
I'm in my forties and the times have not changed that much. We have a limited number of hours on this planet, and we don't know how limited they are until they're already mostly spent. We can slave away doing things we don't gain anything from, or we can go out and take control of our happiness.
This fellow doesn't get paid for his work on Leaf and he works on it during his already spare time. He would gain more doing creative tasks - he wants to "do graphics, write music, make some games and record some videos."
It has nothing to do with hard work and everything to do with allocating his time in the way he most wants to. He is taking control of his own happiness and that is admirable.
^ I don't see it as indicating undesirable character at all. I read the piece as more an indication that the guy knows when to cut his losses and stop allocating resources to unprofitable activity. Which to me, from a business perspective, is a sign of someone with their head screwed on straight.
I also don't grasp the logic behind the notion that once a creator shows his work -- or work-in-progress -- to the public that he is somehow bound by duty, honor, respect for his 'followers', or some other compelling consideration, to finish that work.
If Beethoven starts writing a string quartet, and posts the first movement on the internet, but then realizes that the Duke isn't going to commission it and he'd rather be writing a sonata anyway, does it really reflect badly on LvB if he abandons the quartet?
> I also don't grasp the logic behind the notion that once a creator shows his work -- or work-in-progress -- to the public that he is somehow bound by duty, honor, respect for his 'followers', or some other compelling consideration, to finish that work.
You can show off your work in any way that you want. You are also not bound by duty or anything else to finish that work. However, if you are putting it out there for other to see and or use, at least say that this may or may not be useful in some way. To cover yourself, you could say that it will be a work in progress and that the progress will move in fits and starts as you have time to devote to it. At that point, there will never be a need to say that you are giving up on it.
Bad comparison with Beethoven. But to answer your question, if he had said that this is the first movement and may have a potential to be completed if the Duke commissions it, then it doesn't reflect badly on him when the Duke doesn't commission it.
It is a matter of what expectation you are creating in those who are viewing your work. If you are saying that it is there as an example of something, then so it is. But if you go out and say "here is the bee's knees", and then you decide that it is no longer worth your while because the amount of work is now too much, then you have created the problem for yourself.
There is a project called Axiom, which has inspired me to look at my own code and projects in a different light. But to follow in the footsteps presented by Axiom in my own projects involves a lot of tedious hard work. The benefit that I see is that anyone who comes after me and is interested in what I have done will be able to follow. That "anyone" may only ever be me, so be it.
Pretty much nobody but you has this perspective, it's completely irrelevant to the reality other people live in. And such a perspective is harmful, as it could discourage people from work under the false perception that an unfinished piece of work is worse than none.
I'm not sure where you got this whole idea from, but it's not true, neither in the real sense nor in the perceived sense. People benefit from working on projects they do not finish, and plenty of people are impressed with unfinished projects. This person is going to be a much better developer than average from this experience. There is literally no issue here. It's his work and it's his time and what he does with it is none of anyone else's business.
The only issue here is you making an issue out of it according to some strange ethical norms that nobody else shares. This is a massive overthinking/overjudge and the thinking here is rather unhealthy.
See my responses elsewhere in this discussion. Simply put, he is closing down the project because to continue requires too much hard work and is boring and uninteresting. It is not that he has found an answer to his investigations and so he can move on and here are the lessons learned.
Yet I suspect that the intent of what he may have wanted to say is that final sentence above. But that's not what he said.
I'll say it again, there is no problem with unfinished work, if what you were trying to achieve has been completed.
But please, don't then say that you won't complete the work your doing because to do so would require hard work and it's just boring and tedious. This is what reflects negatively on you.
If you have achieved your goal then just say that and show what has been learned from the exercise. If you would like it to be continued but can't do so for whatever reason, which you do not have to state, then offer it to anyone else who might be able to take it on. You never know, you might get some takers. This reflects positively on you.
I struggled with side projects that I never completed until I decided that I would never do a side project that can't be done in one or two afternoons. There are people out there that can chip away at a project over months or years and I think I just took a while to learn that I'm not one of them.
Most of us have side projects that we can be troubled by. We also don't put them out for everyone to see, nor do we say publicly that we are giving up because the hard work is now upon us.
I have lots of side projects that I may live to see finished. However, any that I say I am working on get assigned time to move them forward - they may take years to complete, but they will be worked on over time.
From my perspective, he would have been better off saying that due to time constraints further work will be done when he is able to allocate time and leave it at that. There are plenty of projects that only get updated irregularly over years and can have years between updates. That's fine.
However, if you stop a public project because you just don't want to handle the hard work now involved, that becomes something different. You are making a public statement about your character which you probably weren't intending.
I don't agree. If I'm doing the boring parts of a project at work, at least I get paid for it. If I'm doing the boring parts of a side-project, where the only benefit to me is that it's fun, what's the point?
The point is the completion of the project. Most parts of most projects that we do, whether we are paid to do those projects or not, are boring and tedious. Without those parts, nothing is ever built or completed.
Yes and no. Sometimes it's not about the destination but about experiencing the journey. From the post it seems like the author extracted the value they wanted to extract over the years. Knowing when to give up is difficult, especially when you've sunk a lot of cost into the project and feel like you have to finish it. The thing is, you don't have to and it's perfectly acceptable to put it on hold indefinitely.
In the end you'll still have all those experiences with you and that's what you paid for with your time.
The problem here is that the project was made public for others to use/view. If someone wants to do a private project that impacts no-one else, it is then completely up to them as to whether they continue or not as it their choice.
However, when one starts a project and says "look at me and the fabulous stuff I am doing" then it does not show them in a good light when they give up because they are now in the drudge work.
In a public situation, they are essentially saying that they are not worth their hire when the normal drudge work starts. I can understand stepping back from a project for all sorts of reasons, except for the reason that it is hard work to continue because drudgery.
Most of the work that most of us have to do is not exciting, not learning new things, not even interesting. It is just drudgery that needs to be done to get to the eventual goal that we started with. This is life.
The thing is that even drudgery work can be viewed in a very positive light if we continue to see it as essential for the final goal we started with. We will see the need for it and we work willingly towards the completion of it for the purpose of what we will achieve in the end.
The journey is a part of the destination and it is an essential part of the whole process. A journey without a destination and a destination without a journey are both meaningless without the other. Both are the two sides of each other.
> The problem here is that the project was made public for others to use/view.
This literally doesn't matter if we're talking about someone's character, because whether it's public or not is irrelevant regarding the " they give up because they are now in the drudge work" point. Either that point is valid or it's not, but the public knowing about it is beside the point.
And I would say the point is not valid. Someone starting a personal project for a language and then discontinuing it is still much better off than someone not starting a project at all. I don't think most engineers share the perspective that this shows them in a bad light or something, this is honestly the first time I've seen this perspective in years.
> Most of the work that most of us have to do is not exciting, not learning new things, not even interesting. It is just drudgery that needs to be done to get to the eventual goal that we started with. This is life.
There's nothing good about this, nor anything good about reinforcing it. Godspeed to those who can avoid it.
The author of the language does not owe it to anyone to start, continue, or finishing any projects they have in mind, definitely not to anyone sitting around and judging them for daring to do something at all.
The point is that their character is reflected by what they do. If they say that the work they are doing is looking at a specific problem and when they get the answer then the work is completed, we can see that completion and can say they have achieved their purpose. If on the other hand they say their work is for a much broader area and then they say that they are giving up because it is just too hard, then they are saying something else about their character.
It is a matter of what expectation they are creating and what they say they are trying to achieve.
I don't have any problems with someone creating a language to see what they can achieve with it. If they find it not doing what they need, they can move on. However, they can ambush themselves by the creation of a project that they claim is bigger than what they may actually have in mind.
I have lots of partial language designs to test out specific ideas. Many are incomplete because they have shown that the specific idea I was testing is basically flawed. The information is available to those I discuss this with for them to investigate in their own way. They can see the lessons I have learned, especially about the failures I have come across. But they know well that the work done is both incomplete and was created to test out one idea or another and may or may not be of any use to anyone else.
My discussion point is that the author could have handled himself better without reflecting on his character. Essentially, to say it is now too hard to keep going because it is tedious, boring or just too much effort required doesn't reflect well on him. He could have handled that a lot better and still put everything into a close down mode.
> > Most of the work that most of us have to do is not exciting, not learning new things, not even interesting. It is just drudgery that needs to be done to get to the eventual goal that we started with. This is life.
> There's nothing good about this, nor anything good about reinforcing it. Godspeed to those who can avoid it.
My question to you - do you have a plethora of servants to do all your drudgery work? Who cleans your toilet, washes your clothes, cooks your food, sweeps your floors, mows your lawns, changes your children's nappies, and so on and so forth? Who writes your correspondence, enters your passwords, writes your code, drives your car in traffic?
Far too often, people are taught today to skip the tedious, the uninteresting and the hard boring work and someone else has to come along and clean up after them.
I am not judging that he dared to do something, I am highlighting that the way he has stopped his project reflects badly on him. Whether he starts a project or stops that same project is up to him. It is the reasons he states for that start or stop that reflect positively or negatively on him.
I work as a programmer in the games industry, as well as make games by myself on my spare time.
Like how the author describes, I really had to divorce myself from the thought of being a software designer or computer scientist to even start to make the sort of games I wanted to make. Even then I'm hardly a competent game developer, but I'm at least somewhat proud of my work so far.
Then I thought, "Wait. If I do that, I'll spend 90% of my time writing a language and 10% of my time writing a game".
So I was saved. Except I still haven't even started writing the game, so I suppose it's completely moot :-D