Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming

6 Languages You Wish the Boss Let You Use 264

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."
This discussion has been archived. No new comments can be posted.

6 Languages You Wish the Boss Let You Use

Comments Filter:
  • by burris ( 122191 ) on Wednesday October 15, 2008 @03:50PM (#25388195)

    All of the up and coming languages cited in the article are dynamically typed, interpreted (or bytecode-interpreted) languages.

    scala and f# are both statically typed

  • by LarsWestergren ( 9033 ) on Wednesday October 15, 2008 @03:57PM (#25388339) Homepage Journal

    All of the up and coming languages cited in the article are dynamically typed, interpreted (or bytecode-interpreted) languages.

    Incorrect. Scala is very much statically typed (but has type inference).

    Besides, what an article in a magazine considers hypeworthy may not correspond to real world usage. There are many opionions in the article put forward as facts.

  • How about... (Score:3, Informative)

    by Minwee ( 522556 ) <dcr@neverwhen.org> on Wednesday October 15, 2008 @04:10PM (#25388571) Homepage

    "Six Languages You Wish The Yo-Yo Who Got Fired Before You Had Never Used"?

    We could start with "Incomprehensible" and "I'm Just Learning This" and go on from there.

  • by Anonymous Coward on Wednesday October 15, 2008 @04:36PM (#25389145)

    Scala is a statically typed language with support for functional programming with anonymous functions and closures as well as type inference. It is not, however a dynamic language like Groovy. Nor did the designers ever intend it to be.

  • Re:LOLCODE (Score:2, Informative)

    by Anonymous Coward on Wednesday October 15, 2008 @04:43PM (#25389253)

    The sad part is, that's a real language. Someone wrote a BF compiler in LOLCODE(http://forum.lolcode.com/viewtopic.php?id=51).

  • by Frater 219 ( 1455 ) on Wednesday October 15, 2008 @08:30PM (#25392809) Journal

    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.

  • Prolog imperative? (Score:2, Informative)

    by Enter the Shoggoth ( 1362079 ) on Thursday October 16, 2008 @06:36AM (#25397195)

    I've worked with well over 30 languages in the last 20 or so years, covering the entire gamut you describe and not once have I ever seen Prolog referred to as imperative.

    Prolog is a declarative language (making it a cousin of functional languages) based on the resolution of horn clauses.

    Imperative languages are based upon the idea of destructive update of state, echoing the Von Neumann architecture of the machine upon which they likely run.

    In other words, on a diagram of programming language paradigms they are most likely polar opposites.

    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.

  • by pthisis ( 27352 ) on Thursday October 16, 2008 @10:15AM (#25399433) Homepage Journal

    Exposure is fine, but "at least a project or two"?

    A project or two seems about the minimum to learn a language. It's pretty much impossible to really learn a language without writing _something_ in it.

    How many production projects in Eiffel, or Sather, or Ada, or Erlang, have you, or at least some people you know personally, taken part in?

    This seems like a strawman; most learning projects are a lot smaller than anything production (e.g. compare your compiler design class in university with gcc).

    The point of learning a lot of languages is mainly for exposure to multiple programming paradigms (hence why I split things up that way). Even if you never use the language itself at work, it's a lot easier to get your head around, say, functional programming by going through ML culture shock than trying to write a functional program in Java when you don't really know what that means. Once you know it, you can do it in any language.

    But to answer the question:
    I know dozens of people who are working (or have worked) on Ada projects, and I've done so in the past.

    One of our developers left our company 3 months ago to work on a commercial Erlang product, making him the 2nd I know, and we're considering using it at my current workplace.

    I don't personally know anyone using Sather or Eiffel commercially.

Happiness is twin floppies.

Working...