Slashdot Mirror

Mulitple languages... Ada for sure, and also C++, and probably others.

C++ coding standards for JSF. http://www.stroustrup.com/JSF-AV-rules.pdf

The fact that the Joint Strike Fighter's coding standards are based on MISRA C is not a good advertisement for it. The JSF's software still doesn't work right and they've been working on it for 20 years. Following MISRA C didn't avoid those problems.

> I've never heard anyone refer to C/C++ (or languages of similar power) as 'dangerous' before.

It is obvious you haven't been using C/C++ very long, Bjarne Stroustrup said this about C and C++

C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off.

There is even a famous book:

Enough Rope to Shoot Yourself in the Foot: Rules for C and C++ Programming

Stroustrup's "The C++ Programming Language" is not intended for teaching C++.

For that purpose he wrote this text:

http://www.stroustrup.com/programming.html

The rule of three doesn't come from a C background; it is part of RAII, something that C does not have.

This statement is wrong. It is precisely because of backward compatibility with C that this is the design of the language. As C structures can be assigned and copied, so must C++ structures.

"In the strict mathematical sense, C isn't a subset of C++." -- Source: http://www.stroustrup.com/bs_faq.html

"C++ is a superset of C" -- Source: http://www.stroustrup.com/bs_f...

Yes I am suggesting C++ is a lot better. What the fuck does Microsoft and cross platform have to do with anything?

A lot better than what? A kick in the teeth? Yeah, probably; but only just... C++ ain't all that. Actually it was INTENTIONALLY DESIGNED AS A PRANK. In fact, according to the Father of C++ Bjarne Stroustrup, the joke's on YOU... So, enjoy your PRANK of a Language, Suckas!!!!

Ok, so I'll "out" myself before anyone else does...

The "IEEE" interview linked-to above is (well, duh!) a FAKE!

Gas Music From Jupiter, INDEED!!!

But according to the "horse's" website, HERE IS THE REAL INTERVIEW.

Or is it...? (Sorry, couldn't resist)

Bjarne Stroustrup has always maintained that the ability to do systems programming is an essential feature of C++. It was designed that you should be able to write very resource-constrained, performant code when necessary.

Not too long ago he wrote a very good essay on the benefits of languages like C++ for infrastructure programming, and how it can save memory (and electrical power, even).

Since C++11 the destructor invocation in case of an exception is guaranteed. http://www.stroustrup.com/bs_f...

> Game programmers often use C++ (for various reasons).

Performance is the #1 of reason, but yeah, C++ gets the right balance of power, compactness, performance, and multi-paradigm design which builds upon C's foundation.

> What do you typically use to write programs?

Just because I'm vocal, and passionate, doesn't mean I toss the baby out with the bath water.

I would be stupid to ignore the wisdom of Bjarne Stroustrup:

There are only two kinds of languages:

* the ones people complain about and
* the ones nobody uses.

To answer your question:

Pragmatic C++. (With some Javascript, since WebGL is my (current) day job)

Which is the balance of the middle ground between basic C and the modern over-engineered clusterfuck of C++. Why do you think there was an "Embedded C++" movement years ago which removed all the Templates, Exception Handling, and RTTI junk? Gee, look, Ubisoft C++ usage does the exact same thing.

To clarify, I use _only_ templates when it makes sense. Most of the time it doesn't. I use #define macro's where it makes sense. Most of the time it doesn't. I don't use Boost because it is over engineered 99% of the time. I uses classes where it makes sense. I use 3rd party libraries only when necessary. I use design patterns only when the model fits - instead of trying to shoehorn the code+data into a broken model.

I've shipped enough games where a full build was 45+ minutes. This is insanity.

Minimal C++ is the mantra. Use the expressive complexity and power of the language when it matters. Most of the time it doesn't.

I just want the insanity of C++ to stop and address the common core issues instead of adding yet-another-flavor-of-the-month concept. Retarded ideas like 2D Graphics Rendering API proposal is the epitome of everything wrong with the committee. Completely out-of-touch with reality and solutions in search of a problem.

When you _even_ have a C++ committee member admitting he writes in a sub-set of C++ himself you know the language has gotten too big. /Oblg. Murphy Computer Law: Inside every large programming language is a smaller one struggling to get out.

*ALL* programming languages suck. Most suck even more.

Want to know someone else who hates C++? Andrei Alexandrescu. *Every* C++ programmer should read until they grok Modern C++ Design: Generic Programming and Design Patterns Applied Guess where he works on now? D (All Things D (programming language) - A Conversation with Andrei Alexandrescu.)

When you even have Scott Meyers at a D Conference (DConf 2014: The Last Thing D Needs (Scott Meyers), you know the language has potential. D has its own problems but I would keep my eye on it. :-)

As bad as C++ is, for my needs it is better then the alternatives.

Here is Stroustrup's take on learning C++, which includes some examples of why you might not want to start with C first.

This 100%. C++ has become a clusterfuck of over-engineering and I say that as someone who has worked on a C++ compiler.

* /Oblg. Comedy: Hitler on C++

When you have even committee members admit they only use a sub-set then you know the language is too big.

The C++ committee recognizes there are many problems with C++ iostreams but nothing is being done towards performance and type safety.

The committee would rather argue over the rare case of multi-dispatch / multi-methods then fix core issues.

* http://www.stroustrup.com/mult...

Crap like long long, "long double", etc. should have been deprecated in year X, and removed in year X+5. Are they going to add "long long long" someday?? Having types like "double" in 2015 is just retarded -- replace it with "float64_t", and the fore mentioned long double with the clear "float80_t". Bandaging the problem like int_fast32_t doesn't solve anything. How many fucking integers types does the compiler need to throw at us?? short, long, long long, int, long int, int_fast32_t, int_least32_t, etc. and I'm not even talking about MS's hacks of __int32, __int64, etc. Simplify the dam language already!!! Set year 2020 as the date when these barbaric types are deprecated, and year 2030 when they are removed.

Modules have been in a constant state of on-again-off-again for over 10 years:

* First mention N2073 (Sept.2006)
* Revived N4047 (May 2014)
* 2nd draft N4214 (Oct. 2014)
* 3rd draft N4465 (April 2015)
* Wording N4466 (April 2015)

The pre-processor is STILL broken. One would expect #define token operation to work for ALL user-defined tokens. i.e. This isn't rocket science, just a basic Search-and-Replace:

#define @(func) printf("%s\n",func)
 
void foo()
{
  @(__func__);
}
 
// Hell, even this should work
#define @ printf("LOL. Your pre-processor is broken. HA-HA!\n" )

There are no standard pre-processor macros for function names as a string. GCC has the excellent __func__ which Microsoft finally got around to implementing C99 N2340 in Visual Studio 2015!

The C++ committee failed to learn the first lesson about design:

* "Needlessly complexity is a symptom of bad design."

Or paraphrased from Einstein:

* "Things should be as simple as possible, but no simpler"

> So we all program in different dialects, and then scratch our heads when we read other peoples' code.

The practice of programming in dialects is more a function of the origins of the language than the size of the language. Stroustrup's most recent book does a marvelous job of demonstrating how little you have to know to program in C++ effectively: http://www.stroustrup.com/prog...

C++'s C compatibility is both its strength and its weakness, and the weakness primarily comes from people treating it as a bunch of add ons to C. If you scrap that attitude, it is entirely possible to be proficient in the language after a year of use and capable of reading most anyone's code (assuming they aren't shooting for obscurity) in another year or two. That's longer than some simpler languages, but it is hardly sufficient to excuse people's ignorance.

> I had one applicant tell me he had experience with C, C+, and C++. Orly.

There is actually a C+ programming language, according to Stroustrup: "The slightly shorter name 'C+' is a syntax error; it has also been used as the name of an unrelated language." But it's highly unlikely your applicant knew anything about that. I can't even find a description of it online.

http://www.stroustrup.com/bs_f...

Just scroll down to after the links at the top and you even got a sound-file with it! :)

Well, he has given that answer several times. On his FAQ, he says:

"There are only two kinds of languages: the ones people complain about and the ones nobody uses". Yes. Again, I very much doubt that the sentiment is original. Of course, all "there are only two" quotes have to be taken with a grain of salt.

C++

Started in 1979 (which for D is 1999), and by 1987: "In 1987 USENIX, the UNIX Users' association, took the initiative to hold the first conference specifically devoted to C++. Thirty papers were presented to 214 people in Santa Fe, NM in November of 1987." (page 36 in A History of C++: 1979-1991.

Objective-C

Debatable. From Wikipedia: "Objective-C was created primarily by Brad Cox and Tom Love in the early 1980s at their company Stepstone.[2] Both had been introduced to Smalltalk while at ITT Corporation's Programming Technology Center in 1981. The earliest work on Objective-C traces back to around that time.[3] [..] In 1988, NeXT licensed Objective-C from StepStone (the new name of PPI, the owner of the Objective-C trademark) and extended the GCC compiler to support Objective-C, and developed the AppKit and Foundation Kit libraries on which the NeXTstep user interface and Interface Builder were based. While the NeXT workstations failed to make a great impact in the marketplace, the tools were widely lauded in the industry. This led NeXT to drop hardware production and focus on software tools, selling NeXTstep (and OpenStep) as a platform for custom programming."

So while Objective-C really didn't take hold until it was the de facto implementation for iOS, it was a central component for a major commercial endeavor, and went with Jobs to Apple.

SQL

From Wikipedia: "SQL was initially developed at IBM by Donald D. Chamberlin and Raymond F. Boyce in the early 1970s.[13] [..]

In the late 1970s, Relational Software, Inc. (now Oracle Corporation) saw the potential of the concepts described by Codd, Chamberlin, and Boyce and developed their own SQL-based RDBMS with aspirations of selling it to the U.S. Navy, Central Intelligence Agency, and other U.S. government agencies. In June 1979, Relational Software, Inc. introduced the first commercially available implementation of SQL, Oracle V2 (Version2) for VAX computers.

After testing SQL at customer test sites to determine the usefulness and practicality of the system, IBM began developing commercial products based on their System R prototype including System/38, SQL/DS, and DB2, which were commercially available in 1979, 1981, and 1983, respectively.[15]"

What did D have going for it in 2009 in comparison?

ML and Haskell (while not as "major") also took a long time to find their feet.

I'll pass on these. They're both still niche. Anyways, it's been 15 years since the start of D (or 13 since the work has been made public). It's hardly a young language, especially when you compare it to the success C++ had on the same timelines, which is the most appropriate comparison here.

Good point. I checked out http://www.stroustrup.com/appl... and I can see they're mostly all quite demanding applications. I guess they deserve a demanding language :) But yes, fair enough. There are plenty of times getting the most out of what you have is going to be important.

I once worked on Java code which ran on the most ludicrously limited hardware. It was like treacle. I spent a lot of time tuning that code. Logging was the worst offendor, but some poor algorithms lurked in there too. Garbage collection was quite noticeable, even after rewriting to minimise it as much as possible.

Yet I don't even regard C++ code written without smart pointers to be acceptable, and it certainly misses the whole point of C++.

I thought the whole point of C++ was to add functions to structs to allow object-oriented programming. Or at least that's the idea I got when I read D&E.

I'm not asking rhetorically btw. You seem to be a couple steps ahead of me.

I don't know about that, but......IMO:
I would call Stroustrup misguided for a lot of reasons. :)

More seriously though, the design philosophy of C++ has always been, "if there is a language feature people want, make it available." I don't claim to read Stroustrup's mind, but adding garbage collection fits that design philosophy.

The other design philosophy of C++ is to try to make it fast. So most likely garbage collection in C++ will be an optional feature, that can be turned on or off. There is already a garbage collector like that available with GCC. Or possibly they will learn from Apple's experience, and make something like ARC, which is not exactly garbage collection, but still takes care of 99.99% of your memory issues. This article goes in depth on some of these issues, although it's looking at it from a mobile standpoint, not a server standpoint. I believe that story was covered on Slashdot, too.

Incidentally, I can't find any reference to where Stroustrup says garbage collection is inevitable. This seems to be his official position.

Thanks for the hint, but I've found the Wikipedia page on it (and the first results on the web) not very exciting. However, Software for Infrastructure from Stroustrup has a really cool example on how to do it very pretty. It uses user-defined literals to create expressions such as "Speed s = 10m/2s".

C++ is well suited for game development, because it gives you the abstraction level and speed computer games require.

You're not very demanding if you claim that C++ gives you "abstraction levels" of any kind. But then again, historically, game programmers have never been suckers for abstraction levels. They were using assembly instead of Forth in the 1980's, C instead of C++ in the 1990's; these days, I guess they're using whatever in C++ gives them the best speed and skip the rest.

When i said abstraction level i was talking about programming language abstraction (operators, keywords, types), not on the class/object level, from the language point of view C++ is very abstract. language abstraction leads to class abstraction and other abstractions. In fact C++ is defined as "A light-weight abstraction programming language" (Bjarne's 2012 Keynote). Developers should start listening to what he has to say, he's very smart dude.

I'm actually not professional game developer, just an armature one trying to learn and explorer my way to the professional level and create my own games. I am developing web-based client and server software for 15 years, so what can i say ... technologies like emscripten just look the answer i was looking for for my needs, desire and long term development.

If you wish people will be able playing your game even in a 100 years or more, you better build them with C or C++.

inability to communicate good ideas is more an indicator the ideas aren't that good

If you find his book too complicated, then check out Stroustrup's other book, "Programming Principles and Practice using C++", which is more like a high school text book. Or check out his amazing and simplistic site for the aggregation of information crucial to c++, http://www.stroustrup.com/C++.html

He may not be the greatest writer, or the most congenial, but his ideas were great, and no one can argue against it. No language is as dominant and most crucial to the world's infrastructure, and his books (and his online material) are a great companion in your time of need.