Slashdot Mirror

You completely missed the point.

He lacked vision, (let alone intelligence, awareness and knowledge.)

Anyone designing a file systems asks basic engineering questions:

* What's the use case?
* What's the maximum filename length a user would like?
* If we're going to be stuck with this thing for years how long should filenames be?

This isn't rocket science, just basic computer science. You can see the complete clusterfuck of idiotic design in the various OS File System Comparisons

Instead of picking something reasonable like 16, 24 or 32 characters, Gary pulled 8.3 chars out his ass due to his stupidity and short sightedness. He was completely ignorant of The Mother of All Demo back in 1968 (!) that demonstrated 16 key technologies:

* The personal computer
* The mouse.
* Internetworks.
* Network service discovery.
* Live collaboration and desktop/app sharing.
* Hierarchical structure within a file system and within a document.
* Cut/copy/paste, with drag-and-drop.
* Paper metaphor for word processing.
* Advanced pattern search and macro search.
* Keyword search and multiple weighted keyword search.
* Catalog-based information retrieval.
* Flexible interactive formatting and line drawing.
* Hyperlinks within a document and across documents.
* Tagging graphics, and parts of graphics, as hyperlinks.
* Shared workgroup document collaboration with annotations etc.
* Live shared workgroup collaboration with live audio/video teleconference in a window.

I'm glad he and his myopic vision of 8.3 is long dead.

So yeah, Fuck him and his stupidity for inflicting it upon the world.

C is a trivially simple language

You're crazy.

Back in the eighties when I was primarily a C programmer, I spent years mastering the art of writing portable C code. Our main application was required to compile under both the Microsoft and the Watcom compiler, and under the Watcom compiler we targeted both MSDOS and QNX. This was a royal PITA at times. The worst case I recall is that Microsoft had a bug in their type deduction logic for expressions that mixed signed and unsigned values. In actual fact, the Microsoft code generator used the correct rules, but the Microsoft diagnostic routine in the parser did not, causing it to issue "type conversion" warnings opposite to its own internal behaviour. Just imagine how that gave us a bad case of group-consciousness head spin until we tracked down the underlying cause.

It's terribly hard in C to defend yourself against certain kinds of accidental errors, which is one of my original reasons for moving to C++. My well-developed C programming subset (oh yes, I had a subset) was even more robust in C++. For example, in modern C++ there's much less justification for writing complex expressions using #define. Modern C++ programmers largely restrict the use of the C++ preprocessor for implementing a Turing-complete language at compile time.

Is the C99 preprocessor Turing complete?

Actually, I lied. That harmless looking C preprocessor from the dusty depths of time is but a C-hair short of being Turing complete at compile time. The smallest fiddle in the specification of token pasting might get you there.

Concerning underhandedness, the Karen Pease PIU winner would not survive having __isleap() recoded from a macro to a C++ inline function. Many of the other examples abuse the #define mechanism for encoding object lengths, rather than having the objects maintain their own lengths, such as any STL container does.

What you can foist in the unwary if you're off-scale malicious in C++ is off-scale high (it is, after all, a superset of C itself).

On the other end of the scale, if you use C++ abstractions to do good rather than evil, the never-ending refinement of the C++ language takes you to a better place, not a worse place.

Elements of Modern C++ Style

I'm not overly enamoured of Great Man theory, and likewise I'm not greatly enamoured of sanitary-conception language design, in which all the sins of the past are taken behind the woodshed and put straight en masse.

Co-existence with our dirty origins is a simple fact of human biology. It isn't true that every complexity of human evolution is automatically a turn for the worse (as you seem to imply about accrued complexity in programming language design).

The truth of the matter is that C++ used wisely can be a clean and empowering programming language, for those of us able and willing to pay the price of admission.

Whether it's reasonable to pay that price given the many other choices available now is another question. In my case, I had already paid half the price in my first professional decade as a C programmer, after stripping away the illusion that C is simple language.

I'm pretty much agnostic at this point about whether an ambitious young programmer should bother learning C++ or not, unless it happens that C++ is the only vehicle that will take you where you want to go (high abstraction level co-existing with raw hardware performance).

Too many people sit there in a state of contempt fundamentally saying "if C++ is the only viable solution, then I want a simpler problem to solve!"

Well, go to it. Fill your boots. But don't sit there and sneer at the brave souls who make the opposite choice.

Pot. Kettle.

Nope, because you provided no evidence. So here, refute this list. Oh right, you dont actually understand the concept of auto which is why you can't provide any evidence nor refute the contrary evidence presented to you. So yet again the only thing you have succeeded at is looking stupid.

It isn't a hard concept but you even compared it to dynamic languages which is irrefutable proof that you have no idea what you are talking about.

Auto solves NO problems except the number of characters you need to type when declaring stl iterators.

But he just gave you a link that demonstrates many problems that auto solves. Did you not read it or do you lack the cognitive ability to understand it? If you want to dispute the resolutions to the many problems listed in that link then go right ahead.

But based on your posts on this topic you won't, because you don't know enough about it.

• -You seem intent on sticking to your view regardless of all the evidence to the contrary
• -You call everybody else "shitty programmers" for using auto yet you can't explain what you don't like about it.
• -You say Herb Sutter is wrong in all of those listed solutions to problems but don't tell us why.
• -You incorrectly associate auto with dynamic typing, further evidence you have no idea what you are talking about.
• -You say "strong typing is a feature", well it is a feature of auto too. You say this because you don't know what auto or strong typing are. If you did you would know that auto *is* strongly typed, its type is deduced at compile time, you cannot have an uninitialized auto variable (a variable with no type) and you cannot change its type.

So in short, as was said here, "Shut up. Now.". You look stupider every time you post.

Auto is the most braindead addition in history, it causes bugs, loses all the advantages of a typed language, and only needs to exist because they fucked up the STL by not using proper inheritance.

You. Are. Talking. Out. Your. Ignorant. Ass.

Auto SOLVES every single one of those things you're complaining about.

Shut up. Now.

Herb Sutter responded to this on his blog (Sutter's Mill): http://herbsutter.com/2013/08/...

If you change a private implementation detail in a class, you have to recompile everything which uses the class. This is the opposite of encapsulation.

Yes, that's what the PIMPL idiom is for. Here's a nice introduction to it .

Yes I know this.

As with most everything, there's a way to solve that problem in C++, it just takes some work and knowledge to know what, when, and how to use it.

Sure, but why waste so much time working around short-comings in the language? This idiom is a very good example. A lot of code and complexity which does nothing useful but is required to work around the stupidity of the language designer.

I do agree that the language is too big though; conceptually, C++ could be broken into 4 distinct components (C, STL, templates, OOP), as each have their own quirks and idioms that don't necessarily carry over well to the other, and some are even Turing complete on their own (ie template metaprogramming)

I use the C component. It is not perfect, but not as mis-designed as what has been added in C++.

If you change a private implementation detail in a class, you have to recompile everything which uses the class. This is the opposite of encapsulation.

Yes, that's what the PIMPL idiom is for. Here's a nice introduction to it .

As with most everything, there's a way to solve that problem in C++, it just takes some work and knowledge to know what, when, and how to use it. I do agree that the language is too big though; conceptually, C++ could be broken into 4 distinct components (C, STL, templates, OOP), as each have their own quirks and idioms that don't necessarily carry over well to the other, and some are even Turing complete on their own (ie template metaprogramming)

Oops, URL missing: http://herbsutter.com/welcome-...

If by modern C you mean C99 and beyond ITYF almost no one uses it outside of academia and a few specialist areas. Almost invariable C90 or ANSI C is the global standard which plays nicely with C++.

It must be stated that the biggest barrier that was placed on C99 and C11's adoption is Microsoft's sabotage of the C standardization committee and their unwillingness to add support for other standard beyond ANSI C in Microsoft's compilers. For a glimpse, check herb sutter's blog post on what features the public believes are missing from Microsoft's compiler

I found some additional information (see the link below). It looks like Microsoft intends to implement those parts of C99 and C11 which are a subset of C++11. Which is better than nothing, I guess, but hardly what I would call a great effort to truly support C99 and C11.

Reader Q&A: What about VC++ and C99?

The better links t check your language is in demand is the job-search ones like IT Jobs Watch but I've noticed that can show a fair bit of volatility.

Currently jQuery and PHP are growing in popularity.

As for C++, Microsoft have discovered that their .NET languages are quite resource hungry, and that the cloud and mobile require more efficient resource use, hence their "C++ Renaissance" push.

Not that .NET will disappear, just that it'll become more of the language that filled the niche VB left vacant as their systems programming becomes more c++ oriented. Can't blame everyone from fleeing Java, even if oracle doesn't screw it up, it's still fast becoming a legacy language (ie the new Cobol :) )

" With so much happening in the computing world, now seemed like the right time to write "Welcome to the Jungle" - a sequel to my earlier "The Free Lunch Is Over" essay. "

I'm not sure what that idea was. Herb Sutter says that before C "There was no such thing as a general-purpose program that was both portable across a variety of hardware and also efficient enough to compete with custom code written for just that hardware. Fortran did okay for array-oriented number-crunching code, but nobody could do it for general-purpose code such as what you’d use to build just about anything down to, oh, say, an operating system.", but that ignores both B (which admittedly Dennis Richie worked on, but was mainly Ken Thompson's work) and BCPL which was Martin Richards' baby. They were both general purpose languages suitable for building operating systems (and B was used for early versions of Unix).

That's not to diminish Ritchie's contribution, any more than that of anybody else who saw further by "standing on the shoulders of giants", but it's important to keep it in perspective.

See the following:
http://mariusbancila.ro/blog/2011/06/20/cpp-renaissance-at-microsoft/
http://herbsutter.com/2011/07/28/c-renaissance-the-going-native-channel/
http://channel9.msdn.com/Shows/Going+Deep/Craig-Symonds-and-Mohsen-Agsen-C-Renaissance
It's true that MS it starting to push JavaScript/HTML5, but there's also a "return to roots" movement for C++.