Slashdot Mirror
New Programming Languages Come From Designers
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."
Aren't the basic programming concepts understood and defined now? All a new language can really bring to the table is a different syntax.
The successful new 'languages' these days are those that include a big set of libraries, eg. Java and C#. People use them for the libraries more than the language. Without the libraries Java and C# are nothing more than reinventions of the UCSD p-system.
No sig today...
When someone designs a programming language to solve a problem that they have, they are designing a programming language that will likely solve the problems of a lot of other people (unless you have particularly esoteric problems).
Matz has said that he built Ruby because he wanted a scripting language more powerful than Perl but more object oriented than Python. He solved his own need and that coincided with the needs of other people, making it a popular language.
Design-by-committee languages tend to feel like they've taken a blind guess at what problems need to be solved without consulting the people experiencing those problems.
It's also worth remembering that performance doesn't mean the same as it used to. An Erlang program, for example, typically runs at about a tenth the speed of a C program doing the same thing... when you have one core. On the other hand, it's pretty easy to write Erlang programs that scale up to 1024 processors (I've written Erlang code that, without any special effort, scaled almost linearly when moved from my single-core laptop to a 64-processor SGI machine and the profiling data indicated that the load was still pretty evenly distributed between Erlang processes so going to 512 or more CPUs would have been easy). When even mobile phones are multicore, this matters a lot more than single-threaded performance. There are lots of things in C that make it very difficult to get good performance when you go beyond about 16 threads (e.g. no differentiation between thread-private and shared data, no immutable-after-creation data types) but which were not a problem for single-threaded performance.
I am TheRaven on Soylent News
You should at least provide some arguments as to "why" you think those are bad examples. Otherwise do not be surprised to be modded flamebait.
By "from academia" they probably meant just "pure and untainted by worldly matters".
Some time ago, Pacal and BASIC came from professors and were quite popular until recently.
And this one is undeniably "from academia" in literal sense:
History
The design of Scala started in 2001 at the Ãcole Polytechnique Fédérale de Lausanne (EPFL) by Martin Odersky, following on from work on Funnel, a programming language combining ideas from functional programming and Petri nets.[5][not in citation given] Odersky had previously worked on Generic Java and javac, Sun's Java compiler.[5]
Scala was released late 2003 / early 2004 on the Java platform, and on the .NET platform in June 2004.[3][5][6] A second version of the language, v2.0, was released in March 2006.[3]
On 17 January 2011 the Scala team won a 5 year research grant of over â2.3 million from the European Research Council.[7] On 12 May 2011, Odersky and collaborators launched Typesafe, a company to provide commercial support, training, and services for Scala. Typesafe received $3 million investment from Greylock Partners.[8][9][10][11]
Anyways, it's just too opinionated, from his 4 examples - PHP, JS, Python, Ruby - only PHP and JS are really widespread, with Ruby still rather rare and Python somewhere inbetween.
And then there's this pearl:
the languages designed by academics who are obsessed with internal consistency and correctness include a bunch of mostly dead tongues: Fortran, Cobol, Lisp, C and Smalltalk.
TL;DR: This dude doesn't know shit about history (well, and present as well)
I have programmed professionally in more than 30 languages including machine codes, assemblers, FORTRAN, COBOL, Algol, C,C++, lisp, Prolog, and a variety of "4GL"s. I have used Java and Python since retirement and I can say one thing for sure about them all. Choose the right one for the job and you're half way done, choose (or be forced into) the wrong one and you you are going to pay for it in blood, sweat and eventually tears. On at least two projects (each being more than 50 man years of design and coding effort) it was worth devising a new language with a syntax suited to the problem and writing the compiler. For some jobs, readability of the code by non IT staff can give a huge payoff, for others raw performance is the only criteria. Real time interaction with physical systems usually needs a "lower" level, C or even assembler, Complex data requires object orientated structures and for once off "need it today" jobs, Java might be the answer. Maintainability brings another load of constraints, as does the intended "longevity" of the project, and don't get me started on the whole domain of "proof of correctness".
It is very easy to forget that a language is just a tool. If you only have a hammer you will find screwing a problem, but then you are reading this on slashdot.
nec sorte nec fato
Ideally, programming should be a playground accessible to all, not like today where it's more of a military discipline camp accessible to all.
I very strongly disagree. Good programming can't allow for lack of discipline. People who go for more "elaborate" languages, with loads of libraries available, should be forced to understand what goes on behind the scenes.
I remember a researcher in a biotech company I used to work for, who tried to get help on forums on the Internet, and published parts of her ruby code (she'd had a 4 hour lessons of ruby once at university). The code included (read-only) account passwords to a research database and her own AD password in the company. Plus the variable names left little doubt as to what she was working on at the time.
Bottom line is: she didn't know what she was doing, but someone trusted her with code, and put the company's research at risk. So no, programming is not a playground, it's a serious matter. And as far as you don't understand what a buffer overflow is (and a load of other things), your employer shouldn't allow you to code.
The problem isn't "serious developers", it's those that aren't taking it seriously.
You can take all the precautions you like, but short of getting your own dedicated server and running nothing but your own code (or code you have audited), you are always at risk of the issues introduced by someone else. On a shared host, an exploit in someone elses code is only one local exploit away from your data...
Any Turing complete language provides an infinite number of ways of solving any given problem. The difference between a good language and a bad one is whether the easiest and most obvious way of doing something is the correct way. The existence of things like register globals and magic quotes that can only be used incorrectly is a good sign of poor design.
I am TheRaven on Soylent News
I did not advocate abolishing good coding practice or the "hard" languages, or intelligent thought.
I mean there ought to be a programming language my little sister could use casually. An intially level and smoothly steepning ramp to ease users into the world of coding. Not the current case where it's pretty much a solid veritical wall that is only slowly chipped down.
Example of inexperienced people doing stupid thing with professional grade stuff is common, your example is equivalent to some dense person in a workshop that ruins some woodworking tool by putting metal it in. Which is not an argument for banning all entry grade powertools. It's just an anecdote about a stupid guy, or girl in your case.
"There are lots of things in C that make it very difficult to get good performance when you go beyond about 16 threads"
What on earth are you on about? The language has nothing to do with threading, thats down to the OS. The pthreads API on unix scales to any number of threads and if the threads arn't being spread evenly among cores than thats down to a problem in the OS kernel , not the C library.
Also I suspect Erlang is a managed language and would therefor probably be pretty hopeless when used for multi process as opposed to multi threaded.
Dude, Sean, chill. You thought way to hard about that.
Admit nothing. Deny Everything. Make Counter-accusations.
Come on Raven, this isn't even an argument. The two settings you talk about had a reason to be there, they provided functionality. Sure it is common sense now that this type of functionality has way too many drawbacks and this is why it is being iterated out of the language. All I see being talked about in this whole thread is features of languages that when used by some half informed programmer can have a bad effect.
Dear everybody: Please, get over it. Every language will bite you in the ass if you are going to create a big enough program in it. Every C writer in history has at some point written a buffer overflow, every code monkey an SQL injection, every rails genius a mass assignment vulnerability and don't even get me started on MicrosoftLand...
The fact of the matter is this: "It's not the language it is the DEADBEEF in front of the keyboard."
-- no sig today
No, it's not irrelevant, infact it's as far from irrelevant as it's possible to be.
You can use all the correct methodologies you want, but if you haven't secured the environment then you are trusting everything else to be correctly coded.
Now, with OSes etc that's always going to be a factor to a degree, but the situation here is when you are trusting every other developer hosting their code in a shared platform - in that case you can do everything correctly, you can use PDO, you can turn off Globals, but you can't trust someone else to have done the same.
So its utterly relevant that the issue is not just applicable to "serious developers", it's the 14 year old who has banged something out before bedtime and uploaded it to their host - a compromised account is still a compromised account, whether it's a "serious developers" account or not, and their compromised account can expose your data without you ever doing anything wrong (other than picking a bad shared host).
The problem isn't people creating new languages, its people creating new languages with gaping holes to start off with - register Globals should have been rejected from the outset, instead it became ingrained into the language to the point where it's taken a decade to get rid of it in the latest versions.