New Programming Languages Come From Designers 435
eldavojohn writes "A very lengthy and somewhat meandering essay from Crista Videira Lopes has sparked off some discussion of where new programming languages come from. She's writing from the viewpoint of academia, under the premise that new languages don't come from academia. And they've been steadily progressing outside of large companies (with the exception of Java and .NET) into the bedrooms and hobbies of people she identifies as 'designers' or 'lone programmers' instead of groups of 'researchers.' Examples include PHP by Rasmus Lerdorf, JavaScript by Brenden Eich, Python by Guido van Rossum and — of course — Ruby by Yukihiro Matsumoto. The author notes that, as we escape our computational and memory bounds that once plagued programming languages in the past and marred them with ultra efficient syntax in the name of hardware, our new languages are coming from designers with seemingly little worry about the budget CPU being able to handle a large project in the new language. The piece is littered with interesting assertions like 'one striking commonality in all modern programming languages, especially the popular ones, is how little innovation there is in them!' and 'We require scientific evidence for the claimed value of experimental drugs. Should we require scientific evidence for the value of experimental software?' Is she right? Is the answer to studying modern programming languages to quantify their design as she attempts in this post? Given the response of Slashdot to Google's Dart it would appear that something is indeed missing in coercing developers that a modern language has valid offerings worthy of their time."
C isn't dead...yet. (Score:2, Interesting)
Well there is always been two sides of the medal balancing each other - convenience and performance, and i doubt it will ever change. And i think Ruby is really stands apart from other mentioned languages, a lot more sophisticated and carefully designed.
Re:Doomed (Score:5, Interesting)
Not quite true. There are believed to be a very large number of possible models for computation, of which functional and imperative programming are but two.
Most of them are unlikely to be particularly useful, but there is plenty of scope for new languages which exploit them.
Re:C isn't dead...yet. (Score:4, Interesting)
Convenient programming should be prioritized nowadays, most people at an entry level don't plan to code anything massive and performance critical anyway.
While I do love ruby(and processing, and ruby processing) I think there's a lot of room for improvment in convenience, perhaps at a massive expense of performance, but most people have a core or two, or five sitting idle most of the time anyway.
Ideally, programming should be a playground accessible to all, not like today where it's more of a military discipline camp accessible to all.
Article contians junk (Score:5, Interesting)
"Languages designed by academics like FOTRTAN, COBOL, C"
Were apparently desighned by academics obsessed with internal consistency and are now mostly deat tounges.
These are contrasted with languages hacked up by people to get stuff done.
WTF?
FORTRAN was the first ever language and was hacked up by someone who wanted to get stuff done because ASM was too much of a pain in the neck. It was unlike the author's bizzare assertion the easiest to use language at the time of being written. That was the entire point! While its use may be on the decline, it has been in use for 55 years! And major important packages are still written in FORTRAN.
And C? Seriously? Yet another language which was hacked up by a bunch of hackers to get stuff done. Apparently it's mostly dead. Even though it is the main implementation of 3 of the "less academic" languages listed.
I'm surprised there isn't a "c++ is dieing haha lol!1!111" in there too. I'm glad the author never tried to argue that C++ has internal consistency (I do love C++, but...).
And COBOL being an academic language? Oh dear.
Conclusion: article is crap.
It's the libraries and frameworks, stupid (Score:1, Interesting)
We don't really need any new languages. We need libraries and frameworks that are simple, flexible, minimalistic and don't force you into their own unintuitive way of doing things just so they can claim to have cobbled together 300 design patterns into a buzzword compliant mess. All the libraries and frameworks are complete ass. Java and .NET, C and C Sharp. All crap. We've actually gone backwards in the last 15 years. It use to be relatively easy to put together a program that did simple IO and database work. Now you have to create mappings and configuration that makes things slow and cumbersome. The solution when you get bogged down? Lightweight cobbled together languages that can't scale for shit. When I was programming int he mid 90s it use to take 2 hours to prototype a screen to show a customer. Now you're lucky if it takes a week, and you spend another week on test cases that have less to do with actually being useful than meeting some damn coverage quota. Programming, like most things has regressed in the last decade and a half.
Compiled vs. scripting languages (Score:4, Interesting)
I would worry if important projects with large budgets and generous timeframes switched from Java to e.g. Ruby, but this won't happen. The existing compiled languages for such purposes are obviously very good already, so why should it matter that a new compiled-to-JS-language pops up every day?
Re:Doomed (Score:4, Interesting)
Compiling functional languages down to C is extremely simple. Functional code is imperative, it's just accepting the rule that you can never reassign a variable. It's the reverse that's hard.
But just because it's hard doesn't mean it's not done. Pretty much every C compiler with the partial exception of gcc compiles C code into a functional-style imaginary assembly-like language, because that allows more optimization algorithms to work. It's hard and complex, but it gains you a few percent of efficiency.
Most high-level programming languages easily "compile down" to C, in a straightforward and easy manner. Just look at the gnome source code to recoil in horror at the manual, convoluted and incomplete reimplementation of C++'s virtual method tables. Complete with the "your destructor isn't virtual" gotcha just waiting to bite you, except without the compiler warning when you do screw it up. Or the linux kernel's way of dealing with all sorts of datatypes, like a file handle. It *is* object-oriented, both gnome and the kernel, they just prefer to compile manually.
Want to give C "all the power of python" ? Just make all variables part of a huge dictionary, and do everything with symbolic lookups. ( x.y(z) => (*dict_get(dict_get(global, "x"), "y")) (dict_get(global, "z")), and all types reduced to "void *". There's people who actually do stuff like this (like, again, gnome).
The new linux iptables code looks like an extremely basic lisp implementation, because they know how to make that fast. The previous one looked like an interpreter for an extremely convoluted language (much slower because of the 2 strands of execution : first the interpreter itself, second the actual rules being executed. This hinders cache efficiency a lot).
Going down is never the problem. Compiling any highlevel language down to C is an easy exercise (I won't go as far as to say it's trivial, it's not). Imho it's not the best option. C is hard to optimize (but code is available to do that), so compilers necessarily miss a lot of opportunities. The compiler actually has to determine the programmer's intention, prove difficult properties about portions of code, before a lot of optimizations can be applied. Needless to say, this is very hard. Dataflow oriented languages, by contrast, are much easier to optimize and beat C in performance. But nobody knows them, and so actually coding such a compiler is a very hard, very lonely exercise.
Re:Doomed (Score:3, Interesting)
This is like arguing for good Engineering. The Efiel Tower is a great piece of engineering and applied sciences. It is also a terrible house or car factory.
What these "bad" languages provide are tools to do a TASK well. The classic case of a well designed and engineered language would be Java. The underlying computer science is excellent.... But it doesn't SOLVE PROBLEMS PROGRAMMERS ACTUALLY HAVE. Java is like a store full of Craftsman tools of every type.. A langauge like Perl is a master lockpicker's toolset... Not much to look at, but get the job done.
So efficiency is no longer a worthy characteristic (Score:4, Interesting)
...marred them with ultra efficient syntax in the name of hardware...
I stopped reading right there.
Re:Quite obviously... (Score:4, Interesting)
Yeah, started as a quick joke, but grew in to an Uncyclopedia article. I'm going to sit down with a cup of tea.
Re:Examples include (Score:5, Interesting)
Which is something that affects every single computation ever done, from meta programming to processor microcode to pen and paper multiplication.
So, yes it is true but also irrelevant.
As is the question of the AC that spawned this debate.
As is the story really (in my very honest opinion). I don't care where the language I program comes from as long as it behaves as I want it to. today languages are designed instead of being engineered. Ok, I'm pretty sure that when some mega corp or institute finds itself in dire need of creating a language, to solve all their computational problems, they will engineer one or design one depending on their needs. Compiler creation guidelines flow freely on the net and are available in books as well, Why wouldn't someone create a new language if he felt like it? And why wouldn't other people adopt it if they felt like it.
Whoever thinks that all technological progress should come out of universities is fooling himself, nothing bad is happening here.