In Middle-Earth Mordor is the progressive nation, which (together with Isengard) is inventing industrialization. Gondor, Rohan and the elves are the conservative faction. ;)
BTW - to whomever is down-voting this comment - it was the first comment made when the article was initially submitted, so there was no clue as to what language was being referred to. The comment I made genuinely provided information for those clicking on this submission and looking for clues as to what the language might be, before deciding whether or not to click through and read the article.
Quite likely you're down-voting it because you think it was a glib, content-free comment. If that's your assessment, you're wrong. It wasn't.
Julia is interesting for sure, but I think Clojure has had more of an impact in terms of what the future of languages might look like. I would argue the same for Rust as well.
I agree on Clojure. Rust I'd need to know more about, but I may study it now that it's post-1.0.
What do you think about Haskell's impact on the future? I think that static typing, although less popular as of now, could make a resurgence given the value it adds once one learns how to use the type system.
Most of the negative reputation of static typing, I'd argue, comes from languages that are falling out of favor (C++, Java) and that never did static typing right in the first place.
I hear a lot about Haskell but I don't see a lot about Haskell...
Clojure has two optional type systems known as the core.typed library, and Prismatic's schema library. I don't think it's an all or nothing situation. Use types when you need them and don't when you don't.
No I'm not, but I guess there was a possibility of you thinking that. Let's erase all ambiguity.
> TLDR; Optional type systems are the future
Optional type systems have their place, but I think you are ignoring applications that types can have besides type assertion and documentation.
> I hear a lot about Haskell but I don't see a lot about Haskell...
It's a shame you haven't "seen" Haskell and have only heard about it, I know how that can make the entire language seem like vaporware. I personally have seen at least one big thing from a large company that used Haskell. I'm guessing you didn't see Facebook's semi-recent release of Haxl[0].
> Clojure has two optional type systems known as the core.typed library, and Prismatic's schema library. I don't think it's an all or nothing situation. Use types when you need them and don't when you don't.
Optional typing is cool, but it's not useful for type based programming since it makes types optional. You can do some cool stuff by programming types. Haskell does some of this, but Idris[1] does much more by taking advantage of dependent typing[2].
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?
> 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).
... 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.
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....
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.
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.
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).
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.
If it were only true! But the way Julia is tied in (REPL ONLY), it's nothing more than a lab tool for number crunchers. And the developers don't plan to make Julia create stand-alone binary executables (R or Matlab users wouldn't expect that). That's a deal breaker for me.
BY REPL I think you mean it's got a console and you access it by running commands at a console? This is true, but also you can create programs which are executable and invoke the interpreter to run them in the way that you can do that with Java or C#.
Perhaps, like Python where you bundle the interpreter with the program. There are tools like py2app and pyinstaller which can bundle these together and include the dependencies. I don't know how big the dependencies for Julia would be, however. Clang itself is 8MB on Ubuntu.
This is why I'm so interested in stand-alone binaries. You would only need the runtime libs on the target system, and wouldn't need to distribute source code.
I've been using it to to play with fractals and other procedural graphics. I've enjoyed it. The only thing that was slightly unpleasant (besides growing pains and REPL startup time) was getting used to 1-based indices.
Don't know what happened. Think someone deleted my comment. What I said was we need a common metalanguage or knowledge representation for algorithms that can be translated to different programing languages.
Opening line: "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."
Interestingly, it was Bjarne Stroustrup's experience implementing a distributed system simulator in Simula that lead to him working on what became C++. He liked the architecture of the code, but it was too slow for him to get any results. He reimplemented the whole thing in BCPL, and that experience got him interested in having a fast language that provided Simula-like abstractions.
I originally read this anecdote in his book "The Design and Evolution of C++", but it's also in the beginning of his History of Programming Languages paper: http://www.stroustrup.com/hopl2.pdf
>> 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.
Probably was coding as a kid. And according to his resume his first professional (money paid) part-time job was in 1996, coding in C/ALGOL/C++/Perl. That is close to 20 years. Reasonable enough. People tend to keep it simple and not design overly complicated things when they've been doing something for 20 years.
>He and several other computer scientists are building a new language they hope will be suited to practically any task. [...] What we need, Karpinski realized after struggling to build his network simulation tool, is a single language that does everything well.
a few paragraphs later:
> That said, it isn’t for everyone. Bezanson says it’s not exactly ideal for building desktop applications or operating systems, and though you can use it for web programming, it’s better suited to technical computing.
So he made one language that's good for everything, as long as everything doesn't include desktop apps, operating systems, or web apps? That's a pretty big lacuna...
57 comments
[ 2.6 ms ] story [ 105 ms ] threadI'm getting mixed messages here.
Quite likely you're down-voting it because you think it was a glib, content-free comment. If that's your assessment, you're wrong. It wasn't.
What do you think about Haskell's impact on the future? I think that static typing, although less popular as of now, could make a resurgence given the value it adds once one learns how to use the type system.
Most of the negative reputation of static typing, I'd argue, comes from languages that are falling out of favor (C++, Java) and that never did static typing right in the first place.
I hear a lot about Haskell but I don't see a lot about Haskell...
Clojure has two optional type systems known as the core.typed library, and Prismatic's schema library. I don't think it's an all or nothing situation. Use types when you need them and don't when you don't.
Did you hear about Haxl[0]?
[0]: https://code.facebook.com/projects/854888367872565/haxl/
> TLDR; Optional type systems are the future
Optional type systems have their place, but I think you are ignoring applications that types can have besides type assertion and documentation.
> I hear a lot about Haskell but I don't see a lot about Haskell...
It's a shame you haven't "seen" Haskell and have only heard about it, I know how that can make the entire language seem like vaporware. I personally have seen at least one big thing from a large company that used Haskell. I'm guessing you didn't see Facebook's semi-recent release of Haxl[0].
> Clojure has two optional type systems known as the core.typed library, and Prismatic's schema library. I don't think it's an all or nothing situation. Use types when you need them and don't when you don't.
Optional typing is cool, but it's not useful for type based programming since it makes types optional. You can do some cool stuff by programming types. Haskell does some of this, but Idris[1] does much more by taking advantage of dependent typing[2].
> 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?
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).
Solution: Use "metaprogramming"!
Problem: You have to deal with 5 languages and 4 bespoke translators.
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.
This is useful.
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.
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.
> 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.
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....
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.
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.
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.
Not sure when you last tried, but in my tests on Windows this is much better now due to switching to a more direct API: https://github.com/timholy/Images.jl/issues/24#issuecomment-...
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).
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.
It's a nine months old story. And the hyperbole in the title has been thoroughly acknowledged in that discussion as well.
(Edit: Typo)
https://groups.google.com/d/topic/julia-users/rttSG6_pAiA/di...
now we have 5 programming languages ;)
Interestingly, it was Bjarne Stroustrup's experience implementing a distributed system simulator in Simula that lead to him working on what became C++. He liked the architecture of the code, but it was too slow for him to get any results. He reimplemented the whole thing in BCPL, and that experience got him interested in having a fast language that provided Simula-like abstractions.
I originally read this anecdote in his book "The Design and Evolution of C++", but it's also in the beginning of his History of Programming Languages paper: http://www.stroustrup.com/hopl2.pdf
Probably was coding as a kid. And according to his resume his first professional (money paid) part-time job was in 1996, coding in C/ALGOL/C++/Perl. That is close to 20 years. Reasonable enough. People tend to keep it simple and not design overly complicated things when they've been doing something for 20 years.
A style guide page here gives a good feel of the language: http://julia.readthedocs.org/en/latest/manual/style-guide/
Compare with Python: http://www.python.org/dev/peps/pep-0008/
And, say, Ocaml: http://caml.inria.fr/resources/doc/guides/guidelines.en.html
a few paragraphs later:
> That said, it isn’t for everyone. Bezanson says it’s not exactly ideal for building desktop applications or operating systems, and though you can use it for web programming, it’s better suited to technical computing.
So he made one language that's good for everything, as long as everything doesn't include desktop apps, operating systems, or web apps? That's a pretty big lacuna...