I can't believe no one's mentioned "worse is better" yet.
I meant to, but you beat me to it.
Unix versus anything else in the 1970s, TCP/IP versus whatever layered monsters
others tried to dream up.
I still don't see how Windows fits into that, though.
The PC hardware did, and that's what got it rolling, plus the users' childish
tendency to love, trust and bonding to first IBM, then Microsoft.
Any version control is a vast improvement on none, and svn is fine at being svn. But it's the last of its line.
I doubt it. Not because the SVN/CVS model is so great, but because there's for some reason
so much ideology and flag-waving in this. Let someone start using SVN, or git, or whatever,
and suddenly it's as if he's joined some fscking religion.
So when you say SVN "is the last of its line", I hear "Jesus is coming soon!".
Me, I use CVS at home and ClearCase at work.
I like both of them. The main problem is not the tool, but people setting up processes which
destroy any benefits from the tool, and users then deciding the tool is crap, ignoring it
for as long as possible.
No, it's "why should a bloody web browser try to protect me from my own broken software?"
Seems to me that if IE, Firefox or whatever feels like doing something good, they should
scan the local file system and delete software known to be open to malware.
But I must admit that I don't even know what malware is.
I assume it's not executables -- I cannot imagine people still download and execute those.
To be fair, the history section on the page for Ireland only moans on about the British for about 7 paragraphs. After that the page moves on to standard affairs like Politics, Geography, Culture and other things Irish people don't care about.
It is generally agreed upon that the colonialism thing (not only in Africa) was a bad thing,
and it's an important aspect of Ireland's history.
Also, it seems to me you are twisting the facts. The article is about the Republic of Ireland,
which was created in 1916 -- not about Ireland in the sense of green hills, clover leaves, potato famine and NY cops.
Not surprising that it focuses on the fight for independence.
The claim "it's just a website" is often trotted out, but it's untrue.
It's a website set up to function deliberately as a linkfarm, which has search engine rankings far above what it should have if it were treated like every other linkfarm out there. It's full of inaccurate, possibly libelous, or outright harmful [...]
admins and cliques with an agenda [...]
rules the articles with an iron fist [...]
a bunch of organized arabs [...]
the entrenched assholes [...]
When people write like that about the Wikipedia and go on and on, they usually have some personal axe to grind.
Do you, and if so, which one?
My personal experience is that sure, many pages are poor, but as a whole Wikipedia is invaluable to me.
I can't say I like this change, and I doubt I will contribute in the future
if I'm not trusted more than that, if I cannot know when my changes take effect,
if I know any tiny grammar fix I make causes work for someone,
Typing is muscle memory just like playing music [...]
Have you never had a case where your fingers know your password but you don't? Happens to me all the time.
I have... but I think that's a special case.
And I think the OP's problem isn't universal. Might work that way for a lot
of people, but not for me.
One scary thing though is that I read and write so much english that it is getting
harder to write in swedish.
C++ was a valiant and interesting attempt to graft an object oriented language on top of C. Unfortunately, it replaced a few problems that C had (null pointer references, buffer overflows) with an almost infinite series of problems due to the complexity of the language. For example, the default of assignment by bit-copying objects makes it trivial to generate memory trashing problems.
I read the rest of your post as if you think C is actually a decent language.
Then how can you at the same time criticize C++ for working like C in this area?
Do you know that C++ was designed to be -- needed to be -- C compatible?
This particular problem should be a non-problem for everyone but very new C++ novices.
One of the first things to keep in mind is always protect the integrity of your objects.
Applied here it means (a) build your classes from objects which are copyable (like the STL
containers) and (b) failing that, disable the copy constructor and operator+ () to explicitly say that they aren't. And even (c) there's probably something odd going on if you have to define
your own copy constructor.
Which brings up the point that C++ doesn't have "references", it has pointers with some syntactic sugar on them. If it really had references, the references wouldn't get invalidated by underlying memory operations.
Depends on who coined the term "reference" first.
I sure hope you didn't write C++ code with references assuming they worked like Java references.
C++ just seems to be overly laden with traps and problems. Just read thru Scott Meyers Effective C++, which I found very clear and useful, and count the number of entries that are navigating around language traps if you don't believe me.
I haven't read the book, but I know from first-hand experience that this isn't the case.
Sure, it's not Python. And it does take more effort to learn well than most
other languages. But it's not some kind of minefield.
When you need C compatibility, speed and/or static type checking, it will serve you very well.
C++ is like a double edged sword. In the hands of an idiot, it will let you create catastrophic type safety failure.
Then again, in the hands of a true coding genius, multiple inheritance, polymorphism and dynamic casting can allow some truly ingenious coding.
But it's primarily the idiots who use those three features you mention!
I'd expect a genius to stick to the normal features (of which there are plenty,
unique to C++) most of the time,
and only use the things you mention when there's a real need.
For at least multiple inheritance and dynamic casting, that is rarely.
So far, I've used dynamic_cast once or twice, and the former never.
It's a simple error, and no different than the error made by other posters who think the language is called `perl` and not `Perl'.
I disagree.
Calling the language 'perl' is something people do today.
Calling it 'PERL' is something people would do in the 1980s; it indicates you
have little contact with the Perl community. Or that you are a little odd, or
have some amount of dyslexia.
The idea of a will has existed for quite a while now. And your loved ones will, in all likeliness, find it a lot more useful if you leave them a dead-tree folder with all the collected information on insurances, people to notify, financial information etc. Much less creepy than postmortem emails, and less likely to end up in the spam filter. Not to mention that such a folder is useful in other situations too, such as if you have an accident and end up incapable of taking care of your affairs.
Yeah. People who provide services like these need to explain how this is better than an actual
will. And how they expect the service to survive longer than you and me.
The same goes for a similar service which got a lot of press here in.se recently -- one which
would, at your death, unregister your accounts at sites like... uh, Slashdot.
At the same time, perhaps lawyers (or whoever manages wills) need to adapt to modern
technology and offer some of these things.
I'm writing a tech book as well and I deliberately skipped O'Reilly for an altogether different reason. I never liked how their books all look the same; it gives me a definite "work for hire" vibe whenever I look at their stuff. (they all have an animal on the front or have a consistent look with other books O'Reilly has published in the same category) For instance, every time I see one of their books, I think "Oh, here's an O'Reilly book" instead of "Oh, here's a book written by $author."
That's not the impression I get as a reader.
Sure, the cover screams O'Reilly! but to me that just means the author has adapted
to a framework which is sensible and familiar to the reader.
That someone has created a sensible index, put examples and errata on the web, and so on.
Not a bad thing.
It doesn't mean the author is some kind of faceless robot; you realize quite soon
(as a reader) that writing good tech is a creative art.
I'm writing a book mainly to get exposure and to help open other doors career-wise down the road (the royalties are nice too) and I don't want to do all the work and have someone like O'Reilly get all the kudos. Granted, they do have good distribution, but so do other publishers that don't over-brand your work like O'Reilly does.
Don't know how others react, but being published by O'Reilly seems way cooler to me than
being published elsewhere -- at least if the work is something concrete and practical
where O'Reilly have such a good track record.
And lacking BSD, they miss the story of the two Texans reacting to the BSD daemon T-shirt, one of the best stories in BSD history.
Thanks! I had been looking for that story.
Last time I saw it, it was reprinted in an Ericsson company-internal Unix course compendium, under the title "Devil worshipping in Texas".
There, it was illustrated with a three-year-old girl wearing a BSD tshirt and looking mischievous...
Instead of fixing the mess underneath, C++ papered it over. Arrays were wrapped with classes in the Standard Template Library. The STL is a good thing, but it's not good enough to totally replace built-in arrays. So real-world programs remain a mixture of ambiguous built-in arrays, pointers to arrays, and STL arrays.
There is no thing called "STL array". Do you mean std::vector?
I think it's worth noting the precise reasons why STL containers aren't "good enough" to "totally" replace arrays:
Extra overhead from carrying information about the array's size in addition to its data address
Lack of syntax support for declaring elements of a vector
Use of built-in arrays didn't end due to the continued need for the zero-overhead methods for dealing with memory
Minor inconveniences, which rarely apply.
I don't use C arrays much in my programs; std::vector is so much more easier to handle.
The third bullet above sometimes applies -- if I need a 20-char buffer inside foo() and foo() gets called
a million times per second, I wouldn't like to malloc memory every time. But that's a local thing
which doesn't spread globally throughout the code.
Maybe the Boost array type would help here, but I haven't used it so I wouldn't know.
The main cause for C arrays in C++ code today is, I think, that there are/still/
programmers who haven't learned to use the standard containers.
And finally, we cannot remove C arrays anyway.
The grandparent seems to be one of those guys who pretend we could ignore all existing code,
throw C compatibility out the window, and start from scratch. Well, we can't.
And besides, the C compatibility is one of the big assets of C++.
Kalev's questions came across as ignorant and belligerent, but Stroustrup answered all of them intelligently, thoroughly and patiently. It's good to know that there are men like Stroustrup still working hard on C++, even though I no longer do much work in it.
It's called being a professional. Rare these days, I know. Good to see though.
He was clearly annoyed by the questions (or the way they were phrased, or what was implied by them), though. And he didn't try to hide it. Maybe he should have.
It's only a big deal to certain programming groups and applications. The programming I do cannot use templates so generic programming is useless to me and removal of concepts is not a big deal at all.
You do C++ programming and cannot use templates? How's that?
Broken compiler/linker?
A boss with irrational fears of anything younger than fifteen years?
I cannot see any other reason; fear of code bloat is not a valid reason to ban/all/ templates,
not even in tiny embedded systems.
Note that templates isn't all about metaprogramming voodoo.
It's also about some very simple, straightforward uses: small utility functions and classes
which can make plain old C++ code more readable.
Well, either you believe in static typing, or you don't. If you do, Java is a good choice. If you don't, Ruby is a good choice. C++, on the other hand, is static enough to be annoying, but not static enough to be safe.
What's less static about C++ compared to Java?
I don't know Java, but the only thing I can think about is the wealth of integer types in C and C++,
and the conversions between them (some of which you can tell your compiler to warn you about even though
they may be legit).
I don't count casts (foo_cast or the less safe legacy C-style cast) because if you use them it's your fault.
C++ also includes 'const', which adds a whole new dimension to the static checking.
I really miss that in other languages.
And come to think of it, since you can create new types for free in C++, you have/more/ opportunities to
add type safety. Don't want to accidentally do arithmetic on TCP port numbers? Write a TcpPort class, with no more
runtime cost than an uint16_t would have had.
There is a lot of overlap between the two concepts, but screen supports a (strict?) subset of Emacs's features.
Subset? Does emacs have a working terminal emulator, then?
*checking*
M-x terminal-emulator. Damn Emacs.
I can swallow that some people still (after GUIs and screen(1) became available twenty years ago or so)
prefer to live entirely inside one emacs instance,
but personally I could never learn to run my shells, run make and so on there.
In contrast, when I discovered screen(1), I got addicted immediately.
Oh well, I don't mind new features as long as they don't hurt me.
I never thought I'd see the day that a text editor needed a network-aware client-server architecture.
The grandparent doesn't describe network-awareness -- he ssh:s into the machine and
connects to a running emacs and its buffers.
But yeah, I'm an emacs user, and I doubt I'll ever use that feature.
That's what you use screen(1) for. One task, one tool.
And by the way, what does
"pop up new emacs windows in the blink of an eye" mean?
That's how emacs works by default on any decently new machine these days.
No need to jump through hoops to accomplish that.
most OS X apps have already been ported from PowerPC to x86 so have no CPU dependencies
Huh what? Porting a app to another CPU means it has no CPU dependencies? What are you smoking? An RDF cigar?
I think he means "make portable", i.e. to remove the bugs which make the application
only *accidentally* work on a on a certain CPU:
unaligned memory accesses, endianness issues, assumptions about the size of integers and pointers,
and so on.
Changing a program which works on ppc but breaks on anything else,
into working on x86 and breaking on anything else -- that would be stupid.
Inside the store they have three separate racks: new, used, and used-and-no-one-likes-it. The new rack generally sells albums for $12-$14, which is slightly more than iTunes would run you. The used rack sells albums for $5-$9, or slightly less. The third rack sells albums for $2, or $1 if you buy 10 or more at a time. The third rack's quality, however, is a lot more suspect than the other two.
Yeah, at one point these third racks were dominated by early Kylie Minogue albums, and 1984-era
hits. (That was when vinyl still dominated those stores, of course.)
I can't stand buying music in a large retailer, and hope that small independent stores can make a comeback.
Around here (.se) independent stores have always dominated, as far as I can tell.
A store tends to either have a broad range of music (but attract its own kind of crowd) and staff who clearly love music,
or be faceless and carry the twenty best-selling albums. It's the former kind who gets
the customers, or at least the kind of customers who buy music as more than just
lame birthday presents.
What drivel. Drag'n'Drop is the shortcut equivalent of 'Save File' in program 1, 'Open File' in program 2. It's a bunch of o' bytes. It makes absolutely no difference if the bytes come through the Drag'n'Drop route or through a file.
More or less.
There should be something like "Hey, clipboard: give me your stuff as
an image/as plain text/as foo" with just one or two data formats for each
data type.
You would want to paste text from a web browser as a bitmap into a bitmap editor,
but as plain text into a text editor.
I was one of those unfortunate users of Debian 3.0 stable (woody). It was released in July 2002. The next release was (two week shy of) three years after that.
[---]
From March to June of 2005, you were, aside from security updates, running the 2001 version of Python on your current Debian stable box. It is ridiculous. I was trying to run Python scripts written in 2004 and 2005 and couldn't because they were all based on Python 2.3+, if not 2.4.
Python is a bit of a special case, though.
It's a great programming language, but IMHO the Python culture is
way too bleeding-edge-oriented. As soon as Guido & co invent some new language construct,
Python programmers are too eager to use it immediately, everywhere...
It's telling you you're not running a real release at all, but
testing or unstable, or whatever it's called (I almost never run
anything but stable). Perhaps that file should
be clearer... but if you need that, you probably shouldn't
be running anything but a stable Debian release.
Slashdot Mirror
I meant to, but you beat me to it. Unix versus anything else in the 1970s, TCP/IP versus whatever layered monsters others tried to dream up.
I still don't see how Windows fits into that, though. The PC hardware did, and that's what got it rolling, plus the users' childish tendency to love, trust and bonding to first IBM, then Microsoft.
I doubt it. Not because the SVN/CVS model is so great, but because there's for some reason so much ideology and flag-waving in this. Let someone start using SVN, or git, or whatever, and suddenly it's as if he's joined some fscking religion.
So when you say SVN "is the last of its line", I hear "Jesus is coming soon!".
Me, I use CVS at home and ClearCase at work. I like both of them. The main problem is not the tool, but people setting up processes which destroy any benefits from the tool, and users then deciding the tool is crap, ignoring it for as long as possible.
But I must admit that I don't even know what malware is. I assume it's not executables -- I cannot imagine people still download and execute those.
It is generally agreed upon that the colonialism thing (not only in Africa) was a bad thing, and it's an important aspect of Ireland's history.
Also, it seems to me you are twisting the facts. The article is about the Republic of Ireland, which was created in 1916 -- not about Ireland in the sense of green hills, clover leaves, potato famine and NY cops. Not surprising that it focuses on the fight for independence.
When people write like that about the Wikipedia and go on and on, they usually have some personal axe to grind. Do you, and if so, which one?
My personal experience is that sure, many pages are poor, but as a whole Wikipedia is invaluable to me. I can't say I like this change, and I doubt I will contribute in the future if I'm not trusted more than that, if I cannot know when my changes take effect, if I know any tiny grammar fix I make causes work for someone,
I have ... but I think that's a special case.
And I think the OP's problem isn't universal. Might work that way for a lot
of people, but not for me.
One scary thing though is that I read and write so much english that it is getting harder to write in swedish.
Next time, try to pick it down from the shelf first. Much easier.
I read the rest of your post as if you think C is actually a decent language. Then how can you at the same time criticize C++ for working like C in this area? Do you know that C++ was designed to be -- needed to be -- C compatible?
This particular problem should be a non-problem for everyone but very new C++ novices. One of the first things to keep in mind is always protect the integrity of your objects. Applied here it means (a) build your classes from objects which are copyable (like the STL containers) and (b) failing that, disable the copy constructor and operator+ () to explicitly say that they aren't. And even (c) there's probably something odd going on if you have to define your own copy constructor.
Depends on who coined the term "reference" first. I sure hope you didn't write C++ code with references assuming they worked like Java references.
I haven't read the book, but I know from first-hand experience that this isn't the case. Sure, it's not Python. And it does take more effort to learn well than most other languages. But it's not some kind of minefield. When you need C compatibility, speed and/or static type checking, it will serve you very well.
But it's primarily the idiots who use those three features you mention!
I'd expect a genius to stick to the normal features (of which there are plenty, unique to C++) most of the time, and only use the things you mention when there's a real need. For at least multiple inheritance and dynamic casting, that is rarely. So far, I've used dynamic_cast once or twice, and the former never.
I disagree. Calling the language 'perl' is something people do today. Calling it 'PERL' is something people would do in the 1980s; it indicates you have little contact with the Perl community. Or that you are a little odd, or have some amount of dyslexia.
Yeah. People who provide services like these need to explain how this is better than an actual will. And how they expect the service to survive longer than you and me.
The same goes for a similar service which got a lot of press here in .se recently -- one which
would, at your death, unregister your accounts at sites like ... uh, Slashdot.
At the same time, perhaps lawyers (or whoever manages wills) need to adapt to modern technology and offer some of these things.
That's not the impression I get as a reader. Sure, the cover screams O'Reilly! but to me that just means the author has adapted to a framework which is sensible and familiar to the reader. That someone has created a sensible index, put examples and errata on the web, and so on. Not a bad thing. It doesn't mean the author is some kind of faceless robot; you realize quite soon (as a reader) that writing good tech is a creative art.
Don't know how others react, but being published by O'Reilly seems way cooler to me than being published elsewhere -- at least if the work is something concrete and practical where O'Reilly have such a good track record.
Thanks! I had been looking for that story. Last time I saw it, it was reprinted in an Ericsson company-internal Unix course compendium, under the title "Devil worshipping in Texas". There, it was illustrated with a three-year-old girl wearing a BSD tshirt and looking mischievous ...
And this is iostreams' problem ... how?
There is no thing called "STL array". Do you mean std::vector?
Minor inconveniences, which rarely apply. I don't use C arrays much in my programs; std::vector is so much more easier to handle. The third bullet above sometimes applies -- if I need a 20-char buffer inside foo() and foo() gets called a million times per second, I wouldn't like to malloc memory every time. But that's a local thing which doesn't spread globally throughout the code. Maybe the Boost array type would help here, but I haven't used it so I wouldn't know.
The main cause for C arrays in C++ code today is, I think, that there are /still/
programmers who haven't learned to use the standard containers.
And finally, we cannot remove C arrays anyway. The grandparent seems to be one of those guys who pretend we could ignore all existing code, throw C compatibility out the window, and start from scratch. Well, we can't. And besides, the C compatibility is one of the big assets of C++.
He was clearly annoyed by the questions (or the way they were phrased, or what was implied by them), though. And he didn't try to hide it. Maybe he should have.
You do C++ programming and cannot use templates? How's that? Broken compiler/linker? A boss with irrational fears of anything younger than fifteen years? I cannot see any other reason; fear of code bloat is not a valid reason to ban /all/ templates,
not even in tiny embedded systems.
Note that templates isn't all about metaprogramming voodoo. It's also about some very simple, straightforward uses: small utility functions and classes which can make plain old C++ code more readable.
What's less static about C++ compared to Java? I don't know Java, but the only thing I can think about is the wealth of integer types in C and C++, and the conversions between them (some of which you can tell your compiler to warn you about even though they may be legit). I don't count casts (foo_cast or the less safe legacy C-style cast) because if you use them it's your fault.
C++ also includes 'const', which adds a whole new dimension to the static checking. I really miss that in other languages.
And come to think of it, since you can create new types for free in C++, you have /more/ opportunities to
add type safety. Don't want to accidentally do arithmetic on TCP port numbers? Write a TcpPort class, with no more
runtime cost than an uint16_t would have had.
Subset? Does emacs have a working terminal emulator, then?
*checking*
M-x terminal-emulator. Damn Emacs.
I can swallow that some people still (after GUIs and screen(1) became available twenty years ago or so) prefer to live entirely inside one emacs instance, but personally I could never learn to run my shells, run make and so on there. In contrast, when I discovered screen(1), I got addicted immediately. Oh well, I don't mind new features as long as they don't hurt me.
The grandparent doesn't describe network-awareness -- he ssh:s into the machine and connects to a running emacs and its buffers. But yeah, I'm an emacs user, and I doubt I'll ever use that feature. That's what you use screen(1) for. One task, one tool.
And by the way, what does "pop up new emacs windows in the blink of an eye" mean? That's how emacs works by default on any decently new machine these days. No need to jump through hoops to accomplish that.
I think he means "make portable", i.e. to remove the bugs which make the application only *accidentally* work on a on a certain CPU: unaligned memory accesses, endianness issues, assumptions about the size of integers and pointers, and so on.
Changing a program which works on ppc but breaks on anything else, into working on x86 and breaking on anything else -- that would be stupid.
Yeah, at one point these third racks were dominated by early Kylie Minogue albums, and 1984-era hits. (That was when vinyl still dominated those stores, of course.)
Around here (.se) independent stores have always dominated, as far as I can tell. A store tends to either have a broad range of music (but attract its own kind of crowd) and staff who clearly love music, or be faceless and carry the twenty best-selling albums. It's the former kind who gets the customers, or at least the kind of customers who buy music as more than just lame birthday presents.
More or less. There should be something like "Hey, clipboard: give me your stuff as an image/as plain text/as foo" with just one or two data formats for each data type. You would want to paste text from a web browser as a bitmap into a bitmap editor, but as plain text into a text editor.
This is, IIRC, how the X11 clipboard works.
Python is a bit of a special case, though. It's a great programming language, but IMHO the Python culture is way too bleeding-edge-oriented. As soon as Guido & co invent some new language construct, Python programmers are too eager to use it immediately, everywhere ...
salix:~% cat /etc/debian_version /etc/debian_version
5.0.2
salix:~% ssh tuva cat
4.0
It's telling you you're not running a real release at all, but testing or unstable, or whatever it's called (I almost never run anything but stable). Perhaps that file should be clearer ... but if you need that, you probably shouldn't
be running anything but a stable Debian release.