This is compelling evidence. It's gotten unmaintainable.
Time to take stuff out. But it won't happen, will it? Nobody wants to lose his favorite feature.
Refactor? Risky. Especially this late in the game.
Now, if they were to add some sort of safe/smart pointers to gcc and throw up warnings on all pointer arithmetic, we might slowly refactor many data corruption issues and memory leaks away.
The standard class library, mainly. They kind of screwed that up, despite several tries. In particular, over-use of exception handling. It's not inherently a bad idea, but they went over the top with it.
I really wanted to love Java. The core language is just fine, I think. Huge improvement there over C and C++. Everything else about it irritates me.
How would a standard C compiler make use of that when compiling pointer arithmetic? The array bounds are unknown, except just maybe to the programmer.
Get the language semantics right first. That needs doing right now. Then we can optimize the hardware to the semantics at our leisure. Correctness first, speed optimization later.
Management sucks. Can we do anything about that? Programmers also suck, because sucky managers hire sucky programmers. Can we do anything about that?
If not, then settle for doing what we can, where we can, to manage and ameliorate the problem we can't fix. It's a Band-Aid, but it's what we have, and better than nothing.
We can't fix human nature. Stupidity is a given. But we can compensate for it.
The idea isn't to enable the untalented or unskilled to produce good software. The idea is to put a floor on how bad the bad software can get. Bosses will always hire idiots. Worst case with safe pointers: the idiots fail to produce something that works, so the bosses relent and bring in good programmers. Worst case without: the idiots produce something that seems to work, but then a stray pointer leads to disaster. Which worst case do you prefer?
Also, pointer safe languages take the stress off of good programmers so we can concentrate on the level at which our insight is needed most.
The best we say can say about unsafe pointer use is that there are special cases where it's worthwhile. It absolutely should not be the default.
C makes it easier to be unsafe than safe. Safe takes extra effort, shooting your users in the foot is enabled. It should be the other way around. Make programmers jump through some hoops to do it the dangerous way, instead of the safe way.
C++ is better, but not all the way there. And there's too much legacy code in C. We need a migration path.
Reformed C or entirely new language, it costs what it costs regardless.
It's really about priorities. Here in the 21st century, we need safe programs more than we need CPU-efficient programs. I'm not saying performance doesn't matter. I'm saying other things matter more. I don't care how fast your race car runs if it's going to hit a wall.
The reason unsafe, unmaintainable cruft sticks around is that all these people coming up with new languages don't think to provide a migration path. What's needed:
1. An interface to existing C code, so we don't have to convert all at once. Okay, that one they usually provide. But... 2. Ditto for C++ code. 3. Ditto for Perl 5 code. 4. Tools to assist in translating from old languages to new. Fully automated translation may be over-optimistic, but we can get halfway there.
Or... 1. An improved edition of C/C++ that provides safe pointer features, alternatives to preprocessor, and... 2. DEPRECATES pointer arithmetic and other language malfeatures with obtrusive compile warnings and such.
Then we can get rid of all those compile warnings at our leisure.
If standards bodies don't come through fast enough, let GNU take the initiative.
Cross-site embedded images are a problematic capability. If there were some sort of meta tag by which a server could inform a browser that its images are not to be cross-linked, then we could have the best of both worlds.
...that kind of thinking has never been a friend of open source, or of developers who want to do things right.
Now that I'm my own boss, I'd really like to know. What's the best open source GUI toolkit for cross-platform development? Please don't tell me great Qt is, and don't tell me how much Qt sucks. I need to know how the various options compare to each other.
Oh, and... how exactly do I submit to Ask Slashdot? Thanks.
If not, the kluge that the Web has become will do for now. It may diminish, but it need not die. Even gopher has not entirely vanished.
I'm very much for freedom, but I understand that implies permitting others to throw their own freedom away if they so choose. Let them handle the consequences. Just as long as freedom remains an option, meta-freedom is a reality - and that's fine for me.
I value others' privacy enough not to demand access to their walled gardens. I value the network effect enough not to want to be in a walled garden myself. Just leave me that option.
Also, lots of sites block Tor outright. Not even the courtesy of a CAPTCHA. That's a troubling trend.
Maybe if we force upstream-downrange ratios into a narrow range then we can avoid exit nodes looking distinct from ordinary client hosts. That will make it harder to upload large files, but I can live with that.
This is a concern for me. It seems like exit nodes get blacklisted because they look like exit nodes. If we sculpted their traffic to look more vanilla we could get past this, and maybe reduce Tor's usability for spammers at the same time.
The danger is it could also reduce usability for legit users as well, but CAPTCHA is already doing that anyway.
Slashdot Mirror
why didn't somebody fork it long before now?
All the people who made it possible for them to do it Meaning the vendors, and the low information consumers.
Spread the blame around. There's plenty.
This is compelling evidence. It's gotten unmaintainable.
Time to take stuff out. But it won't happen, will it? Nobody wants to lose his favorite feature.
Refactor? Risky. Especially this late in the game.
Now, if they were to add some sort of safe/smart pointers to gcc and throw up warnings on all pointer arithmetic, we might slowly refactor many data corruption issues and memory leaks away.
We need a feasible plan and tools to convert all that PHP code to something better. Python, maybe.
When laptop computers fell under $300 in price I started thinking of them as FRUs.
The standard class library, mainly. They kind of screwed that up, despite several tries. In particular, over-use of exception handling. It's not inherently a bad idea, but they went over the top with it.
I really wanted to love Java. The core language is just fine, I think. Huge improvement there over C and C++. Everything else about it irritates me.
you could bake the bounds into some pointers at malloc/calloc time. Far from perfect, but an improvement over the status quo.
Anyone remember 286 protected mode?
How would a standard C compiler make use of that when compiling pointer arithmetic? The array bounds are unknown, except just maybe to the programmer.
Get the language semantics right first. That needs doing right now. Then we can optimize the hardware to the semantics at our leisure. Correctness first, speed optimization later.
Management sucks. Can we do anything about that? Programmers also suck, because sucky managers hire sucky programmers. Can we do anything about that?
If not, then settle for doing what we can, where we can, to manage and ameliorate the problem we can't fix. It's a Band-Aid, but it's what we have, and better than nothing.
We can't fix human nature. Stupidity is a given. But we can compensate for it.
The idea isn't to enable the untalented or unskilled to produce good software. The idea is to put a floor on how bad the bad software can get. Bosses will always hire idiots. Worst case with safe pointers: the idiots fail to produce something that works, so the bosses relent and bring in good programmers. Worst case without: the idiots produce something that seems to work, but then a stray pointer leads to disaster. Which worst case do you prefer?
Also, pointer safe languages take the stress off of good programmers so we can concentrate on the level at which our insight is needed most.
The best we say can say about unsafe pointer use is that there are special cases where it's worthwhile. It absolutely should not be the default.
C makes it easier to be unsafe than safe. Safe takes extra effort, shooting your users in the foot is enabled. It should be the other way around. Make programmers jump through some hoops to do it the dangerous way, instead of the safe way.
C++ is better, but not all the way there. And there's too much legacy code in C. We need a migration path.
Reformed C or entirely new language, it costs what it costs regardless.
It's really about priorities. Here in the 21st century, we need safe programs more than we need CPU-efficient programs. I'm not saying performance doesn't matter. I'm saying other things matter more. I don't care how fast your race car runs if it's going to hit a wall.
And that's the problem. We have to deal with legacy code, written by others.
The reason unsafe, unmaintainable cruft sticks around is that all these people coming up with new languages don't think to provide a migration path. What's needed:
1. An interface to existing C code, so we don't have to convert all at once. Okay, that one they usually provide. But...
2. Ditto for C++ code.
3. Ditto for Perl 5 code.
4. Tools to assist in translating from old languages to new. Fully automated translation may be over-optimistic, but we can get halfway there.
Or...
1. An improved edition of C/C++ that provides safe pointer features, alternatives to preprocessor, and...
2. DEPRECATES pointer arithmetic and other language malfeatures with obtrusive compile warnings and such.
Then we can get rid of all those compile warnings at our leisure.
If standards bodies don't come through fast enough, let GNU take the initiative.
shut off service to the pirate sites (under court order, for legal cover) for a week and see what happens.
Maybe PyPi will do the job. We'll see.
Give me something comparable for Python and I'll be done with Perl for good.
Anaconda doesn't quite give me the same communitarian, open sourcey feeling.
an observation:
Cross-site embedded images are a problematic capability. If there were some sort of meta tag by which a server could inform a browser that its images are not to be cross-linked, then we could have the best of both worlds.
...that kind of thinking has never been a friend of open source, or of developers who want to do things right.
Now that I'm my own boss, I'd really like to know. What's the best open source GUI toolkit for cross-platform development? Please don't tell me great Qt is, and don't tell me how much Qt sucks. I need to know how the various options compare to each other.
Oh, and... how exactly do I submit to Ask Slashdot? Thanks.
Deal breaker right there.
The whole point of freedom is to reduce dependency on other people. We do for ourselves,
If not, the kluge that the Web has become will do for now. It may diminish, but it need not die. Even gopher has not entirely vanished.
I'm very much for freedom, but I understand that implies permitting others to throw their own freedom away if they so choose. Let them handle the consequences. Just as long as freedom remains an option, meta-freedom is a reality - and that's fine for me.
I value others' privacy enough not to demand access to their walled gardens. I value the network effect enough not to want to be in a walled garden myself. Just leave me that option.
Also, lots of sites block Tor outright. Not even the courtesy of a CAPTCHA. That's a troubling trend.
Maybe if we force upstream-downrange ratios into a narrow range then we can avoid exit nodes looking distinct from ordinary client hosts. That will make it harder to upload large files, but I can live with that.
Other people's complacency should not be my responsibility.
Let them be spied on if they're fine with that. But if it affects me, then a line has been crossed.
This is a concern for me. It seems like exit nodes get blacklisted because they look like exit nodes. If we sculpted their traffic to look more vanilla we could get past this, and maybe reduce Tor's usability for spammers at the same time.
The danger is it could also reduce usability for legit users as well, but CAPTCHA is already doing that anyway.
Well, I was feeling bad because I'd prototyped in Perl/Tk. But text mode?
This does look very much along the lines of what I'm doing. Why isn't there a generic name for this sort of thing, so we can find them?