A tour in ooc land
ooc-lang.org
ooc-lang.org
I like the approach of dropping the reader immediately into the language, and introducing new concepts as as you scroll down. This works well, I think. I think they should go a little more in depth. People who don't know what a class or inheritance is aren't going to experiment with new programming languages, but we do want to know whether the language has value or reference semantics, what the type system is like, and so on. 90% of the text was explaining what the syntax does... and that's frustrating when you just want them to get to the point.
Examples.
1) Don't explain that `for x in [1, 2, 3]` is a for loop, I can guess that. Explain whether it's lazy or not, whether you use iterators / generators behind the scenes or whether it's just syntactic sugar. Explain whether the "x" is a copy of the variable in the container, or a reference to it. Does `for x in [1, 2, 3] x *= 2`, work? If not, does the type checker warn me? Or does it work like most scripting languages nowadays, where it doesn't work for primitives, but does work when iterating over something more complex like [[], [], []].
2) Objects on the stack or the heap? Both? Objects on the heap, rest on the stack? What about structs?
3) I see you can almost have a 1-1 mapping between C structs and OOC objects, but OOC just has "integer". How can you map that faithfully to "unsigned char", "signed short", "long long int", etc? Are they arbitrary precision integers? And if so, do they magically become heap objects when they exceed 2^31 or 2^30 (see: ruby)?
4) And objects... Multiple inheritance? Mixins? Single or multiple dispatch? Messages based system? I think the answer is: all method calls are virtual, single inheritance only, but that's just a guess.
5) Their claim that "garbage collection is fast and if you disagree you're an idiot" (liberal quote) is silly. What kind of garbage collection do they have anyway?
6) They mention templates/generics, but not whether their type system works w.r.t. covariance/contra variance. I suspect their type system / inference system simply isn't sound.
Anyway, most of these questions are rhetorical. The language has a number of nice characteristics, but the cutesy approach and focus on syntax over semantics doesn't give me confidence.
First off: I understand your cuteness overload at reading the frontpage. As a matter of fact, you're not the first http://github.com/nddrylliog/rock/issues#issue/1
Also, I wasn't aware XL and Io were internet memes now. They'll be happy to learn about it though =) Moving on to the interesting stuff
1) Generics (not templates, ie. not a subset of macros) support primitive types. This is one of ooc's points of interests (compared to, say, Java). How else would 'for(i in [1, 2, 3])' work, knowing that [1, 2, 3] is an ArrayList<Int> and that Int is a cover from 'int' ?
No it's not lazy, list comprehensions are planned: http://github.com/nddrylliog/bootcamp/blob/master/source/upc... We're still throwing ideas around, AFAIK there's no definitive best solution.
for(x in [1, 2, 3]) x = 2 compiles and runs very well, but doesn't modify the list. Which makes sense, given that it's equivalent to: { list := [1, 2, 3] x : Int iter := list iterator() while(iter hasNext()) { x = iter next() x = 2 } }
Iterating over [[],[],[]] will make 'x' a list too, not iterate over the sub-lists recursively. That would be a nightmare imho. You can have a CompoundList or something with a custom iterator if you want.
2) Objects are allocated on the heap, covers/primitives/structs on the stack. This is just a start. Escape analysis will allow the compiler to allocate objects on the stack where it's possible. It is my belief that in a modern language, it shouldn't be up to the programmer to decide if he doesn't want to (but still be possible)
3) No, ooc doesn't have just 'integer', it has covers of all numeric C types. http://docs.ooc-lang.org/sdk/lang/types.html#module-lang/typ... This is not a definitive state of things, but it worked well enough so far. Also, no, there's a 1-1 mapping between ooc covers and structs, but object clearly have reference semantics on ooc.
No bignums in the core language at the moment (for your 2^30 question), but we're looking for a good (and fast) BSD lib for that. Any suggestions?
4) Hint: we wouldn't announce we got interfaces if we had multiple inheritance. http://news.ycombinator.com/item?id=1288250 Mixins are on the way. Single dispatch. All methods are virtual by default (what horrible C++ term), you can make them non-virtual with the 'final' keyword.
5) No, it says "stop listening to your mom about your father's GC and go do some actual performance research to see what fits best for you". Also, -gc=off exists for a purpose. And from the very same paragraph which you 'quoted', we have a link to http://www.hpl.hp.com/personal/Hans_Boehm/gc/ Which says quite clearly 'The Boehm-Demers-Weiser conservative garbage collector can be used as a garbage collecting replacement for C malloc'. This is not necessarily a final state of things. It just makes it very easy to use C libs in a garbage-collected manner (think GTK+, etc.), and it performs a lot less worse than one would expect of a conservative GC. That's why the page says "and no, it's not necessarily slower"
6) This is one of the areas where we could definitely get more type safety. You can cast a List<File> to a List<Object> alright, and you can also do the reverse. The compiler is precisely too lax in that area, and that is a real issue to work on for the next releases.
While you make some interesting points and ask some uneasy questions (not hard, just uneasy), I'm surprised that you didn't just try it out and look at the generated C code (-noclean compiler option), which would've answered most of your questions in an eye-blink.
Also, yeah, we do care that our syntax doesn't suck. Most people agree with that. There are interesting semantics all over the place (recent C#, ahem Java7 ahem, all the JVM-ish languages, all the FP languages), the world doesn't need one more Lisp, seriously. I hear Clojure covers pretty well the "FP language that doesn't suck at getting shit done" thing. Kudos to them.
Also, is it possible that you are taking yourself too seriously? When did programming last sounded fun for you? What is your last free time project you enjoyed working on? Those are mostly rethorical questions, but I'd still love to know.
I didn't download or try the language to answer my questions (or read the rest of documentation) because I was just giving my opinion on the introductory guide, not on the language itself! In other words: I'm not saying your language sucks. I haven't formed an opinion on it yet.
Regarding bignums, for my programming languages I've settled on imath ( http://spinning-yarns.org/michael/sw/imath/ ). It has a BSD compatible license, it's ANSI C, it's very fast and it has both bignum and bigdecimal support. It's also memory efficient for small numbers.
I'm happy to report that I'm working on hobby projects and my own startup all the time. Having a blast. Next time, please don't assume I'm a sarcastic jerk.
Also, I understand very well what you want to know as a language designer yourself, the difficulty resides in making the homepage friendly for beginners too! Let me know when we can do expertise-detection of the audience in the browser =)
Thanks for the feedback anyway, we're always looking for ways to improve the docs, it's just that one has only 24h a day, as I'm sure you're well aware (especially with a startup on your hands.)
IMath sounds awesome, someone suggested it earlier I think but we were worried about performance. I'll definitely give it a shot.
I'd love to hear more about your programming language and the design choices you made, where can I get more information?
EDIT: I'm sorry that you felt like I considered you a sarcastic jerk. It really wasn't my intention :/ it's just hard to tell the good people apart, you know? Again, apologies if I sounded harsh.
I expected Go to have a syntax more like this--different, but in a good way, not a weird way.
Maybe you can start by telling us what this language has that others don't?
I'm seriously considering the use of <blink> at this point.
"All our code are belong to BSD."
"BSD" is a link to the license.
Most of the post-70s children of Algol have adopted "C syntax" as I refer to it, although I'll agree this language is some distance from that, e.g. it doesn't suffer from "cancer of the semicolon". But it is strongly C/C++ influenced at the very least.
Algol syntaxes, e.g. wordy ones with begin end instead of { and }. It introduced cancer of the semi-colon and := and quite a few languages followed it, most notably Ada and Pascal and its derivatives. C is obviously an optimization of it, but it also adds its distinct features.
There's the postfix Forth family including Postscript and Factor.
Python's use of significant white space deserves mention.
I could go back further to BASIC and its line numbers, FORTRAN IV with its column significant spacing (e.g. the statement continuation column), but you get the idea....
Um, why put the word "modern" together with all the other ideas from the 50's, 60's and 70's?
It's like to claim something is modern because it's made of plastic, isn't it?
Mainline Lisp, which is for the most part stuck in amber with Common Lisp.
Scheme, which is semi-stuck in its MIT design style "do it right or not at all".
Clojure, the new hot Lisp that many think is the future of Lisp.
Scheme made some major departures from mainline Lisp, only one of which was adopted by the later (static scoping and all that implies (I now forget how good its support for closures is)).
Clojure is a further departure: not very multi-paradigm (and much more functional than Scheme) and its unification of data types (lists, maps, etc.). It's also like Scheme in getting rid of a lot of legacy cruft (starting with cons!) but is not an essence of purity language like Scheme, e.g. while a Lisp-1 it has mainline Lisp style macros.
So I'd say it's "more modern", e.g. its embrace of STM, which is an idea of the mid-80s to mid-90s. Most other new Lisp dialects strike me a "yet another Lisp"; I'm not sure about Arc, though.
I agree at least in part with the comment you are replying to, a modern language needs concepts newer than the '60 and 70s (closures are I think the only '70s concept in what Flow enumerated).
While its mathematical roots are fairly old, aggressive Hindley–Milner style type inference is I think a "modern" language concept. '70s at least???
* My limited understanding of Ocaml is that it supports both, but nobody uses the OO features of the language so I assume there's a reason for that.
Good question; I'm not up enough on this direction of languages to answer.
It has closures, as noted.
One might say that functional programming is new again, or at least strong functional programming where you have guarantees that certain varieties (almost said "classes" there, which in this context would be confusing at best :-) of data will not change out from under you. Haskell has this, of course, as does Clojure in a weaker form.
What about first class continuations? Continuations per se are too basic to be entirely modern, e.g. Steve Russell, inventor of obscure things like Spacewar and the Lisp REPL invented them for the second implementation of LISP (on the vacuum tube 704), but they weren't first class until Scheme in the 1975 (all this according to Wikipedia, and Scheme's aren't quite first class enough for my tastes).
Modern concurrency stuff? For that matter, what's its concurrency story? A search for various keywords like that, thread and SMP didn't find anything.
I'm sorry to say that I personally am only interested in new languages that have a good concurrency story, that and languages per se are the only areas of pure CS that I find interesting. (And of course I have Clojure for concurrency.) If it's "functional-ish" but not functional enough, it might be hard to graft that onto the language.
Concurrency is obviously one of the last points (with exceptions) to tackle before we throw together a 1.0 spec.
We haven't settled on a final solution there, but there are definitely discussions and hacktivity in that area.
We're not so foolish as to pretend to be a modern language without even caring about concurrency =) It just takes some time to get it right.
I was wondering.... You might want to make a note of that on the home page, as well about exceptions.
"It just takes some time to get it right."
Indeed, as do exceptions. Go doesn't have them yet, many languages have problems with them, especially if grafted on later, and I know they were a work in progress (well, the work had about finished, I think) when I left the Lisp Machine community in mid-1983.
If I wasn't in love with Lisp, i.e. if I hadn't started programming in 1978 and therefore had long ago established a variety of preferences, I might well be interested in your language, it does have variety of tasteful features. I wish you luck.
Thanks for the luck-wishing, we'll definitely need it.
However it ends up, it will still have been a wonderful journey. Every programming experience should be so.
I understand the vaporware concern, but if you e.g. are saying to yourselves "this won't be successful without concurrency" then you might as well mention it as an in progress feature. If you are at least playing around with it, serious discussions, designs or even have cut a little code for it, that's not dishonest in any way.
For a lot of people, including myself, it's now a "checklist" feature. So are exceptions, but those are a bit obscure, or perhaps more appreciated by the more experienced or something like that. Those who know about these things also know they're hard to do (right).
That allows you to have modern wheels, music, art.