Oddly enough, after a re-read, the original post by David that I responded to had Python in it, not Ruby. So yes, I guess I was guilty of reading too little. I guess after having a page or so of "C++ is evil" and "C++ can't do X", I got carried away, as I already noted.



Not at all. That is not what I am saying. I am saying that, to a "native" speaker of two languages, my experience is that two similar phrases (such as those cited before, both the map/transform and the english/dutch) will require little enough extra "processing power" to be unnoticeable. I'm pretty sure I don't need to write a research paper to make that claim. I would perhaps agree that, to a non-native speaker, languages can look a lot more complex than each other. Here, that's mostly because of the slightly different range concepts in the two languages. Trading brevity for expressiveness? That's a different argument.



My work domain has a reasonable amount of vector maths in it. Call it muscle memory. http://en.wikipedia.org/wiki/Absolute_va...

It's the same problem that people have in C++ about the shift operators being used for i/o. It's a mental hurdle to get over.



I already conceded that I was getting carried away. Please don't belabour the point.



The point was that, once the boilerplate was in place, modifications to the algorithms are short and simple. A different measure of conciseness, sure.



Yes!



No, not really. Unless you have some research papers on the subject…



Really? Then why does the Python code talk about cartography? I recall being quite stumped for a few minutes at university with the concept of "map" (and as for fold… Grr). "Transform", however, says what it does much more clearly. The python is obscure as well, except to people who know how to read it. Kind of my point.

I'm pretty sure that we're viciously agreeing on a couple of points here…



Gosh. tra<CTRL-SPACE>.



Coz, you know, nobody ever makes subjective claims about their personal experience on forums. o.O

Re: Kaz

Here's some things I want you to answer:
* Do you use any other programming language? Do you know any as well as you know C++?
* What do you think is the most compelling reason to use C++? Which projects are fit to use C++ for?
* What is the most compelling reason not to use C++? Which projects are it not fit for?
* Specifically, what is your biggest complaint about C++? Specifically, what do you like the most about it?

Ooh, fun. Should probably be split off, but whatever.

First, I want to say I'm not trying to dismiss any other languages here; merely defend certain aspects of C++. Perhaps somewhat overzealously. *shrug* Lots of languages are great.

With that said,



My everyday job has me using C++. I enjoy the language and will be open by saying that it is by far my favourite. I find its capabilities and its expressiveness to be first class. That's not to say it has no downsides, though.

During my pre-university days, I wrote an awful lot of Turbo Pascal. Once at university, I did mixtures of Pascal, C and C++, and my final year project was written in (self-taught) Java. Java's moved on a lot since then and I can't say I've kept up, though it's certainly a fun language to program in. We also studied other language paradigms, using ML and Prolog as the functional and declarative examples. I tinkered around with a couple of other languages – Eiffel, Smalltalk, etc. – at the same time. I looked at a couple of assembly languages (MIPS and x86) during a compiler writing course. I've written a good deal of C code for a couple of muds out there. I even wrote my own language (with its own VM - that was fun) during development of my own (unreleased) mud codebase.

I also write the occasional Awk script.

Oh, and how could I forget A2191 ADSP assembler. *shiver*. Now there's a language where conceptual clarity seems to have been eschewed.



It's my experience that people starting up a project should choose a language for that project with two criteria: 1) Is the language capable of doing the job. 2) Does everyone know the language.

C++ is fit-for-purpose for a huge variety of projects, from operating systems (despite what Linus says) and embedded systems, to video games to desktop applications. It's possible that, for some of these projects, features of the language may have to be selected carefully, but the same goes with most other languages (I remember the whole Swing vs. AWT days of Java).



If one doesn't know how to use the language (or any language), one probably shouldn't start a large project with it. The biggest complaint of C++ is its complexity. This is largely because of its C legacy (not that C was particularly complicated, but it didn't extend easily). Off the top of my head, I'd say that C++ isn't fit for anything that's like dynamic scripting.

Additionally, there are certainly other types of project for which certain languages are far better suited. For example, Perl and similar languages are still pretty much king when it comes to text processing (I said above that I use Awk occasionally. That's mostly to compile metrics and produce reports for Lint results). C++1x is getting a built-in regex library, along with some fun-looking user-defined string types, but I don't know how it'll compete. Should be interesting.



It has the right balance of control and expressibility for me, I think. It has a mixture of compile-time and run-time dispatch mechanisms that seem to hit a sweet spot in my brain, and it has an enormous toolbox to support all of this, from standard object orientation stuff way up to metaprogramming.

So… s/C++/<your favourite language> to you.

I'm not sure if you aren't registering or aren't believing me when I say that this is a debated topic in linguistics, psychology, etc. If you insist on making these claims, you might want to start by reading pages like this one and the linked references.


I'm not wholly sure if you're being facetious, or even disingenuous because we're supposed to be comparing "native speakers", not people who'd think that "map" means "cartographic instrument". I'd also really rather that you be more careful and read more attentively, because the Python version doesn't talk about the 'map' operation at all. :sad:


Sure they do. But they don't usually do so by stating that they're correcting assertions. :wink:

If your only claim is to argue personal preference, I certainly won't try to stop you. I get the impression that we are, as you have hinted at yourself, pressing buttons of yours and words are being understood to mean things they weren't supposed to mean.

Ugh. I'm still getting the Ruby and Python mixed up in my head. I think I'm gonna do the sensible thing and a) wave a white flag, and b) get a coffee.

(I'm actually serious about having stumbled a bit on 'map', though.)

It would be rude to pick apart your answers to my questions after being kind enough to answer them, but I think your reply really makes clear our break in philosophy here.

Huh? It may do to you, but I have little idea what your philosophy is.

Anyway, you may have missed the last line, but I asked the same questions of you, with respect to your favourite language. Perhaps that will fill the gap.

I'm not Kaz, but these aren't bad questions for anyone to answer, really.

Yes, several. Yes, better in fact.

In my case, I'm a C warhorse. I learned BASIC, then assembly, then C on the Commodore 64 (Yes, we had a C compiler, and it even had colour syntax highlighting in 40 columns!). Later, I learned Pascal, Fortran, COBOL, and a bunch of other obscure languages that used to be popular. When I started working, it was in Visual Basic 3 and VB5 (the company was migrating). Then I learned Perl, and picked up some C++ along the way.

So, for me, I would say I know C and Perl *MUCH* better than C++. I know Ruby and Python enough to read them, but not enough to consider myself any kind of expert.



Personally, I'd use C++ for anything you'd use C to do. C++ is a lot like Perl. It's NOT an object oriented language (as much as its proponents would like it to be one), it is an object-enabled language. Perl works like that too. In both cases, you can build objects and lay out their interactions and hierarchies… or you can ignore them and work with the functional interaces.

What would I use C/C++ for these days? Anything where timing is critical, because compiling from source to assembly (and thus machine code) is still superior to compiling from source to a virtual machine. Not all that MUCH superior, but if you're doing stuff in real-time where you only have a set window to respond to events, that can be the difference between pass and fail.

Also, anything where it's super-CPU intensive and the problem space has already been worked on in C++. There's no point in re-re-reinventing the wheel if there's a perfectly good library you can use. If such a library does a good chunk of your work for you, its existence may be the deciding factor for language choice.


I would NOT use C++ for a MUD. In fact, I wouldn't use it for any non-graphical game. I also wouldn't use it for general utility work. It's the wrong solution for all these things.

Why? Ok, for general utility work, C++ is just too much of a pain. If I want some small task done, I want it done quickly, and I'm not going to spend a month drawing up a proper design document and object hierarchy. I'm gonna sit down and write something in an hour to do the job. Ruby, Perl, Python… all great language to do this. C++, that hour will be spent mostly copying boilerplate and making the compiler happy that I've jumped through the right hoops.

Why not for a MUD? MUD's (and most text games) spend a good chunk of their time processing text. C++ is a dressed up version of C. It does not handle strings as a native data type. To C or C++, a string is just a block of memory that happens to have a NULL byte at the end, and which may (for C++) have some type checking and operator overloads to make it easier to work with. However, you can't build a MUD without dealing with the standard OS library (libc), and *THAT* knows strings only as the old C style char * pointers. So, no matter how nice your string class is, you still have to kludge things back and forth into NULL-terminated madness to get the job done.

This is more of that boilerplate…. you have to spend as much time transforming your data around to make the library API happy, as you do actually working with the data. C++ is better than C for this, because of std::string and such, but it's still weak sauce compared to any language which treats strings as a first class data type.

What do I like most about C++?

Hmmm….. *thinkthink*…. I guess that it is a mostly-strict typed language. IF you're willing to put in the time to code something properly with it, you will be less likely to get stomped on by runtime conversion errors. By this, I mean silly things like passing in an integer when you mean to pass in a string, but having the language auto-convert it without error… so your application happily eats your data and you end up with database records like "First_name: Bob, Last_name 387". 387 was, perhaps, the customer number instead of their name, but because the language auto-converted it, the database couldn't report the type mismatch either (it was the string "387"). Note that this isn't unclean user input, this is a programmer error, and one that C++ would have caught by saying "no method foo(std::string, int)".

No, not necessarily. When you're doing JIT compilation, or really any compilation at runtime (which is what, e.g., the JVM does) you can look at real program execution statistics and optimize the usual case. But a static compiler can't do this. So, you can have super-fast code optimized to how functions are actually used in practice, and fall back to some normal version in unusual cases.

That said, not many dynamic languages collect intelligent runtime statistics to allow this kind of analysis, however the above quoted statement is becoming somewhat precarious.


This "kludging" is in fact very simple: you just call c_str(). Besides, there are very, very few places where you need to talk to OS functions that only understand char* strings, like networking, and in that case you're not doing anything more complex than shuffling stuff around anyhow into your nice string class. The vast majority of string work doesn't need to know about char* strings. If you're going to criticize C++ strings, it should be that it's difficult to construct them dynamically; creating an ostrstream is possible but verbose; there is no easy, lightweight regex support even for simple things like splitting and joining; etc. Whenever you start doing things like this, you need to reach out to a plethora of libraries, which adds all kinds of complication.

No, it's not.

Use whatever language you feel appropriate. Personally, I find C++ ideal for mud development.

It's pretty hard to evaluate this statement and separate hyperbole from true opinion; "ideal" is a pretty strong word. How much have you evaluated alternatives? How well do you know the alternatives? Is it "ideal" or "good enough"? etc.
I'm not trying to tell you that you're wrong (although, in the interest of full disclosure, I don't share the opinion), I'm just trying to understand what makes it "ideal" (which to me is a rather strong statement). Of course, it might not be worth discussing what are essentially personal opinions, unless you feel that there is something objective (meaning, easily, functionally comparable) that makes it ideal.

I used C/C++ for 8 years. I also have experience with Java, perl, and smalltalk. I work with Python from time to time, but really just enough to somewhat read another script. Currently I develop with Ruby.

The most compelling reason to use Ruby is, in my opinion, the amount of facility it brings to your finger tips in the form of standard libraries, profilers, and debuggers built in. The high level, object oriented approach of the language is appealing to a lot of projects, as well.

The most compelling reason NOT to use Ruby is obvious. It's very 'slow' compared to something like C++. Also, it's not as easy to sandbox as something like Lua. Generally I find the need for the speed is exaggerated. For a project like a MUD Ruby is just fine on modern servers.

I actually have plenty of complaints about Ruby. Most recently I've been complaining about the metaclass syntax. I don't like that the open classes aspect involves a lot of people defining helpers that become essentially used everywhere except in standard library distributions. I don't like that Ruby doesn't come with any type of compilation options without using an alternative implementation. I don't like how class variables work in Ruby. I don't like that Ruby gems are often so dependent on C code based on a specific implementation. There should have been a better way of using Ruby to redefine core functionality without being implementation specific. (See Rubinous). I hate the ugly perl practices that are kept around for legacy. Such as the regexp matches going to $_ or whatever. I don't like how difficult it is in Ruby to estimate how much memory you're using with any given data structure or section of code. It usually doesn't matter, but it can make it difficult to optimize on a macro level.

I think he means "ideal" to him (personally), so the scope of his statement
was from his point of view.

As I said, I'm not trying to dispute personal opinion (a fruitless endeavor anyhow); I was merely trying to find the reasoning behind the sentiment, assuming that the reasons are technical, functional, etc. It's always interesting to find why people hold certain preferences, unless it comes down to "I like chocolate and you like vanilla".

When it comes to C++ I think some people just like the precise lower level control it gives them to build their framework.

That's a very interesting point, I think, and one worth exploring. What does "framework" mean in this context?

If you look at languages like Lua, Python, and Ruby, you actually have a great deal of low-level control on the framework. You can add all kinds of hooks, and even change fairly fundamental things about semantics. (In Lua, for example, you can add hooks for when variables are declared, and transform expressions into declarative, lazy-evaluated formula specifications. You can probably do this stuff in Ruby/Python/whatever, I just haven't looked into it.)

But of course these languages don't give you to-the-byte control. C++, of course as well, does.

So what does low-level control over your framework really mean? Does it mean controlling each byte in memory at a low level in the OS, or does it mean controlling the semantics, the OO definition itself, at a low level?

A lot of people – and I'm not saying that KaVir is one of them (hence why I asked the question) – think that having per-byte control gives them expressive power. But this is an odd statement, depending on what you're doing. Expressive power is almost by definition related to semantics. But sometimes, sure, what you need to express can only be done at the byte level. Arguably, though, that is oftentimes not what people are trying to express.

I just think a lot of people want to express exactly what they want to express and nothing more. It somewhat bothers a lot of people to do something higher level that might accomplish what they're wanting but at the expense of being general purpose. This is the reason you still find people who dispute C++ vs C as inefficient. I happen to disagree a little bit.

I think building a proper framework in C++ probably takes some time per larger application. Keep in mind someone like KaVir has been working on his for ages. It's no surprise that today C++ would be perfect for his project. it's what he knows best, and it's what he's spent developing his mud with for ages. It's probably finely tuned as a project.

As far as what's ideal for a MUD it just doesn't make sense to me to use a low level language. Mostly because the benefits of such a thing are becoming more mitigated by modern hardware every day. I also think there's a weird misconception that you don't have any low level control, as you said, in higher level languages. Which is untrue. It just so happens that once people really start working with higher level languages they typically stop prematurely optimizing stuff.

Also, one more point. I think some people enjoy the process of low level code. Which is a bit like wanting to examine everything at ground level and build something with your hands. Some people, like me, care more about the bigger picture from a birds eye. We care more about results than the process, perhaps.

If the statement is that C++ is better because the whole codebase is written in it, then the statement isn't really about C++ so much as the amount of work it would take to change things. Sometimes it makes sense to stay with an imperfect tool when changing tools would not be worth the effort.

As for low-level control, well, I'm a little surprised to hear you say that it's a misconception. Heck, even Java, lower-level than the dynamic languages discussed here, doesn't let you do things like pointer arithmetic. Perhaps we're simply using the term differently…

I think it's a misconception because in many higher level languages it exposes the low level API directly. For example, you can interlace C/C++ into your Ruby code pretty seamlessly to define methods on your classes that need to be fine tuned at a low level way.

Well, if the statement is that you have control because you can use C/C++ extensions to give you that control, I won't disagree with that. But that seems like saying that in the end of the day, you have the control because C++ gives it to you. :smile:

That said, you still don't get control over details like object deletion, memory block allocation, etc., short of (again) using extensions to do it. I think that this is the kind of stuff that is considered low-level.