4 ms·

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

by gizmo 17y ago

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 17y ago
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 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/upcoming/list-comprehensions.ooc 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/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 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/ 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.
deleted 17y ago
[deleted]

by gizmo 17y ago

nddrylliog 17y ago

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 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/upcoming/list-comprehensions.ooc 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/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 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/ 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.

deleted 17y ago

[deleted]