> Yeah, languages aren't for everyone, but specifically trying to scare people off of it seems harsh and unnecessary.
That depends. It's really hard to articulate just how much work is involved in writing a programming language. It's one of the classic infinite time sinks that exists in the CS field; no matter how much work you put into it, there's more to be done. It's very hard to ever call it "finished". I've seen a lot of language projects start as "I was working on this other thing and then I thought to myself, gee, here's a great opportunity for a programming language to make this easier." 8 years later they're still working on that programming language, the original project a distant memory.
Programming languages have a way of sucking in developers without them realizing it until it's too late. So while I wouldn't dissuade anyone from writing a PL per se, I would warn them that writing a PL is a *huge* undertaking in its own right, and should really never be undertaken to help you solve your own problems. If you want to go this route, then you need to abandon your problem and focus on the PL instead.
I'd almost agree, but at the same time such work can be a lot of fun.
Personally I think an average programmer could knock out a BASIC, FORTH, or similar programming language - with extensions - in a few months of part-time work, if not less.
The harder part, the part that I can see taking a lot of time, is trying to create a "batteries included" language which has a very complete and complex standard library.
Sure there are cheats if you're able to use dlopen, and FFI, to access C-stuff, but it's still not easy to create client-libraries for MySQL, Postgres, Redis, HTTP, etc, etc. Those kind of extensions/support make your language very very useful for users though. So there's a trade-off.
I've put together a couple of simple languages, with a standard-library of maybe 30 functions. I'd draw the line at anything more no matter how appealing it might seem because I can just imagine how much of a time-sink it might become.
The article is aimed at people hoping to make an actual useful language.
Lots of people could make a BASIC or a FORTH in a week. It would almost certainly be rather useless, unless the language itself is the point of the project using it.
99% of GitHub repos appear to be useless. They show up because someone wanted to make a simpler version of something that they can understand.
They don't teach much about the mainstream professional way. They often don't perform better, since things like GPU and SIMD are more important than simplicity.
They are perfectly fine as toy projects. I have a few myself(Although none of them use any real interesting algorithms or new concepts or anything). But that's... all they are.
At most they will become super niche things like suckless.
But all programmers should know that Electron apps run just fine even on cheap modern hardware, and that existing solutions are probably going to be better than anything you can do, unless you spend months to years like they did.
The programming community doesn't really seem to respect just doing everything by the book, the way a Microsoft dev would, and it's cool to see someone reminding people that it's a perfect good option to just grab some npm packages and make your thing and not bog yourself down with how it all works.
That depends. It's really hard to articulate just how much work is involved in writing a programming language. It's one of the classic infinite time sinks that exists in the CS field; no matter how much work you put into it, there's more to be done. It's very hard to ever call it "finished". I've seen a lot of language projects start as "I was working on this other thing and then I thought to myself, gee, here's a great opportunity for a programming language to make this easier." 8 years later they're still working on that programming language, the original project a distant memory.
Programming languages have a way of sucking in developers without them realizing it until it's too late. So while I wouldn't dissuade anyone from writing a PL per se, I would warn them that writing a PL is a *huge* undertaking in its own right, and should really never be undertaken to help you solve your own problems. If you want to go this route, then you need to abandon your problem and focus on the PL instead.