Hacker News Reader

Comment by Roboprog | Hacker News Reader

Back in 1990, it didn't take long to figure out that (Borland) Turbo Pascal was much less insane than C. Unfortunately, it only ran on MS-DOS & Windows, whereas C was everywhere.

Employers demanded C programmers, so I became a C programmer. (now I'm a Java programmer, for the same reason, and think it's also a compromised language in many ways)

For anybody who is willing to run a few percent slower so that array bounds get checked, there is now an open source FreePascal environment available, so as not to be dependent on the scraps of Borland that Embarcadero is providing at some cost. Of course, nobody is going to hire you to use Pascal. (or any other freaky language that gets the job at hand done better than the current mainstream Java and C# languages)

View on HN

Pascal, in general, was an amazing language. Simple to understand, compiled to native code - honestly the only complaint you could now (with FreePascal) make about the language is that it is a little "wordy."

Much the same as D - which was my initial thought when I read "friendly C." We already have a friendly C.

When I first learned C, after having used Turbo Pascal for years (back in the 80s) it was frustrating. When I finally understood it well a little later, I felt like I had taken off the shackles of Pascal...

Granted, original, 1970, flavor Pascal on the CDC Cyber was very limited. I'm curious, though, what is it that Turbo Pascal 5.0 and above would prevent you from doing?

It's been a while, but if I really have to, I could cast a pointer to a long, increment it by sizeof in a loop, and cast it back to a pointer in Pascal to do pointer arithmetic in a tight loop.

I can use procedural types anywhere a function pointer in C would be used.

I can make complex constants (tables) just like a pre-initialized array of structs in C.

There is an extension to return in the middle of a function/procedure rather than toggling flags to pinball-style drop to the end of the routine.

I can set compiler pragmas to allow/force me to check for error codes after every memory and I/O call (at the risk of accidentally stumbling on to cause secondary damage), rather than just failing with a line number.

I can nest functions inside of other functions, and reference the enclosing variables, just like in GNU C (oh, wait, that's a non-standard GNU extension), even if I can't return such a function as a "use it later", honest to God closure.

What are the shackles? (I'm probably in for a face palm, oh, that, moment when I get the answer, but I'm drawing a blank at the moment)

> What are the shackles?

I think it would be supporting libraries. Looking at RedMonks's statistics[1] Pascal doesn't even feature (I was able to find ~600 on GitHub). By today's standards that's a pretty big shackle, you'd have to write a lot of functionality yourself (although that's ignoring that you can use C libraries with a little effort).

I love the language, it just had no staying power. Maybe people just prefer curly braces.

[1]: http://redmonk.com/dberkholz/2014/05/02/github-language-tren...

>> curly braces

and "wokkas"

I mean, how many XML interpreters do we really need? At least for Java, it seems like there are too many "Enterprise!!!" libraries that seem to exist to extend the lameness of the language by requiring you to write a DSL in XML.

I suppose for C there really are a lot of low level libraries that actually do things, though, such as read/write sound and graphics files, or implement useful abstract data types. Things that might seem "built in" in a 21st century language/environment, but not in C or Pascal.

Reply on news.ycombinator.com