

A tour in ooc land - viraptor
http://ooc-lang.org/about

======
gizmo
For the record: I only read the front page, and didn't look much further. The
had trouble reading through it because of all the cutesy references to
internet-memes. Very distracting, and honestly, I just don't think the jokes
are funny enough to warrant the distraction.

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.

~~~
nddrylliog
Reading your post was an experience in humility that usually only happens on
reddit. Nevertheless, let me try to respond in a constructive manner.

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...](http://github.com/nddrylliog/bootcamp/blob/master/source/upcoming/list-
comprehensions.ooc) 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...](http://docs.ooc-lang.org/sdk/lang/types.html#module-lang/types)
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.

~~~
gizmo
Thanks for the in-depth response. Let me first state that it was not my
intention to attack your language.

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.

~~~
nddrylliog
Of course, it's just the pile of adjectives that eventually started to sound a
little aggressive, but no offense taken.

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.

------
stephen
Having the class/function name come first on the declaration line is
different, but surprisingly consistent with variable declarations where names
do traditionally come first.

I expected Go to have a syntax more like this--different, but in a good way,
not a weird way.

------
hristov
Well I am getting a bit nostalgic about the use of ":=" for assignment
(reminds of Pascal of course), but otherwise, I am not sure what the point is.

Maybe you can start by telling us what this language has that others don't?

~~~
nddrylliog
So <em> is not enough?

I'm seriously considering the use of <blink> at this point.

------
henning
One problem is that when I saw "ooc" I thought it was the esoteric programming
language Ook!: <http://www.dangermouse.net/esoteric/ook.html>

------
hga
I'm not looking for another C syntax language, but I do rather like this bit
of style:

" _All our code are belong to BSD._ "

"BSD" is a link to the license.

~~~
nddrylliog
C syntax? We clearly haven't read the same homepage.

~~~
hga
Err, vs. Lisp/s-expression syntax.

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.

~~~
nddrylliog
Oh, I see what you mean now. Calling everything that is not S-expression a C
syntax is pretty far-fetched though =)

~~~
hga
Well, there are also:

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

------
Batsu
I dare not make the attempt, but I think you could use regular expressions to
turn their examples into valid C++ code.

------
Flow
"ooc is a modern, self-hosting, object-oriented, functional-ish, high-level,
low-level sexy programming language, starring closures, interfaces, enums,
garbage collection.."

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?

~~~
nddrylliog
What do you consider modern then? A reincarnation of Algol-68? Yet another
Lisp? Another python-killer-killer (ie. a ruby-killer) ?

~~~
hga
Lisp lucked out in the temporary hack of s-expressions plus its basis in the
lambda calculus such that it has managed to modernize itself without too many
changes in its essential nature. E.g. there are I would say (from my '80s and
on background) three major changes, each more "modern" than the next:

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

~~~
chancho
Aggressive Hindley-Milner inference is old but getting it to mesh well with
the OO concepts that developed independently of it (subtyping/inheritance,
run-time polymorphism, virtual functions, etc.) is seriously tricky and is an
area of cutting-edge research. I'm not a type theory expert but my impression
of the current state of things is that you can have aggressive HM inference
(infers the type of everything and does so correctly) or OO language features
but not both.* If you want both you have to settle for "best effort" inference
where the compiler infers things when it can but sometimes needs the
programmer's help. This flavor of inference is just now (within the last
decade) making it into mainstream languages, cf. C#'s var, C++0x's
auto/decltype, Scala, etc. And ooc's inference appears to work this way too
(or at least it's going to.) So how is this not modern? What are the "modern"
features that ooc language is missing?

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

~~~
hga
" _What are the "modern" features that ooc language is missing?_ "

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.

~~~
nddrylliog
Don't be sorry by what you're interested in =)

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.

~~~
hga
" _We're not so foolish as to pretend to be a modern language without even
caring about concurrency =)_ "

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.

~~~
nddrylliog
while I don't want to fall too much into vaporware, the homepage mention might
indeed make sense.

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.

~~~
hga
You're very welcome.

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

