Critter: Pascal vs C

[Bo Persson]

I absolutely don't want any kind of flame war or c++ vs anything else.

In my opinion everybody is more productive with the language that he likes, whatever this language is.

I was just asking


P.S: An hint to avoid discussion is to answer with the name of the features someone (I have asked to Hyatt but of course I am interested in anyone's opinion) thinks are poorely designed instead of something vague and so prone to be discussed like "many features", "a lot of thing" or other sentence with very small information content in.

But alright, I will say that I intently dislike the way templates are done, as well some of the overloading.

When you have to guess which gets called and promoted and so on, something is seriously wrong with the language.

I also don't like how some things in C++ may not result in the nice, simple, quick code you expect. It is possible to stay with a reasonably safe & efficient subset of C++, though.

Don't listen to this!

He is just saying that badly written C++ is worse than good C. Nobody argues about that.

In well written C++ you just don't have to guess what overload is called, because it shouldn't matter. All the overloads should do the same thing for its respective parameter type.

In C++ you call std::abs(x) to get the absolute value of x. In C you must choose between abs, labs, fabs, cabs, and whatever. Much more difficult!



Who didn't want to start a language war?

[michiguel]

Remember that C was never intended to be a tightly-defined idiot-proof language. It was designed to let you write portable code, while getting as "close" to the hardware as you wanted to get to obtain max performance and flexibility. No one would begin to claim that assembly language has any useful type-checking or constraints, and C was designed to eliminate the assembly language itself, without hurting the performance you could expect. The older "register" declaration is a good example of how close to assembly it would let you get.

I know that and I agree with most of that.

I do take exception that they couldn't have added a little safety. Even asm macro languages can have some safety to keep you from making mistakes. Like trying to transfer a FPU register to a cpu register. Or trying to treat an address register like an ALU register. Or...

I also have to take exception about it being designed for portability. The original C was nearly antithetic for portability. It went out of its way to be very PDP'ish. It wasn't designed 'on' the PDP, but *for* the PDP.

It took a lot of effort in the K&R era to reach tolerable portability levels. In both the language and the library. And it took 10 years for the first C standard to work out enough of the flaws in k&r to make it into a somewhat portable language. Even function prototypes was a radical idea!


C was designed to let the user do nearly anything they wanted with no concern for whether it was *right*. That's a very poor design goal.

Over the years, C has added some safety, but very little. And along with that, they've even abstracted some stuff, in the name of portability. It's permissible for the compiler writer to actually hide some of the CPU stuff. (Think NULL is always zero. Nope. It can be anything. But it has to behave *exactly* as if it was, including transparent conversion when you use it or try to check its real value.)

I hated Pascal. I know what I want to do when programming, and I don't want the compiler to get in the way and make me jump through hoop after hoop. Writing a compiler in Pascal was a syntactical challenge. Writing one in even Fortran was much more pleasant, and in C it was a wonderful project for students.

I agree the classic versions of Pascal (like you used) are a PITA to use.

That Pascal should never have been developed.

Years ago I tried using an ISO version of Pascal. (shudder!) That was even worse than the original.

(Just look at all the hoops that Larry Atkin had to jump through to write Chess 0.5 That's an excellent example of how bad the Pascal language used to be.)


Fortunately, modern versions (started with TurboPascal) have left much of that idioticy behind. Not all, but much of it.

There are still types and you can't blindly (or accidently) confuse a char and an integer unless you choose to. If you want a small integer, then you *say* you want a small integer and not a text character.

If you say a var is going to represent a color, you aren't going to be able to accidently put a piece type in there.

You can still do what you want, with the compiler catching mistakes. Like this C code:

#define WHITE 1
#define PAWN 1

int SideBasedVar[...]; /* White / Black */

func() { if (SideBasedVar[PAWN]) .... }


Pascal, then and now, does require you to think a bit differently.

That's part of the point and the problem. After years of C programming, it is *hard* to think logically and properly and not like C's "Everything is an int" attitude.

That is the problem. C gives you the freedom to do whatever you want, but that does not mean you should do it. I learn with pascal, and stayed with it for a long time. I started comp. chess with the excuse to be proficient in C and I cannot be happier for that.

My programs in C are as safe (or unsafe ) as my previous programs in pascal or more. Almost nothing is int, and I use typedefs for everything (except local counters). The ability of pascal to check things are basically hidden asserts. I have those same asserts explicit in my C code. In fact, they are much more powerful because I can be very picky with them when I need them, or they can spit very useful info in the debug version.

At the same time, there are very stupid habits that you develop with pascal. For instance, the OCD attitude that you cannot break any loop except with flag variables detected in only one spot. Many times this is not the best way to do it.

C is very dangerous if you learn programming with no discipline. But, if you already have one (coming from pascal you have to much discipline ), it is great.

Pascal is great to learn programming and I am grateful I did it with it.

Miguel

You can write proper code in C, but it doesn't encourage it and it wont notice if you don't. It even encourages you to not write properly.

That's why I said I've been brain damaged by C.

In the old days, I could write Pascal code pretty well. It all made sense and I thought that way and writing was easy. I didn't have to jump through hoops or struggle with the compiler to let me do something. (My first Pascal compiler was slightly more advanced than the classic ones. It had relaxed type checking like what is common these days.)

After 20+ years of C programming though, Pascal is no longer easy for me. I've been brain damaged.

[mcostalba]

In well written C++ you just don't have to guess what overload is called, because it shouldn't matter. All the overloads should do the same thing for its respective parameter type.

In C++ you call std::abs(x) to get the absolute value of x. In C you must choose between abs, labs, fabs, cabs, and whatever. Much more difficult!

DISCLAIMER: I am a big fan of C++ that I consider miles ahead of anything else.

Said that I have also to say that overload in C++ is not for the faint of heart. Overload and the strictly related names lookup alone are bigger then the whole C, and an order of magnitude more difficult.

Yes, you can chose, as always with C++, to just scratch the surface and limit yourself to use an overload for dummies : same function name different number/type of arguments and that's all.

But if you start to dig, as I guess you now very well, it quickly become extremely difficult.

Of course you cannot use "extremely difficult" as a synonym of "misdesigned", at least until you don't have understood the subject and I would think people with C background and that think of C++ as a "C with objects" are not at that point.

I consider myself well versed in C++, but still I don't remember/know all the name lookup rules and special cases.

[Don]

Have you looked at D by digital mars? I really like that language although I have only done a little programming with it. It tries to be a much cleaner C/C++ without compromising performance. And it does this by not trying to be a superset or subset of C, it's it's own language but you will be immediately comfortable with it if you are a C programmer - because it does not go out of it's way to be different either.

It's also object code compatible with C, so you can write C routine all day long and just link it in.

I still haven't moved over to it for a couple of reasons. I don't know for sure where it's going - it's not open source although it's free and I fear it is totally dependent on one man. And it seems to be just slightly slower than GCC although in principle it should be faster than C since the author of the language made design decisions that would enhance the compilers ability to optimize it (in ways that C cannot.)

Remember that C was never intended to be a tightly-defined idiot-proof language. It was designed to let you write portable code, while getting as "close" to the hardware as you wanted to get to obtain max performance and flexibility. No one would begin to claim that assembly language has any useful type-checking or constraints, and C was designed to eliminate the assembly language itself, without hurting the performance you could expect. The older "register" declaration is a good example of how close to assembly it would let you get.

I know that and I agree with most of that.

I do take exception that they couldn't have added a little safety. Even asm macro languages can have some safety to keep you from making mistakes. Like trying to transfer a FPU register to a cpu register. Or trying to treat an address register like an ALU register. Or...

I also have to take exception about it being designed for portability. The original C was nearly antithetic for portability. It went out of its way to be very PDP'ish. It wasn't designed 'on' the PDP, but *for* the PDP.

It took a lot of effort in the K&R era to reach tolerable portability levels. In both the language and the library. And it took 10 years for the first C standard to work out enough of the flaws in k&r to make it into a somewhat portable language. Even function prototypes was a radical idea!


C was designed to let the user do nearly anything they wanted with no concern for whether it was *right*. That's a very poor design goal.

Over the years, C has added some safety, but very little. And along with that, they've even abstracted some stuff, in the name of portability. It's permissible for the compiler writer to actually hide some of the CPU stuff. (Think NULL is always zero. Nope. It can be anything. But it has to behave *exactly* as if it was, including transparent conversion when you use it or try to check its real value.)

I hated Pascal. I know what I want to do when programming, and I don't want the compiler to get in the way and make me jump through hoop after hoop. Writing a compiler in Pascal was a syntactical challenge. Writing one in even Fortran was much more pleasant, and in C it was a wonderful project for students.

I agree the classic versions of Pascal (like you used) are a PITA to use.

That Pascal should never have been developed.

Years ago I tried using an ISO version of Pascal. (shudder!) That was even worse than the original.

(Just look at all the hoops that Larry Atkin had to jump through to write Chess 0.5 That's an excellent example of how bad the Pascal language used to be.)


Fortunately, modern versions (started with TurboPascal) have left much of that idioticy behind. Not all, but much of it.

There are still types and you can't blindly (or accidently) confuse a char and an integer unless you choose to. If you want a small integer, then you *say* you want a small integer and not a text character.

If you say a var is going to represent a color, you aren't going to be able to accidently put a piece type in there.

You can still do what you want, with the compiler catching mistakes. Like this C code:

#define WHITE 1
#define PAWN 1

int SideBasedVar[...]; /* White / Black */

func() { if (SideBasedVar[PAWN]) .... }


Pascal, then and now, does require you to think a bit differently.

That's part of the point and the problem. After years of C programming, it is *hard* to think logically and properly and not like C's "Everything is an int" attitude.

You can write proper code in C, but it doesn't encourage it and it wont notice if you don't. It even encourages you to not write properly.

That's why I said I've been brain damaged by C.

In the old days, I could write Pascal code pretty well. It all made sense and I thought that way and writing was easy. I didn't have to jump through hoops or struggle with the compiler to let me do something. (My first Pascal compiler was slightly more advanced than the classic ones. It had relaxed type checking like what is common these days.)

After 20+ years of C programming though, Pascal is no longer easy for me. I've been brain damaged.

[Dann Corbit]

In the past 2 months I was experimenting with bitboards. At the point I had working board class and captures/evasions/checks generator, I fell in love with them. My only concern was speed. I am very disappointed with the performance of delphi compiled code. Looking through the disassembly of generated code the compiler seems to be 15 years behind any decent C compiler out there. Inlining sucks, register allocation is poor, dependency chains are HUGE. It cannot even unrool simple loops with constant number of iterations (for i:=WHITE to BLACK). Not to mention absence of 64bit target...

Then I decided to learn C and try to port Critter. So far I have working perft and the results are _very_ promising.

There are the test result fors perft(5) in 300 WAC positions:

Code: Select all

        |        Pascal       |      C 32bit       |      C 64bit
--------+---------------------+--------------------+------------------                 
time    |   1220163 ms        |   730547 ms        |   536157 ms
speed   |     18793 knodes/s  |    31338 knodes/s  |    42769 knodes/s

While I expected _some_ improvement, this is simply outrageous, the 64bit C version is more than 2x faster !

There is a 64 bit free Pascal compiler. What happens when you try that one?
http://www.freepascal.org/

[Tord Romstad]

Have you looked at D by digital mars?

I have. The problem is that even though it sacrifices backward compatibility with C, it still tries too hard to resemble C++. I can't get excited about a somewhat improved C++. What I would like to see is a low-level programming language with a modern, powerful type system, type classes, type inference, a minimalistic, but programmable syntax, source code as data, and a Common Lisp-like macro system.

The only programming language which comes close is BitC. Unfortunately, the project is not likely to ever get finished.

I would still vastly prefer D over C or C++, of course. If there were some top-quality optimizing compilers for all the major platforms, I would certainly consider switching to D for low-level tasks.

[rvida]

There is a 64 bit free Pascal compiler. What happens when you try that one?
http://www.freepascal.org/

I didnt try 64bit FPC yet, but 32bit FPC produced a little bit (5-7%) slower binary than Delphi. Now I am busy with the mailbox version (rewriting king safety code and implementing some endgame knowledge). As soon as it is finished I will resume my experiments with bitboard version.

... in the last weeks I enjoyed C so much that it is very hard for me to write Pascal

[Ron Murawski]

Have you looked at D by digital mars? I really like that language although I have only done a little programming with it. It tries to be a much cleaner C/C++ without compromising performance. And it does this by not trying to be a superset or subset of C, it's it's own language but you will be immediately comfortable with it if you are a C programmer - because it does not go out of it's way to be different either.

It's also object code compatible with C, so you can write C routine all day long and just link it in.

I still haven't moved over to it for a couple of reasons. I don't know for sure where it's going - it's not open source although it's free and I fear it is totally dependent on one man. And it seems to be just slightly slower than GCC although in principle it should be faster than C since the author of the language made design decisions that would enhance the compilers ability to optimize it (in ways that C cannot.)

I like the language myself.

Some minuses:
- The Digital Mars version is 32-bit only
- One man dependency
- Poor error messages

A Plus:
- GCC can compile D.
See: http://dgcc.sourceforge.net/

That one plus offsets most of the minuses.

Lately the language has lost its first flush of popularity. See the popularity chart (based on search stats):
http://www.tiobe.com/index.php/paperinfo/tpci/D.html
and where it fits in with other languages in terms of popularity.
http://www.tiobe.com/index.php/content/ ... index.html

Ron

[Tord Romstad]

A Plus:
- GCC can compile D.
See: http://dgcc.sourceforge.net/

That implementation is incomplete, outdated, and no longer in development. The leading free implementation these days is LDC; the LLVM D Compiler. Unfortunately, the LDC web page appears to be down at the moment.

My impression is that GDC is completely dead and abandoned, and that the developers have moved to LDC.

[Ron Murawski]

A Plus:
- GCC can compile D.
See: http://dgcc.sourceforge.net/

That implementation is incomplete, outdated, and no longer in development. The leading free implementation these days is LDC; the LLVM D Compiler. Unfortunately, the LDC web page appears to be down at the moment.

My impression is that GDC is completely dead and abandoned, and that the developers have moved to LDC.

Thanks for the info, Tord. My outdated link goes back to the days when I was investigating/learning the D language.

Ron