The comments in the OP pretty much state the skepticism that I feel...but let me limit my layperson's cynicism:
> Stefan Karpinski was building a software tool that could simulate the behavior of wireless networks, and his code was a complete mess. But it wasn’t his fault.
As a computer science grad student with years of industry experience under his belt, Karpinski was far from a programming novice. He knew how to build software. The problem was that in order to build his network simulation tool, he needed four different programming languages. No single language was suited to the task at hand, but using four languages complicated everything from writing the code to debugging it and patching it.
Is the code for this simulation open-source? I'm not sure what that simulation entails, to need four different languages to effectively implement it...but I would definitely be interested in reading some specifics on what these languages are (or at least, the domains that they pertain to) and in which ways Julia adequately fulfilled their roles (I'm going to assume that Julia wasn't the flat-out best language across all the roles...though really, that's what the OP's headline leads me to believe...)
I'm mostly a Rubyist. I hope Julia is faster than Ruby (what isn't?)...but is it as easy to read and write, and does it serve well as a glue language?
I used to work in this area, on a system that also used multiple languages.
Physics simulation: simulate wireless signals propagating over different kinds of terrain. This was performance-sensitive, and in C. At some point we stuck real hardware in the loop, so we had VHDL too.
Behavioral logic: simulate the behavior of each node in the network, including algorithms like selecting available transmit/receive channels and transmit power control. This was less performance sensitive, and in C++. At some point we also had Prolog in this layer, for doing channel selection subject to arbitrary decisional constraints.
Simulation setup: select a number of nodes, place them on a map, tweak behavioral knobs, etc. This was not performance sensitive, and was in a scripting language.
Prototyping and data analysis: this was in Matlab. It's the lingua franca of the engineering world.
Not simulation, but here is my example from finance which does things pretty similar to those in technical computing. First you want to prototype things and see what works. You need low-overhead fast iteration interpreted language with good graphing abilities. This is usually Excel, sometimes Matlab, R, or Python. The solution that you get does not scale, so you roll up your sleeves and re-implement calculations in C++, C#, or Java (and in some cases more exotic languages like F#, Haskell or OCaml). Then you need to present these results to users, which means you need Visual Basic or C# to integrate that back into Excel, or C# or Java (or maybe Python) to build a standalone desktop GUI application or web application. At this point build and deployment is supported by a bunch of other technologies, like Makefiles, batch scripts, maven files and what not.
There is nothing to stop you from writing a nice-looking, fast app in C++. I routinely do this kind of thing in a mix of C++ and Python because wxPython makes it easier to throw together a UI, but the development overhead for doing it in C++ is relatively small.
There are very few algorithms in Matlab or R that you can't find in decent libs for C++, so translating is no big deal given you're going that way anyway.
The question is: are we better to put resources into new special-purpose, highly-optimized-for-a-single-type-of-job languages like Julia (which for some reason the article talks about as universal, then admits at the end it is totally special purpose and unsuited for a whole bunch of applications)... or are we better off learning to use the tools we have with greater discipline?
I generally opt for the latter. Changing our behaviour as developers will produce better results than building new tools. We have the tools to manage our processes now (CMake, for example, rather than Makefiles). We need to be disciplined about using them. If we aren't, no new tools will help that much.
I don't know Ruby (boo hiss on me!) but I find Julia very easy to read and write. It's not production ready (in my opinion) yet, and I tried to use it at work - and found I couldn't because of some of the glitches in the windows implementation (specifically loading images in the case I tried, where it used to back door to ImageMajik and this took 20 seconds to bring in a gif). It does seem very good as a glue language. I think that the good thing about it is that it is really nice to write with very powerful syntax and semantics but also very fast (until you hit a corner case...)
I think that the corner cases will get rubbed out one at a time in the next year or so, and what will be left will be truely impressive. The fear I had was that interest would wane before it took off, but the libary growth in the last 6mths makes me increasingly confident that the Julia community is robust enough to deliver.
I don't really see a problem using several languages, of course depending on how much and what you're doing with them. Alternating soft and hard layers is well suited to a lot of tasks, with a more dynamic "scripting" language and something closer to the metal. Maybe have a GUI in something different, too (esp. if we're talking 'bout the web), and maybe some build/deployment/data munging...
I'd much rather do that than have four different data formats or complicated protocols (i.e. Java and it's rat's tail of XML and OO-RPC variants, or shudder some abomination that combines ASN.1 and CORBA).
> he needed four different programming languages. No single language was suited to the task at hand
Are we so behind in the world of software development that people don't understand the concept of metaprogramming? If you have to write code for two or more languages, just use a meta-language (it could be Python or Lisp, for example) to write code for each language as needed. People discovered this concept as far back as the 70s (see how Smalltalk is implemented for example).
I'd just use Ruby or Lisp, depending on whichever you know better. Wrap the domain concepts you're working with in classes, and use templating to deal with the other languages. Don't bother with translators, just wrap IO.
The most exciting development I can think of is gradual typing. I don't want Ruby to be fast. I mean, definitely make performance improvements, but in order to be truly fast, you need an honest-to-goodness static compiler that understands machine code better than you ever will. Can't use one on Ruby 'cause it's not static.
But if you can build up your type system gradually, so it emerges as your domain model does, then you can get all the benefits of rapid iteration while still preserving your ability to eventually make it fast without rewriting it in another language. Imagine being able to compile to C in production, while keeping it in Ruby in development and testing. Best of both worlds. If the static step gives you problems, just switch it off and report a bug.
Your second paragraph illustrates the issue with lumping ruby and lisp together.
Lisp is already fast, in some common lisps (e.g. sbcl) you have a compiler that gets within about 2x of a good optimizing c compiler, which is pretty good. So in some sense, it already has the best of both worlds (more powerful than a ruby or python, faster than most languages when compiled).
I think the reasons it did't take over the world have nothing to do with the technical core, and everything to do with ecosystem and network effects.
I've a hunch that the speed of those flavors of Lisp is coming from a bunch of really smart people basically spending their entire careers optimizing it. Which gives me hope that Ruby can get there too.
> ecosystem and network effects.
Which is a really important consideration. Technologies are a dime a dozen, community is rare and ephemeral. If you can build a solid, robust community around your tech, it doesn't matter what the limitations are.
Actually most of these compilers have pretty small teams, and in some cases part time volunteer effort has done a lot of the optimizer
But language design really matters, for example one guy put together a JIT for lua that is roughly as fast as the JVM. He's good at it, but he wouldn't have been able to do the same thing with Java (or, I expect ruby) on his own....
... and that hasn't been a problem for programmable programming languages like Common Lisp. In fact, it's a strength.
A great example is GLSL. It's a great system but the context switching required by the programmer and the plumbing necessary to send the compiled program to the graphics card... tedious. cbaggers is working on a CL package that provides a DSL that compiles from Lisp to GLSL code and helpers which compile and upload the code for you. You can essentially live-edit GLSL code without switching gears.
maybe I am not understanding what you mean, but I thought that metaprogramming still involved knowing both/multiple languages.
I get the sense from the article that he was trying to eliminate the overhead of glue-code and meta-languages while also preventing context switching between languages.
> Stefan Karpinski was building a software tool that could simulate the behavior of wireless networks, and his code was a complete mess. But it wasn’t his fault.
As a computer science grad student with years of industry experience under his belt, Karpinski was far from a programming novice. He knew how to build software. The problem was that in order to build his network simulation tool, he needed four different programming languages. No single language was suited to the task at hand, but using four languages complicated everything from writing the code to debugging it and patching it.
Is the code for this simulation open-source? I'm not sure what that simulation entails, to need four different languages to effectively implement it...but I would definitely be interested in reading some specifics on what these languages are (or at least, the domains that they pertain to) and in which ways Julia adequately fulfilled their roles (I'm going to assume that Julia wasn't the flat-out best language across all the roles...though really, that's what the OP's headline leads me to believe...)
I'm mostly a Rubyist. I hope Julia is faster than Ruby (what isn't?)...but is it as easy to read and write, and does it serve well as a glue language?