CommodoreJohn wrote:Still, given my druthers, I'll take a questionable language that was designed for flexibility and real-world use from the ground up over a questionable language that was hacked into flexibility and usability contrary to the entire spirit of the original project
That's an arguement that you'll hear a lot -- but kind-of forgets that all the useful C dialects ALSO have been "hacked into flexibility" and have NEVER had the "and usability" aspect addressed properly.
Comparing the old vanilla Pascal to any ANSI C or even K&R is unfair at best -- and have you ever dealt with C prior to K&R? Hell, even Ansi C made improvements to the language that the mainframe environment pascals never saw. Is C++ less of a kludge than Object pascal or more?
Of course, that has ALWAYS been the real weakness of pascal -- it's not the language or the syntax, it's the compilers that are often the limiting factor... hence why Borland's implementation, especially once they "allegedly" borrowed object pascal from Apple remains the most successful "pascal" -- though as I often say Object pascal is NOT Apple's idea, it's actually just Modula-2 with a couple minor things renamed. Modula couldn't make it because I've NEVER seen a decent capable compiler for it... so they tricked us by changing a few minor things and calling it Pascal.
Seriously, apart from the swap between "class" and "object" -- just how much difference is there from Modula by the time of say... Delphi 3?
Though to me, the biggest advantage of Pascal comes from how objects work. In C++ and most objective C offshoots objects often feel shoehorned into the language and often LACK the versatile inheritance methodologies like ELF's or even proper handling of constructors/destructors. In pascals, objects feel like a natural extension to the language because they are nothing more than overglorified records that happen to have functions in them.
But then I always considered C's STRUCT's to be uselessly crippled because of the LACK of strict typecasting, definition on how it's supposed to be (or not be) packed, and of course the lack of a length-first string type or more importantly a by-type memory allocation/release mechanism. I'll stack NEW and DISPOSE against malloc/calloc/free any day (though a realloc might be nice!) -- especially with the ability to pass a constructor to NEW and a destructor to DISPOSE WITH parameters... especially when depending on the compiler your constructor/destructor may or may not get run when you allocate a pointer to a class or run the constructor. (really depending on dialect of C or the offshoot).
I can use C and C-dialect offshoots like JS, PHP, etc... but I always feel like kicking someone square in the nuts by the time I'm done.
Though at least so far we've not heard the crybaby "but the rules are too strict" nonsense from anyone. Whenever I hear that one I think the same people who sleaze out HTML 3.2, slap a tranny doctype on it and then try to pass it off as modern markup and professional quality work. Much like HTML 4 STRICT the rules put in place help prevent you from doing things you shouldn't be doing in the first place and making mistakes that can be avoided altogether. There's a fine line between order and anarchy -- and if people would just follow a few simple rules and use programming languages that prevented dumbass mistakes we wouldn't have 20 year old bugs in the BSD codebase still existing in OSuX, the ability to use a memory overflow in many jpeg decoders to actually execute code hidden in a image file, and the billions of other "overflow" type errors that occur due to the idiocy of actually trusting things like null terminated strings to stay in range, for buffer counters to actually EQUAL the end and not go past them due to some process you might not have control over or rogue encoding values in the data stream, etc, etc...
Heh yeah... let's face it, the top programming mistakes made by people using non-Wirth languages? A total lack of RANGE CHECKING and trusting input to be safe to process.
