Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Justice]

I've used lambda expressions in C++, they're nifty.  Not a big fan of C# in general, but I haven't used it since it was a fairly early version (1.1, I think).  It had a lot of problems then that weren't documented, like the problem with foreach not operating in-place on collections (it made a new collection, copied all references of the specified type into the new collection, and iterated over that).  I suspect if things like that still exist people know not to use them.  Great if it's awesome now, though.  Still wouldn't use a garbage collected language as primary for most types of games myself, but it would be something I would consider for tool development if I had to make something Windows-only and had to use Microsoft's tools.

[CptFastbreak]

There's also that Haskell code is almost always shorter than the corresponding C/++ code. One example is parsing. A parser in C written in a thousand lines can sometimes be written in 30 lines using the appropriate parsing library in Haskell!

I have no hands on experience in Haskell, still I feel obliged to point out that such a comparison is not really fair. If you're using appropriate libraries, anything in any language will be shorter than in any other language without using libraries. It's true that C++ wasn't really designed for concurrency since it wasn't that much of an issue when C++ came into being, also that concurrency is easier to achieve in languages explicitly designed for it, but what with it being a multi-paradigm language it is certainly not impossible to achieve concurrency if you're disciplined. After all, Google's map/reduce also is implemented in C++.

On the other hand, C++ is not a bad language if you are a disciplined programmer who knows how to design their code. There are a thousand different ways you can overdesign in the wrong direction and screw yourself, particularly with OOP. But if you are awesome at it, C++ gives you a great deal of power in multiple ways. Performance reasoning is easier, you have all the C/++ libraries you could ever want, and you can write the program at the level of abstraction you like.

++ on that. As Stroustrup pointed out in TDECPL, language comparisons are generally unfair because mostly you can do anything in any language in some way, or even if you can't, most languages add it at some point. It's mostly a matter of programming culture and what you feel comfortable with/what you're experienced in. There's this interview where Google's Pete Norvig (who is a big LISP fan) answers Reddit users' questions in pretty much the same way.

Having said that, I would like to take the opportunity to pimp Ruby to everyone looking for a scripting language for a small project, simply because it's very elegant and really fun to code in.

[catsplosion]

No one has mentioned Lua.  It's not as neat as Haskell -- if you're a programmer and haven't grokked Haskell, you owe it to yourself, or at least ML -- but it's immensely practical.  It cooperates with C more nicely than any other language I've ever tried to embed, which gives it the immense advantage that Toady could shift new functionality to it gradually.  It's fast enough to handle everything except pathing, flows, temperature, cave-ins (not that we have them), and weather, and it would be an absolute armoksend to modders

The biggest problem in such a mature project is that it embeds so nicely that there's a temptation to use Lua's userdata to store things that already exist in C++, instead of using Lua's datatypes to really take advantage of the language.  One nice thing is that, as with other extensible languages, if Toady ever changed the Lua api you'd only have to write a wrapper that would make the new api look like the old one and old scripts could run.

The second biggest problem is that Toady wants to protect his source and avoid the severe spoileriness that comes from knowing everything.  That's fine.  If he used Lua for things that belong in the raws anyway, there'd be no conflict.

[jfs]

The second biggest problem is that Toady wants to protect his source and avoid the severe spoileriness that comes from knowing everything.  That's fine.  If he used Lua for things that belong in the raws anyway, there'd be no conflict.

Part of Lua's heritage in fact is as a data definition language. It can be great as a way to have very flexible configuration files, and would probably be well-suited for what the current DF raw data format is used for.
(Oh, and Lua is among the fastest interpreted languages, and you can use it as a purely functional language if you want to, too. There's also JIT compilers for it, and I wouldn't be surprised if there is or at some time comes, a Lua compiler that targets LLVM.)

[Footkerchief]

Haskell (or any other FP language) is not something you would use for program if you want to ever finish it.

Well, that would make it pretty appropriate for DF.

[Rafal99]

Seems very relevant to this thread:

[Baughn]

DF *will* be getting an extension language, eventually, but it probably won't be Lua.

I've looked at several different languages.. evaluating them purely for size, Lua wins hands down, but simplicity of embedding and language features also matter. Especially for the former (which is going to matter for Toady), Lua requires way too much boilerplate.

For the moment, I'm leaning towards Chibi-scheme. It's unix-only, though, so I'll have to port the relevant portions to Windows if we go with that. On the other hand, it's really very nice as embeddable schemes go.. we'll see.

[Baughn]

Please note that we don't mind C. It's dangerous, but useful in the right hands, much like dynamite.

..hm, yes, I guess that table sounds just about right. Though I'm not sure I agree with the rightmost column. I'm pretty sure Java fans would see us an eldritch abomination or something.

[jfs]

Hum, I've found Lua to be very straightforward for embedding, though the stack-based parameter passing in and out of C does get annoying at times. However there are several C++ libraries that simplifies it. (I've always rolled my own, though...)

Chibi-Scheme sounds interesting.

[catsplosion]

I'm not sure where this perception of heavy boilerplate for Lua is coming from, either.  It's really easy to write a few helper functions to deal with it however you prefer, if you don't want to munge the stack too much.  I've seen particular strategies that people often use for registering bunches of C functions for use with Lua; I've never liked those very much, myself.  I tend to use a custom function that generates a Lua table from a printf-style format string, and I focus on a style that doesn't generate many Lua callbacks; instead, I'll use a few functions that accept and interpret Lua tables.

On the other hand, Scheme would be pretty cool.  Except for the headers themselves I haven't found any documentation on embedding Chibi-scheme -- do you have any links, Baughn?

[Baughn]

It's explained in the README, but basically there's a scheme program provided that converts a stub (export definition) to a .c file you can compile.

Then you call scheme functions as if they were ordinary C functions.

..check it out, it's pretty nice.

[barconis]

..hm, yes, I guess that table sounds just about right. Though I'm not sure I agree with the rightmost column. I'm pretty sure Java fans would see us an eldritch abomination or something.

Oh, I don't know. I haven't looked closely at it, having had more need to futz with OCaml code than to touch Haskell, but the Einstein picture seems apt. Concise expressions that require lots and lots of unpacking for my poor imperative-language mind to grasp. Kind of like a Lisp, but with syntax.

[Urist McDepravity]

Kind of like a Lisp, but with syntax.

Lisp is imperative language (or 'multi-paradigm', as lisp-fans claim). Just you need to code directly in AST, and can change it in run-time.

[Lokii]

Well this doesn't seem to have been mentioned yet.. erm...
I'm not to clear on a lot of this stuff, but what about Ruby?

[catsplosion]

Ruby's a terrible pain to embed, and it's pretty big.  Good embedding languages are designed for the purpose.