Programming languages

[BenTC]

The "C" programming language is probably the best thing ever done to destroy software productivity

"C" was fit for purpose as operating system programming language requiring direct access to hardware, with tight resource restraints. You might consider it high-level-assembler. It improved software productivity for developing and porting Unix. The genesis of the C programming language is imparted here. The trouble perhaps was its spread from systems programming to application programming and some syntactical issues carried over from its heritage of the typeless BCPL and B languages, and well as the ease with which pointers could accidently corrupt the heap and stack.

C++ on the other hand is a mongrel beast of an OO language that should have been shot in the head at birth - darn you Microsoft!!!! Why oh why could you not have chosen Objective-C with its Smalltalk roots?

For anyone needing some mastery in C programming, I highly recommend this book:
http://www.amazon.com/Expert-Programmin ... 0131774298

[pfrit]

There is a common misconception that one programming language or another is more efficient than another. With few exceptions, there are all equal in output code. It is simply easier to build efficient compilers for some languages. With C it is easy to write a compiler that leaves most of the task of efficiency of the output code up to the programmer. A bad C programmer can write truly crap code. The more work you put into the back end of a compiler, the more efficient the output will be. I worked at a compiler company that made C and ADA compilers for military embedded chips. We produced fantastically efficient output with both. The back end knew how to make the meta language (the middle pass) more efficient by unwrapping loops and inserting optimized sub-code. A bad programmer could still screw it up.

[BenTC]

...but before you choose which language to program in, you should know How To Shoot Yourself In the Foot

[MSimon]

Ben,

Ever write extensively in Forth? It does all that OS stuff and simpler. How about a 4K (compiled) OS?

It is not about output though. It is how the language makes you "think".

Thinking Forth

Forth encourages small fragments of code and proper factoring. C because of the stack thrash encourages larger modules that are hard to test and hard to reuse.

And Forth was object oriented way before C++. And Objects in Forth are easy to understand while C objects are not simple. Check out the "Builds" and "Does" constructs in Forth. Simplified: Builds - builds a data base and Does - acts on it.

And then there is the write everything twice in C so the compiler can understand what you are doing. Yuck.

Typical productivity in Forth vs C can run any where fro 4X to 30X. In time. Ask FedEx. Or any of the Space Programs written in Forth. The Shuttle Arm for instance.

Did I mention that you can pass more than one parameter on the Stack? Why? Because Data and Return stacks are separate. And the kicker. Because Forth is a virtual machine it can be easily converted to hardware. It was first done 30 years ago. Check out the RTX200/Novix line of machines.

Registers? In Forth you add more by making the stack deeper. Simple. Data paths don't change. You want a 100 register machine? Make a 100 word deep stack (i.e. a bigger RAM block). Try doing that in a register machine. Well you can. But then the instruction words get longer. You have to redesign your assembler. What do you have to do in Forth? Nothing except change the hardware.

Or as we used to like to say back in the day:

Never underestimate the power of the Forth.

[choff]

I've been playing around with Fedora for over a year, and after finding out about the C Shell using C decided to read a book on it. Over 10 years ago had a couple courses in Basic, Pascal, and Assembler. The thing about C++ is, you can create a functioning program that can do things not intended. Thats a very hard thing to do with a language like Assembler. In my estimation, its much more vulnerable to exploit.

[MSimon]

I've been playing around with Fedora for over a year, and after finding out about the C Shell using C decided to read a book on it. Over 10 years ago had a couple courses in Basic, Pascal, and Assembler. The thing about C++ is, you can create a functioning program that can do things not intended. Thats a very hard thing to do with a language like Assembler. In my estimation, its much more vulnerable to exploit.

It is a problem with FORTH as well. You need SOB disciplined managers to make it work. OTOH I have taken English majors and trained them to write excellent code. Why? Well English majors understand WORDS. In fact well written FORTH is as easy to understand as English.

Constructs like:

Turn-On Grinder Motor

are easy.

[blaisepascal]

I've been playing around with Fedora for over a year, and after finding out about the C Shell using C decided to read a book on it. Over 10 years ago had a couple courses in Basic, Pascal, and Assembler. The thing about C++ is, you can create a functioning program that can do things not intended. Thats a very hard thing to do with a language like Assembler. In my estimation, its much more vulnerable to exploit.

I've been programming since 1985 in dozens of languages (including C, C++, at least 4 different assemblers, APL, Forth, Scheme, ML) and I doubt that I've once yet come across a language that I haven't written a functioning program that does things not intended. The language doesn't prevent programmers from writing bad code, the best it can do is eliminate certain classes of bad mistakes that the previous generation of language designers didn't know about or how to fix.

A classic problem (which C is known to be vulnerable to, but Java isn't so much) is buffer overruns -- where you try to access the 101st byte in a 100-byte buffer, for instance. When dealing with buffers in assembler, nothing is automated; for every array access you either have to know that it won't overrun, or check that it won't. If you get it wrong -- don't check that one place where you thought it was safe but it wasn't -- you've got a potential exploit. But putting in checks is expensive in terms of developer overhead, so it's easy to forget or to convince yourself it's OK here incorrectly. C makes it a little easier to code, but you still have to be careful about every buffer access.

Newer languages build bounds checking into the language, so you can't forget it. But there are always ways to write bad code.

[MSimon]

Forth - being extensible at the user level can add bounds checking easily. Or any other belt and suspenders device you might care to add.

But because Forth makes checking so easy you can fix stuff at the design level with hardly any muss or fuss.

C is ideal for sloppy programmers because it checks a lot of stuff. The price you pay is the ugly Cast construct. And the difficulty of making what used to be easy (in assembler) difficult.

I always was more of a word guy (by a slight margin) than a math guy. I'm told that is not true of most engineers.

And the way C handles pointers with the * construct is one of the clumsiest ways to build such a device I could imagine. But having started out in assembler (and I LOVE assemblers) I could be prejudiced.

[chrismb]

Anyone who claims to be an engineer, but doesn't desire to use Fortran 77 when programming, is too young to be considered truly competent.... Just an opinion

[bcglorf]

Or the argument from the view of someone still young enough to now everything:

Arguing over fortran or forth is like arguing whether it's better to make fire by rubbing sticks or banging rocks.


On a serious side I like using lua, lisp and php, but obviously I don't need to interact directly with hardware either.

[MSimon]

Why would any one want to learn programming just to promote global warming hysteria?

[BenTC]

I am familiar with RPN programming from developing applications on the HP calculators. Years ago I thought about trying Forth, but didn't have a purpose to use it at the time, or access to a system. However I'm doing control system work now, so it might be useful to know more. So since I do like expanding my horizons to open up my options, and good books make so much difference, I've bought the book. Thanks for the reference.

For a long time I ignored Fortran as "ancient" and irrelevant, but am now now thinking that was a mistake. Its now on my list of things to do.

Another language I do hope to have the opportunity to explore on day is ERLang that was developed by Ericsson.

[Tom Ligon]

You pups! I started out with Fortran IV (back when we used Roman numerals for everything, which, trust me, was a really awkward way to enter numerical values on punched cards).

I do not miss Fortran.

I do miss Pascal, an elegant language. Turbo Pascal 7 was fast, efficient, and stripped itself of unused code so that it compiled compactly. It was interchangable with Borland's Turbo C++ compiler, and played well with Turbo Assembler. I prefer procedures to voids ... C is just ugly.

C was intended to be transportable between platforms. Oh yeah? Just try telling one of the software engineers here that they need to move our existing code to a new processor! Screaming, hollering, tantrums ... not a pretty sight. C does nothing useful without headers and libraries that are almost never standardized. By the time you install enough of these to get your code running, you wind up with a porker full of unused junk with unpredictable habits, slow to compile, and a memory hog.

[chrismb]

I do not miss Fortran.

Just gimme a language that I can toss complex variables around in, with ease, then I will consider it suitable for engineering purposes!

[DeltaV]

I do not miss Fortran.

Spaghetti code is a choice, not a requirement. You can write clean, blazingly fast, structured, modularized code with Fortran90 or newer. It excels in fast number crunching for array data and deeply nested loops, and add-on libraries for things like OpenGL are easier to use than those for C and its ++/#/.... spawn. I don't miss the punched cards either, and I haven't used a goto since the 70s.

C does nothing useful without headers and libraries that are almost never standardized. By the time you install enough of these to get your code running, you wind up with a porker full of unused junk with unpredictable habits, slow to compile, and a memory hog.

Fully agree.

Lately I bought Mathematica Home Edition (only ~$300, but a very Draconian license, use it for personal enlightenment only). I've only scratched the surface of what it can do, but within a few days I was doing some interactive 3D visualizations, using about 10 lines of code, that compare roughly to ones I'd done in Fortran using ~10000 lines. To be fair to Fortran, about 95% of those 10000 lines dealt with setting up and implementing the GUI in the Windows event loop. Mathematica is under-appreciated. I hope they don't go the MATLAB route and bloat it with too many "features". Unlike MATLAB, their user support has not yet migrated to India.