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.
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 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).
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.
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.
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.
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."
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.
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).
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.
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.
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.
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 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.
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.
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:
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/.
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 ;)
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.
