Live data from Hacker News

LASP: A Language for Distributed, Eventually Consistent Computations

lasp-lang.org

11–20 of 29 posts

Re: LASP: A Language for Distributed, Eventually Consistent Computations

#11
post #5

Earlier quoted context omitted.

Which is good, because there already are way too many languages...

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?…

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.

Re: LASP: A Language for Distributed, Eventually Consistent Computations

#12
post #7

Earlier quoted context omitted.

Which is good, because there already are way too many languages...

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.

Re: LASP: A Language for Distributed, Eventually Consistent Computations

#13
post #5

Earlier quoted context omitted.

Which is good, because there already are way too many languages...

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?…

Good question!

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.

Re: LASP: A Language for Distributed, Eventually Consistent Computations

#14

I'm kind of disappointed that with a name like LASP, it doesn't have lisp syntax.

As we note in the full paper that will be presented as part of PPDP 2015 [1]: "Inspired by LISP’s etymology of “LISt Processing”, our fundamental data structure is a join-semilattice, hence Lasp." (Disclaimer, I'm one of the primary authors of Lasp, @cmeik on Twitter) [1] http://costa.ls.fi.upm.es/ppdp15/

Then it should have been Slap as in "SemiLAttice Processing". Well, Lasp is a better name :).

Re: LASP: A Language for Distributed, Eventually Consistent Computations

#15
post #14

Earlier quoted context omitted.

As we note in the full paper that will be presented as part of PPDP 2015 [1]: "Inspired by LISP’s etymology of “LISt Processing”, our fundamental data structure is a join-semilattice, hence Lasp." (Disclaimer, I'm one of the primary authors of Lasp, @cmeik on Twitter) [1] http://costa.ls.fi.upm.es/ppdp15/

Then it should have been Slap as in "SemiLAttice Processing". Well, Lasp is a better name :).

Haha, fair. :)

Re: LASP: A Language for Distributed, Eventually Consistent Computations

#16
post #3

Earlier quoted context omitted.

Apparently it's not even really a "language" in the same way most articles mean, but simply an Erlang library.

Which is good, because there already are way too many languages...

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.

Re: LASP: A Language for Distributed, Eventually Consistent Computations

#17
post #12
post #7

Earlier quoted context omitted.

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.

Oh, probably not, but I have a feeling that none of the languages that exist today will still be used in a 100 years.

Re: LASP: A Language for Distributed, Eventually Consistent Computations

#18
post #5

Earlier quoted context omitted.

Which is good, because there already are way too many languages...

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?…

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.

Re: LASP: A Language for Distributed, Eventually Consistent Computations

#19
post #12
post #7

Earlier quoted context omitted.

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.

http://www.info.ucl.ac.be/people/PVR/flopsPVRarticle.pdf

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

Post reply on HN