Out in the Open: Man Creates One Programming Language to Rule Them All
wired.com
wired.com
It's a nine months old story. And the hyperbole in the title has been thoroughly acknowledged in that discussion as well.
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
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?
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.
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 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).
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.
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....
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.
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.
now we have 5 programming languages ;)
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...
I'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.
(Edit: Typo)
https://groups.google.com/d/topic/julia-users/rttSG6_pAiA/di...