Slashdot Mirror
Programming Language Gurus Converge on 'Curry On' Conference (curry-on.org)
Videos are now online from this week's Curry On conference, which incuded talks by programming pioneers Larry Wall and Matthias Felleisen, as well as speakers from Google, Twitter, Facebook, Microsoft, and Oracle. Dave Herman from Mozilla Research also talked about building an open source research lab, while Larry Wall's keynote was titled "It's the End of the World as We Know It, and I Feel Fine."
Billing itself as a non-profit conference about programming languages and emerging computer-industry challenges, this year's installment included talks about Java, Rust, Scala, Perl, Racket, Clojure, Rascal, Go and Oden. Held in a different European city each year, the annual conference hopes to provoke an open conversation between academia and the larger technology industry.
Billing itself as a non-profit conference about programming languages and emerging computer-industry challenges, this year's installment included talks about Java, Rust, Scala, Perl, Racket, Clojure, Rascal, Go and Oden. Held in a different European city each year, the annual conference hopes to provoke an open conversation between academia and the larger technology industry.
Going to a technical conference for a language that is popular or that you know well does not offer that much value, because almost anything you learn there could have been learned online quicker.
Going to a conference filled with niche languages or higher level ideas is great because it's much more mind-expanding, and even if ideas seem esoteric there's always some interesting twist you can take back into languages you know better or are more practical to work with. It also helps keep you from getting too pigeon-holed by ignoring changes in the world around you, as I see many object-oriented die-hards doing...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Is that you Larry Wall?
The same reasoning in civil engineering would translate to saying that you only need a shovel and a mason's trowel to build anything. Yes, you can, the "competitive features" like improved insulation or just fashionable architecture don't depend on how you put the parts in place. But more powerful tools allow you to do more things in limited time.
Having said that, building those tools is complicated enough so it takes too much time and isn't generally done, be it building languages, debuggers, or whatever tool you need, basically equally. You do correctly, if obliquely refer to a well-identified problem of insufficient tooling even in those languages that are generally considered sufficiently expressive to not require additional syntax or semantics. Interestingly, this is independent of whether you're working in a more specialized language that has the concepts in question embedded in its core primitives, or in a less specialized language that requires you to first build these higher concepts (of interest to you) out of its lower-level constructs. It would even appear that the problem is roughly of the same scope regardless of whether you're building a new language (in the traditional "lexical-syntactic" sense, not just in terms of new APIs) or not, with the "standard approach" you're mentioning involving using non-specific analysis and debugging tools that are all-too-often only of marginal benefit because they don't provide the views that a large system might require to be more easily comprehended or modified, for example, by a newcomer. Building improved tools unfortunately requires some kind of model regardless of whether the model is explicit in form of another language or merely implicit in the code of the tools and the patterns of use of some API you're building. But the designers of programming environments can't possibly anticipate all the domains you might want to use their environment for, so even if you decide not to use or develop another language for an application, unfortunately, not much changes, there are still tooling problems to be solved. You've merely shifted the burden from one kind of tools to another kind of tools, and one could successfully argue that accessible techniques for building better tools (to bring them into the realm of what Eric Raymond refers to as "casual programming" in TAoUP) are highly desirable for overall productivity.
Ezekiel 23:20
Just my take. That is why I am back to C for anything but glue-logic. All that clutter more "modern" languages add is just not worth it. True, I currently use Python3 as glue, and the C I write is somewhat OO as it is Python modules, but that is it. Most "revolutionary" trends in programming languages are just not fit for actual production use.
Of course, most programmers are not fit to write productive code either (the utter crap I see when doing code-reviews is incredible), but that is another story.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Well I guess different people have different opinions about what is "relevant" and a "fad".
I haven't seen any Perl in production use in a number of years - although I'm sure it exists, for me and my career it's way past being "relevant". I was using it 20 years ago...
Scala is highly relevant, it's a fantastic language which I've been using professionally for over 2 years to great effect. I've built infrastructures serving millions of requests per second using it - and I'm not alone - Scala is widely used at Twitter, LinkedIn, Netflix, FourSquare, AirBnB, Apple, ... the list goes on.
Java is widely used, of course, but it's kind of dull at this point. Relevant but there's not much new to talk about at a conference.
Rust is .. interesting. I don't think it's ready for production yet, but it has some really interesting ideas, which even if they don't make it in the form of Rust could be seen in future languages. Very relevant to discuss and think about.
Go is spreading very quickly - I personally don't care for it but in my last job we had ops people who swore by it (I just swore at it). Extremely relevant right now as so many places are evaluating it, plus, obviously, the Google link.
The others - clojure, racket, & co are niche for sure. I don't think they even qualify as fads because (with the possible exception of clojure) no-one's really using them - and fad implies something is popular.
I do think they could have included F# though, that's a really interesting language that's starting to pick up steam in the commercial world. And Swift, while not that revolutionary, is bringing some new stuff to the masses and spreading very fast.
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
The main replies to this story seem to be basically hatin' on people who want to do something interesting with their spare time. How horrifying that people want to do something new and better rather than stick to whatever was state-of-the-art in the 1970s.
SJW n. One who posts facts.
I'm definitely not afraid of learning new languages, but if by "new" you mean "recently created", those very often bring little or nothing novel relative to what was already known. For example, people have already compared Go to Algol 68. In a way, it's a favorable comparison, but it's also damning with faint praise. Otherwise...no. Currently looking into APL.
Ezekiel 23:20