Forgot your password?
typodupeerror
Programming Education

New Programming Languages Come From Designers 435

Posted by Soulskill
from the sprung-fully-formed-from-their-beards dept.
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."
This discussion has been archived. No new comments can be posted.

New Programming Languages Come From Designers

Comments Filter:
  • Doomed (Score:2, Insightful)

    by Joce640k (829181) on Wednesday March 07, 2012 @06:34AM (#39273007) Homepage

    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.

  • Re:Doomed (Score:2, Insightful)

    by ledow (319597) on Wednesday March 07, 2012 @07:00AM (#39273103) Homepage

    This.

    Pretty much, after you learn your second or third programming language, they are all pretty much the same. There are some oddball ones for very specific purposes (e.g. PROLOG), but pretty much they are all the same things with different syntax and different libraries.

    Some of them are slightly more suited to different tasks (e.g. LISt Processing, etc.) but there's really not much to choose between them. I'm not a fan of the newer languages - anything that LOOKS like gobbledegook from a distance usually does a good job of masking gobbledegook close-up. Just looking at some of the Ruby examples on the Wikipedia page makes my programming-mind want to vomit. I find C++ quite obtuse too. C99 is pretty much the best compromise that I've found between gobbledegook and flexibility.

    Does your language compile to the target? Does your language run and compile from your development host? Does your language enable you to do the things you want without unnecessary hindrance? Almost every programmer who chooses a language asks themselves that and if they aren't satisfied it's true, will move to something else.

    To an extent, OOP is just a formalisation of things that function programmers have been doing for decades into a space-saving syntax. Similarly for other "paradigms" of programming. In the end, the compiler still has to squeeze it all into the same instruction set and it's just whether it bothers to check for over-runs, abstract away certain details, make certain optimisations, etc. that makes any difference. The end code is usually pretty indistinguishable.

    This is my answer when someone wants to choose a language to "start programming": Any of them. It doesn't really matter. Probably good to start with something you can understand immediately but it really doesn't matter what you do it in. It's like a child who's started learning to speak wondering what language they should speak - whatever is available, practical and you can manage.

    Programming is communication of some instruction to the computer, that's why we call them "languages". What language you use is merely a practical consideration (i.e. verbosity, popularity, availability, what others can understand, etc.) that's pretty much made for you. Some languages aren't available, don't have a compiler (only an interpreter), need external libraries for everything, aren't cross-platform, etc. Beyond that, the only thing that matters is the message - the program itself - not the language.

    Since I was a teenager, I thought of writing my own language that would pick bits I like out of each language and merge them. It would just create a hideous mess, of course, but if I've considered it, it usually means lots of other people have done it before me. Any language that purports to be the collation of the good points of others will be regarded by everyone else as a collation of the bad points of everything else.

    A one-man language isn't, in and of itself, a bad thing. The problem comes when it literally does nothing you can't already do, albeit with slightly different syntax and slightly more work.

    Basically, if you wanted, you could rewrite a C pre-processor to compile any of those languages directly to C syntax, and vice-versa. There's nothing "new", just some "shiny" things.

    Things haven't moved on since C, really. Sure, we've prettied up the syntax, clarified some edge-cases, added some libraries, etc. but it's all just spit-and-polish on a language made in the 60's. The fact we use those slightly-cleaner versions for the vast majority of software today (including the compilers of most of those other languages) means that there really wasn't any huge paradigm shift, or change in the way we work, or need to move on.

    The only thing I think might change the way we work in quantum computing. That's going to need a serious rethink and redesign in order for people to "program" them effectively. But, you know what? I have a suspicion that the first practical languages for that will be "C with knobs on".

  • Re:Doomed (Score:5, Insightful)

    by TheRaven64 (641858) on Wednesday March 07, 2012 @07:05AM (#39273125) Journal

    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.

  • by jholyhead (2505574) on Wednesday March 07, 2012 @07:06AM (#39273129)
    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.
  • by TheRaven64 (641858) on Wednesday March 07, 2012 @07:10AM (#39273149) Journal
    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.
  • by freedumb2000 (966222) on Wednesday March 07, 2012 @07:18AM (#39273181)
    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.
  • Re:Wrong premise (Score:5, Insightful)

    by Anonymous Coward on Wednesday March 07, 2012 @07:19AM (#39273191)

    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)

  • Re:Doomed (Score:2, Insightful)

    by aaaaaaargh! (1150173) on Wednesday March 07, 2012 @07:20AM (#39273201)

    Aren't the basic programming concepts understood and defined now?

    Not when it comes to parallel programming with the inherent synchronization issues. Particularly the attempts to automatically parallelize seemingly sequential programs are still in their infancy and even if these are more problems of compiler optimization these need a certain amount of support in the core language such as immutable data structures in the right place or a particular synchronization model.

    But yeah, it is annoying that many recent languages are worse than what was there before in terms of readability, security, or practical expressivity. I'm not a big fan of Ada because of its sometimes arcane syntax and its verbosity, but you've got to admit that many modern languages barely have half of its features. Or, take those languages who shall remain unnamed whose inventors try to sell dynamic scoping as a good thing (whereas in reality they were probably just unable or too lazy to implement lexical scope).

    That being said, in the end it's the libraries that count, and another big problem is that libraries are constantly being rewritten for each language or interfaced from inherently buggy and unsafe languages like C and C++. It's understandable and somewhat unavoidable but still idiotic.

  • Re:Doomed (Score:5, Insightful)

    by Anonymous Coward on Wednesday March 07, 2012 @07:27AM (#39273227)

    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.

  • horses for courses (Score:5, Insightful)

    by HarryatRock (1494393) <harry.rutherford@btinternet.com> on Wednesday March 07, 2012 @07:32AM (#39273243) Journal

    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.

  • by alex67500 (1609333) on Wednesday March 07, 2012 @07:34AM (#39273249)

    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.

  • Re:Doomed (Score:3, Insightful)

    by Nursie (632944) on Wednesday March 07, 2012 @07:47AM (#39273309)

    C/C++ inherently buyy and unsafe?

    No more buggy than code written in any other language, and only unsafe in the hands of people that don't know what they're doing. Arguably these people shouldn't be allowed near any programming language anyway.

  • by Richard_at_work (517087) <richardprice&gmail,com> on Wednesday March 07, 2012 @07:55AM (#39273355)

    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...

  • Re:Doomed (Score:1, Insightful)

    by Viol8 (599362) on Wednesday March 07, 2012 @07:59AM (#39273381)

    "Haskell and LISP"

    Functional and list processing languages are not magic despite what the fanboys would have us believe. And if they were the best solution on a day to day basis they'd be used far more often than they actually are.

    "I can do more work in one line of Python than you can do in 100 lines of C"

    You must be a pretty lousy C programmer then. Python may be higher level than C but its not THAT mush higher.

  • by TheRaven64 (641858) on Wednesday March 07, 2012 @08:09AM (#39273409) Journal
    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.
  • by durrr (1316311) on Wednesday March 07, 2012 @08:09AM (#39273413)

    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.

  • by Viol8 (599362) on Wednesday March 07, 2012 @08:17AM (#39273453)

    "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.

  • Re:Doomed (Score:4, Insightful)

    by JasterBobaMereel (1102861) on Wednesday March 07, 2012 @08:33AM (#39273543)

    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 ...

  • Re:Doomed (Score:5, Insightful)

    by buchner.johannes (1139593) on Wednesday March 07, 2012 @08:38AM (#39273593) Homepage Journal

    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.
    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, .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 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).

  • Re:Doomed (Score:3, Insightful)

    by Joce640k (829181) on Wednesday March 07, 2012 @08:51AM (#39273689) Homepage

    Just because it can be done, doesn't mean you should do it.

    Most arguments against C++ are of the "Look, I can do this and it's bad!!!" type. Real C++ programmers just ignore them and carry on writing code which doesn't do that.

    Yes. C/C++ are inherently predisposed towards being buggy and unsafe, relative to more modern languages. They trade runtime checks for minimal runtime overhead (and I'm not saying that's a bad thing), but they don't make any effort to assist the programmer in the area of code correctness.

    Modern C++ implementations usually have run time checking on by default. eg. In Visual C++ std::vector checks the range of all indices to see if they're legal. If you do C++ right then the only memory error you'll is a null pointer (just like super safe Java).

    C++ isn't problem-free, but all the old mid-1990's arguments aren't applicable any more, sorry.

    PS: C and C++ are completely different languages, writing "C/C++" only shows your ignorance.

  • by f3rret (1776822) on Wednesday March 07, 2012 @08:53AM (#39273705)

    Dude, Sean, chill. You thought way to hard about that.

  • by justforgetme (1814588) on Wednesday March 07, 2012 @09:39AM (#39274063) Homepage

    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."

  • Re:Doomed (Score:5, Insightful)

    by TheLink (130905) on Wednesday March 07, 2012 @09:55AM (#39274207) Journal
    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.
  • by Richard_at_work (517087) <richardprice&gmail,com> on Wednesday March 07, 2012 @09:56AM (#39274215)

    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.

  • Re:Doomed (Score:3, Insightful)

    by Anonymous Coward on Wednesday March 07, 2012 @10:09AM (#39274351)

    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.

  • Re:Doomed (Score:4, Insightful)

    by im3w1l (2009474) on Wednesday March 07, 2012 @10:24AM (#39274485)
    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?

Never invest your money in anything that eats or needs repainting. -- Billy Rose

Working...