Come on, Linus, tell us what you REALLY think about C++!

[GreyGeek]

It's a four year old article, but I had never seen it before my son pointed it out to me this week end. Wow! I didn't know that Linus felt that way about C++. Personally, I love C++, but then I'm not in the same league as Linus when it comes to coding. I guess I'll never be working on the kernel!

http://article.gmane.org/gmane.comp....trol.git/57918

Linus unloads on a guy who asked why C++ wasn't being used to write the kernel... "unloads" is too kind of a word...

[Snowhog]

Re: Come on, Linus, tell us what you REALLY think about C++!

Not a programmer myself (well, not really - any more), but I understand where Linus is coming from. C is *pure*. It is, if I understand the hierarchy, one-step above assembly language. C++ (as with all the other +, ++ morphed languages) 'easier' to use because they are so tolerant of user mistakes. As such, a lot of garbage code can be included that should not be present, but is.

[Qqmike]

Re: Come on, Linus, tell us what you REALLY think about C++!

I can't comment on the programming issues (not a programmer these days), but ...
I like his direct, to-the-point style (in that email). Well put. I'd say the world needs more people to communicate so strongly and directly based on their firm, well-informed convictions! IOW, let's take the BS out of our language, too.

[SteveRiley]

Re: Come on, Linus, tell us what you REALLY think about C++!

How to shoot yourself in the foot in any language.

Selections...

C
You shoot yourself in the foot.
C++
You accidentally create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical care is impossible since you can't tell which are bitwise copies and which are just pointing at others and saying, "That's me over there."
Assembler
You try to shoot yourself in the foot, only to discover you must first invent the gun, the bullet, the trigger, and your foot.
...

[blobfish]

Re: Come on, Linus, tell us what you REALLY think about C++!

I read that exchange a while ago and I thought that linus was just sick of the questions of why linux wasn't wrote in "insert favorite programming language" and I guess he really doesn't hate C++ that bad. C was developed along with unix and was designed to help program operating systems. C++ probably didn't add any major benefit to operating system coding and is more of a benefit to application development. Just working with strings is enough for me to choose C++ or C. C strings (char arrays) are cubersome at best.

[GreyGeek]

Re: Come on, Linus, tell us what you REALLY think about C++!

How to shoot yourself in the foot in any language.
....

That was an hilarious hoot!!! I laughed till my sides hurt.

I have experimented with most of the languages mentioned there during the 40 years I coded, but only a few were practical enough to use to earn a living. The language had to include sufficient power to be applicable to almost any problem but sufficiently easy to use to allow rapid development, deployment and support. That rules out Assembler, and most of the others listed, except for use in academia, where time, milestones and customer write offs were not issues.

Forth is my favorite. Before you can use "Foot in yourself shoot" (I also loved RPN - Reverse Polish Notation) you first have to write the threads "Foot", "in", "yourself" and "shoot". Then, it will work! If you ever find a copy of Lee Brodie's "Learning Forth" grab it! It is the best and funniest programming manual I've ever read. Forth produces the fastest and most compact executables of any language, bar none. Unlike Visual Basic, Pascal, or Cute, Forth is a bottom up language. You started at the "inside" of your program and worked out, finally developing the user interface.... not with the GUI, menus, functions and downward to the nitty gritty. You had to know your customer's needs and business inside out before you could write a line of Forth.

The first program I wrote for money, $500 @, was a Land Leveling program using UCSD Pascal on an Apple ][+, in 1980, the year I began my own computer consulting program. Commercial versions that existed at the time used iteration to find a "solution", which usually took 15 minutes or more. I solved a 3rd order differential equation to arrive at an exact solution, which took a few seconds to find. Today it takes a millisecond. The next program I wrote for money was an Amortization Schedule using TuboPascal 3.02A. It did well until Visicalc became popular. It included a demo AS spreadsheet. That's when I went into computerizing a client's entire business process. I rescued several clients from their attempts to computerize their business using Visicalc and subsequent spreadsheets.

My first COBOL program was my last. Written on a Baby 36, with RPG4 doing the reporting, it was like trying to swim with cannon balls chained to your legs. At least with Fortran IV, the first language I ever learned, one could be brief and concise, even if one had to follow column designations.
Paradox truly was. Creating new instances by making copies of the old, which it did every time you made an SQL request, it would easily write off the end of the HD and never tell you, until your app blew up.

I learned Advanced Revelation while driving to a client's site. I steered with my knee while reading the documentation. (Yes, I know, I am lucky to be alive...) The neat thing about AREV was the Pick database on which it was built. It didn't honor the 3rd Normal Form, but used the FD hex byte (253) to separate multiple values in a single field, and each field was "limited" to 32KB, and later 64KB. The table definition was kept in a table "data dictionary", which you could edit without having to empty the table. The data dictionary could hold symbolic fields, which used BASIC like code to manipulate actual data in the data table to produce results. Say you had a table called "Customer Orders". It had the usual links to the Customer table, and a series of fields the contained invoice data.... invoice id, date, inventory id (a link to the inventory table), quantity purchased, price, salestaxrate, 30d, 60d, 90d, etc... A symbolic field called, say, extcost, would mulitply the price by the quantity purchased to give the total amount for that item. Another symbolic field would keep a running total of quantity purchased to give the total for that invoice, which would be multiplied by the salestaxrate, to give the total invoice amount. Each of the fields for a line item in the invoice were muti-valued fields. The biggest problem in a Pick database was that when the tables got large the speed slowed drastically. Even after almost 30 years one of my former clients is still using AREV to manage his photography business. (I would teach clients how to program AREV so that after I left they could do their own maintenance. That wasn't for all of my clients but several had the ability.)


I found polymorphism and inheritance easy concepts to learn, but difficult to put into practice. Users of Visual Basic "thought" that it had inheritance. When I asked them how (because I had used VB in the past) they explained that all they had to do was "cut & paste" a function from one location to another. Microsoft claimed that Visual FoxPro had inheritance, and it did. BUT, (you just knew there was a BUT, didn't you!), after you created a new class by "inheriting" a base class, that actual base class and all of its supporting baggage got carried along into your applications instances, quickly resulting in a bloated application. And, to make matters worse, when Microsoft updated a base class and changed a procedure or property you were using into something you didn't want, changing the base class didn't reflect into your class, as it should, without having to drop your class and rebuild it from scratch. Plus, inheritance in VFP slowed it down to a crawl. On occasions a control on a VFP GUI would "break"... just cease to work. Your only solution was to edit the GUI, delete the control, drop in a new one and customize it to what it was before. IF that control was the parent or part of the inheritance chain, you were in for a long day.

It is Qt's adherence to C++'s polymorphism and inheritance which makes it a joy to use. By adding garbage collection, automatic pointer destruction and such to their QBLOCK, which is the first object added to any inherited class that you create, Qt gave you the benefits of Java without the slowness or the verboseness. Polymorphism and Inheritance allow for a lot of code reuse, which eliminates re-inventing the wheel in every project.

[dibl]

Re: Come on, Linus, tell us what you REALLY think about C++!

My first COBOL program was my last.

Yeah, I hear that!

In my undergraduate work I took a quarter of COBOL. It was 1972 and it ran on an IBM 370. Although I was quickly (and correctly) convinced that I had no future as a career computer programmer, I did manage to get the formula for a paraboloid into a COBOL routine and got it to print a table of values for the 8" reflector telescope mirror that I made that year.

Since then, I've steered clear of anything resembling programming.

[GreyGeek]

Re: Come on, Linus, tell us what you REALLY think about C++!

....
Since then, I've steered clear of anything resembling programming.

Look at what you could have been taught in 1972, instead of COBOL:
# 1954 - FORTRAN
# 1954 - IPL (forerunner to LISP)
# 1958 - LISP
# 1958 - ALGOL 58
# 1962 - APL
# 1962 - Simula
# 1963 - CPL (forerunner to C)
# 1964 - BASIC
# 1964 - PL/I
# 1967 - BCPL (forerunner to C)
# 1968 - Logo
# 1969 - B (forerunner to C)
# 1970 - Pascal
# 1970 - Forth
# 1972 - C
# 1972 - Smalltalk
# 1972 - Prolog

Under than Carbon I'll bet is a Diamond!