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