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."
scsh and BeanShell (Score:1, Interesting)
scsh [scsh.net] and BeanShell [beanshell.org] are both scripting languages that are pretty cool, the first uses Scheme and the second uses Java.
Re:Language Independent? (Score:3, Interesting)
Indeed but I can understand what the article might be getting at without having read it yet.
It's always best to use the best language for the job and far to many Java or .NET shops will use Java and .NET for everything even when there are much better tools for the job. It's a problem that arises time and time again and it took some time to convince many C++ developers that whilst C++ could do everything it wasn't necessarily best for everything.
If the article is suggesting these languages should be used for the sake of being used then that is rather daft and I don't know why we see many blogs like this (e.g. "Use F# it's awesome!"- well no, it's not in every scenario). If however it's suggesting that these languages each have a specific niche that it should be used for where it beats the likes of Java/.NET then yes he's on to something.
There's always a balance of course, a project consisting of 20 different languages would also almost certainly be rather stupid and messy, but there's a balance to strike for sure to achieve maximum efficiency, stability and features and in some cases there is merit in using more than one language.
Re:Scripting Languages? (Score:3, Interesting)
Furthermore, I wish my job was to sit around all day and learn only new stuff each day../
I used to have that job, writing for a magazine. I was really excited about it at first, but I quickly realized that to write intelligently about a technology you have to get to know it by using it in the real world, which simply takes time. I found that I simply couldn't get to know some new piece of hardware of software well enough to write anything decent about it before my article deadlines, and I felt I was getting dumber every day. So I went back into the programming and sysadmin world and now I feel like I know what I'm doing again (at least with the technologies I use regularly).
I think Lynn Greiner may be in the same boat. She asks:
CIO.com: What effect has the growing prevalence of Ajax had on the adoption of the various languages? Are people adapting the techniques to languages other than JavaScript?
The question doesn't really make sense. If you know what Ajax is, you know it's specific to the web browser/web server model. It solves the problem of the web server not knowing the full state of the browser. Rather than having the server regenerate an entire page and try to preserve client-side changes to that page, Ajax is simply a standard to let the browser get data from the server without reloading the entire page. Maybe it sort of makes sense if you use a client/server model with some other language (like tcl/tk), but then you have access to TCP/IP libraries and the command line. Ajax is only necessary because browsers can't just let a client open arbitrary TCP streams and run arbitrary commands. If it could, there would be a million different ways to do the same thing easily (think wget | grep | cut | sed | ...).
The people she interviewed seemed to agree with me:
Boyd:... The techniques of Ajax are really only applicable inside the browser.
Dice: Ajax is entirely a JavaScript phenomenon
Holden: Since Ajax is simply asynchronous network calls, it is not affecting the adoption of any specific language beyond more JavaScript usage in webpages.
Lam: Ajax is popular because browsers are popular. JavaScript's popularity is directly tied to the fact that it's deployed on virtually all browsers today.
Pall: Ajax is a very specific technology that allows webpages to rise above mediocre user-interfaces and become true applications using JavaScript.
I think Lam's comments are the most interesting. JavaScript isn't a horrible language, and it should get credit for helping people realize that useful things could be done in interpreted languages, but aren't we all really itching for a better language on the browser. Too bad the W3C moves at a sails pace and Microsoft and Mozilla disagree on things simply to disagree with each other half the time.
Re:Language Independent? (Score:5, 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.
Re:Language Independent? (Score:2, Interesting)
You forgot to give a clear example of what you meant by that learning curve. If anyone has trouble with that, try to picture the difference between C and C# with .NET. Good luck using C to do what you can do in C# using just a few clicks.
You're conflating the tools with the language. There's nothing inherent within C# that cannot also be done with C given the proper libraries. Likewise there's nothing that you can do in C that you cannot also do in assembly. Of course the effort involved will be different from the standpoint of the programmer using the language depending on what libraries one utilizes. When you add in tools (such as IDEs like Visual Studio which .Net programmers tend to forget is different from the language) certain operations are optimized further in that you can use large chunks of what is essentially boilerplate code inserted automatically by the IDE, but you also sacrifice control and flexibility in that case (a well written tool should allow you to override it, but once you've made that jump it's essentially useless for further adjustments of that same piece of code).
An honest appraisal of a language should be done in two parts. First you should compare the language itself. What features does it provide, what sacrifices have been made, how stable is the language, etc. Secondly the tools, libraries, and IDEs should be compared. Any decision concerning a language needs to factor in both the things the language excels at, as well as the availability of tools and libraries for the language to accomplish the task you're attempting.
Re:Language Independent? (Score:3, Interesting)
Have scripting languages gotten faster, or have the computers we run them on gotten faster?
Re:Language Independent! (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.
Groovy (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.
Re:Using a different language is expensive. Summar (Score:3, Interesting)
I love Lua. I'm glad it was mentioned because I think it's one of the most underused languages I've had the chance to work with.
I had a GPS daemon I needed to write for an MDT (Mobile Data Terminal) Windows CE environment, and the CE API is just a complete shocker. In the end I managed to compile a branch of Lua called LuaX (has wince libraries) which comes with a bunch of awesome modules. A few of the modules did exactly what I needed (serial port and network sockets). One simple script handled everything I needed. I'm not saying it was the only solution, but I found it to work quite well, and the libraries were all there for me.
There's even a project called Kepler [keplerproject.org] to use Lua for server-side scripting (similar to PHP).
Re:Language Independent! (Score:5, Interesting)
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.