Which programming language is more useful?

[MattieShoes]

Code: Select all

genSANMoveString(currentMove, moveString);
printf("%s", moveString);

That's what I do in my code at least... I actually prefer it to cout << currentMove for some reason. It feels more explicit, and I could call genLANMoveString(...) to produce the more typical engine output (e2e4, e1g1, etc)

[Zach Wegner]

That's funny!

However, should you ever want to display something other than a double, how do you do that with printf?

Code: Select all

// In C++

Chess::Move   CurrentMove;

std::cout << CurrentMove;


/* or in C */

printf("what goes here", &CurrentMove);

As long as we only need some ints or a double, add them up, and display the result, C works just fine.

Solution 1:
printf("%s", move_string(move));

Solution 2:
custom_print("%M", move);

QED

[michiguel]

It teaches the use of the C++ standard library, containers, iterators, overloads, generic functions, and user defined classes, before going into the really difficult stuff like pointers and arrays.

...

There is a lot of C that is of very little use, once you have learned the better ways of C++. So start there!

Just for the pleasure of pumping gas into our little flame war, I show you the words of Linus Torvalds:

C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

http://thread.gmane.org/gmane.comp.vers ... ocus=57918

Man, this guy is insane. He's great.


(Linus doesn't like operator overloading, too much abstraction, boost, stl)

Jorge Luis Borges was asked by a French journalist what language should they speak in the interview. Borges said "Let's speak in French, which is the perfect language...." and he continued with his typical wit...

"They say that the French language is so perfect that it needs no writers. Conversely, they say that Spanish is a language that is so desperate because of its own weaknesses that it needs to produce once in a while a Gongora, a Quevedo, or a Cervantes."

We can use this to state:
They say that the C++ language is so perfect that it needs no good programmers. Conversely, they say that C is a language so desperate because of its own weaknesses, that it needs to produce once in a while a Ritchie, a Thompson, or a Torvalds.


Miguel
PS: These religious wars do not affect me, because in this case I am agnostic. However, good laughs can come out of it.

[Tord Romstad]

Boost, which was linked above, is also good to learn. It should be considered an essential part of C++ programming nowadays.

Boost would be useful, if it were part of the standard, or a de facto standard in the sense that you could rely on it to be installed everywhere. One of the main points of using C or C++, at least for me, is to make it as easy as possible for anyone, regardless of the platform, to compile and run the program. It should be possible to just unpack the source code and type 'make', without having to download any extra libraries.

Boost, unfortunately, is far from ubiquitous. It's not part of a standard Mac OS X install, for instance. I'd love to use it (at least for threads and sockets), but as long as it prevents my program from compiling right out of the box on some of the major operating systems, I can't.

Tord

[Tord Romstad]

Solution 1:
printf("%s", move_string(move));

A problem with this solution is that it is not clear how to implement the move_string() function, because of the lack of a real string type in C. You would probably have to do something like this:

Code: Select all

char *move_string(Move m) {
  static char str[MAX_MOVE_STRING_SIZE];
  sprintf(str, ...);
  return str;
}

Which is quite ugly, and probably not thread-safe.

Solution 2:
custom_print("%M", move);

This would force you to reimplement the entire functionality of printf(), which is a lot of work, besides being ugly. Moreover, you have no type safety. There is no way to check at compile-time that the parameter paired to the %M directive in the argument list is a move.

There are also numerous other limitations: You'd have to find new custom_print directives for every new type you want to support. If you ever distribute your custom_print() function as a library without source code, users will have no way to extend it to new types, and will have to roll their own, just like you had to do when printf() didn't fill all your needs.

The only sensible way to handle IO with user-defined types is to define methods for each type for converting the type to and from strings, and to let the stream input/output functions of the language call these methods. This way, everything becomes fully extensible and type safe. C++ does get this right, apart from the incredibly tasteless choice of syntax.

Tord

[Gian-Carlo Pascutto]

Boost would be useful, if it were part of the standard, or a de facto standard in the sense that you could rely on it to be installed everywhere.

The more interesting Boost libraries are becoming part of the standard TR1/TR2, and recent gcc's ship them out of the box.

One of the main points of using C or C++, at least for me, is to make it as easy as possible for anyone, regardless of the platform, to compile and run the program. It should be possible to just unpack the source code and type 'make', without having to download any extra libraries.

Boost, unfortunately, is far from ubiquitous. It's not part of a standard Mac OS X install, for instance. I'd love to use it (at least for threads and sockets), but as long as it prevents my program from compiling right out of the box on some of the major operating systems, I can't.

Tord

In this case you can't really rely on very much besides the standard library, which doesn't offer portable way to deal with the things you mention (threads, sockets). In fact, that's also the main part of Boost I use exactly because of this reason. I'd rather deal with the Boost dependency that rewrite this code several times, and have to do some magic to correctly guess which version (POSIX, Win32, ...) I have to use at compile time.

So I draw the line at introducing a dependency at the point where I have to write code for multiple platforms. (In fact, the features that require Boost in Deep Sjeng can be turned off for small platforms. You don't want to cluster a bunch of embeddded ARM's)

You have to make a choice about what range of platforms you want to support. I believe Boost is now a reasonable choice for most platforms. For some platforms I want to run on, it's not, but for some of those, modern C++ isn't either. So this is just as much an argument to write ANSI C rather than C++, let alone Java: it's more portable.

I was actually a bit surprised that on many Linux distributions, it's difficult to get the latest Boost without installing it yourself. The problem seems to be a combination of C++'s lack of ABI guarantees and stability. I guess Mac OS X has the same issue.

[Bill Rogers]

There is always the old question "which came first, the chicken or the egg?" Being that C++ was an offshoot of C to begin with it only makes sense to learn C first as it will lay a good foundation for later learning C++. As many people here have said C++ contains a lot of advance subroutines that are not available in C but they would be appreciated by those who have mastered C to begin with. You must walk before you can run, etc. To be sure that there are some really smart people here who learn C++ first does not automatically make it suitable for all begining programmers.

This all reminds me of a time years ago when someone found maching language commands that acted very much like those in "Basic" and by using those 15 or 20 little commands people were able to write code in machine language. It worked, I know because I used it for a few years.
The point is it gave the users a better understanding of machine language programs to begin with, so choosing C over C++ is a better way to start.
Bill

[MattieShoes]

C is neither the chicken or the egg. It was derived from older languages (B?), which were derived from even older languages (BCPL?) Surely they all lead back to assembly at some point. I'm sure some would recommend learning assembly first too

There's nothing wrong with learning C first, but I think learning a higher level language makes things more immediately rewarding because you can make things happen faster. Learning a language with C-like syntax seems advantageous because you're learning most of the syntax of a bushel of popular languages simultaneously, but beyond that? I don't think it makes a whole lot of difference which language you choose.

[diep]

Programming languages are different, but the underlying logic is the same for all of them.

Many people think so, but I don't agree, and I think most people who make such claims have never been exposed to any languages apart from descendants of Algol (like C, Pascal, Java, C#, etc.). Once you move to other paradigms, you'll quickly be forced to think about algorithms and data structures in new and initially completely alien ways. Try a concatenative language like Forth or Factor, a lazy, purely functional language like Haskell, a dynamic object-oriented language like Smalltalk, or a logic language like Prolog.

I find that learning new programming languages is an fun, addictive and often mind-bending experience, as long as the new languages are sufficiently different from those I already know (going from Pascal to C, for instance, wouldn't be a big change).

Tord

Actually Haskell isn't pure functional. It also has stuff inside that allow imperative programming, which is why Haskell was so popular within the functional language domain.

That's why implementing a checkers program a year or 15 ago, i used only pure functional parts of Gofer and didn't use imperative extensions of Haskell for it.

It was factor 10000 slower than a C version i wrote, which code later was the basis for my 10x10 international checkers program later called Napoleon (together with Marcel Monteba).

Just using functional things like lazy evaluation and other phenomena's, let's not even speak about lambda notations, it's just too slow.

That's the problem with c++ also.

An imperative language is simply giving more nps for majority of the programmers. Maybe there is a handful of exceptions and by accident that's nearly all of them top chess programs with Pradu to come probably there.

So having a very good understanding on how to write low level code seems really important. No other object oriented programmer manages. If i look to companies how very good object oriented programmers are over there, none of them would manage to write a chessprogram that's really fast. They total lose it to guys that program at the same level in an imperative language such as Fortran or C. Good object oriented code is ugly SLOW code. Sometimes up to factor 100 slower. Generic code nearly always is slower and templates and such nonsense just make up for bigger codesize, which in case of diep already gets hit so hard.

C and Fortran are more than enough of a high level language to write a chess engine, that's reality.

It won't get a project of 10 people, where object oriented languages have an advantage in maintenance, especially figuring out who produced what bug in which module.

That would all slow down a chess engine too much.

Having a good understanding of how processors in general work and what is slow and fast, is a necessity to write a chess engine simply that's strong.

It is requirement 1.

Vincent

[sje]

I was actually a bit surprised that on many Linux distributions, it's difficult to get the latest Boost without installing it yourself. The problem seems to be a combination of C++'s lack of ABI guarantees and stability. I guess Mac OS X has the same issue.

With Mac OS/X, a bunch of the system interface topics like threads and timers are already covered by NextStep, er... I meant "Cocoa". So there's not much motivation for Apple to finance Boost integration and deployment.