(In common vernacular, you're smart and I have the stupid.)
It's probably more accurate that you have the ignorant. There's no shame in not knowing, right?
Where's a good place to get into C++?
I honestly don't know! The best I can suggest is borrow a Scott Myers book from a library (latest edition of Effective C++), have a copy of the FAQ at the ready and join a reasonably welcoming open source project.
Why Scott Myers? Because one of his books will give you a sense of the difference between C and C++.
You clearly have no idea how much nicer C# is to use than C++, especially due to the facts that C# has real generics instead of preprocessor templates, that Visual Studio's debugger works much better with C# code (by showing the actual hierarchical members of your objects instead of vtable pointers everywhere, for example), and that LINQ exists.
I have used both C# and Haskell in anger. C# "generics" are more applicable than C++ templates, but C# generics are not a sweet spot. If you think of C++ templates as generative programming (as opposed to generic programming), they make a lot more sense. C# generics are comically clunky if you've experienced parametric polymorphism as you find in Hindley-Milner languages.
Incidentally, debugging C++ can be done extremely well (Xcode is far superior to VS at this), but the state of debugging on Linux is terrible just in general.
Also, the article you cited is based on an archaic version of Java; what applied then does not apply now.
His main point still applies: Java keeps the "OO gook" of C++ and leaves the interesting stuff (e.g. compile-time code generation).
My point is merely that there is such a thing as a mainstream right wing, and it's much, much bigger than the loony right-wing. Same goes for the left wing. And as you rightly point out, the mainstream partisan outlets are good enough that those who aren't in the party will still read it.
If I'm under the knife, I'd like a doctor present in the room, not some dude with a "medical degree" dialing in from the other side of the world while moonlighting from his IT helpdesk job.
If you got appendicitis in Antarctica, I wager you'd be happy to have a surgeon fixing it remotely (assuming the technology was up to the task) than the local GP with no surgical qualifications.
I love C++ and use it professionally, and prefer it to a lot of languages - but if someone tells me they're a C++ expert I'll laugh in their face unless they're Stroustrup or Herb Sutter or someone like that.
I consider myself a C++ expert. (I actually refer to myself as a "language paralegal" as opposed to "language lawyer"; I used to have a desk next to someone on the standards committee.) The main reason why I think I can confidently call myself this is that I know enough to know where the limits of my knowledge are. You really don't have to be Myers or Sutter to get past the Dunning-Kruger barrier.
It's interesting that you mention ADL. Anyone who used C++ templates in a non-trivial way before two-phase lookup was standardised had to learn the new rules because they almost certainly had to port their code to the new standard. As breaking changes go, it wasn't too bad, since the effect was to make some previously legal code illegal and the fix was just to qualify some identifiers. Still, many C++ programmers of a certain age know the ADL rules for that reason alone.
Literally anything that you might think C++ would be good for is better solved by either C#, C, or a combination of both.
This makes literally no sense. With minor caveats, C++ is C with more stuff. Even if you only use (say) namespaces or a modest amount of ad-hoc overloading, C++ is a better C.
The main cause of problems with C++ is using it as an object-oriented language, but you'd have the same problem in C#. What Alex Stepanov rightly said about Java equally applies to C#: "I spent several months programming in Java. Contrary to its authors prediction, it did not grow on me. I did not find any new insights - for the first time in my life programming in a new language did not bring me new insights. It keeps all the stuff that I never use in C++ - inheritance, virtuals - OO gook - and removes the stuff that I find useful."
The Principle of Charity is the first lecture in any decent university-level critical thinking course. It should be required knowledge for any Slashdot comment thread.
That's a real thing; just look at all the right-wing sites like breitbart.com and wnd.com.
That isn't even close to all the right-wing sites. Breitbart's Alexa ranking is 232 in the United States and WND is 378. Disturbingly high, to be sure, but nowhere near the readership of the Wall Street Journal (122) or Forbes (75).
Actually, there's something to this definition. Christianity (the major world religion) does have loose organisation at the national and international level, as a network of ecumenical organisations. Many countries have a national council of churches, most denominations have one (e.g. Anglican Communion, World Methodist Council, etc). A church is "Christian" if it is part of the network; that means it's in communion with other Christian churches. Someone is a Christian if they are part of that.
If you go by this definition, then pretty much every reasonably-sized denomination that you can name is "Christian". The one notable exception is the Southern Baptist Convention, which voluntarily withdrew from its last ecumenical communion (the Baptist World Alliance) in 2004. As of that date, the SBC is (in a technical sense) not part of Christianity.
I was thinking about prototyping a new language rather than prototyping a new compiler for an existing language. In that situation, YACC would give you a faster turn-around time during the exploratory phase.
The separation of tokeniser and parser is an artificial distinction driven by slow computers with small amounts of RAM (as is the C preprocessor).
The distinction is usually made by the language definition itself. Also, lexical analysers tend to be where you hide all of the ambiguity so that the syntax analyser doesn't have to deal with it (e.g. an "identifier" is anything which looks like an identifier but isn't a keyword). Having said that, I tend to agree with you; it's just as artificial as the two-level "recursive descent parser for statements, operator precedence parser for expressions" that they did back in the bad old days. Or van Wijngaarden grammars, which are probably best forgotten.
Incidentally, the C committee was smart about this, by defining the C preprocessor so that it operates on C tokens rather than text. That means you can either share the lexer between the preprocessor and the compiler, or do it in a single pass like Clang does (the conceptual phase ordering being lexer -> preprocessor -> parser).
Which brings up another point: Lex (in particular) also comes from a time in history where it was prohibitively expensive to hold the program text in memory. Today we just memory map it all and work on memory buffers. It's much easier to hand-write a lexer if it doesn't have to deal with interleaved I/O!
Every single sexual harassment induction thing that I've had to do for the last 20 years has had a completely consistent definition of sexual harassment: It is any unwanted or unwelcome sexual behaviour, which makes a person feel offended, humiliated or intimidated, and does not stop when asked.
Unless it's obvious to an idiot in a hurry that some behaviour is humiliating or intimidating, it is the last point that really makes something "sexual harassment". If you don't like what someone is doing, you need to tell them (or tell a third party who will then tell them) to stop. If they don't stop, that's when it's sexual harassment. This has been the case in every policy in every workplace that I've been in.
I think the Hindley-Milner languages beat it. Haskell had Maybe types standard in the mid-90s (and non-standard several years before that). ML probably had them before Haskell did.
The short answer is "it depends". Lex and YACC are not too bad for prototyping or internal tools, but I'd never ship a production compiler that used them. OK, maybe Lex, but definitely not YACC.
Lex and YACC are extremely C-specific. You have to write glue code if your compiler is written in something else such as C++, which it probably is if you're using LLVM. There are more modern YACC-alikes which overcome these problems, but still. Also, you have to jump through hoops if you want more than one lexer/parser linked into the binary. Many modern production compilers effectively have more than one "input language" (e.g. multiple revisions of a standard, C/C++/Obj-C/CPP), and there's just no nice way to do this in YACC.
But more importantly, YACC (and, indeed, pretty much any parser generator) tends to produce terrible syntax error messages. Diagnostics about errors in the program is, in a sense, the only part of the compiler's output that a programmer will read. Those syntax and type error messages are, in a deep sense, the most important part of the "user interface" of a compiler. If the error messages are less helpful than they could be, the compiler fails at ergonomics. Just look at all the people who complain about STL type errors.
Getting YACC to produce high-quality error messages, and convincing it to recover gracefully from a syntax error so that it can proceed, is more work than hand-writing a parser in the first place. You might as well just do that.
That's only true of an operator language, which most languages are not. Stripping whitespace turns struct foo into structfoo, which doesn't mean the same thing. Maybe you could do it with AP/L?
Having said that, I've been Haskell programming for over 20 years, and I don't recall this ever happening once.
You're right, designing a language the fucks up based on different text editor default preferences makes the users that are complaining about that design decision wrong...
That's also true of Makefiles, by the way. You might not have written a Makefile in a while, but I remember it well.
Please explain the advantage of white space sensitivity without sounding like a moron, go:
A "bug", according to people who work on the theory of debugging, is defined as a discrepancy between two interpretations of a program: the programmer's intended interpretation, and the compiler's interpretation. Indentation already contains information about the programmer's interpretation of a program. It's crazy not to let the compiler use that information.
Python's realisation is terrible, but try using Haskell some time. It has significant whitespace and curly braces, and you can mix and match them as you need to.
But I am glad Apple is not buying the Script Kiddies Crap and 'dumbing' down the language.
Swift is a dumbed-down Objective-C. No, that's not a complaint.
Python is the last language on Earth anyone should be modeling a professional language on. The Last.
Can't argue with that. Of course, indentation-based syntax is the least of Python's problems. It was fine in Occam and it's great in Haskell, but it would ruin Swift.
If we start talking about ethnicities then it becomes more useful, but at the end of the day it's important to remember we're just referring to probability distributions of genes.
Exactly.
To pick one famous example, we tend to associate sickle-cell anemia with people of Sub-Saharan African ancestry, but the incidence is higher in Saudi Arabia than it is in (say) Somalia or Lesotho.
Slashdot Mirror
(In common vernacular, you're smart and I have the stupid.)
It's probably more accurate that you have the ignorant. There's no shame in not knowing, right?
Where's a good place to get into C++?
I honestly don't know! The best I can suggest is borrow a Scott Myers book from a library (latest edition of Effective C++), have a copy of the FAQ at the ready and join a reasonably welcoming open source project.
Why Scott Myers? Because one of his books will give you a sense of the difference between C and C++.
You clearly have no idea how much nicer C# is to use than C++, especially due to the facts that C# has real generics instead of preprocessor templates, that Visual Studio's debugger works much better with C# code (by showing the actual hierarchical members of your objects instead of vtable pointers everywhere, for example), and that LINQ exists.
I have used both C# and Haskell in anger. C# "generics" are more applicable than C++ templates, but C# generics are not a sweet spot. If you think of C++ templates as generative programming (as opposed to generic programming), they make a lot more sense. C# generics are comically clunky if you've experienced parametric polymorphism as you find in Hindley-Milner languages.
Incidentally, debugging C++ can be done extremely well (Xcode is far superior to VS at this), but the state of debugging on Linux is terrible just in general.
Also, the article you cited is based on an archaic version of Java; what applied then does not apply now.
His main point still applies: Java keeps the "OO gook" of C++ and leaves the interesting stuff (e.g. compile-time code generation).
My point is merely that there is such a thing as a mainstream right wing, and it's much, much bigger than the loony right-wing. Same goes for the left wing. And as you rightly point out, the mainstream partisan outlets are good enough that those who aren't in the party will still read it.
How many hospitals would waste money on a remote surgery robot rather than hiring more doctors or better doctors...
You probably live in a decent-sized city with more than one very good hospital.
Think instead of some very remote place, like Antarctica.
If I'm under the knife, I'd like a doctor present in the room, not some dude with a "medical degree" dialing in from the other side of the world while moonlighting from his IT helpdesk job.
If you got appendicitis in Antarctica, I wager you'd be happy to have a surgeon fixing it remotely (assuming the technology was up to the task) than the local GP with no surgical qualifications.
I love C++ and use it professionally, and prefer it to a lot of languages - but if someone tells me they're a C++ expert I'll laugh in their face unless they're Stroustrup or Herb Sutter or someone like that.
I consider myself a C++ expert. (I actually refer to myself as a "language paralegal" as opposed to "language lawyer"; I used to have a desk next to someone on the standards committee.) The main reason why I think I can confidently call myself this is that I know enough to know where the limits of my knowledge are. You really don't have to be Myers or Sutter to get past the Dunning-Kruger barrier.
It's interesting that you mention ADL. Anyone who used C++ templates in a non-trivial way before two-phase lookup was standardised had to learn the new rules because they almost certainly had to port their code to the new standard. As breaking changes go, it wasn't too bad, since the effect was to make some previously legal code illegal and the fix was just to qualify some identifiers. Still, many C++ programmers of a certain age know the ADL rules for that reason alone.
Literally anything that you might think C++ would be good for is better solved by either C#, C, or a combination of both.
This makes literally no sense. With minor caveats, C++ is C with more stuff. Even if you only use (say) namespaces or a modest amount of ad-hoc overloading, C++ is a better C.
The main cause of problems with C++ is using it as an object-oriented language, but you'd have the same problem in C#. What Alex Stepanov rightly said about Java equally applies to C#: "I spent several months programming in Java. Contrary to its authors prediction, it did not grow on me. I did not find any new insights - for the first time in my life programming in a new language did not bring me new insights. It keeps all the stuff that I never use in C++ - inheritance, virtuals - OO gook - and removes the stuff that I find useful."
The Principle of Charity is the first lecture in any decent university-level critical thinking course. It should be required knowledge for any Slashdot comment thread.
That's a real thing; just look at all the right-wing sites like breitbart.com and wnd.com.
That isn't even close to all the right-wing sites. Breitbart's Alexa ranking is 232 in the United States and WND is 378. Disturbingly high, to be sure, but nowhere near the readership of the Wall Street Journal (122) or Forbes (75).
I know what you're saying, but to be fair, the faceless mob has "come for" practically everyone at some point.
Actually, there's something to this definition. Christianity (the major world religion) does have loose organisation at the national and international level, as a network of ecumenical organisations. Many countries have a national council of churches, most denominations have one (e.g. Anglican Communion, World Methodist Council, etc). A church is "Christian" if it is part of the network; that means it's in communion with other Christian churches. Someone is a Christian if they are part of that.
If you go by this definition, then pretty much every reasonably-sized denomination that you can name is "Christian". The one notable exception is the Southern Baptist Convention, which voluntarily withdrew from its last ecumenical communion (the Baptist World Alliance) in 2004. As of that date, the SBC is (in a technical sense) not part of Christianity.
Eastern Orthodox churches would beg to differ.
Uh, that's what SJW means.
That's certainly not what it originally meant. The term "Social Justice Warrior" originally referred to a certain kind of Internet-only slacktivist who regurgitated half-understood academic soundbites on social media in return for brownie points.
Like "troll" (which was a perfectly useful term back in the Golden Age of Usenet), the word has completely lost its meaning in the last few years.
Pretty much exactly this. While the Westboro Baptist Church is still in business, nobody is going to shut you (whoever "you" are) down.
Even for prototyping, I wouldn't use them.
I was thinking about prototyping a new language rather than prototyping a new compiler for an existing language. In that situation, YACC would give you a faster turn-around time during the exploratory phase.
The separation of tokeniser and parser is an artificial distinction driven by slow computers with small amounts of RAM (as is the C preprocessor).
The distinction is usually made by the language definition itself. Also, lexical analysers tend to be where you hide all of the ambiguity so that the syntax analyser doesn't have to deal with it (e.g. an "identifier" is anything which looks like an identifier but isn't a keyword). Having said that, I tend to agree with you; it's just as artificial as the two-level "recursive descent parser for statements, operator precedence parser for expressions" that they did back in the bad old days. Or van Wijngaarden grammars, which are probably best forgotten.
Incidentally, the C committee was smart about this, by defining the C preprocessor so that it operates on C tokens rather than text. That means you can either share the lexer between the preprocessor and the compiler, or do it in a single pass like Clang does (the conceptual phase ordering being lexer -> preprocessor -> parser).
Which brings up another point: Lex (in particular) also comes from a time in history where it was prohibitively expensive to hold the program text in memory. Today we just memory map it all and work on memory buffers. It's much easier to hand-write a lexer if it doesn't have to deal with interleaved I/O!
Every single sexual harassment induction thing that I've had to do for the last 20 years has had a completely consistent definition of sexual harassment: It is any unwanted or unwelcome sexual behaviour, which makes a person feel offended, humiliated or intimidated, and does not stop when asked.
Unless it's obvious to an idiot in a hurry that some behaviour is humiliating or intimidating, it is the last point that really makes something "sexual harassment". If you don't like what someone is doing, you need to tell them (or tell a third party who will then tell them) to stop. If they don't stop, that's when it's sexual harassment. This has been the case in every policy in every workplace that I've been in.
Perhaps it's the jurisdiction?
I think the Hindley-Milner languages beat it. Haskell had Maybe types standard in the mid-90s (and non-standard several years before that). ML probably had them before Haskell did.
The short answer is "it depends". Lex and YACC are not too bad for prototyping or internal tools, but I'd never ship a production compiler that used them. OK, maybe Lex, but definitely not YACC.
Lex and YACC are extremely C-specific. You have to write glue code if your compiler is written in something else such as C++, which it probably is if you're using LLVM. There are more modern YACC-alikes which overcome these problems, but still. Also, you have to jump through hoops if you want more than one lexer/parser linked into the binary. Many modern production compilers effectively have more than one "input language" (e.g. multiple revisions of a standard, C/C++/Obj-C/CPP), and there's just no nice way to do this in YACC.
But more importantly, YACC (and, indeed, pretty much any parser generator) tends to produce terrible syntax error messages. Diagnostics about errors in the program is, in a sense, the only part of the compiler's output that a programmer will read. Those syntax and type error messages are, in a deep sense, the most important part of the "user interface" of a compiler. If the error messages are less helpful than they could be, the compiler fails at ergonomics. Just look at all the people who complain about STL type errors.
Getting YACC to produce high-quality error messages, and convincing it to recover gracefully from a syntax error so that it can proceed, is more work than hand-writing a parser in the first place. You might as well just do that.
That's only true of an operator language, which most languages are not. Stripping whitespace turns struct foo into structfoo, which doesn't mean the same thing. Maybe you could do it with AP/L?
Having said that, I've been Haskell programming for over 20 years, and I don't recall this ever happening once.
You're right, designing a language the fucks up based on different text editor default preferences makes the users that are complaining about that design decision wrong ...
That's also true of Makefiles, by the way. You might not have written a Makefile in a while, but I remember it well.
Please explain the advantage of white space sensitivity without sounding like a moron, go:
A "bug", according to people who work on the theory of debugging, is defined as a discrepancy between two interpretations of a program: the programmer's intended interpretation, and the compiler's interpretation. Indentation already contains information about the programmer's interpretation of a program. It's crazy not to let the compiler use that information.
Python's realisation is terrible, but try using Haskell some time. It has significant whitespace and curly braces, and you can mix and match them as you need to.
Oh, BTW, when you rewrite it in another language be sure to take full advantage of automatic tools to find basic mistakes you may make.
If by that you mean a static type system, then yes. It helps find the mistakes that the typical Python programmer made, too.
But I am glad Apple is not buying the Script Kiddies Crap and 'dumbing' down the language.
Swift is a dumbed-down Objective-C. No, that's not a complaint.
Python is the last language on Earth anyone should be modeling a professional language on. The Last.
Can't argue with that. Of course, indentation-based syntax is the least of Python's problems. It was fine in Occam and it's great in Haskell, but it would ruin Swift.
You are so on the wrong website, dude.
Between the Persian carpets and splitting the atom, [...]
Oh, so that's what they're doing at Fordow!
If we start talking about ethnicities then it becomes more useful, but at the end of the day it's important to remember we're just referring to probability distributions of genes.
Exactly.
To pick one famous example, we tend to associate sickle-cell anemia with people of Sub-Saharan African ancestry, but the incidence is higher in Saudi Arabia than it is in (say) Somalia or Lesotho.