The problem isn't that C++ exists, the problem is that in _most_ places where it is used it shouldn't be. Used by people who aren't gurus for projects where a higher level language would serve both them and the project much better. Fewer bugs and a much faster development cycle.
Sometimes I think it goes like this: Bad programmer creates slow code in HLL, so we tell him to use C(++) instead so that he regain some of it...
C++ is a complex beast of a language where features interact in extremly subtle and often pathological ways. You might not pay for the features you don't use in performance, but you often end up doing so in cognitive load.
I'm sorry, but that's a load of crap. Bad tool can cause injury and makes the job harder than it could (should) be. Programming languages are a whole more complicated than hammers and there is much more room for different dimensions of goodness. Trying to make a cupboard with a saw designed for cutting down Redwoods is not only overkill, it's a whole lot harder than using the appropriate tool.
The problem isn't that C/C++ exist, the problem is that they are used by people and in projects which would be better benefitted by different tools.
The logic seems to be: Bad programmers produce slow code, so let's mitigate that by giving them a language that generally compiles to really fast executables, C/C++.
The smart programmer uses the appropriate tool for the job, 95% of the time that wouldn't be C/C++ if it wasn't for the fact that the tool and library support for those languages often tip the scale.
Well, my (albeit limited) experience is that it, in practise, does not work very well at all =) I hated every second of it, but it did provide a bit of perspective.
I still have a lot nicer memories of m68k asm than those of x86 asm =)
I might have misread your post, if I did, sorry =)
The 387 is the x86 FPU architechture. It doesn't have regular registers but is (at least was) stuck with 8 (?) 'stack registers', which meant that all register accesses are done relative to the current top of stack register. This meant the same value had to be accessed from different points, so keeping track of the top of the register stack was extremly important.
This design had me entierly confounded, and it's widely believed that it was partly responsible for the x86 FPU's often non-competetive performance.
But you probably get to use real register don't you? Don't you? The real mess is keeping track of what's where in the 387 register stack. Never did I comment my code as much:-)
And not to talk about all these macro things, what, a machine code monitor is all that you need...
Thing is, the class/prototype distinction has yet another use, one that is wholly pragmatic but not theoretically significant. It's documentation. Having a few orthagonal concepts as the basis for a language is a good thing that has many disadvantages. Actually programming in these concepts might not be a good idea. Python _is_ a particular set of abstractions, chosen with a particular goal in mind, to support each other and a particular style of coding. It could have had more of a theoretical basis, but it works anyway.
Python has disadvantages, and it does not have the power or flexibility of many other languages. But it does have a sound underlying philosophy and it does a good job of expressing it in the language design. Theoretical soundness and beauty factored in rather late in the design process, and in hindsight a bit of foresight (and more research) might have prevented some of the theoretical ugliness that rears it's head in the current design. Python is now (slowly) being retrofitted to fix these historical problems, at least to some degree.
That you don't see the value in Pythons original design philosophy is another matter that can't be fixed. I do, and I like it a lot, even though my own language would have a sounds type system.
I don't usually post 'mod this up' stuff, but I sure wish I had some of those moderation points I most often don't find anywhere decent to spend, right about now:-)
And I think we're slowly getting a picture of where the market is going to be, given some time. But time is a luxuary when you've spent a lot of money you don't have.
But, they may well have saved money because they prototyped the project in a language suited for prototyping before committing to the larger project. They may very well have gotten a better product in less time as a result.
At the very least very debatable. Our brain's ability to handle languages is in fact highly developed and could very well be what sets us apart from the "animals". It could well be the enabler of advanced abstract thinking. Sure, our brain also excell at pattern matching and image processing, but our language is very fundamental as well. This is what the modern direct manipulation interfaces misses almost entierly. Using them to communicate with the computer is a lot like communicating with another human without a language, a lot of humming, pointing, and demonstrating. You lose the ability to talk about the abstract, the future, the past, the invisible, and the general. Our brain is indeed a language processing machine, and those glyphs have proves, over and over again, to be faster and easier to recognise than icons (refer to Nielsen). In fact, when it comes to icons Apple knows what it's doing in OS X, the icons are based around different shapes which makes them easy to use and access. A myriad of small icons with similar overall shapes is a very inefficient way of communicating with the user.
It has little to do with a lack of ability to grasp these things and everything to do with a lack of interest in grasping the concepts. Perfectly demonstrated by how your dad learned when he had to. As you grow older you won't have that unlimited fascination for everything technical. You'll just want a lot of things to work and get out of your way. If you stay on top of it you'll be just as sharp (and wiser) but you'll discover that you're pickier about exactly what you learn.
Many children, at a certain age, read everything that comes in their way. But this doesn't last, soon they become picker, they know what kind of books they like and they will read that and will when going outside that field be deliberate when chosing how to expand their horizons. We think they get more mature, self conscious, and smarter. But when someone older than ourself gets picker we accuse them of getting lazy. Or?
I'm still confused, because Netscape 4.7whatever that I currently use under Solaris doesn't even adhere to the standard I guess. Which leaves that one fairly useless for me.
I know this is historical baggage, and I know it's not going away. But I can still complain about how much I wish it would =) I have mostly used Unix with three button mice (Sun hardware) so maybe you're right.
I'm still confused but cut-n-paste. But now I at least know how it ought to work.
Gee, I'm not dumb, I'm probably extremly computer literate, and I've been using X for a few years, and I still hadn't figured that one out. Thanks for informing me, but something is seriously wrong with that approach. It might look and feel tasty to experts, but it's a seriously complicated and messy way to have two slightly differing ways of doing what is, in most respects, the same thing.
It's cute, and knowing what's really going on even I might find it useful, but seriously don't expect my mother to get it, ever. And as long as the middle mouse button is used to paste, she won't be able to ignore it either, she'll just be terminally confused. I know I've been.
Do you have any idea about how many of the complaints about X copying/pasting that comes from this issue? I'd wager it's a huge part of them. This, if nothing else, should be a hint...
One of the most basic and important lessons in HCI is this:
Don't try to be unique for the sake of it. Don't be unique for small improvements. Familiarity is so powerful that small (percieved) improvements are dwarfed by it. Uniqueness is not a virtue, the drive for it is your bane.
Hm, meaning that with #1 refuted the rest of your discussion is pointless. I'm not radical, I think we should proceed carefully and try minimizing the costs (and losses) associated, we can't seriously expect the world to turn on a dime. But turn it has to, it's the duty of our generation to do that. True, we can't know what will happen in 300 years and that nobody will end up screwing the planet at that or a later point. But that's a really lame argument for screwing it right now and leave it to those who come in 300 years in a position where they are already screwed to start with. Unless we just accept it all as futile and decide that mankind has no future anyhow.
"Actually, that isn't my basic assumption. It is my point #1, which is based on the previous poster's somewhat erroneous assumption that the climate system is too complex for us to understand out impact thereon."
Is is your basic assumption, because it's the assumption on which all the others rest. Only if this one is true can we in any feasible way act as the rest of your points suggest. If we accept this as false (which as I pointed out it is) than we have no choice other than doing _something_. You can't say that "well, if we aren't careful we could end up making this planet uninhabitable (or very, very hostile) to humans" as a fact and then not be careful unless our actions are equally likely to save us from the same fate. And that just isn't the case, our actions are much more likely to end up destroying us than they are saving us.
"IOW, the only way to have *no* effect is to turn back the clock 10,000 years. The only way to have no further effect is to kill off all of mankind"... "In order to have no practical effect, you have to do things that are prevented by my remaining points in the post, which apparently you didn't read since you stopped with point #1."
Refuted above.
It's not hard to find environmentalist with strange opinions and no factual footing. But that doesn't change the fact that there is a lot of serious and good researchers who think we need to do something. There's something about a baby and bathwater...
All this ranting and it still comes down to one thing:
"I certainly don't feel like changing things so they would be less comfortable for me."
Your whole rant is completly meaningless because your basic assumption, that the chances of us having positive effect are roughly equal to the risks of us having a negative effect, is false. The truth is, we don't want to have _any_ effect. The earth has gone on for at least tens of thousands of years in a fashion that suits our needs just fine. The risk that this is changing dramatically for the worse without our intervention in the next 100 years is not worth taking into account.
Everything else you say leans on this and boils down to a huge excuse for not doing anything because it would compromise your precious "lifestyle". Ofcourse the Kyoto treaty is like pissing in the Sahara, but at least it's something, and attitude changes are necessary right now if we are going to make real changes later. You are stupid, stupid, stupid if you think of the Earth as a inexhaustible resource that we can keep on treating however we want forever, or at least as long as it happens to be convinient.
Almost. But as it turns out a lot of what people imagine they want at some point or another would be totally useless in reality. Atomic cars and what not. In the 1970's people thought speech recognition surely was the golden calf, today when we're almost there we know better. In the 80's virtual reality was going to be the final and ultimate computer interface, I hope few live in that dillusion today. And so on.
The other thing is that a lot of things then imagined turned out to be AI-complete. And while people have proclaimed the existance of AI for long that's one dream that's going to remain the stuff of dreams for a long time to come. Perfect natural language recognition is AI complete, ever better approximations is all we can expect on any reasonable timeframe.
And when you finally have a theoretically secure system but where the interaction design is intrusive enough that people abuse or don't use the security features you've so carefully designed, what have you gained?
User centered design is about making sure that all the time you spend perfecting your system design has any value to it and ends up being useful for the intended audience. Sure, from a far enough overhead view user centered design looks like stating the obvious, this is true for many fields. In reality there is ample evidence that it isn't, because man, do some interfaces suck for the intended audience.
Only by explicitly stating what everyone thought was obvious can we move beyond it. This is in a sense the essence of science.
> They're just following a different set of guidelines.
So, in a sense, the filesystem might be better of if it could accomodate both types of needs with different tools. The average users need to treat filenames as sensible labels by which they recognise and organize their data. This is the HCI view. The system administrator o.t.o.h. needs to treat filenames as one needs to treat strings in programming language, often with great precision and exact matching, no guesses on what the computer might consider equal. I'm not entierly certain that it's not the culture that should change (in the long run), but at any rate one needs to be practical and plotical right here and right now. So is there any way one could accomodate both sides equally without creating a quagmire of redundancy? I have this sinking feeling there might not...
> Oh, and on a personal note, thanks for the debate...it's not often you get sensible replies on slashdot;-)
Actually, it's not. I talk about the one and only use letters were designed for, to be read and written by humans. This is how they are designed. Fact remains, filenames are metadata designed to be read by humans primarily. The fact that such a system also is useful for the computer and that it's convinient for them to use the same system as humans in many situation doesn't change this. To limit the usefulness of metadata for humans just because the computer also likes to use it is ass backwards. If that's the problem the right thing is instead to invent a parallell system for the computer to use where the problems doesn exist for the computer. I repeat, if filenames were primarily designed for computers to read, they would be file numbers.
That you like to think of words on the computer as different than words anywhere else doesn't change the fact that this is a lousy interface decision for humans, because words are words even in a filename.
> That's like saying domain names are just for humans to use and computers should just use IP addresses.
Exactly.
> This is clearly not true as if a computer needs to change IP and if there was no lookup system via the DNS then none of the other computers would be able to find it and it's resources again.
Problem found, analysis deficient. URLs are designed for one purpose, to make addresses human readable (one can argue whether they succeded or not but...). The fact that it can _also_ fill a function for computers is superflous. Sure it can, but it wasn't designed primarily for this, and every time this secondary use hampers the primary use you're doing things the wrong way.
Slashdot Mirror
It certainly sucks a whole less than Java or Ada. In fact, I enjoy OCaml :-)
The problem isn't that C++ exists, the problem is that in _most_ places where it is used it shouldn't be. Used by people who aren't gurus for projects where a higher level language would serve both them and the project much better. Fewer bugs and a much faster development cycle.
Sometimes I think it goes like this:
Bad programmer creates slow code in HLL, so we tell him to use C(++) instead so that he regain some of it...
C++ is a complex beast of a language where features interact in extremly subtle and often pathological ways. You might not pay for the features you don't use in performance, but you often end up doing so in cognitive load.
I'm sorry, but that's a load of crap. Bad tool can cause injury and makes the job harder than it could (should) be. Programming languages are a whole more complicated than hammers and there is much more room for different dimensions of goodness. Trying to make a cupboard with a saw designed for cutting down Redwoods is not only overkill, it's a whole lot harder than using the appropriate tool.
The problem isn't that C/C++ exist, the problem is that they are used by people and in projects which would be better benefitted by different tools.
The logic seems to be:
Bad programmers produce slow code, so let's mitigate that by giving them a language that generally compiles to really fast executables, C/C++.
The smart programmer uses the appropriate tool for the job, 95% of the time that wouldn't be C/C++ if it wasn't for the fact that the tool and library support for those languages often tip the scale.
www.ocaml.org
Well, my (albeit limited) experience is that it, in practise, does not work very well at all =) I hated every second of it, but it did provide a bit of perspective.
I still have a lot nicer memories of m68k asm than those of x86 asm =)
I might have misread your post, if I did, sorry =)
The 387 is the x86 FPU architechture. It doesn't have regular registers but is (at least was) stuck with 8 (?) 'stack registers', which meant that all register accesses are done relative to the current top of stack register. This meant the same value had to be accessed from different points, so keeping track of the top of the register stack was extremly important.
This design had me entierly confounded, and it's widely believed that it was partly responsible for the x86 FPU's often non-competetive performance.
But you probably get to use real register don't you? Don't you? The real mess is keeping track of what's where in the 387 register stack. Never did I comment my code as much :-)
And not to talk about all these macro things, what, a machine code monitor is all that you need...
"Having a few orthagonal concepts as the basis for a language is a good thing that has many disadvantages."
=
Having a few orthagonal concepts as the basis for a language is a good thing that has many _advantages_.
Thing is, the class/prototype distinction has yet another use, one that is wholly pragmatic but not theoretically significant. It's documentation. Having a few orthagonal concepts as the basis for a language is a good thing that has many disadvantages. Actually programming in these concepts might not be a good idea. Python _is_ a particular set of abstractions, chosen with a particular goal in mind, to support each other and a particular style of coding. It could have had more of a theoretical basis, but it works anyway.
Python has disadvantages, and it does not have the power or flexibility of many other languages. But it does have a sound underlying philosophy and it does a good job of expressing it in the language design. Theoretical soundness and beauty factored in rather late in the design process, and in hindsight a bit of foresight (and more research) might have prevented some of the theoretical ugliness that rears it's head in the current design. Python is now (slowly) being retrofitted to fix these historical problems, at least to some degree.
That you don't see the value in Pythons original design philosophy is another matter that can't be fixed. I do, and I like it a lot, even though my own language would have a sounds type system.
I don't usually post 'mod this up' stuff, but I sure wish I had some of those moderation points I most often don't find anywhere decent to spend, right about now :-)
And I think we're slowly getting a picture of where the market is going to be, given some time. But time is a luxuary when you've spent a lot of money you don't have.
But, they may well have saved money because they prototyped the project in a language suited for prototyping before committing to the larger project. They may very well have gotten a better product in less time as a result.
"The brain is an image processing machine."
At the very least very debatable. Our brain's ability to handle languages is in fact highly developed and could very well be what sets us apart from the "animals". It could well be the enabler of advanced abstract thinking. Sure, our brain also excell at pattern matching and image processing, but our language is very fundamental as well. This is what the modern direct manipulation interfaces misses almost entierly. Using them to communicate with the computer is a lot like communicating with another human without a language, a lot of humming, pointing, and demonstrating. You lose the ability to talk about the abstract, the future, the past, the invisible, and the general. Our brain is indeed a language processing machine, and those glyphs have proves, over and over again, to be faster and easier to recognise than icons (refer to Nielsen). In fact, when it comes to icons Apple knows what it's doing in OS X, the icons are based around different shapes which makes them easy to use and access. A myriad of small icons with similar overall shapes is a very inefficient way of communicating with the user.
It has little to do with a lack of ability to grasp these things and everything to do with a lack of interest in grasping the concepts. Perfectly demonstrated by how your dad learned when he had to. As you grow older you won't have that unlimited fascination for everything technical. You'll just want a lot of things to work and get out of your way. If you stay on top of it you'll be just as sharp (and wiser) but you'll discover that you're pickier about exactly what you learn.
Many children, at a certain age, read everything that comes in their way. But this doesn't last, soon they become picker, they know what kind of books they like and they will read that and will when going outside that field be deliberate when chosing how to expand their horizons. We think they get more mature, self conscious, and smarter. But when someone older than ourself gets picker we accuse them of getting lazy. Or?
=)
I'm still confused, because Netscape 4.7whatever that I currently use under Solaris doesn't even adhere to the standard I guess. Which leaves that one fairly useless for me.
I know this is historical baggage, and I know it's not going away. But I can still complain about how much I wish it would =) I have mostly used Unix with three button mice (Sun hardware) so maybe you're right.
I'm still confused but cut-n-paste. But now I at least know how it ought to work.
Gee, I'm not dumb, I'm probably extremly computer literate, and I've been using X for a few years, and I still hadn't figured that one out. Thanks for informing me, but something is seriously wrong with that approach. It might look and feel tasty to experts, but it's a seriously complicated and messy way to have two slightly differing ways of doing what is, in most respects, the same thing.
It's cute, and knowing what's really going on even I might find it useful, but seriously don't expect my mother to get it, ever. And as long as the middle mouse button is used to paste, she won't be able to ignore it either, she'll just be terminally confused. I know I've been.
Do you have any idea about how many of the complaints about X copying/pasting that comes from this issue? I'd wager it's a huge part of them. This, if nothing else, should be a hint...
One of the most basic and important lessons in HCI is this:
Don't try to be unique for the sake of it. Don't be unique for small improvements. Familiarity is so powerful that small (percieved) improvements are dwarfed by it. Uniqueness is not a virtue, the drive for it is your bane.
> Trying to become a monopoly is fine.
Unless it's done by leveraging a different and already existant monopoly, then it's illegal.
Then you're really going to hate this:: //www.hypernews.org/HyperNews/get/computing/l ang-list.html
http://sk.nvg.org/lang/lang.html
or
http
"Refuted above."
Hm, meaning that with #1 refuted the rest of your discussion is pointless. I'm not radical, I think we should proceed carefully and try minimizing the costs (and losses) associated, we can't seriously expect the world to turn on a dime. But turn it has to, it's the duty of our generation to do that. True, we can't know what will happen in 300 years and that nobody will end up screwing the planet at that or a later point. But that's a really lame argument for screwing it right now and leave it to those who come in 300 years in a position where they are already screwed to start with. Unless we just accept it all as futile and decide that mankind has no future anyhow.
"Actually, that isn't my basic assumption. It is my point #1, which is based on the previous poster's somewhat erroneous assumption that the climate system is too complex for us to understand out impact thereon."
...
Is is your basic assumption, because it's the assumption on which all the others rest. Only if this one is true can we in any feasible way act as the rest of your points suggest. If we accept this as false (which as I pointed out it is) than we have no choice other than doing _something_. You can't say that "well, if we aren't careful we could end up making this planet uninhabitable (or very, very hostile) to humans" as a fact and then not be careful unless our actions are equally likely to save us from the same fate. And that just isn't the case, our actions are much more likely to end up destroying us than they are saving us.
"IOW, the only way to have *no* effect is to turn back the clock 10,000 years. The only way to have no further effect is to kill off all of mankind"
"In order to have no practical effect, you have to do things that are prevented by my remaining points in the post, which apparently you didn't read since you stopped with point #1."
Refuted above.
It's not hard to find environmentalist with strange opinions and no factual footing. But that doesn't change the fact that there is a lot of serious and good researchers who think we need to do something. There's something about a baby and bathwater...
All this ranting and it still comes down to one thing:
"I certainly don't feel like changing things so they would be less comfortable for me."
Your whole rant is completly meaningless because your basic assumption, that the chances of us having positive effect are roughly equal to the risks of us having a negative effect, is false. The truth is, we don't want to have _any_ effect. The earth has gone on for at least tens of thousands of years in a fashion that suits our needs just fine. The risk that this is changing dramatically for the worse without our intervention in the next 100 years is not worth taking into account.
Everything else you say leans on this and boils down to a huge excuse for not doing anything because it would compromise your precious "lifestyle". Ofcourse the Kyoto treaty is like pissing in the Sahara, but at least it's something, and attitude changes are necessary right now if we are going to make real changes later. You are stupid, stupid, stupid if you think of the Earth as a inexhaustible resource that we can keep on treating however we want forever, or at least as long as it happens to be convinient.
Almost. But as it turns out a lot of what people imagine they want at some point or another would be totally useless in reality. Atomic cars and what not. In the 1970's people thought speech recognition surely was the golden calf, today when we're almost there we know better. In the 80's virtual reality was going to be the final and ultimate computer interface, I hope few live in that dillusion today. And so on.
The other thing is that a lot of things then imagined turned out to be AI-complete. And while people have proclaimed the existance of AI for long that's one dream that's going to remain the stuff of dreams for a long time to come. Perfect natural language recognition is AI complete, ever better approximations is all we can expect on any reasonable timeframe.
And when you finally have a theoretically secure system but where the interaction design is intrusive enough that people abuse or don't use the security features you've so carefully designed, what have you gained?
User centered design is about making sure that all the time you spend perfecting your system design has any value to it and ends up being useful for the intended audience. Sure, from a far enough overhead view user centered design looks like stating the obvious, this is true for many fields. In reality there is ample evidence that it isn't, because man, do some interfaces suck for the intended audience.
Only by explicitly stating what everyone thought was obvious can we move beyond it. This is in a sense the essence of science.
> They're just following a different set of guidelines.
;-)
So, in a sense, the filesystem might be better of if it could accomodate both types of needs with different tools. The average users need to treat filenames as sensible labels by which they recognise and organize their data. This is the HCI view. The system administrator o.t.o.h. needs to treat filenames as one needs to treat strings in programming language, often with great precision and exact matching, no guesses on what the computer might consider equal. I'm not entierly certain that it's not the culture that should change (in the long run), but at any rate one needs to be practical and plotical right here and right now. So is there any way one could accomodate both sides equally without creating a quagmire of redundancy? I have this sinking feeling there might not...
> Oh, and on a personal note, thanks for the debate...it's not often you get sensible replies on slashdot
The feeling is 100% mutual I assure you =)
> It's a cultral thing.
Actually, it's not. I talk about the one and only use letters were designed for, to be read and written by humans. This is how they are designed. Fact remains, filenames are metadata designed to be read by humans primarily. The fact that such a system also is useful for the computer and that it's convinient for them to use the same system as humans in many situation doesn't change this. To limit the usefulness of metadata for humans just because the computer also likes to use it is ass backwards. If that's the problem the right thing is instead to invent a parallell system for the computer to use where the problems doesn exist for the computer. I repeat, if filenames were primarily designed for computers to read, they would be file numbers.
That you like to think of words on the computer as different than words anywhere else doesn't change the fact that this is a lousy interface decision for humans, because words are words even in a filename.
> That's like saying domain names are just for humans to use and computers should just use IP addresses.
Exactly.
> This is clearly not true as if a computer needs to change IP and if there was no lookup system via the DNS then none of the other computers would be able to find it and it's resources again.
Problem found, analysis deficient. URLs are designed for one purpose, to make addresses human readable (one can argue whether they succeded or not but...). The fact that it can _also_ fill a function for computers is superflous. Sure it can, but it wasn't designed primarily for this, and every time this secondary use hampers the primary use you're doing things the wrong way.