The Erlang library is a prototypical implementation of the programming model. It's a research project, and this allows us to quickly prototype and experiment with the model as we see what works and what doesn't. It's not meant for production use.
The paper that will be presented as part of PPDP 2015 [1] will contain language semantics for a subset of the operations in the language (and we will continue to provide these, with the end goal of having a standalone language.)
(Disclaimer, I'm one of the primary authors of Lasp, @cmeik on Twitter)
I generally agree: too many people think they have to make an entire language—with its own grammar, parser, standard library, and runtime—every time they want to play with some new language semantics.
I would love to see more "languages" that are either:
1. alternative syntaxes (with their own semantics) for existing languages (Lisp-Flavored Erlang, for example); or, better yet,
2. [reader-]macro libraries (as used in DSLs, but not Domain-Specific) implemented within sufficiently flexible languages, which encapsulate the base language's semantics and provide the alternative semantics you want, but which also allow you to "drop down to" the source language wherever the experimental wrapper-language isn't complete. HN's Arc language is this way, a macro library sitting on top of Racket. Erlang was also originally this way, a macro-library on top of Prolog.
A language should only be grown out into its own ecosystem if-and-when that would provide a benefit to the people programming in the language, such as support for new platforms, or greater performance. Otherwise, it's just meaningless busywork.
Or, in other words, building out an entire "programming language" is almost always premature optimization.
Could you elaborate on the drawbacks of having "too many languages"?
I thought that it was commonly accepted that having a diverse ecosystem of programming languages was good thing for everyone (Companies and engineers) because it fostered and fueled innovation in more mainstream languages by showing that feature X is relevant, or possible or desired by the community.
I sincerely don't see how it could be a problem? You can just ignore the bad ones or those that don't suit your needs while enjoying the others. Also, I might be mistaken but I am under the impression that new PLs have faster iteration cycles and are more receptive to feedback to suit one's particular needs.
I personally enjoy to see a new programming language makes the front page of HN because they often try to address existing problems in current big PLs, in a new way or incorporate state of the art PL theory concepts that I did not know!
Edit: why the downvotes? This is a genuine question!
I don't know why people are downvoting either, but I feel like you deserve an answer. I'll admit others are probably in a better position to answer you though.
A language's popularity is not really proportional to how clever it is unfortunately. For example, Javascript is extremely popular but that's because it's the only language supported by all browsers. Ruby is popular because.. well probably because Rails is in Ruby, although I haven't used Rails enough to know whether it needed to be written in Ruby. From my limited time using Ruby though, I don't see how it solves a different problem than Python does, but hopefully someone more familiar with it than I am can pass on his or her wisdom.
Having a diverse language ecosystem is not necessarily good because there are a finite number of people working on them, and having more languages means each of them will not be worked on as much. On the other hand, making a new language CAN be good when an existing language doesn't fit a particular problem well.
Having to learn a new language, while fun, is still time consuming and I think most people would agree that there is time better spent except in the case that a language truly presents something novel. Of course, most would also agree that the more novel something is, the more time it would take to learn as well.
In any case, because of the effort required to both make and learn a new language, I think the person you are referring to was implying that people are currently too liberal in deciding to make a new language and instead we should only be making a new one if it's actually warranted.
Let's say I want to join a new company / contribute to some open source project. In winner-takes-all-world, I already know the language they are working in and am familiar with the framework they are using.
In super-diverse world, I have spend a few weeks getting up to speed. Cannot drive by commit easily.
Well, I started writing an answer (about me, having difficulties with picking the "right" technologies for my new website), but then I saw rifung's comment. Actually, I couldn't say it any better than he did.
Disagree. Maybe there's too many popular ones but I can't imagine there ever being too many toy ones. We're nowhere need figuring out how to make a perfect language. It takes a lot of trial and error to continue to improve.
Is there ever going to be a perfect language? My impression is that even among "styles" of programming languages, they have benefits and drawbacks. It seems more likely that we will be able to understand the problems programmers are faced with, group them, and then make specific languages to tackle each of these groups very well.
Found that in on of the blog posts regarding the OP. Basically, there's been a convergance of certain features of abstraction building, and at least some general outlines of what he refers to as "definitive languages".
Commutative (operation-based) and convergent (state-based) have been grouped under the more general term conflict-free.
In 2011, Shapiro et al. [2] showed equivalence between the two types, and later the name was generalized [3]. I've compiled a list of CRDT related resources for more information. [1]
You can usually guess quality of programming language from the first page of its description. For LASP it clearly sucks. No simple example, are you kidding me? I finally dug out example at below link and all I can say is this is pretty ugly language. So many _ and curly brackets that it feels dizzy. None of the sample code is even remotely intuitively readable to make a guess what's going on.
The syntax you're complaining about is Erlang's.
(_ is to ignore a token in a pattern match, braces denote tuples.)
I've added a simple example, because I received that criticism from others, so, thanks for your feedback.
Lasp's prototypical implementation is provided as an Erlang library: this is a research language and we're researching the semantics of distributed computation and not the syntax. The syntax seen in the examples is extremely close to the syntax of the built in 'lists' module of Erlang, with the addition of having to declare types, because of Erlang's type system. This was done to make it seem natural to Erlang programmers.
(Disclaimer, I'm one of the primary authors of Lasp, @cmeik on Twitter)
Please don't post comments to HN that dismiss new work so nastily. There are many ways of suggesting improvements that don't involve trampling all over someone's freshly planted garden.
