Ooc - modern object oriented c | Hacker News Reader

Ooc - modern object oriented c

ooc-lang.org

111 pointsvluft79 comments

Group answer so I don't blow up my HackerNews quota:

thrives/strives : yeah! thanks a lot, fixed now

wrong url in downloads: all fixed, thanks for reporting.

guess vs inferred: replaced.

why some things are prefix and some infix: that's the magic of covers. In "hi world" println(), it's the method String.println() which is called. In println("hi world"), it's a different function, e.g. println(String) which is called.

prank by ruby users: actually there seems to be a lot of interest from the ruby community =) maybe they're realizing you can have nice syntax without a VM.

Objective C && ooc: that's been mentioned on #ooc-lang, it would be very interesting for iPhone development, definitely something to explore =)

sorry about the delay, I've got more traffic than I can handle right now =)

EDIT 1: fixed syntaxic/syntactic. Damn me and my French background ;) thanks for reporting

EDIT 2: I love the comparison "ooc is to C as Scala is to Java." Seems very fit =)

You also have "syntaxic" in a number of places when you want "syntactic" :)

Looks very cool!

Minor question: what's the RSS feed for the blog?

Safari lists two:

  feed://ooc-lang.org/feed.php

and

  feed://ooc-lang.org/feed.php?mode=list&ns=

The former one appears to be empty and the latter one doesn't appear to include blog posts (or at least it includes a lot of other stuff; I'm not sure). It would be nice to have a regular RSS just for the blog for us non-Twitter-aficionados.

There is one actually, (and now I must reveal the ugly blog hack I made to integrate wordpress with DokuWiki), http://ooc-lang.org/blogbackend/?feed=rss2

It should probably be linked on the website. Lemme fix that.

EDIT: Added link to rss and atom feeds on the blog.

At first I wanted to say "bah humbug" but it really does seem to hit a sweet spot:

-Common modern features(implicit typing, generics, GC, iterator syntax)

-Source-to-source C, so it is compatible with just about everything

-Doesn't attempt to reinvent libraries

-Doesn't attempt to reinvent the build system

-Doesn't diverge strongly on syntax(apart from supporting the new features)

These are the kind of things that make a language easy to pick up and start using :)

Seems to fit the pattern "ooc is to C as Scala is to Java."

It's beautiful. I think I'm in love!

It's a wonderful framework giving me a graceful syntax and some nifty tools. I may just get involved!

Please do =) We're open about its design, all contributors are welcome, all the code is BSD licensed on GitHub. Join the fun!

The documentation has issues, e.gs.

"But remember, the compiler is your friend. He guessed that's what you wanted to return."

Yuk, a compiler is not a cuddly teddy bear, and I really don't want a compiler to "guess", I want it to be very predictable in its behaviour.

add: func(a, b : Int)

Previous function example specifies a return type, why doesn't this one?

The strange little dots

Oh please.

No explanation of why some things seem to be prefix, e.g. "Hi, softer world =)" println() and some are infix, e.g. add(1, 2)

That's why it's called a "tour", not a reference documentation ;) Reference docs are being written, and are updated here http://docs.ooc-lang.org/ from this git repo http://github.com/nddrylliog/ooc-docs If you want to help you're welcome.

> A compiler is not a cuddly teddy bear

Why, shouldn't it? I always found gcc so cold and all. Friendly compilers surely aren't so bad. I could do a -hardass flag if you wanted.

> Previous function example speicifes a return type, why doesn't this one?

Wohow, my bad. Fixed in the doc.

> The strange little dots

Actually they are strange, because they're unexpected. It's a bit of the syntax that would probably most appeal to perl hackers, and is totally optional.

EDIT: Realized the return type was missing in add: func definition. :/ sorry.

>> Previous function example speicifes a return type, why doesn't this one?

> Because the function doesn't return anything (e.g. is void), I guess.

Have another look at it. Does "add" look to you in this context at all like a function that returns void?

printf("1 + 2 = %d\n", add(1, 2))

And now I feel very dumb.

You were right :/ It's all fixed now, thanks a lot for reporting.

(At first I thought that you thought that return type specification was non-optional, e.g. that it lacked "-> Void")

About the other issues: are you really bothered by them? (e.g. the familiarity of the writing, etc.) I thought it'd be less boring, but I didn't mean it to annoying.

EDIT: fixed the "strange little dots" and "compiler is your friend" parts.

I think your writing was fine! I like seeing some style with programming talk :D

Striking the right tone is hard, and you can't please everyone. Personally, I like a slightly conversational tone, but it's easy to got to far with it, and it just becomes a waste of words. You're writing to please the reader, not the writer ( see http://news.ycombinator.org/item?id=875094 ).

E.g. "Foreaches. Foreaches is like.. a regular For that gave up alcohol, decided to shave daily, and bought a new suit. It's prettier, and more effective. "

I've been programming in C# for years, I know foreach. It's a workhorse feature that I use daily. There are similar constructs in Ruby and PHP and others.

+1 for a -hardass flag, that would be awesome

http://github.com/nddrylliog/ooc/issues/#issue/25

Friendly compilers surely aren't so bad.

No, they aren't bad. Cryptic error messages are just annoying.

Would "inferred" be a better word than "guessed" in that context? It sounds more deterministic, conveys more of a meaning of "worked it out for itself from the context" rather than "rolled the dice and took a stab at what you might mean".

Vector3f: class { x, y, z : Float }

vec := Vector3f new() vec x = 3.14 vec y = 6.18 vec z = 42.0 // hey, Java/C/C++/C# guys: look! no dots =)

Uhh, are "no dots" supposed to be a good thing?

If it's message passing, then yeah it's a good thing, but apparently it's just a syntax thing so not too exciting.

I'm sad that i don't see any references to first class functions and closures. But that may be because they're not implemented yet.

Also, any thoughts about all that "immutability by default" rumble ? Is ooc too close to c to give that a thought ? Simplify the use of immutable data structures would be very cool, and very possible since ooc has a gc.

Actually, i was thinking about a "competitor" for this nice language, and the closest thing to it that i found was BOO : http://boo.codehaus.org/. Boo has a syntax that is just as nice, comparable set of features + closures, very nice type inference, and very good interaction with native code. It runs on .Net, but i think the interop with c is really very flawless for once. You can even manipulate pointer data. And it has the nicest macros i've seen yet in a non lisp language (i've not seen a lot except lisps tho).

Closures are planned, indeed.

About immutability, it's really a hard call for me to do here. C is very much about in-place data modification (as far as I know). Working with immutable objects seems to be a very different approach.

What do you mean with "simplify the use of immutable data structures" ? Like a good support for const?

Thanks for the feedback, I'll definitely look deeper into Boo to steal.. huh get inspiration from it ;)

> About immutability, it's really a hard call for me to do here. C is very much about in-place data modification (as far as I know). Working with immutable objects seems to be a very different approach.

Yeah i know what you mean. But anyway this is a whole other topic, and it could be programmed by third parties. The important part would be more about enforcing a transitive const keyword, and some other nice things like that.I think what the d people are doing at the moment is very interesting : http://www.digitalmars.com/d/2.0/accu-functional.pdf

Another question i had is, do you plan to provide any meta-programming facilities (macros) ? Boo is very interresting in this regard, i can only recommend you look into it.

Oh and one last thing, how does ooc fare performance wise compared to plain c at the moment ?

Also i've been toying a bit with ooc and it's very nice to code in. I will probably follow its evolution with a great lot of interrest. Thanks for your work and dedication !

Look at http://www.digitalmars.com/d/2.0/const3.html also. C++0x and D both seem to allow compile time evaluation of expressions or even full functions that depend only on constants.

I agree that mutable state is valuable and its use should be easy (boo Haskell).

(note: the example the D article gives of C "int const p" should be "int const p")

Yet another interesting looking new language -- but not on the JVM for once.

The site doesn't explain how C and C++ libraries can be used, especially with respect to GC. There doesn't seem to be a destructor/finalizer to wire up to a 'legacy' free(), so wrapper classes might be tricky.

That's a good point. I'll write some docs on that now. Stay tuned.

The second to last example looks like it is incomplete:

    include time // equivalent to #include <time.h> in C
 
    TimeT: cover from time_t
    Tm: cover from struct tm {
       tm_sec, tm_min, tm_hour, tm_mday, tm_mon, tm_year, tm_wday, tm_Tm*
 
    main: func {
      timestamp := time() // timestamp is now a TimeT
      t := localtime(timestamp&) // t is now a Tm*
      printf("It's %dh%d.", t@ tm_hour, t@ tm_min)
    }

I would have expected a closing } in the definition of the TimeT cover.

Generally speaking, ooc looks really promising. Compiled to plain C, hence fast and super compatible, and with syntactical treats borrowed from Python and Ruby. I wanted this for a looong time. :-)

Compiled to plain C, hence fast and super compatible...

In the beginning, there was cfront... ;)

True, but it wasn't exactly Ruby/Python/IO inspired. ;-)

I've added the optional {} after the empty TimeT cover =) Is it clearer now?

I'm really glad to see that it scratches an itch for many people out there. As always, suggestions are welcome.

Uh, no. I guess I picked the wrong declaration; I meant Tm. There is a bracket/scope opened after 'struct tm' that, as far as I can tell, is never closed.

"Compiled to plain C, hence fast" is not actually a great argument. See e.g. lua-jit, which IIRC just generates subroutine-threaded code. (In other words, it "merely" takes a series of lua opcodes generates C code that is a series of calls to the functions that implement these opcodes.)

Looks really interesting!

The one thing I was missing, coming from an objective-c background, is named parameters in method calls. Definitely one of my favorite parts of objective-c.

Any thoughts on adding anything like that?

> it thrives to be

I think you mean: "it strives to be"

Maybe he has a Lisp?!

or it's all part of some grand scheme...

I think it's a prank set up by Ruby users, but don't see it anywhere in the text.

This looks a lot less syntactically confusing than D. Specifically, by describing it as "here's how to shorten the C you already want to write".

I'm part of the crowd who thinks it's too bad that D didn't get that far, that it was encumbered by licence issues and a syntax sometimes more complete than what you need.

I'm trying to stay minimal with ooc's syntax. From 0.3 on, it's heavily Io-inspired (Steve Dekorte and I are regularly discussing syntax matters.) and with operator overloading, generics, etc. you get a very expressive language at little cost.

In the end, it's just a bunch of new idioms to learn =)

D still has a few tricks up its sleeves, don't worry ;).

But nice language. It's pretty!

I would love to see some benchmarks against c and c++.

Done and done, but it's not such a good idea.

ooc translates to C, and as someone mentioned, it's often the C you would write yourself.

What you would really be benchmark here is Garbage collector vs vanilla malloc/free. And whether one or the other is fastest depends greatly on your scenario (and on your malloc implementation, e.g. http://goog-perftools.sourceforge.net/doc/tcmalloc.html is looking good)

That your compiler produces C doesn't imply anything about performance. When you introduce general abstractions, you also make it harder to perform certain optimizations. It's still worthwhile, and potentially informative, to write an idiomatic OOC program, an optimized OOC program, and compare their performance to both an idiomatic C program and an optimized C program. (Solving the same problem, of course.)

Your statement "it's often the C you would write yourself" is a claim that you can support with numbers.

It's very difficult to determine what is "idiomatic", and how far to go.

For example, in ooc you often have to choose between classes and covers. When you don't need inheritance, covers is often enough, + you get to work on the stack rather than all on the heap (in that respect, ooc offers more flexibility than Java, and a little less than C++)

What would also be interesting is offering abstractions for parallelism in ooc, etc. and then differences in benchmarks would show for "idiomatic" implementations. (Very much like Haskell idiomatic solutions are sometimes faster than C ones.)

The challenge that programmers are presented with nowadays is much more than just rewriting a few tight loops in assembler ;) Concurrency and parallelism are the most important challenges for us now, imho.

Hey, you're the designer and implementer. You need to explore what idiomatic OOC codes looks like. If you pick up enough users, they'll evolve it for you, but you need to start it.

If you're interested in abstractions for concurrency and parallelism, I suggest you look at both Cilk and Apple's block extension for C (used in conjunction with Grand Central Dispatch). There are many others, of course, but those perhaps are the easiest fit into your language.

Looks very cool. Any thoughts on adding closures?

Indeed =) It will be implemented very simply, as in the latest Vala release (in fact they should even be compatible).

Now I'm really salivating. Good work!

For me it looks like a compilable python (with more complex syntax, of course) but with all the libraries of C.

The garbage collector without gc_free() means less control and memory leaks in complex programs (my biggest issue with python). I guess one could use malloc() and free() if they really want to (since C headers can be imported).

The hello world example is confusing though.

Hmm what is confusing in the hello world example?

And yeah, you can totally use malloc/free.

Either globally (e.g. just change the definitions of gc_malloc/gc_realloc etc. to be extern(malloc), extern(realloc), etc.) or locally for a specific class, e.g. overriding the "alloc" method of a class or writing your "new: static func() {}" yourself instead of relying on auto-new generation from "init: func() {}" methods.

We need more documentation =) Stay tuned.

EDIT: Added some docs here http://ooc-lang.org/docs/memory/no-gc.html

Thanks for the docs, what a quick and effective feedback !

Let's have a look at the "hello world" :

"Hello world!" println()

It is simple and short but makes no sense to me because the print function takes no argument and doesn't seem linked to the string "Hello world!" it prints.

When a function manipulate data, shouldn't it be passed as argument ? I would understand better:

println("Hello world!")

But maybe it's because it's not the first time I read code.

EDIT : OK, I just read your group post. Thanks.

println() isn't a function, it's a method/message passed to the "Hello world!" string object. The lack of syntax highlighting that (the strange dots) makes it difficult to notice.

Excuse the superficial review, but it looks like JSON, not C. Why the name association with C, apart from the fact that you can include C libs? Vala or D look much closer to C.

Actually, the syntax has evolved much since ooc 0.1 (which was then closer to C).

The main implementation is still a source-to-source translator to C99 so the name association is still justified.

Plus, if you don't like "ooc = object oriented C", you have plenty of choice. My personal favorite is "only on caturday". But YMMV.

That you compile (not translate) down to C is an implementation detail. I think you've deviated enough from C that a name change might help people's first impression - I had very different expectations because of the name.

Just curious - what did you expect?

And a name change isn't excluded, do you have any cool language name idea?

Backwards compatible with C with object-orientation. When you include the name of another language in your own name, I assume you're either a subset or a superset of that language.

I have no real suggestions, but it's worth noting that some popular languages have names with no relationship to the language (Java, Python, Ruby). I think perhaps the most important criteria are that it's a single syllable, easy to say, easy to type and doesn't have unfortunate associations.

I'm not sure what you mean with "Backwards compatible with C". You can easily use ooc code from C, and C code from ooc. What more do you want?

ooc is indeed not a superset of C syntactically. Objective-C is there for that, and its syntax is (imho) a mess.

You can mix and match C and ooc code at will =)

Please don't confuse this with an issue of what I want. It's just what I think the name implies.

"Backwards compatible" implies, to me, that if I take out the new features from the language, I'm left with legal code in the original language. This is markedly different than being able to call one language from another. I can call Fortran code from C, and I would never characterize Fortran and C as "backwards compatible."

One is about source code compatibility. The other is about object code compatibility.

Keep the name. I wasn't confused. Looks sweet.

I quite like the one you get when you google for "ooc":

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

On a serious note: if you label your language as a C, people will be expect C syntax.

I once stumbled upon BitC, but was disappointed because it looked like LISP.

i was going to say that there's already c++ or c#, but the language looks really cool. i guess the keyword there is "modern".

C# isn't modern? Do you know C#?

I don't consider C# a modern language.

C# is a good proprietary ripoff of Java, with a few things done right. Java itself was a wrong interpretation of Smalltalk with C++-like syntax to attract the masses and, they randomly crossed every feature they thought was "complicated".

What's modern about it? Except that they add bloat with each new version. The original C# wasn't so bad. Just my 2 cents =)

EDIT: Stay calm. The above is obviously an over-statement. I don't really care about C#. Relax. Breathe. Write some Python. Feeling better now?

What would you expect a "modern" language to be like?

Your opinion about C# is flat-out asinine. The original C# had less type safety. And it lacked anonymous delegates. And it required you to write out all your types. If you actually used C#, you would not decide that you'd rather use C# 1 instead of C# 3 unless you were deliberately being irrational.

Alright - before it becomes a troll =)

I have no definitive opinion on C#. I don't use it, don't really care about it, and yeah the fact that bloats comes with successive versions doesn't mean there weren't improvements as well.

In fact, bloat is often the price to pay for completeness/usefulness, and as I see it, C# is both quite complete and very useful (makes up for a lot of jobs now).

I'd expect a modern language to be either very minimalistic like Io, or very expressive like Scala, or very straight-forward like Python.

But I guess this is a point that would gain to be elaborated in a blog post or something - we're too limited here in the comment to say much of value.

If you're ignorant of C#, then you probably shouldn't make declarations about it. Your definition of "modern," while reasonable, is not a commonly accepted one, so be careful about using it without defining it.

You're right, now that I'm a public person, I must be careful what I declare. (Damn you, scope)

No seriously - who cares what I say? ;)

No one cares what you say until you start flaming something you know nothing about. Then some people develop a need to set the record straight.

I would expect a modern language to be like Limbo: http://limbo.cat-v.org

By putting c# in the same league as c++ and this ooc, you've automatically tagged yourself as clueless.

And why is that? Many parallels can be made with C++/C/C#. I wouldn`t go that far and call it clueless.

When someone lists "C/C++/C#" (not "Java/C#" or "C/C++/D" or "C/ObjC/C++") this typically means two things: - He's judging language proximity by their name instead of their traits. - He doesn't know other languages (often: his experience is limited to MS platform).

If someone isn't judging languages by name and have broad sight, he would recognize that C# falls into entirely different bucket (bytecode virtual machine, mandatory garbage collection, managed execution, inseparable class library) than any of C, D, C++, ObjC, ooc.

This looks great. Let's all hope bloat and feature creep don't turn it into C++ in a few years.

I would like to take a look at this project, but the link to the source on github is broken.

The link on the download page seems to be broken. The correct one is on the community page: http://github.com/nddrylliog/ooc/

interesting.

will it be possible to use libs like QT and CUDA?

QT is C++ and CUDA is C so yeah, it would be quite straightforward =)

An ooc user has been looking into adapting http://qt.nokia.com/doc/qtjambi-4.4/html/com/trolltech/qt/qt... to generate ooc QT bindings. If you're interested, join us on our IRC Channel #ooc-lang at Freenode

I'd be very interested in seeing some CUDA/ooc work!

Objective C && ooc == ?

Could it be a precompiler generating Objective C, while using the GC in Apples' frameworks?

oooc

Reply on news.ycombinator.com