Modern little languages (?)
Michael Fogus
modern little language? In the historical LL mailing list a lot of
focus was spent on languages like SmallTalk and Scheme and there is no
reason to believe that they and their incarnates are still relevant.
However, it would be nice to survey the LL space and see what kind of
language fall out of it.
As far as generalities among what comes to my mind when I think if LL,
the following seem consistent:
1. Built on a handful of core concepts
2. Not-necessarily general purpose, but something "more" than a DSL.
It could even be an "ideal" driving variations on a theme.
3. A single developer (or maybe a small team of core members and contributors)
4. Too young to have barnacles
5. Sheltered from the dirt of real-life usage and influence
6. Symbiotic (hosted, transpiled, etc.)
7. Forward thinking (a bonus, not a requirement)
What am I missing?
Off the top of my head the following languages fit into the LL
category as I've described it:
* Kernel
* Pure
* ClojureScript
* Roy
* Datalog
* Vis.io
* Io
* Pharo
* newLISP
* Elixir
* Julia
* Shen
There are many more not listed or course -- let's build on this list.
Discuss if you please.
:F
Pepijn de Vos
On Apr 11, 2012, at 3:21 PM, Michael Fogus wrote:
> The name of the group is Little-Languages.Next, but what entails a
> modern little language? In the historical LL mailing list a lot of
> focus was spent on languages like SmallTalk and Scheme and there is no
> reason to believe that they and their incarnates are still relevant.
FYI, I recently found a job posting for SmallTalk, so apparently companies are using it. But maybe your relevant refers to research rather than use?
> However, it would be nice to survey the LL space and see what kind of
> language fall out of it.
>
> As far as generalities among what comes to my mind when I think if LL,
> the following seem consistent:
>
> 1. Built on a handful of core concepts
> 2. Not-necessarily general purpose, but something "more" than a DSL.
> It could even be an "ideal" driving variations on a theme.
> 3. A single developer (or maybe a small team of core members and contributors)
> 4. Too young to have barnacles
> 5. Sheltered from the dirt of real-life usage and influence
> 6. Symbiotic (hosted, transpiled, etc.)
> 7. Forward thinking (a bonus, not a requirement)
>
> What am I missing?
Little syntax? Possibly as a result of #1 and #3.
>
>
> Off the top of my head the following languages fit into the LL
> category as I've described it:
Without all of the traditional LLs?
>
> * Kernel
> * Pure
> * ClojureScript
I'm curious why you think ClojureScript is LL, but Clojure itself is not?
> * Roy
> * Datalog
> * Vis.io
> * Io
The only one I briefly used so far. It seems there is a lot of prototype cross-pollination going on in this area?
Michael Fogus
Not really. All of this is pretty vague.
> Little syntax? Possibly as a result of #1 and #3.
That is probably something that many LL's share, but I would probably
hesitate to include it as a prerequisite.
> I'm curious why you think ClojureScript is LL, but Clojure itself is not?
No particular reason except that it popped into my head first.
ClojureScript is a smaller language than Clojure however.
:F
Michael J. Forster
[...]
> As far as generalities among what comes to my mind when I think if LL,
> the following seem consistent:
Hi,
I would think that OMeta, Pepsi, Cola, and the other languages under
the STEPS umbrella would fit your criteria -- the comment about
general purpose vs. DSL, in particular.
Cheers,
Mike
Bruce Mitchener
> The name of the group is Little-Languages.Next, but what entails a
> modern little language? In the historical LL mailing list a lot of
> focus was spent on languages like SmallTalk and Scheme and there is no
> reason to believe that they and their incarnates are still relevant.
> However, it would be nice to survey the LL space and see what kind of
> language fall out of it.
It was my impression (from your blog posting and other discussion)
that the hope was that this list might be the intellectual successor
to the original ll1-discuss list. That list was the "Lightweight
Languages" list rather than "Little Languages" and the way that they
defined "lightweight languages" was interesting:
Many of the most widely used languages to emerge in the last five
years have come, not from the academic programming language
research community, but from industry. Examples include Perl,
Python, Ruby, and Rebol. These languages have borrowed heavily
from academic research, sporting features such as garbage collection
and closures, but they also experiment with many novel ideas, such
as first class environments and keyword-free syntax. In the
meantime, academic research has made substantial progress in
formally addressing issues such as safety, correctness, and also
the implementation of seemingly expensive features such as closures
and dynamic dispatch. Lightweight languages have proven to be the
most effective vector for getting innovative language features into the
hands of working programmers.
We use the term "lightweight languages" to describe some of the common
features of these new languages. The term "lightweight" refers not to
actual functionality, but to the idea that these languages are easy to
acquire, learn, and use. Examples that would fall into this category
include Perl, Python, Ruby, Scheme (and scsh), and Curl.
-- http://ll1.ai.mit.edu/cfp.html
> As far as generalities among what comes to my mind when I think if LL,
> the following seem consistent:
>
> 1. Built on a handful of core concepts
> 2. Not-necessarily general purpose, but something "more" than a DSL.
> It could even be an "ideal" driving variations on a theme.
> 3. A single developer (or maybe a small team of core members and contributors)
> 4. Too young to have barnacles
> 5. Sheltered from the dirt of real-life usage and influence
> 6. Symbiotic (hosted, transpiled, etc.)
> 7. Forward thinking (a bonus, not a requirement)
>
> What am I missing?
It depends on the goal?
I don't see why items #3, #4 or #5 are terribly interesting
personally. They sound more like (possible) criteria for "emerging
languages" to me.
> Off the top of my head the following languages fit into the LL
> category as I've described it:
>
> * Kernel
> * Pure
> * ClojureScript
> * Roy
> * Datalog
> * Vis.io
> * Io
> * Pharo
> * newLISP
> * Elixir
> * Julia
> * Shen
>
> There are many more not listed or course -- let's build on this list.
I'm interested in Dylan (http://opendylan.org/) (and I treat working
on it as a part time job). Despite Dylan's age, it spent many years
asleep, so it is a bit of a Rip Van Winkle situation.
If part of the motive for discussion here is to get ideas into broader
mainstream usage, then Go is interesting. Rust may well be as well ...
- Bruce
David Nolen
I'm interested in Dylan (http://opendylan.org/) (and I treat working
on it as a part time job). Despite Dylan's age, it spent many years
asleep, so it is a bit of a Rip Van Winkle situation.
If part of the motive for discussion here is to get ideas into broader
mainstream usage, then Go is interesting. Rust may well be as well ...
- Bruce
Bruce Mitchener
> That Dylan is being reinvigorated is very exciting.
It is indeed, I hope! We have a lot of things happening and some
exciting stuff coming in our next release. The next release should be
soon, but a couple of us keep going on holidays instead.
> Any thoughts about Julia?
Yes ... Hopefully nothing in what follows offends anyone.
I was initially interested in the surface similarities between Julia
and Dylan. That said, some of the missing pieces in Julia have made
me that much more aware of how things fit together well in Dylan.
Things that I immediately miss when looking at Julia have been:
* Module system. I think there are some serious flaws in what we have
in Dylan, mainly around having the library / module definitions separated
from the source a bit.
* Keywords, rest arguments. This isn't a difficult thing to integrate with
multiple dispatch.
* A lot of features at the compiler level and tool support levels.
* Libraries broader in scope than challenging Matlab / R.
Given the lack of a module system and any real way to control symbol /
binding visibility, it seems like it would be difficult to build any
larger applications within Julia itself.
They've got an interesting challenge ahead of them however.
Displacing R (or Matlab) seems like it would be rather difficult. I
suspect that they'd be further along in some areas if they built on
top of a more mature language implementation in some ways (be that
Dylan, a Lisp, PyPy, Clojure, etc). Where's the vision for something
as nice as Tableau can be, but for the type of work that one does with
R or Matlab? (Or even something like RStudio?)
The interesting problems that they want to solve involve statistics
and math, not creating a general purpose programming language and an
industrial implementation thereof, along with a full set of general
purpose libraries for things like I/O, parallelism, and so on. I'm not
sure how building everything from scratch gets them closer to that
goal ...
The problems that I want to solve are pretty different from Julia and
require a compiler and tool environment with the amount of information
at hand that Open Dylan has. I'm more interested in the level at
which we interact with the tools and with the environment in which our
code is running. (Some 15 years ago, I worked in a Smalltalk-like,
networked environment where you could edit everything on the fly. I
miss that a lot.)
Take all of this with a grain of salt though! I'm clearly only barely
sane given that I've taken on reviving Open Dylan.
- Bruce
David Nolen
* A lot of features at the compiler level and tool support levels.
* Libraries broader in scope than challenging Matlab / R.
(Some 15 years ago, I worked in a Smalltalk-like,
networked environment where you could edit everything on the fly. I
miss that a lot.)
Take all of this with a grain of salt though! I'm clearly only barely
sane given that I've taken on reviving Open Dylan.
Michael Barton
They've got an interesting challenge ahead of them however.
Displacing R (or Matlab) seems like it would be rather difficult.
Bruce Mitchener
> On Thu, Apr 12, 2012 at 1:19 PM, Bruce Mitchener <bruce.m...@gmail.com>
> wrote:
>>
>> * A lot of features at the compiler level and tool support levels.
>
> What in particular?
Well, in Dylan, we have a full IDE and the UI code is separated from
the backend. This includes stuff like finding all references, a lot of
optimization support, ways to view the intermediate code, debugger,
tracing, profiling, etc. (Some of these features haven't aged well and
are being updated this year.)
>> * Libraries broader in scope than challenging Matlab / R.
>
> Sure, though I think suprising things fall out of languages with very
> limited scope. JavaScript comes to mind here :)
Agreed.
>> (Some 15 years ago, I worked in a Smalltalk-like,
>> networked environment where you could edit everything on the fly. I
>> miss that a lot.)
>
> What environment was that?
This was Cold, a sort of response to MOO:
* http://cold.org/coldc/ (pretty dead, lots of broken links)
* https://github.com/waywardmonkeys/cold (the C sources)
Unfortunately, it isn't all that useful without an image / database
and I'm not sure if there's a publicly available / accessible image
any longer.
We used it for writing online games (with commercial success).
There used to be a lot of stuff going on in that space with MOO,
CoolMUD, ColdMUD / Cold, LPMUD, DGD, Muq and others in the
programmable server space. Muq was the creation of Cynbe ru Taren who
now works on an SML/NJ derivative (Mythril?).
- Bruce
David Nolen
There used to be a lot of stuff going on in that space with MOO,
CoolMUD, ColdMUD / Cold, LPMUD, DGD, Muq and others in the
programmable server space. Muq was the creation of Cynbe ru Taren who
now works on an SML/NJ derivative (Mythril?).
- Bruce
Patrick Logan
On Apr 12, 2012 6:58 PM, "David Nolen" <dnolen...@gmail.com> wrote:
>
> Again any links documenting the history of the implementation of this stuff much appreciated!
One interesting branch of the MOO history is lambdaMOO...
Manuel Simoni
Given the lack of a module system and any real way to control symbol /
binding visibility, it seems like it would be difficult to build any
larger applications within Julia itself.
On LtU, Casey McCann made an interesting point:
"It's easy to design a [module] system to make easy things a bit easier, but hard to do so without simultaneously making hard things a lot harder!
"The benefit of not providing any namespace management at all is that it forces people to deal with all the headaches sooner, and accustoms them to dealing with irritating namespace issues, so that when an unusually tricky issue comes up--well, it's only a bitworse than the constant day-to-day hassles, and at least there's nothing getting in the way of hacking together some workaround."
http://lambda-the-ultimate.org/node/3991#comment-60418
Michael Fogus
> We do have ample proof that it is possible to write large software systems
> without any kind of module system: C, JavaScript, and Emacs Lisp.
No one said that it was impossible.
I can't speak for ELisp because I've not written anything
substantially large with it. As for the other two, they do have module
systems, it's just that they happen to be of the "because you can"
variety. That is, these have some set of features that one can build
ad hoc module systems out of -- and everyone does -- over and over.
Bruce Mitchener
And, importantly, most languages offer ways to constrain the
visibility of bindings (.h vs .c in C, usage of file-scope static,
private / protected in C++, etc).
Julia doesn't appear to have a way to limit visibility at all. You
load a Julia file and there aren't any documented ways to make
something not be visibile that I saw. Nor did I see any usage of stuff
like that in the 'extras' directory in the Julia git repository.
- Bruce
Patrick Logan
On Apr 13, 2012 7:37 AM, "Bruce Mitchener" <bruce.m...@gmail.com> wrote:
>
> Julia doesn't appear to have a way to limit visibility at all. You
> load a Julia file and there aren't any documented ways to make
> something not be visibile that I saw. Nor did I see any usage of stuff
> like that in the 'extras' directory in the Julia git repository.
What Julia seems to have at hand are first class functions, multiple values, and dynamic loading. So that allows you to put on a moderately sized show in your dad's barn with the neighborhood kids.
The site does list modules as a possible feature at some point.
Brian McKenna
Thanks for mentioning Roy. Let me put it through the checklist:
> 1. Built on a handful of core concepts
I'd probably put the "core" concepts down as: Functional programming for JavaScript via type-checking and immutability.
> 2. Not-necessarily general purpose, but something "more" than a DSL.
> It could even be an "ideal" driving variations on a theme.
Check. I'm going after general JavaScript use.
> 3. A single developer (or maybe a small team of core members and contributors)
Only me as a core developer - though I've surprisingly had about 15 devs contribute! :)
> 4. Too young to have barnacles
Roy definitely has barnacles :P
> 5. Sheltered from the dirt of real-life usage and influence
Sadly :(
I'll soon have Roy to a stage that I can write some web services with it. I'll then be able to work on the "Real World" language problems I run into.
> 6. Symbiotic (hosted, transpiled, etc.)
Transpiled, not (yet) hosted
> 7. Forward thinking (a bonus, not a requirement)
I have a lot of plans for the future of Roy. Mainly focusing around the type system. Type level programming. Functional lenses. Type errors at runtime.
Lots of fun.