My favorite Old Testament story is when some youths mock Elisha's bald head, he curses them, and a she-bear comes out of the woods and tears them to pieces. DON'T MESS with Old Testament prophets. Those dudes were hard core.
I like the passage where the Pharaoh wants to marry Moses' sister, only to be told she's actually his wife.
So Moses has to come and explain why he's told everyone the woman is his sister.
"Well, she's my wife *and* my sister..."
(I might have gotten the people wrong. It was *some* bigshot king, and *some* great Old Testament figure. Possibly Abraham.)
Also most people don't realize these were the same arguements given back in the 80s for writing stuff in assembly instead of C, and given that people have moved on to C++ since with the same things being said 'If it's too slow in C++ then optimize that routine in C'[...]
I've never heard that last statement. It's rather well known that C++ is as fast as or faster than C.
you can write the code in python several times in the same amount of time it takes to write it in C or C++.
Or C++? Maybe if you don't know C++, otherwise I would have to say that is a wild exaggeration or at best an over generalization. I find that Python development generally progresses somewhat faster than C++, but not enormously faster. And the quality of result is generally better with C++.
I know and like both languages, and I disagree.
I can write idiomatic Python code significantly faster than the equivalent idiomatic C++ code.
List comprehensions, duck typing, a much bigger standard library...
The problem, for me, with the Python code is that it's harder to maintain, due to the lack of static typing.
You're confusing the protocol with the client. Many nntp clients didn't support threads-- the Vax I used at college didn't have a threaded newsreader.
Seems to me it's you who's confused. The point isn't whether all clients support threads; it's that the protocol guarantees that they are there for those who want them. (Today, pretty much everyone does. Non-threaded readers have been obsolete for 20 years or so.)
Given the widespread annotation of xxx I don't see why people should think lego.dk and lego.xxx would be the same company or why lego.xxx would be bad reputation for lego.dk.
Unless lego.xxx somehow claims to be a site for Lego(tm) porn, and then the company can hit them
with defamation, trademark violation, or whatever it's called. They don't need to own lego.xxx for that.
It saddens me how boring computing has become. When I was a kid, computers were my friends, mysterious odd creatures with their own faults, oddities and dark corners. Thus I learned to talk, dream and breathe in binary so that I could better understand and associate with them. Apparently not so today.
Apparent *how*?
I don't feel that way at all.
I have more control over mine now since they come with documentation and aren't running some bastard CP/M,
but there are dozens of areas that would be fun and exciting to explore.
I thought "genius" was the gratuitous part. I would go more with "A handful of moderately competent hackers surrounded by a legion of fucking morons".
Moderately competent hackers perhaps, but they seem to be very good with PR and group psychology.
Channeling all the petty acts of vandalism and bending them to your purposes... #include "godwin.h".
Why is it if something like this were done against the Jews or Muslims it would be considered a hate crime but against the Catholics people feel it is okay? Why don't all of the politically correct types denounce this? Unless it is secretly condone by them.
(a) It's an attack on the organization, not the people. That's not generally considered a hate crime.
(b) I don't see more people than usual condone this.
Movie and TV producers have been dubbing in bird sounds for decades, including one infamous time when CBS backed a golf match with the sounds of birds that have never lived anywhere near the game's location.
Never heard of it in sports television, but it happens often in TV series and movies.
Woodland birds in farmland settings; Old World birds in the US or Australia; the spring calls of birds in scenes shot in the summer, and so on.
To be fair, they seem to often make an effort to get it right, too.
...but isn't it everywhere around us and called 'the Web' ?!?
It amazes me to see so many people claiming Wikipedia, the web or even bloody YouTube refutes the article's thesis.
These are not literature in the sense TFA uses -- just as pre-web media like
the daily paper, ads, movies, TV shows, encyclopedias...
For me, the most dramatic example of the progress of hardware in the intervening years is Emacs.
It used to be regarded as a heavyweight editing environment, comparable in scope and resource requirements to a full programmer's IDE. There was even a special server designed just to allow several editing windows (aka frames) to coexist.
Now, it's so lightweight and fast to load up, my web browser launches a completely independent Emacs for each comment field in a web page, my MUA launches its own Emacs for writing mails, I have multiple independent Emacs processes for editing code, and another for writing LaTeX.
You're right, yet wrong.
My first PC was from 1995, and already back then Emacs was a lightweight thing. Now it launches in a fraction of a second; back then it took a second or so.
I remember when Emacs was *truly*, Eclipse-style heavy -- it was on aging Sun3 machines around 1991.
... the external RCS being *strictly better* at management of changes is the valid reason. Until you can branch and merge, you're not really managing changes.
+1.
Paying the Microsoft tax isn't the main stupidity caused by using MS Office.
It's the maze of shared folders with obsolete versions of various documents and
"-- No, I can't start with my changes, because I'm waiting for Sue to finish hers."
"-- I meant to update that document, but Bob has it locked and he's sick today."
"-- The FooBar document? I remember getting a copy in the mail last fall... let me check if it's still in my inbox..."
If you're a programmer and compare it to how source code is handled, this is infuriating.
I gave up on C++ years ago. It has really become a 'geek cred' language with a constantly changing 'right' way an aesthetic, perfect for figuring out if a fellow geek is from the same snapshot of teaching you came from, but that is about it. It has become overly complex with redundant language features that one needs to keep relearning in order to understand other people's code.. and of course with complexity comes the ability to show off your knowledge through doing things in 'clever' ways.
Good for showing off.. bad for getting actual work done, esp for projects that last more then a year or two.
Well, what are the alternatives? I my domain, it's plain old C.
Java is not an option, and from the little I hear fashion changes *more* quickly there anyway.
I think your impression of the changing "right" way is warped, or perhaps you're in a subculture I'm not familiar with.
I see these different ways:
(a) C with classes, from C programmers who've read a book but don't quite get it.
(b) OOP/Design Patterns rule! Popular in the mid-1990s. Lots of inheritance and stuff; every piece of code aspiring to generality
and inclusion in a reusable library.
(c) The pragmatic view, e.g. in Stroustrup's "The C++ programming language".
(d) Template Meta-Programming rules!
(a) and (b) are dead ideologies today, although you discover lost tribes practicing them now and then.
I happily ignore the (d) crowd unless they can provide a stable, documented library which I don't have to debug.
Besides, they seem to have settled down a bit in recent years.
To summarize, I see no big change since the late 1990s.
All popular C++ compilers already implement large parts of C++11, so the chance of seeing widespread C++11 adaption in the not so distant future is pretty high. Also this wasn't really any different with C++98, which essentially no compiler supported on release and which then took a few years to gain widespread adoption.
C++98 was worse.
There was extern templates, which was a major mistake (read the proposal to remove it from C++11 for some amusement).
There was Microsoft, who lost interest in C++ around that time, and condemned a generation of Windows programmers
to Visual Studio 6 and a weak standard library implementation.
And yet gcc was usable around 1999 or so. I started using the std namespace in late November that year.
Time to overhaul the academics. Nearly every engineering course here (I'm in India) has a couple of programming courses. A lot of students do coding some time or the other. Yet not even a sentence is uttered about threads or parallelism, even though practically every computer they code in has multiple cores. They should probably introduce a course on parallel processing as an elective for freshmen.
I took such a course back in the early 1990s.
Can't say it did me any good, except to teach me that parallelism is damned hard, and that you can stare on a piece of
threaded code for a while and convince yourself it's correct... and yet it isn't.
20 years later, I have seen little production code with threads that didn't suck, and little code without concurrency bugs.
I think half of the C++ projects out there are delayed in starting up just because there is no full C++11 compiler to use.
That would be stupid if it was true, because C++11 is not really a world-changing thing (unless you're deep into template meta-programming, which most people shouldn't be).
The compiler situation is much better today than when C++ was first standardized in the late 1990s: the GCC crowd has their shit together, and Microsoft are on the bus again.
I've been using the C++11 for 6 months now in my own project (libbitcoin) and the new features and syntax really make your code sharper, clearer and better. C++ is no longer that unsafe language if you know how to code in it properly - you never really have to do any manual memory management if you use shared pointers.
Fine, but (a) you don't need C++11 to have shared pointers -- it just standardizes them; (b)
shared pointers are *not* the primary way to avoid manual memory management -- that would be the standard containers.
auto means I no longer have to type std vector iterator in every for loop
You didn't anyway. You type in "int" to loop over a vector.
Only if you want to tie yourself to using a vector. Using a proper iterator costs you nothing in code space or execution time (because for a vector it optimizes down to just pointer arithmetic anyway), but means that at some future time you can replace that vector with a different data structure without having to modify the code that operates on it.
That is *one* reason, I suppose.
A more important one is that you use iterators everywhere else in C++.
When you're used to that, throwing in a loop for(int i=0; iN; i++) looks odd.
I think he simply claimed that you have to deal with C++ written by C programmers all too often.
That's my experience, too.
STL isn't suited for all possible uses, sometimes you need your own string and container classes.
I don't see what that has to do with the above. I suppose there are some rare cases where the standard library
isn't appropriate, but are you arguing this is an excuse *never* to use it?
By the way, your reference seems severely dated. Some of its complaints are still valid, but seem based on the state of
STL support ten years ago.
Which as a developer I hate. What I really want testers to do is write automated tests. The only hand test a tester should do is one to see what the automated test should do. Yes, reality ends up being a mix, but reality should be informed by the ideal. It irritates the hell out of me that testers are doing the same thing over and over, that is what computers are for.
It irritates *me* to see testers executing thousands of automated tests of dubious quality, inherited down from their predecessors.
You don't learn anything that way, and you never touch the functionality which those testers of the past didn't cover.
(Not that I recommend doing the same thing, with humans as the automats: that's just as stupid, and also cruel.)
All internal systems should use the internal DNS server.
The firewalls should block any outgoing DNS queries from any systems (except the internal DNS servers).
The firewall logs should be checked each day for violations.
The internal DNS server logs should be checked each day for unusual activity.
Even if you cannot prevent your systems from being compromised you should be looking for the signs that they are compromised.
You mean the "insights" section on page 17 in the report.
That part scared me. They also recommend blocking traffic from the network to address X unless it's preceded by a DNS query which
resolves to X. Breaking IP in non-obvious ways (impossible to debug unless you have control over the firewalls) has pretty bad consequences too...
[...] At the end of the day, you are meant to be an advocate for the end user, argue to get bugs fixed, don't accept "Thats how it's meant to work" just because the spec said that is how it will work if that doesn't help the user etc.
Yes, that is how it should work. Clever organizations let their testers acquire that wisdom, and then listen to them.
Also, grow thick skin and be prepared for cynism to creep into your view of the world (or maybe good testers are already cynical?)
It's a job which breeds a negative view of live, you spend your time not producing anything directly sellable and tearing other peoples work apart.
I somewhat disagree. Not letting bugs through certainly feels productive to me.
For many products (maybe not consumer software, but at least those with few and powerful buyers)
a high-profile bug in the field can be devastating.
Slashdot Mirror
The fact that Commodore makes it doesn't make it an Amiga.
The fact that the company has bought the name "Commodore" doesn't make it Commodore. This tedious crap has happened over and over, since -94.
My favorite Old Testament story is when some youths mock Elisha's bald head, he curses them, and a she-bear comes out of the woods and tears them to pieces. DON'T MESS with Old Testament prophets. Those dudes were hard core.
I like the passage where the Pharaoh wants to marry Moses' sister, only to be told she's actually his wife. So Moses has to come and explain why he's told everyone the woman is his sister. "Well, she's my wife *and* my sister ..."
(I might have gotten the people wrong. It was *some* bigshot king, and *some* great Old Testament figure. Possibly Abraham.)
Also most people don't realize these were the same arguements given back in the 80s for writing stuff in assembly instead of C, and given that people have moved on to C++ since with the same things being said 'If it's too slow in C++ then optimize that routine in C'[...]
I've never heard that last statement. It's rather well known that C++ is as fast as or faster than C.
you can write the code in python several times in the same amount of time it takes to write it in C or C++.
Or C++? Maybe if you don't know C++, otherwise I would have to say that is a wild exaggeration or at best an over generalization. I find that Python development generally progresses somewhat faster than C++, but not enormously faster. And the quality of result is generally better with C++.
I know and like both languages, and I disagree. I can write idiomatic Python code significantly faster than the equivalent idiomatic C++ code. List comprehensions, duck typing, a much bigger standard library ...
The problem, for me, with the Python code is that it's harder to maintain, due to the lack of static typing.
You're confusing the protocol with the client. Many nntp clients didn't support threads-- the Vax I used at college didn't have a threaded newsreader.
Seems to me it's you who's confused. The point isn't whether all clients support threads; it's that the protocol guarantees that they are there for those who want them. (Today, pretty much everyone does. Non-threaded readers have been obsolete for 20 years or so.)
Given the widespread annotation of xxx I don't see why people should think lego.dk and lego.xxx would be the same company or why lego.xxx would be bad reputation for lego.dk.
Unless lego.xxx somehow claims to be a site for Lego(tm) porn, and then the company can hit them with defamation, trademark violation, or whatever it's called. They don't need to own lego.xxx for that.
It saddens me how boring computing has become. When I was a kid, computers were my friends, mysterious odd creatures with their own faults, oddities and dark corners. Thus I learned to talk, dream and breathe in binary so that I could better understand and associate with them. Apparently not so today.
Apparent *how*? I don't feel that way at all. I have more control over mine now since they come with documentation and aren't running some bastard CP/M, but there are dozens of areas that would be fun and exciting to explore.
I thought "genius" was the gratuitous part. I would go more with "A handful of moderately competent hackers surrounded by a legion of fucking morons".
Moderately competent hackers perhaps, but they seem to be very good with PR and group psychology. Channeling all the petty acts of vandalism and bending them to your purposes ... #include "godwin.h".
Why is it if something like this were done against the Jews or Muslims it would be considered a hate crime but against the Catholics people feel it is okay? Why don't all of the politically correct types denounce this? Unless it is secretly condone by them.
(a) It's an attack on the organization, not the people. That's not generally considered a hate crime. (b) I don't see more people than usual condone this.
Movie and TV producers have been dubbing in bird sounds for decades, including one infamous time when CBS backed a golf match with the sounds of birds that have never lived anywhere near the game's location.
Never heard of it in sports television, but it happens often in TV series and movies. Woodland birds in farmland settings; Old World birds in the US or Australia; the spring calls of birds in scenes shot in the summer, and so on. To be fair, they seem to often make an effort to get it right, too.
...but isn't it everywhere around us and called 'the Web' ?!?
It amazes me to see so many people claiming Wikipedia, the web or even bloody YouTube refutes the article's thesis. These are not literature in the sense TFA uses -- just as pre-web media like the daily paper, ads, movies, TV shows, encyclopedias ...
For me, the most dramatic example of the progress of hardware in the intervening years is Emacs.
It used to be regarded as a heavyweight editing environment, comparable in scope and resource requirements to a full programmer's IDE. There was even a special server designed just to allow several editing windows (aka frames) to coexist.
Now, it's so lightweight and fast to load up, my web browser launches a completely independent Emacs for each comment field in a web page, my MUA launches its own Emacs for writing mails, I have multiple independent Emacs processes for editing code, and another for writing LaTeX.
You're right, yet wrong. My first PC was from 1995, and already back then Emacs was a lightweight thing. Now it launches in a fraction of a second; back then it took a second or so. I remember when Emacs was *truly*, Eclipse-style heavy -- it was on aging Sun3 machines around 1991.
... the external RCS being *strictly better* at management of changes is the valid reason. Until you can branch and merge, you're not really managing changes.
+1.
Paying the Microsoft tax isn't the main stupidity caused by using MS Office. It's the maze of shared folders with obsolete versions of various documents and ... let me check if it's still in my inbox ..."
"-- No, I can't start with my changes, because I'm waiting for Sue to finish hers."
"-- I meant to update that document, but Bob has it locked and he's sick today."
"-- The FooBar document? I remember getting a copy in the mail last fall
If you're a programmer and compare it to how source code is handled, this is infuriating.
I gave up on C++ years ago. It has really become a 'geek cred' language with a constantly changing 'right' way an aesthetic, perfect for figuring out if a fellow geek is from the same snapshot of teaching you came from, but that is about it. It has become overly complex with redundant language features that one needs to keep relearning in order to understand other people's code.. and of course with complexity comes the ability to show off your knowledge through doing things in 'clever' ways. Good for showing off.. bad for getting actual work done, esp for projects that last more then a year or two.
Well, what are the alternatives? I my domain, it's plain old C. Java is not an option, and from the little I hear fashion changes *more* quickly there anyway.
I think your impression of the changing "right" way is warped, or perhaps you're in a subculture I'm not familiar with. I see these different ways:
(a) C with classes, from C programmers who've read a book but don't quite get it.
(b) OOP/Design Patterns rule! Popular in the mid-1990s. Lots of inheritance and stuff; every piece of code aspiring to generality and inclusion in a reusable library.
(c) The pragmatic view, e.g. in Stroustrup's "The C++ programming language".
(d) Template Meta-Programming rules!
(a) and (b) are dead ideologies today, although you discover lost tribes practicing them now and then. I happily ignore the (d) crowd unless they can provide a stable, documented library which I don't have to debug. Besides, they seem to have settled down a bit in recent years.
To summarize, I see no big change since the late 1990s.
All popular C++ compilers already implement large parts of C++11, so the chance of seeing widespread C++11 adaption in the not so distant future is pretty high. Also this wasn't really any different with C++98, which essentially no compiler supported on release and which then took a few years to gain widespread adoption.
C++98 was worse. There was extern templates, which was a major mistake (read the proposal to remove it from C++11 for some amusement). There was Microsoft, who lost interest in C++ around that time, and condemned a generation of Windows programmers to Visual Studio 6 and a weak standard library implementation. And yet gcc was usable around 1999 or so. I started using the std namespace in late November that year.
Time to overhaul the academics. Nearly every engineering course here (I'm in India) has a couple of programming courses. A lot of students do coding some time or the other. Yet not even a sentence is uttered about threads or parallelism, even though practically every computer they code in has multiple cores. They should probably introduce a course on parallel processing as an elective for freshmen.
I took such a course back in the early 1990s. Can't say it did me any good, except to teach me that parallelism is damned hard, and that you can stare on a piece of threaded code for a while and convince yourself it's correct ... and yet it isn't.
20 years later, I have seen little production code with threads that didn't suck, and little code without concurrency bugs.
I think half of the C++ projects out there are delayed in starting up just because there is no full C++11 compiler to use.
That would be stupid if it was true, because C++11 is not really a world-changing thing (unless you're deep into template meta-programming, which most people shouldn't be).
The compiler situation is much better today than when C++ was first standardized in the late 1990s: the GCC crowd has their shit together, and Microsoft are on the bus again.
I've been using the C++11 for 6 months now in my own project (libbitcoin) and the new features and syntax really make your code sharper, clearer and better. C++ is no longer that unsafe language if you know how to code in it properly - you never really have to do any manual memory management if you use shared pointers.
Fine, but (a) you don't need C++11 to have shared pointers -- it just standardizes them; (b) shared pointers are *not* the primary way to avoid manual memory management -- that would be the standard containers.
You didn't anyway. You type in "int" to loop over a vector.
Only if you want to tie yourself to using a vector. Using a proper iterator costs you nothing in code space or execution time (because for a vector it optimizes down to just pointer arithmetic anyway), but means that at some future time you can replace that vector with a different data structure without having to modify the code that operates on it.
That is *one* reason, I suppose. A more important one is that you use iterators everywhere else in C++. When you're used to that, throwing in a loop for(int i=0; iN; i++) looks odd.
For a vector both are equivalent, but for structures like "list", iterator is faster.
Faster than what? There is no indexing of std::list. (You could write one, I suppose, but that would make iterating a list O(N^2).
So what?
I think he simply claimed that you have to deal with C++ written by C programmers all too often. That's my experience, too.
STL isn't suited for all possible uses, sometimes you need your own string and container classes.
I don't see what that has to do with the above. I suppose there are some rare cases where the standard library isn't appropriate, but are you arguing this is an excuse *never* to use it?
By the way, your reference seems severely dated. Some of its complaints are still valid, but seem based on the state of STL support ten years ago.
You also unroll loops for performance.
In the 1970s perhaps you did. Not now.
Which as a developer I hate. What I really want testers to do is write automated tests. The only hand test a tester should do is one to see what the automated test should do. Yes, reality ends up being a mix, but reality should be informed by the ideal. It irritates the hell out of me that testers are doing the same thing over and over, that is what computers are for.
It irritates *me* to see testers executing thousands of automated tests of dubious quality, inherited down from their predecessors. You don't learn anything that way, and you never touch the functionality which those testers of the past didn't cover. (Not that I recommend doing the same thing, with humans as the automats: that's just as stupid, and also cruel.)
All internal systems should use the internal DNS server. The firewalls should block any outgoing DNS queries from any systems (except the internal DNS servers). The firewall logs should be checked each day for violations. The internal DNS server logs should be checked each day for unusual activity.
Even if you cannot prevent your systems from being compromised you should be looking for the signs that they are compromised.
You mean the "insights" section on page 17 in the report. That part scared me. They also recommend blocking traffic from the network to address X unless it's preceded by a DNS query which resolves to X. Breaking IP in non-obvious ways (impossible to debug unless you have control over the firewalls) has pretty bad consequences too ...
[...] At the end of the day, you are meant to be an advocate for the end user, argue to get bugs fixed, don't accept "Thats how it's meant to work" just because the spec said that is how it will work if that doesn't help the user etc.
Yes, that is how it should work. Clever organizations let their testers acquire that wisdom, and then listen to them.
Also, grow thick skin and be prepared for cynism to creep into your view of the world (or maybe good testers are already cynical?) It's a job which breeds a negative view of live, you spend your time not producing anything directly sellable and tearing other peoples work apart.
I somewhat disagree. Not letting bugs through certainly feels productive to me. For many products (maybe not consumer software, but at least those with few and powerful buyers) a high-profile bug in the field can be devastating.