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."
All you need to create a good programming language is a beard. The more epic the beard, the better your language will be
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.
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.
>under the premise that new languages don't come from academia
http://en.wikipedia.org/wiki/Guido_van_Rossum :
>Van Rossum was born and grew up in the Netherlands, where he received a masters degree in mathematics and computer science from the University of Amsterdam in 1982. He later worked for various research institutes, including the Dutch Centrum Wiskunde & Informatica (CWI), Amsterdam, the United States National Institute of Standards and Technology (NIST), Gaithersburg, Maryland, and the Corporation for National Research Initiatives (CNRI), Reston, Virginia.
Wrong premise.
http://en.wikipedia.org/wiki/Yukihiro_Matsumoto
>He graduated with an information science degree from University of Tsukuba, where he was a member of Ikuo Nakata's research lab on programming languages and compilers.
Again wrong premise.
Aren't the basic programming concepts understood and defined now? All a new language can really bring to the table is a different syntax.
If you really believe this, then you've been stuck in Algol-derivative land for far too long.
I am TheRaven on Soylent News
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
"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.
SJW n. One who posts facts.
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.
The article seems to ignore modern compiled (and carefully crafted) languages like Scala, Limbo, Go and tries to criticize the wide adoption of scripting languages among people who aren't really pure developers (as if they mattered!) and those developers who value development speed over quality, maintainability and performance or in places where network and/or human input latency abolish any other performance concern.
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?
"I love my job, but I hate talking to people like you" (Freddie Mercury)
Good grief, what a profound misunderstanding of the entire field this post represents.
If you have an interest in this field, you need to spend some serious time with Haskell and LISP before you even begin to think about writing longwinded comments about how all languages are fundamentally the same.
It is trivially true that any program you can write in [language X] you can also write in assembler, and therefore C. If the entire field of programming languages could be summarized like this, why aren't we all using assembler?
The insight only comes when you understand this thing called "abstraction" and why it's useful. There is a reason I use Django templates, and don't usually write HTML-producing code in C. There is a reason I use LISP when I'm doing natural language processing. I can do more work in one line of Python than you can do in 100 lines of C. The right language for the job can make two orders of magnitude difference in productivity. If you don't understand that, please, STFU.
You've never been to a Rails convention have you?
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.
No. As a woman, I'm pretty sure I'm not allowed to attend.
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.
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.
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.
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.
Really? Because I've worked on several C compilers, and that's not something I've ever seen. Unless you're talking about SSA form, in which case you're wrong on several counts. First, GCC does use SSA form and has for about five years. Second, SSA form is usually quite restricted: memory is not SSA, for example, so it's not very like a functional style at all. I'm not even going to talk about your conflation of vtables with object orientation.
I am TheRaven on Soylent News
"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.
What on earth are you on about? The language has nothing to do with threading, thats down to the OS
Nonsense. Well, sure, if you have 1024 threads doing totally unrelated things then the language doesn't matter, but then you may as well be using separate OS processes and getting some isolation for free.
Back in the real world, threads need to communicate and they need to share data. How the language represents this has a massive impact on scalability.
I am TheRaven on Soylent News
C was widely used because it was well supported on all platforms and had extensive libraries ..
C++ see above (and the syntax is similar to C)
Java - See above for cross platform (and the syntax is similar to C/C++)
JavaScript - See above for Web-browsers (and the syntax is similar to C/C++/Java)
C# See above (for Windows and some other systems) (and the syntax is similar to C/C++/Java)
Do you see a pattern here, can I learn a language similar to what I already know, that will be well supported on the platform I am using, and will have all the libraries I will need ...
Languages that are better in every respect will fall by the wayside if they don't meet these criteria regardless of how much better they are ...
C and it's descendents are not the universal perfect language that people suppose, they are just popular, and now are just popular because they are near ubiquitous ...
Puteulanus fenestra mortis
I disagree. For me, there are three important points to discuss programming languages:
1. Syntax
2. Access
3. Community
ad 1) We know all about and can analyse the syntax. Fine. All the discussion happens here. .NET lacks here, and massively because there is no spirit to make libraries available to others for free causing a non-availability of free libraries.
ad 2) But what does the finest Haskell help me if I can't access a CD, Bluetooth or a XMPP server, and whether it makes a difference where I want to run the code (web server, mobile phone, mainframe, laptop). In principle, all languages are Turing-complete and equivalent, and I can write wrappers between languages, but as long as I can't *practically* do all the things I need, I'm stuck. The available libraries/access methods draw a picture of what is possible. Here C due to its age, Java with it's tendency to make package that are reusable and Python are among the best (from my experience). As an aside,
ad 3) A language is also dominated by its users. This is most noticable with PHP. The background of users dominates what a language should do. Also, this determines the amount of help and easy-to-access documentation. Which again makes a language popular or not.
One individual is not capable of addressing (2). Also, whether a language is picked up by the masses (3), or whether you can build and hold this community, is not a rational, predictable process. When designing a language, you don't have full control over success.
When comparing two languages, don't just look at (1), also look at (2) and (3).
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
The big advantage of C++ over C is resource management (using "RIAA").
I think you meant RAII (resource acquisition is initialisation), also known as SBRM (scope-bound resource management). The RIAA would just disable all your copy constructors to stop copyright infringement.
...marred them with ultra efficient syntax in the name of hardware...
I stopped reading right there.
Register_globals was completely removed in the latest PHP version out in the world a couple of days ago
I'm positive, don't belive me look at my karma
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.
-- no sig today
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
1) Some programming languages are great for all the code you have to write. They are very powerful, very expressive, high performance, etc etc.
2) Other programming languages are great for all the code you DON'T have to write! They have lots of _good_ well documented standard or defacto standard libraries, modules, so you don't actually have to write stuff for a lot of things.
Being a crappy lazy programmer I prefer languages that satisfy both 1) and 2), but with 2) as a priority. Because I end up having to write a lot less and it's not my responsibility to document, support and fix those libraries. Yes I may have to fix or workaround some of the library bugs, but it's not really my job...
The good libraries are written by programmers far better than me, so if I use their stuff instead of reinventing it, it means fewer bugs and higher quality.
Of course, if you are a great programmer your priority would be 1). 2) only being a minor factor.
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.
Of course they're not magic. But they offer abstractions which are very different to what C offers. Haskell's type system in particular needs to be studied to really understand what I'm talking about - if you think functional languages are only about list processing you're just reading the back of the cereal packet.
You must be a pretty lousy C programmer then.
Indeed, I only have 22 years of experience with that language and its successors.
Of course you can write your 100 lines of C in a library and say "hey, I'm only calling a library", but in Python what you can do in one line of ad-hoc code can take 100s of lines of ad-hoc C code. Look up list comprehensions. And yes, eventually a library interprets those, but high-level languages allow you to escape the bounds of that kind of thinking (all programs reduce to how they execute) and think in terms of higher-level abstractions. And that is the whole point which the "everything boils down to C eventually" argument misses.
4. IDEs and tools
Does it have a wysiwyg gui designer?
Can I hotswap code during debugging?
Refactoring?
Can I get documentation on a function just by hovering my mouse over it?
Are there automated bug finders?