Slashdot Mirror


6 Languages You Wish the Boss Let You Use

Esther Schindler writes "Several weeks ago, Lynn Greiner's article on the state of the scripting universe was slashdotted. Several people raised their eyebrows at the (to them) obvious omissions, since the article only covered PHP, Perl, Python, Ruby, Tcl and JavaScript. As I wrote at the time, Lynn chose those languages because hers was a follow-up to an article from three years back. However, it was a fair point. While CIO has covered several in depth, those five dynamic languages are not the only ones developers use. In 6 Scripting Languages Your Developers Wish You'd Let Them Use, CIO looks at several (including Groovy, Scala, Lua, F#, Clojure and Boo) which deserve more attention for business software development, even if your shop is dedicated to Java or .NET. Each language gets a formal definition and then a quote or two from a developer who explains why it inspires passion."

22 of 264 comments (clear)

  1. Language Independent? by Beardo+the+Bearded · · Score: 4, Insightful

    Your programming skills should not be tied to the language you use.

    --

    ---
    ECHELON is a government program to find words like bomb, jihad, plutonium, assassinate, and anarchy.
    1. Re:Language Independent? by dedazo · · Score: 5, Insightful

      Agreed, but even assuming you can become proficient in a given language quickly, there's usually a huge learning curve associated with the library(ies)/runtime. Not to mention the amount of time needed to arrive at the "this is how you actually do it" point for any language.

      I can write a 20-line utility script in Perl or Scheme just fine. Applications are another matter.

      --
      Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
    2. Re:Language Independent? by quanticle · · Score: 4, Insightful

      While your skills should certainly be language independent, it is also true that different languages make different things easy. Otherwise, why would we have so many of them?

      I think the main thing I see is that the old argument, "Scripting languages are far too slow!" has finally been put to rest. All of the up and coming languages cited in the article are dynamically typed, interpreted (or bytecode-interpreted) languages.

      --
      We all know what to do, but we don't know how to get re-elected once we have done it
    3. Re:Language Independent? by steveha · · Score: 4, Insightful

      I think the main thing I see is that the old argument, "Scripting languages are far too slow!" has finally been put to rest.

      Well, that was always an oversimplification anyway. Too slow for what, specifically?

      Even today, no one would seriously think about writing a video encoder entirely in a dynamic interpreted language. That's a very compute-intensive application and you can't afford the overhead. But how many of us write video encoders? There are many tasks for which the overhead of a dynamic interpreted language is no big deal.

      Computers are really fast these days, so you can afford some overhead. If your trivial program runs in 0.6 seconds instead of 0.01 seconds, you may not care about the difference. And if you can write your program in 1/10 the time, you may come out way ahead. (And if the program is a one-off, that only needs to be run a few times, all you really care about is how much of your time it took to write the thing and get it correct.)

      steveha

      --
      lf(1): it's like ls(1) but sorts filenames by extension, tersely
    4. Re:Language Independent? by zullnero · · Score: 4, Insightful

      I had this discussion with a recruiter the other day that was adamant about me inserting every single language and tool they wanted into every job description I had.

      I said "the situation is very much like a mechanic where I have a wide range of tools I use to solve a problem, but the only thing that anyone cares about is that at some point, I used a wrench for something...without really caring about what the problem actually was."

      Anyone can sit down, surf the web, find some sample code, stick it into a project, and then site that you used said tool in your resume...but it's not about that, it's about how you solved that problem.

    5. Re:Language Independent? by Fred_A · · Score: 4, Funny

      Your programming skills should not be tied to the language you use.

      Quite. I use harsh language and it hasn't interfered with my programing skills whatsoever.
      Stupid git.

      --

      May contain traces of nut.
      Made from the freshest electrons.
    6. Re:Language Independent? by Frater+219 · · Score: 5, Insightful

      Your programming skills should not be tied to the language you use.

      Anyone who thinks this doesn't know very much about the diversity of programming languages, I suspect.

      What you say may be true about a restricted set of languages: I would expect a good C++ programmer to be readily able to learn C# or Java; likewise I would expect a Python programmer to be readily able to learn Ruby. But that's because C++ and Java are not very far apart, nor are Python and Ruby.

      But there are plenty of good C++ or Java programmers who would be completely lost in Lisp or Haskell. Why? Because a good Lisp or Haskell program does not break the problem down along the same lines as a good C++ or Java program. They involve a different set of skills. C++ coders do not tend to think of programming as extending the language to fit their problem space; they do not tend to use higher-order functions; they do not necessarily isolate I/O from core algorithm as Haskell programmers must; and they don't have access to anything even remotely resembling Lisp macros.

      Now, you might say that a person is not a good programmer unless they have mastered a wide range of languages with vastly different approaches. But that's a much higher bar than most folks would use to qualify programmers.

    7. Re:Language Independent? by 0xABADC0DA · · Score: 4, Interesting

      However, if I wrote any sort of interactive application, a scripting language would not be my first choice. To me, it basically boils down to this: a "job" that cranks off, does it's own thing, and then ends, is a very good candidate for a scripted language. For an "application", I'm probably going to crack out C or C++ to tackle that one.

      And I completely disagree about GUIs. The only requirement on language choice for an application is that user interaction happen in ~0.1 seconds or less, and on today's computers scripting languages can do this easily. So with that out of the way the choice is on how easy it is to write, how nice it looks, how reliable it is, etc. And in these categories scripting owns C, C++.

      A lot of great programs are being written in JavaScript or Python these days. For instance, MusicBrainz' Picard is written in python, but you would never know it from using it. Even ones that are supposed to be 'fast'... users don't notice a performance difference between mercurial (python) and svn (c), but mercurial is already light-years better because people can understand the code (svn sourcecode is an absolute disaster re: readability).

      I would go so far as to say that the primary reason to write most GUIs nowadays in C or C++ is just so they can't be reverse engineered.

    8. Re:Language Independent? by Frater+219 · · Score: 4, Informative

      There are not just two kinds of programming languages. There are a whole bunch of different features that languages can have, that affect how programmers think about problems. I mentioned a few of them above, but consider:

      Extensible syntax. Some programming languages have extensible syntax; they allow you to define macros or "parsing words" that act like new syntactic constructs. Lisp is the usual example here, but some of the stack-based languages, like Factor, also have this property. C++, Java, and Python do not have it. Extensible languages allow programmers to create embedded domain-specific languages, moving the language's syntax closer to that of the problem domain.

      Type system differences. This isn't just static vs. dynamic typing, either. In Haskell, you create types that describe the meanings of the values your program will manipulate. In contrast, C++ programmers usually use types just to describe the implementation of data structures in memory. In Common Lisp you can talk about "the type composed of integers from 0 to 10".

      Density and function length. Languages that are very dense and do not have a lot of syntactic sugar tend to encourage very small functions. Languages that are more verbose tend to encourage longer functions, if only because it takes more words to get an idea out.

      Object system. There are many kinds of object-oriented languages: prototype-based ones like JavaScript, static ones like C++, multiple-dispatch ones like Common Lisp, and so on. Interfaces? Multiple inheritance? Mixins? Around methods? MOP? The presence or absence of these features greatly influences how you can use objects in a program.

      These are not minor differences. They dramatically change the way that you have to approach problems in order to write good code in a language. If you write Common Lisp as if it were C++, you are going to be producing bad code. If you write functions in Haskell that are as long as the ones you'd write in Java, you are going to produce incomprehensible code.

  2. Vulgar language. by Trespass · · Score: 4, Funny

    Oh, you meant programming. Well, fuck it. =P

  3. Language Independent! by krischik · · Score: 4, Insightful

    Right on! A good programmer will learn any programming language in a fortnight. But sadly average programers don't.

    1. Re:Language Independent! by pthisis · · Score: 5, Interesting

      I'd consider the minimum for a really good programmer to include at least a project or two's worth of exposure to:

      At least one assembly language or pseudo-asm.
      At least one mid-level pointer-driven language (C/C++/etc)
      At least one statically typed functional language (ML/Haskell/etc)
      At least one dynamically typed functional language (Lisp/Scheme/etc)
      At least one dynamically typed OO language (Smalltalk/Python/ruby/etc)
      At least one higher-level statically typed OO language (Java/Ada/C#/etc)

      That still leaves some holes that could be tricky to pick up, and ideally you'd know:
      At least one stack-based language (Forth/Postscript/etc)
      At least one imperative programming language (Prolog/etc)
      At least one DBC-centered language (Eiffel/Sather/etc)
      At least one concurrency-oriented language (erlang, etc)

      But you can have a long and successful career as a top-shelf programmer without really needing that latter group.

      And yes, those monikers are a bit arbitrary; you can do full OO in Lisp, functional programming in Python, etc. So you can get away with a lot fewer languages than there are on the list, as long as you learn the different programming models. It tends to be a little easier to learn a model with a language that's been used that way traditionally.

      I'm sure I'm missing some areas, too.

      --
      rage, rage against the dying of the light
    2. Re:Language Independent! by arevos · · Score: 4, Insightful

      I'd consider the minimum for a really good programmer to include at least a project or two's worth of exposure to...

      I'm familiar with languages in all those categories, but I wouldn't consider them all essential. It's important to have a wide range of experience outside the norm, if only because it demonstrates an enjoyment of learning new things. But I don't necessarily think that a programmer's experience needs to be comprehensive for them to be good at their craft.

    3. Re:Language Independent! by Eskarel · · Score: 4, Interesting
      This is true, but totally beside the point.

      Learning a new language involves lost productivity, and if you choose a language that isn't in mainstream use it will involve lost productivity for everyone you hire to use it.

      Generally speaking new languages don't offer enough benefit over the old languages to justify that expenditure.

      It's the thing everyone always forgets, even if learning something new is easy, the new thing has to be sufficiently better than the old thing to justify the learning.

      Boutique languages are almost never a good investment because even if you hire a programmer who loves to learn the liklihood that they've learned any particular language is fairly low. Languages become popular not because they are superior in any technical sense, but because they provide a benefit for a project which outweighs the investment cost.

      Just because a programmer can learn a language doesn't mean it makes financial sense for them to do so on company time.

    4. Re:Language Independent! by Smallpond · · Score: 4, Funny

      It must be true that this takes time. I've been programming in Perl for years and have yet to learn anything about the compiler.

  4. Let me see... by R2.0 · · Score: 5, Funny

    Klingon, Swedish Chef, Elvish (can't pronounce Dwarvish), Pirate, Porn Star Dialogue, and Latin.

    --
    "As God is my witness, I thought turkeys could fly." A. Carlson
  5. The Tags say it all. by Anonymous Coward · · Score: 5, Funny

    donotwant developers programming

    Sounds like the corporate policies I've gotten used to.

  6. Wait and see. by LWATCDR · · Score: 5, Insightful

    I remember when ADA was going to be the next big thing. Then it was SmallTalk. I actually used Modual-2 back in the day. C? was never going to take off. It was too big and slow for micro computers and not high level enough for minicomputers. The only people that would ever really find use for it where those few people that used Unix.
    Before that it was PL-1 and Simula. I left out the fourth generation languages that where going to let everybody write their own programs. Oh and programing by making flow charts... Or was it Hypercard that was the future...
    Well you get the idea. Most where really good programing languages but there seems to be a limited number of languages that reach critical mass. I remember Comal which was a great little language on the old 8 bit machines but it only became popular in Europe.
    Oh well we will see what happens this time.

    --
    See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
  7. The lost art by Alzheimers · · Score: 4, Insightful

    If you can't write it in a .BAT file, it can't be done.

  8. LOLCODE by Shikaku · · Score: 5, Funny

    HAI
    CAN HAS STDIO?
    I HAS A VAR
    IM IN YR LOOP
          UP VAR!!1
          IZ VAR BIGGER THAN 10? KTHX
          VISIBLE VAR
    IM OUTTA YR LOOP
    KTHXBYE //outputs 1-10

    1. Re:LOLCODE by paulthomas · · Score: 4, Funny

      OMG WAU!!! U CAN HAS javascript implementashun!!

      JAVASCRIPT VERZHUN moer liek:

      HAI
      CAN HAS STDIO?
      I HAS A VAR IZ 0
      IM IN YR LOOP
                  UPZ VAR!!1
                  IZ VAR BIGR THAN 10?
                                  GTFO.
                    KTHX
                  VISIBLE VAR
      KTHX
      KTHXBYE

      Javascript Lolcode Inturpretur.

      KTHXBYE, WTFBBQ!

      *ducks*

  9. Groovy by lgbr · · Score: 4, Interesting

    I wasn't sure what I was getting into when I had asked a programmer to replace our crummy Jython interface with Groovy. Ten minutes after I had asked him to do it he says he's done. He shows me a clean interface complete with the functionality for saving files, copying and pasting, search and replace, and a handy output section. I had even asked him to integrate it with the rest of our program, but a simple 'import com.ourcompany.ourproduct.package' in the groovy console already had that solved. Now development has sped up slightly as we even do some development in the groovy console so that small tweaks and changes don't mean we have to wait for a re-compile.

    I am one boss who welcomes groovy.