Hacker News new | past | comments | ask | show | jobs | submit login

I see his point about how everyone rolling their own thing is bad for the Lisp community, but he's got a kind of ridiculous view of C:

"Making Scheme object-oriented is a sophomore homework assignment. On the other hand, adding object orientation to C requires the programming chops of Bjarne Stroustrup."

It really doesn't. You can have a system that uses structs with function pointers, which is how things like Glib work. You can have a compiler that adds special syntax for doing this, which all gets translated into normal C calls; this is how Objective C works. OO is just Not That Hard To Do in any language.

Anyway, Lua is another great example of this curse because there's no module system or standard library to speak of, everyone rolls not only their own object system but their own list functions. The reasons are different though; Lua's design goals are to be a tiny language for embedding, so they sacrifice completeness for being really easy to customize.




Yeah, if you can't implement a basic object system in C, you don't really understand how OOP works anyway.

Also, I definitely agree w/ you about Lua. Great language, but it's so focused on being shape-able into whatever its embedding project needs that the community refuses to settle on conventions for some things. OTOH, it's small & clean enough that running your own fork of it is actually a decent trade-off, whereas doing so with (say) Python would be pretty harsh.


I've been thinking about things I could build that would fix that, but that's sort of how we got into this in the first place. :-)


Yeah. The people who are using Lua primarily in an embedded context (and thus have a lot of dependencies, such as threading & graphic libs, already chosen for them) have VERY different priorities than the people using Lua standalone. It pulls the community in two different (and occasionally opposed) directions, and the Lua team doesn't want to alienate either camp.

(On the balance, though, it's still one of my favorites.)


Yes, definitely. The problem I'm running into is that the people writing the module systems are thinking in terms of running it standalone.

I want a way to get a bunch of Lua libraries and cram them into one thing I can easily embed and make available to my embedded Lua interpreter. I can't really visualize how that would work though, so I can't write it yet.


You can compile a set of (Lua) libraries with luac, then insert the bytecode as a string literal in a C program. loadstring works on bytecode, too. With C libraries, link as usual.

There are utilities floating around to reformat the luac.out file (compiler output), but all you really need to do is put

    static const char *lua_code = "..."; /* with the body escaped */
If you don't end a line with ;, it will be concatenated to a subsequent string literal at compile time. Oh, and multiple lua files can be compiled into one luac.out.

Does that help? If you have further questions, contact info is in my profile.


That's the core of what I was going to do, but I want to put on top of it something like Bundler, where I can specify which libraries I want (and which ones depend on other ones) and it will build it for me.

Although I think the only one I want is Penlight, so that is probably overkill. :)


>You can have a compiler that adds special syntax for doing this

To be fair, C's base syntax is obtuse enough to make any extended C compiler gratuitously difficult. It wouldn't take a genius, but it would take an unreasonable amount of time and pain.


I agree that basic OO is easy, but inheritance (particularly multiple inheritance), virtual functions, RTII, etc. add significant complication.


It's more complication in design than implementation though, and doing it in Lisp instead of C won't help that any. Once you decide what you actually want to write, it's not a whole lot harder to write it in C than Lisp. It's harder, but it's still something that anyone who can do it in Lisp would be comfortable doing in C.


Lua is another great example of this curse because there's no module system or standard library to speak of

I think this, instead of syntax, is the main cause of fragmentation. The more strongly a language community recommends and bundles a module system and a package manager for it, the easier it is to build an ecosystem




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: