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.

Comments

More useful than current

[SuperKendall]

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...

Re:Wow what a useless conference.

[Anonymous Coward]

Is that you Larry Wall?

Re:how about conference with relevant languages

[K. S. Kyosuke]

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.