A huge problem with this approach is that very few general purpose languages reach the point where they have big standard libraries, great external libraries and tools on top of them. Every time someone invents a new language it wipes away the decades of progress of the general purpose language that could be used instead, so it needs to have a massive advantage or be completely necessary.
Yes, I believe it is folly to try to build a "general purpose" language these days. It's just too much work to clear the bar for adoption (i.e. what do you offer that C/C++/Java/C#/Python/Ruby/JS don't). A language could be great in many ways, but as you say, you have to be able to solve problems you can't solve otherwise with it.
It seems like most newer languages that see some adoption have a solid niche, like Erlang/Elixir, Julia, or Elm.
Why not make the language at least very similar to an existing language? Sure, even if it isnt EXACTLY the same, it at least has a number of people that already write in it, editors that deal with it correctly, etc. Plus you can use general purpose code snippits from such a language, which will help greatly decrease the amount of libraries you will need to make directly before this becomes useful to people.
i feel like each "new" general-purpose language project is just nipping at the boot-heels of the much bigger problem of constructing large-scale systems that can be fully understood by a few (2-3) people.
VPRI's research has shown that one important method for constructing large-scale systems that can be understood by small teams is to have a pipeline of problem-specific languages that express major portions of the system. they were able to reduce LOC for a typical OS with networking and graphics by 3 or 4 orders of magnitude.
general-purpose languages can't compete with DSLs in terms of expression, and yet we keep inventing them. i think our lack of imagination is starting to show. compilation and language design will need to become much more common-place if we expect to continue scaling up.
a tower of babel in computing is healthy, no matter how much employers want us to be easily-replaceable cogs in an IT machine.
Bespoke languages are always a hard sell for this reason. You really have to support SDKs in the main languages people use.
I will never understand why something like this cannot be just a library. They'll make their claims and pleas, but general purpose languages are general purpose languages and can do anything
The point is that it’s really hard to succeed if your primary reason to exist is to make existing practice slightly better. It’s very hard to displace any of the existing languages in the space of general purpose programming.
I don't disagree (though FWIW I do disagree with some of the points you mentioned afterwards as "needs").
This is a real problem, though. If we can't manage to adopt a tool that would make us 50% more productive than what we use today, which was the example scenario under discussion, just because of momentum, then our entire industry is going to languish in substandard results forever. We'll continue churning out code that isn't as reliable as it could be and that doesn't perform as well as it could, at vast cost to our ever more technology-dependent society, all because we couldn't get our act together and learn something new.
I am somewhat more optimistic than you seem to be about the viability of doing this. New languages don't magically become popular overnight, but within the past decade or so, we've seen the likes of Go, Rust and Swift become somewhat established, certainly enough to use for real work and build a significant community and ecosystem. In the world of web development, we've seen incremental but very significant changes in JavaScript, but also serious traction for derivatives like TypeScript and significant interest in more specialised tools like Elm.
It's worth noting that in almost all of these cases, there was a "killer application" for the language that did set it apart from what had gone before. Some of them might have become general purpose languages with time, but usually there was some more specific focus at first while they were building up a critical mass of support.
I'm not against creating new languages. In fact the Lobster language is something I would want (although current syntax is bit repulsive). Python with static types but without getting in the way is pure gold. The problem is that creating interpreter/compiler is one tiny little part of creating language. Much bigger task is creating vast number of libraries that every other popular languages have. Think about everything from numpy to scipy to graphics to networking to web frameworks to OS APIs... Another bigger part is creating tooling and interoperatibility - everything from debugger, refactoring, linting, IDEs, CI, docgen etc. Now put on the top of it all the reusable code that millions of people have already written spending billions of hours in existing languages.
Without large teams working for years, its very hard for a new languages to break in to general use. There are ofcourse outliers and you can get lucky - but then you have to be terribly lucky. So the end result is that 99.9% of languages just die or become hobby project for a person regardless of their features, benefits, beauty or aesthetics. Again, nothing wrong with becoming personal hobby project but if my goal was to create game engines that becomes force in the industry, I would probably not start by creating entirely new language.
I'm not experienced as much as the author, so this is my personal opinion and likely not very well informed. I writing this just because I see several people spending years in creating new languages while their goals have been something else. They dream about repeating success of Java while not realizing how rare it is. After they finish their labor of love, I wonder if they find it depressing to become just line item in the list of dead programming languages. What if they would have actually focused on their original goal instead with emphasis on adding new powerful features that integrates and plays well with existing stuff? It's sure not as sexy and respectable as being father (or mother) of new language but has much higher chance of generating desired impact.
I’m in favor of big general purpose languages. Why? Not for their own sake. Just because it’s tedious to use multiple languages.
- How do they communicate? Maybe Json if it’s just data. For more control you need FFI
- And FFI is such a hassle that some languages seem to focus mostly on getting a nice C FFI
- ... That lingua franca that proves that you can have all the simple languages that you want as long as its name is one letter and starts with “c”
- All kinds of minute differences that are real tradeoffs when it comes to each individual language become major pains when switching between them
- Sometimes you seem to have to rule out languages just because they don’t have good libraries for X. Or can’t do concurrent tasks. How are multiple small languages supposed to flourish when 20+ year old languages can’t get good library coverage or get rid of their global interpreter lock?
I would like small languages if they all played nicely together. But they almost never do.
With so many programming languages around looking very similar, and realising the enourmous tough challenge to get adoption: why do programmers pursue writing a general purpose language and trying to have it adopted?
You know, I hadn't thought about it that way before. Perhaps the dream of a general purpose language was always incoherent. Perhaps the mess you get when perl tries to offer options to do everything well, and the suffocation you get when python tries to do everything the same way, are inevitable. Maybe using one language for small and large projects was never going to end well -- maybe either the language or the programmers were always going to do it wrong.
I suppose I have been assuming that the best policy is to do as the Romans for a long time now. Windows apps are C++ (or is it C# now?) because that's how things are over there. Android is Java, or Scala if you must -- at any rate, you hardly get to pick. Iphone requires learning Objective C. Jquery for frontend, or whatever the cool kids are doing; PHP on the back is good enough for most of the web, and it's good enough for you. And as you say, in ML, Python is not optional.
And as I think about it, I've been using specialized languages in specialized contexts for a long time. It seems the knowing the underlying language is only ever part of the problem -- you have to learn the specialized language for what you're doing, whether it's GL for graphics or your web framework's way of doing things, or MFC or .NET, or . . .
Yeah. Small tools for specific purposes, and follow the local ecosystem. Things have been going that way, and it's probably a good answer.
I really believe that it is better to have many small 'throw-away' programming languages that can interoperate with each other, than having a few huge languages that are isolated in their own ecosystem.
A language shouldn't be complex nor should it take more than a few days to learn, and it should be easy to abandon when another language is better suited for a problem.
What actually makes many languages useful is their standard libraries and library ecosystem, and the two always get mixed up. When people talk about how great language X is, in most cases they mean how feature-rich or easy to use the standard library of that language is.
With few exceptions, those libraries shouldn't be tied to a specific language. Let me access your library written in language X from my language Y.
Let me easily create projects that are made of different languages, for each part of the project the language that fits this part best.
I think, the problem is: the production of languages (and libraries especially) is way too much market-driven, there is too little cooperation, too little time spent to polish and to model at least some major use cases.
Also the quality of education is too poor, too focused on time-to-market - it makes harder for non-seniors to understand e.g. complex type systems (which are required for more usable languages anyway).
A language is released too prematurely -> some companies start to use it -> design problems become clear, but the language is in a compatibility trap at this stage -> e.g. it becomes a swamp or it slowly becomes a monstrosity of design afterthoughts and crutches.
It probably even wouldn't require much more spending from corporations, only some initiative. They anyway already invest considerably in language&toolchain development, but often with wasteful goals.
When I see things like this I can't help but think that WAY too much of the solution to these problems is being hoisted into the language. What this accomplishes could be done using libraries, but declaring a new language all but guarantees it won't be used because it forces an enormous dependency of learning a completely new language instead of learning the ins and outs of what the library actually does.
Currently it is the case that certain languages are better for specific problem domains, but that's mainly a library issue or a platform constraint (e.g. web app -> js). I don't see any reason why we need so many general purpose languages. Domain specific languages, sure. Why do we need so many general purpose languages? What exactly are the design constraints that are fundamentally incompatible between those languages? Case in point: the comment above you cites TCL, Javascript, MATLAB, R as examples of why we need many languages, when all of them are terrible language design. TCL has good built-in gui facilities, Javascript is built into browsers, MATLAB has many scientific libraries, R has many stats libraries. That's why they are used, not because the languages are any good.
I'd guess it's the same thing that makes any niche language difficult to use for real: developer education, tooling and lack of third party libraries. Mainstream languages tend to have these three things in spades, and the language itself is good enough.
"Part of the problem, he says, is that language designers don’t always have practical objectives. “There’s a tendency in academics of trying to solve a problem when no one actually ever had that problem,” said Rabkin, who recently received his computer science PhD at Berkeley and is now at Princeton working on a post-doc. "
I was at Google when Go was birthing (not part of the project or team, just co-employed :-)) and asked the team "What problem does this solve?" I asked because I had been part of the original Java team at Sun. One of the things I had learned at Sun from James Gosling, who had previously done a language for window systems, NeWS, was that the only reason to have a new language is that it solved a problem you could not easily solve with the existing languages.
If you look at all of the durable languages, they share this heritage. BASIC solved the problem of what you had to learn before you could actually program problem. FORTRAN, solved the problem of converting Formulae into computation, which was later made into high art in Mathematica. COBOL which could express business process in code, and of course C which was a logical follow on to BLIS which was the minimal wrapping over assembly language so you could implement large systems and still read the code later and know what they were doing.
I didn't get any sort of coherent answer from the Go team at the time. Which for me was an indication they were a solution in search of a problem, and thus not likely to be much more than a niche language. But to be completely fair I've seen good languages like Rexx go nowhere even though they solved a huge problem (automating the integration of different programs).
A co-worker at Google suggested that we should start holding meetings in High Elvish, their reasoning was that it would keep people out of meetings who were at least motivated enough to learn elvish, and it sounded better when you swore. But applying a language change to solve a structural problem was never going to fly.
Honestly if you're going to take a step back and consider those things, why not also consider that we already have so many programming languages that it's almost impossible to get to a deep level of understanding of all of them.
Obviously if you enjoy making languages then you should do so - and in that case, noticing that your dynamic un-toolable language won't get wide scale adoption shouldn't matter. It's already a guarantee it won't get that wide scale adoption. Either make your un-toolable language because you enjoy making them, or contribute your efforts to an already popular language that you enjoy. There are tons of interesting problems and huge areas for improvements in every single language.
Don't make a new language for the goal of gaining widescale adoption.
reply