Scheme to become two languages | Hacker News Reader

Scheme to become two languages

lambda-the-ultimate.org

84 pointsapgwoz49 comments

Actually, it's not being split at all. There's going to be a "small" variant that is a proper subset of the "large", or complete variant. Small would just be a reduced feature set.

This is a great idea.

To keep a standard subset for lightweight implementations (which are better suited for embedded systems, or for being embedded as a scripting language). How cool is this?

Edit: not to mention that a greater portability among the full featured implementations would be even more cool.

I'm so happy to see Scheme alive and kicking.

I'm currently planning out a project that involves building a OSC controller using an ARM chip. I hope I will be able to use scheme to write the firmware for the device, that would be swell (and much more fun than using ASM).

Pre-scheme.

http://en.wikipedia.org/wiki/PreScheme

I experimented with other languages/things before for embedded programming. I think forth would be great if it worked the way my brain does. Otherwise, there are good reasons everybody uses C.

Check out this: http://arcfn.com/2009/08/arc-arduino-arm-temperature-monitor...

The guy is running an Arc (pg's Lisp, currently implemented in mzscheme) web server on his Arm-based SheevaPlug.

How do you like Lua?

I have very little experience programming so i figured an embedded system would give me a good "ground up" approach to learning some programming. I've heard good things about lua, i was considering ADA (rock solid stability is key for this project) or smalltalk. I'm still in the planning stages of everything involving this project and infact i'm going to build a midibox first to get familiar with embedded systems and circuit design. Some people have made some impressive controllers, and synths with the project.

http://www.midibox.org/ http://www.ucapps.de/

Oh, well, you should try some stuff before you make up your mind, then. Ada and Smalltalk couldn't be much more different.

This kinda looks like a linkjacked version of that:

http://news.ycombinator.com/item?id=777666

It's on Lambda the Ultimate, which is a well-known programming language theory discussion site. While the link could have been to the steering committee statement, the signal-to-noise ratio for LtU's discussion will probably be on par with HN's.

It's worth browsing their archives (http://lambda-the-ultimate.org/classic/lambda-archive1.html) sometime, when you have a couple hours. Great stuff. (I'm only posting the link because it's a Friday afternoon. ;) )

Oh, I read stuff there from time to time, and it's often interesting. I just didn't see anything in the original posting at LtU that made me think "Yes, it was definitely important to submit this instead of the actual meat of the matter."

I linked to it specifically for the discussion that LtU has on the matter.

Fair 'nuff. Upvoted.

I just don't usually like to read discussion in two separate places of the same topic. It gets tedious. I guess it's a matter of personal taste.

Ordinarily I'd agree with you. However, this is a case where the insights of a more specialized community on programming languages makes sense.

You're probably right. I'm still feeling too lazy to sift through it, though. I'd rather just deal with one discussion context, and spend the free time I would have spent on the other discussion context reading SICP instead.

edit: Part of the problem is that I don't like the LtU discussion presentation as much as HN's, I'm sure.

Why do languages always have to evolve? On average, do languages get better over time or do they deteriorate? I am sure that Java has deteriorated a lot.

Keep it simple, please!

Java was never simple. Scheme is simple, Smalltalk is simple, Java was always a beast.

Probably, but they still managed to make it far worse (generics, annotations, ...).

I'm much happier with jdk 1.5 than I was with 1.4 or 1.3 or 1.2 etc.... Not sure why you don't like the new additions. In general you don't have to use them if you don't want to.

Not sure why you don't like the new additions. In general you don't have to use them if you don't want to.

I don't really disagree with you. That said, it's a little bit of an opt-out, in the same sense that arguing that C++ is just as clean as C because "you can avoid all the ugly weird parts if you really try" is something of an opt-out. (I'm not trying to comment on the relative merits of C++ and C (edit: or, for that matter, on Java <1.5 vs. Java >=1.5), so much as on the relative levels of simplicity of the two languages, just to make certain that's clear).

Neah. Generics are useful. Not perfect, but useful. They also happen to be optional.

The language evolution has been good, but too slow.

Even the platform evolution has been good, they have (and perhaps still) set the standard for many types of libraries.

My main issue is the growth of the platform (to what, 200mb?). I would like a much tighter standard library. In an ideal world, Swing, XML parsing ... etc. should be seperate, deprecated items removed and old apis redone.

200MB? The latest JRE is only about 20MB. Those libraries consume very little space.

20 MB might just be the loader, though. I recently installed the JDK after a long pause and I was appalled at how unpleasant the process had become.

No, 20MB is the complete JSE runtime download including all libraries.

Not so much optional - I think in modern Java projects you will be expected to use them. Also, 3rd party code will use them and won't work with your code if you don't use them.

Anyway, it is all a matter of taste.

I see that the poor implementation of generics is an issue, but what's so bad about annotations?

My main issue is that they add more complexity to the language, making it harder to learn and to understand. They also encourage even more verbosity in an already verbose language. Furthermore, the uses I have seen all seemed a bit borderline - they used to say that configuration should stay out of the code, but now it sneaked in again.

How else would you propose to make meta-information about code available at run time? Before annotations we had to put that information in separate configuration files. That ended up being more complex, and harder to learn and understand.

I only know it in the context of Hibernate, and there are ORM frameworks in languages that don't have annotations.

The separate config files had something going for them, because it keeps the concerns distinct.

Yes, things used to be better. It's the decay of the youth.

No, but maybe featuritis is how languages die, to be replaced by newer, simpler languages.

Simplicity of use is what seems important, not necessarily simplicity of design. Though JavaScript is more complicated than C in the sense of having more features, those features generally result in source files that're more succinct and faster to write (since you don't have to, say, roll your own hashtables).

Sometimes, the newer, simpler languages are new versions of the older, more byzantine languages. I think that's basically the Perl 6 approach, for instance.

It's called "evolution", in some circles.

It's like sketching with pencil. Your first version is complicated and gets a lot wrong, with stray lines all about. The final one is cleaned up and simple, yet that simplicity is a direct result of that messy progenitor.

Like small-scheme. Problem solved.

s/languages/software/g

Lua started out as a configuration language in 1993 and since then has evolved into a more general purpose language that is cleaner, yet more flexible and powerful. It has gotten much better with time.

for more information, see: The Evolution of Lua - http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/hopl.pdf

How can anyone think that deciding on expressions of computation should be done by committee? Imagine mathematicians were to get together to agree on standardized terminology for papers - what a waste of time it would be!

Assuming you're not being facetious, I happen to think mathematics would be more advanced today if a little attention was paid to standardizing its notation:

http://news.ycombinator.com/item?id=733265

But don't take that as enthusiasm for committees.

Almost no one is enthusiastic about committees. That doesn't make them any less of a necessary evil.

   '''I happen to think mathematics would be

more advanced today if a little attention was paid to standardizing its notation'''

... as well as the tools available to render those notations.

http://www.stixfonts.org/pub_geninfo.html

http://en.wikipedia.org/wiki/STIX_Fonts_project

That is exactly why one of the goals needs to be a small, understandable, core.

Committees degrade into uselessness when the discussion degrades into warring over features. Everyone has a pet feature, and nobody lets their pet feature go.

When you have a stated goal of minimalism (for at least part of the greater thing you're trying to define), then the argument to include this or that can be a /logical/ one based on whether it is actually /required/.

It seemed to work fine for Haskell.

Really? There are still people who want a rewrite of Haskell's number types to organise it better (numeric prelude). Mainly for stuff like types that implement addition, but multiplication doesn't work for them.

And one would think that implementing math is easy ;)

We already have both Theory Focused Lisp (Scheme) and Practice Focused Lisp (CL).

What did I (sorry, I meant you :) miss?

The idea is that Scheme has been controlled by the expansionists lately and has gotten pretty large and practical.

As for why people don't just use CL, Scheme isn't laden with the historical mistakes that Common Lisp is, Scheme is still capable of evolving, and "large Scheme" is much more approachable to beginners than CL because of DrScheme and other efforts of the PLT people. And some people just like Scheme's approach better.

historical mistakes (regarding CL) is only an opinion, not a fact.

For many aspects it's a huge advantage of CL to not having continuously evolve into something slightly different and only opinionatedly better.

I know both Scheme and CL, and I'll continue to prefer CL for at least the next decade coming, I think.

Meantime, I like all the effort anybody is putting in any kind of Lisp, and I always follow the different attempts (the different Schemes, Arc, Clojure).

No I think Common Lisp does have more mistakes than Scheme. But I should have said, "Scheme isn't as laden with mistakes..." And that's partly because most of the current Scheme standard was evolved after the Common Lisp standard was set.

Agreed on your last point, and I recommend trying Clojure out for some little project. It might surprise you how much more succinct it is than Common Lisp. Arc too, from what I've heard.

You missed this paren: )

Reply on news.ycombinator.com