Ooc: new awesome language with site redesign, guide, and screencast | Hacker News Reader

Ooc: new awesome language with site redesign, guide, and screencast

ooc-lang.org

30 pointsgmaster144044 comments

I'm in language overload at this point. Much more than another language I'd like to see some creative new architectural approaches to problems that are thorny or tedious to solve right now.

I mean, if something as simple as applying MVC principles to web development can create a revolution there have to be a lot of other unplucked ideas out there. Software engineering feels a lot like architecture would if people spent 95% of their time talking about materials.

A good language that is pleasant to write leads to more experimentation with approaches to a problem - which wouldn't get tried out otherwise because it would be too tedious/performance-intensive with other languages/implementations.

I have basically built ooc to make programming a lot less annoying for me (and others) to try new things with. The work is really starting to pay off and I thought I'd share it! It's not like anybody forces you to try it ;)

A new language means I have to start from scratch with all the boring crap that you have to write to make a language usable. Database drivers, http libraries, mail tools, command-line parsing utils, xml & json serialization, test tools etc etc.

There's nothing more annoying IMO than reinventing all those wheels one more time. I'm willing to play with the new JVM languages because I can get all that stuff for free but the advantages of one more sui generis language are going to have to be HUGE for me to even consider retooling all that junk.

Thankfully there's a community (and a bindings generator) for that. Chances are the libs you want to use are already in: http://github.com/search?langOverride=&language=&q=o...

Yes, that's one more advantage of producing C code - integration is seamless. No need to reinvent all the wheels, rewrite what you feel like, re-use the rest.

That sounds like a very leaky abstraction.

Huh? Can you develop your point?

It's one thing to make calling into C easy, but how well do C types fit in with the rest of the system? What about error handling? Memory management? String encoding conventions etc etc? This stuff is all gross in C and inconsistent. I don't see how you're going to paper over all that and make the C libs feel like native, first-class citizens of your world. Just binding to libexpat doesn't mean you have good xml support, for example.

Those are all valid questions that show you haven't researched the least bit into what ooc does and how it works, otherwise you'd have some clue as to how it does solve these problems.

(And please, no "But I don't have the time, you have to chew everything for me"-answer. I'm in overload of this kind of answer too.)

Learning another new language is not on my list of things to do right now. If I hear that somebody has actually built something interesting in it I'll take a look but I'm much more interested at the moment in studying the basics of machine learning, figuring out how to build rich user interfaces in pure HTML5, and helping the rails team shorten its bug queue.

What would a car metaphor be like? Would it be like we're all driving early racing cars? Not everybody even has a seat, and some people are still sitting astride cars like on a saddle? (Yes, some early racing cars are driven like this.) Some people are still arguing the merits of a two-lever yoke over the wheel. Others are arguing about 3 versus 4 wheels. There are people who advocate steam engines.

The thing is, the development of the car got to focus on and nail the use case and user experience before it was able to really take off. Do we really think of end-to-end user experience of programmers? Smalltalk had some human factors thinking put into it, but I'm not sure this happens for new languages with enough applied human factors knowledge and expertise. (And the attention to that sort of detail didn't go quite far enough for Smalltalk either.)

Most programmers are the last people to do that sort of designing. In particular, I think most programmers are too familiar with programming. It's like someone asked a driver of one of those saddle-seated early racing cars to design a minivan.

I think if you want to make a car analogy then languages are more fundamental, like roads. And if languages are like roads then we haven't gotten to the point of really exploring the design space of cars because we're too busy deciding how many lanes roads should have, which side of the road we should drive on, what kind of paving material we should use, and how traffic signs should be posted.

To be competitive in the current web job market, I have to have at least three fundamentally very similar languages under my belt: javascript, and at least two of perl, php, python and ruby. In truth any one of these could easily do the job of the others. Lately I find this irksome. Diversity is only a virtue up to a certain point.

Languages and abstractions aren't really that different. Every time you define a new function, you're in some sense extending the language. In languages with powerful macro systems, this "language extension" is even more potent.

I agree with you that good abstractions (architectures are just large-scale abstractions) are needed, but that doesn't mean the new abstractions won't come in the form of a new language. In some sense, they always will. In the sense you mean, some abstractions fit better into existing languages than others.

I've been following Ooc for a long time, mostly because I liked the syntax. It's a weird blend of C and Ruby.

nddrylliog, I think you should make the "jump to" navigation easier to find in the intro guide.

Made it larger on the opening page ;)

Not to crap on the parade or anything but new languages are a dime a dozen and most all offer the same exact paradigms rehashed over and over and over. What I want is a low level easy to verify OOP/chaining functional concurrent language based on term rewriting. Something needs to be done to allow easier proving of programs with a language that is designed for this. I'm working on one.

> curl: bash -c "`curl -L http://ooc-lang.org/install.sh`

Extra points for this awesome install process. I wish more projects would make a seamless newbie experience higher-priority.

Why not LLVM? Some language compiling to C99 seems kind of outdated since we have LLVM. (And if C99 is really wanted, LLVM can output that too. Whereby nobody really is keeping that up-to-date because noone really is interested in it.)

rock, ooc's compiler, supports compilation with clang ;)

You mean ooc -> (rock ->) C -> (clang ->) llvm?

I mean ooc -> llvm.

Not only that it is obviously faster and simpler, it is also better to maintain and better to optimise. And it gives more power and possibilities to the ooc compiler.

Yeah, seems obvious right? But having a C backend (independent of LLVM) still has advantages. I will continue to maintain it, even if/when we get an LLVM backend.

I only wish llvm-c would suck less, then we'd get proper bindings and be able to write the llvm backend in ooc.

Why not just write the LLVM backend in C++? The C++ interface is actually pretty clean and really easy/trivial to use.

Then we'd need to access the ooc AST from C++, which is also quite a piece of work. (I mean - it's easy to use ooc code from C in a C-like way, e.g. MyObject_myMethod(arg1, arg2), but in C++ that would be tedious/inacceptable)

Besides, what's the point in having a shiny language if we have to use C++ to implement part of its compiler :(

Whoops, my bad, I didn't thought of the self-hosting. Somehow I thought that the compiler is written in C.

How complicated would it be to link against C++ code from within ooc code?

Not too bad, use -linker=g++ and declare your functions extern "C" in the C++ code

If it is easy, why not just use the LLVM C++ interface in the ooc compiler?

rock -> C99 (compiled with clang)

Not to be confused with "Ook!" http://esolangs.org/wiki/Ook!

This is like "Go" / "Go!" all over again, except more people have probably heard of "Ook!".

You think that people who monkey around with eso-langs are in danger of confusing the two?

Probably not, since Ook was designed for orangutans. However, those orangutans would probably take offense to describing their work as 'monkey'ing around since avoiding that word is one of the design principles.

http://www.dangermouse.net/esoteric/ook.html

Or Orc, which keeps to hold my fascination since I first discovered it, weeks ago.

http://orc.csres.utexas.edu/

Hopefully I will have more time for it and SR:

http://www.cs.arizona.edu/sr/

Main reflex: Some useful syntactic advances over Java, but where's the beef? I see generics exist at runtime - what else?

Also, is the type system known or believed to be sound? Are there casts?

There are casts, closures, and more. Feel free to join #ooc-lang on irc.freenode.net to have more informative discussions ;)

The introduction guide HTML rendering is annoying. It needs at least a width of 1280. I usually keep my browser window width at about 700, sometimes even less.

"ooc is a modern, self-hosting, object-oriented, functional, high-level, low-level programming language. It strives to be powerful, modular, extensible, portable, yet simple and fast. ooc translates to C99 via rock, our self-hosting compiler."

Is this for real? Because it sounds like someone is overselling their langauge way too much.

yes, very much for real, feel free to talk about it at #ooc-lang

You forgot "sexy"

ooc is a ... high-level, low-level programming language.

Can someone please explain how it can be both?

It can be very expressive and high-level when you just want to get stuff done - but it also allows you to get down to the bare metal in case you have to/want to.

You can turn off the GC, control when and how the memory gets allocated, use pointers to deal with raw memory blocks, easily link with ASM, and the consuming features are easy to avoid - leaving you with a nicer syntax for C. Of course, in the real world you probably want to find a compromise and not go 'full metal'.

Thanks. Makes sense now.

C++, as an example, can also be both.

I agree that C++ can be very low-level. As far as being high-level.. it's still desperately stuck years in the past, even with all the bloat C++0x (or whatever it's actually called) brings to it =)

</troll> (with a hint of truth)

I use C++ and Objective-C, sometimes both at once (go go gadget GCC). I've had a look through the OOC website - does OOC offer me anything I don't already have?

Sexy syntax. C++ and Objective-C both have the superset-of-C ugliness.

Well I'm sold.

Reply on news.ycombinator.com