Being the perfect programmer doesn't have anything to do with ones preference for unit tests or not. There are other methods (review, debug, lots of logging) and besides, unit tests may simply be too costly and time consuming. What remains is that it does take quite the super-person to be a programmer and a good test-designer at the same time, and even then we're still talking about the butcher judging his own meat. Given that, it's not surprising that a lot of people are adverse to unit testing. You don't have to be a superprogrammer for that.
I think you're probably not in a position to be speculating about the quality of the brains of Mr Knuth. Especially since you do not seem to want to even consider a universe in which unit testing does not provide anything useful to a project, but just wastes time. So you're not only prejudiced in this case, but you're also an assumer.
Personally, I'm not convinced. I like to test stuff to see whether it conforms to my ideas of it, but I'm also humble enough to realize that other people have other ideas of it, and that generally, the stupidest end-user can make a bloody mess of anything. Unit testing is fine while you're in your ivory tower, ready to throw stuff over the fence. Ideally, a bunch of tech-savvy people from the side of the client should be writing/my/ tests. But they're usually not to be had. Leave aside the layers of management that will tell you or them that that's not possible/not going to happen.
At the end of the line, writing your own unit tests is like the butcher judging his own meat. Even if he/does/ have the health and the taste of his clients at heart, it's still his own immune system and his own taste against that of this clients.
I don't think you understood my question; my question was more like this: what stands in between plants 'eating' CO2 and us (and cows, and cars, and volcanoes, and stuff) producing it ? So much so, that it'll take 1000 years to eat away the difference ? I mean, I know that CO2 is pretty low on the enery scale chemically, and that it's hard to break down. OTOH, plants must eat it like candy, because their whole sunlight/chlorophyle/energy cycle depends on it. So much of the surface facing creatures of the earth depend on it in fact, that in my mind, it would indeed be very/difficult/ to produce a meaningful CO2 percentage in the atmosphere. Does this figure of a 1000 years have a sound basis in science ? If so, how ?
But if you had something like an enormous padded sportshall in zero G, one party could throw something, while the other had to catch it. That is, thrust yourself forward with an accurate enough vector to intercept it. And if you fail, you just keep bouncing. Of course, if you don't fail, you keep bouncing as well, but there'd be things to hold on to on the sides of it. Or something.
Can you explain this a bit, please ? I'm honestly curious: I would have thought that the plant-cycle would clear CO2 out of the atmosphere in no time at all. I was under the impression that planting trees could actually be offset against car-production in real time, if you know what I mean.
Tbe fact that mere agriculture was possible, and that it enabled civilizations to prosper, should give us at least a hunch about temperatures for the last 6000 years, shouldn't it ? I mean, what about those Mayans, Egyptians and Chinese ?
You could 'obfuscate' the captcha by cutting the picture in n parts and using divs to realign them. The actual alignment could be part of a javascript algorithm, which changes and uses complex-to-parse math to get to its numbers. The javascript could be eval-ed out of a string, which is decrypted using a user supplied password (anybody implemented AES in javascript yet ?). Now I'm running away with myself; the point is, when you start to force scammers to take actual screenshots of browsers, and use replay of mouse movements to capture what needs to be done to get past the CAPTCHA, then maybe you could be a bit ahead of them. For now.
They also like to sell to many different regimes/nations, all of which are definitely not going to buy it when they other guy has access to their information. So it's in their own interest really, to be as backdoor-less as possible. Any/smell/ of favouritism toward an NSA-like entity anywhere, and their product is in the toilet.
Oh yes there is latency for software-encrypted hard-drives. My company won't allow any computer to run without an encrypted disk, and apart from the fact that it's a bitch to set up under Fedora, it/does/ slow down your access to the drive. Again, no benchmarks here, but the kcryptd process makes overtime on my machine.
This fine asteroid explosion was offered to you by Unilever for the viewing pleasure and the security of you and your children. Because at Unilever, we know what it feels like when you can't by our washing up liquid anymore. Or something.
I said: expand the current functionality with something that simply *must* have better performance. Think laying out functioncalls in shared memory and calling interrupts for local clients. Think transporting events back to the client in the same way. Think painting directly in the frame buffer using shared memory.
Also, I realize that there are a load of APIs on top of the X client library that paint beautiful (and sometimes less beautiful) widgets, but a) they can't be fast because they wrap both the way in (XCreateWindow) and the way out (XGetEvent), and b) it would be a lot nicer if the X server actually understood what you *meant* when you said: 'make a scrollbar'. It can implement a faultless scrollbar namely. And generate scrollbar specific events.
With respect to cut-n-paste; they exist in Gnome and KDE. Separately. And also, separately inside WindowMaker and XFCE. It is a royal *bitch* to program against in X client lib, it depends entirely on the cooperation of the various program- and windowmanager-makers and a few conventions, and it is *very* incomplete.
I'm not saying X should be more complex. I'm saying it should be simpler: local clients get the same functions, but are executed over IPC primitives, elementary widgets go in the server so that the server can be more apt when it goes and generates events, the server is standardly plugged in with widgets, but these can be replaced either hardcoded, or by using the protocol, and communication between clients is taken care of using a pipe and some sort of object serialization.
Various ways: currently, the use of a pipe makes the protocol very safe; there's just one way to 'enter' the X-server, and that way can be monitored byte for byte. You could imagine a more cooperative (but less 'safe') model for local clients; one that uses nothing but shared memory, messages, signals and semaphores to do its job; you could make a model a la kernel syscalls; fill up a piece of memory and call an interrupt. Or even a special build model which delivers a '.so' which is linked into the X server and runs as a separate thread. It all depends how much one attaches to process isolation. The main problem I see is how to safely run various processes with different uids in the same windowing environment. How to prevent leeching of data by X clients. That wouldn't be easy without a pipe, but then again, remote X client would still have to go through the pipe. And you'd have to re-invent the event-model to make a proper difference between an action that is user-instigated and one that is machine-instigated. The X event model would have to go as well; it now depends on the setting of 32 bits. I want the X server to be able to predefine drag-n-drop and mouse gestures. Scrollbar- and menu-retention behaviour should be intrinsic to it. Basically, anything I do with the mouse button pressed, should be understood by the X server already. Unless it doesn't (drawing prgrams, for example), in which case the event should be easy to program against.
I'm no proponent of the GP, but there *is* a 'third way', if you will - expand the X-library so that a) local connections don't necessarily use a protocol over a pipe, but make function-calls instead, and b) implement widgets in the X-client library much more detailed than the current window- and image-primitives; say a basic set of menu-bar, scrollbar, list, tabs etc. All pluggable in the X-server, of course, so that everybody can still 'skin' their desktop according to their taste. c) Do away - finally - with the silly ways that cut-n-paste and drag-n-drop, in short, IPC and buffers, have been implemented in X. Invent a serious way to communicate between X clients, not a tag-along.
I think you and I both know that that's not exactly what I had in mind;-) And even if I don't get it on API level, such a thing could still be a standard UNIX subsystem. But it isn't. The farthest we got was NFS. And that's a joke. Well, it's a very useful joke in certain circumstances, but still, you wouldn't build your scaled database on top of it.
I like UNIX systems programming when it's complete; even when that surprises me. Recently, for example, I had to find a way to know how many processes had open file descriptors to a certain file. You know, the old shared database thing; so that I can make sure that I'm the only one in at a certain point (inside a file lock), to do some checks an'all. To no avail; UNIX basically said: 'if you can't do it with file locks, don't bother'. Then I discovered the good old sys/ipc.h and the associated sys/sem.h and sys/shm.h. Turns out that my issue *has* been thought about, and in a good way too. Sure, the APIs aren't all 'modern' feeling; lots of things are done with extremely short function-names, ellipsis and setting bits inside special structs, but it works. And it's fast too.
Now if they only had a good standard API to a versioned, networked filesystem. Then I would be in heaven. But a guy can dream...
Human consciousness only happened 3000-3500 years ago ? I wonder what he could mean with 'consciousness' then - there are 50000 year old cave drawings in France, does he know that ? Also, a lot of Chinese and Egyptian people might just be a tad offended by this notion.
The difference is more that when postgres has a drawback (which it does, many in fact - replication comes to mind, as well as certain configurability options, a reason why you always need a WAL (which you don't) and good caching) it will be plainly stated on their website; so-and-so is still lacking, we're working on it, if you want you can participate by either sending in your comments or implementing this-and-that. If, however, mysql has a drawback (which it has, many in fact) it will state nothing at their website, at first, and when people have been nagging them about it, it will say something like; 'that's never meant to be inside a database, solve it in the client. O by the way, it might be in the next version.'.
The problem I see with C++ is this. I know it has been recounted over and over again above, but allow me to distill it to what I think is the crux of it: if I wanted to make a C compiler (which I don't) then I would know how to make one. Same goes for java, LISP, or even BASIC. I know C quite well, and java too, but I know only what needs to be known about the other two (that is, I've written some stuff in it). My point is that the languages are simple; the 'old testament' is about two hundred pages thick using a large font and a lot of whitespace. These languages, irrespective of how well you know them or how long ago you used them, fit in your head. Granted, there would be a few lookups here and there, but all in all, given a few days of extra time, access to a web-browser, lex and yacc (or the natural language-specific variety thereof), you could build a compiler or interpreter for them. And not only do they 'fit in your head', they also have an aura around them, a 'homely feeling', or a 'scent' of sorts. You'd know what extensions to the language would be natural for it and which wouldn't be.
Not so for C++. I know some of it; I know almost all of C, but the mind just boggles trying to fit all of that behemoth into one coherent picture. It just can't be done. Not only that, but I can't even begin to define what belongs to the 'scent' of C++ and what doesn't. And that's important, because real compiler builders and standard API watchdogs must also have this feeling. For languages with a super-human scale must also have super-human compiler-makers and standard API watchdogs. And not only that, but also programmers who can say, with some pride, 'I know quite a lot, if not all of C++'. The latter thing being impossible is not a good thing - it is a flaw.
Don't these people have mothers who tell them such things are in bad taste ? If not, why would someone who could be considered an adult be doing this ?
In Europe, some of the institutions that are easily on par with MIT are free (or as good as) ! I don't have to list them, you can just look them up in the various results lists.
Slashdot Mirror
Being the perfect programmer doesn't have anything to do with ones preference for unit tests or not. There are other methods (review, debug, lots of logging) and besides, unit tests may simply be too costly and time consuming. What remains is that it does take quite the super-person to be a programmer and a good test-designer at the same time, and even then we're still talking about the butcher judging his own meat. Given that, it's not surprising that a lot of people are adverse to unit testing. You don't have to be a superprogrammer for that.
I think you're probably not in a position to be speculating about the quality of the brains of Mr Knuth. Especially since you do not seem to want to even consider a universe in which unit testing does not provide anything useful to a project, but just wastes time. So you're not only prejudiced in this case, but you're also an assumer.
/my/ tests. But they're usually not to be had. Leave aside the layers of management that will tell you or them that that's not possible/not going to happen.
/does/ have the health and the taste of his clients at heart, it's still his own immune system and his own taste against that of this clients.
Personally, I'm not convinced. I like to test stuff to see whether it conforms to my ideas of it, but I'm also humble enough to realize that other people have other ideas of it, and that generally, the stupidest end-user can make a bloody mess of anything. Unit testing is fine while you're in your ivory tower, ready to throw stuff over the fence. Ideally, a bunch of tech-savvy people from the side of the client should be writing
At the end of the line, writing your own unit tests is like the butcher judging his own meat. Even if he
Eh.. this should be modded funny. Not interesting. It got me to almost splurt the keyboard full of port anyway.
I don't think you understood my question; my question was more like this: what stands in between plants 'eating' CO2 and us (and cows, and cars, and volcanoes, and stuff) producing it ? So much so, that it'll take 1000 years to eat away the difference ? I mean, I know that CO2 is pretty low on the enery scale chemically, and that it's hard to break down. OTOH, plants must eat it like candy, because their whole sunlight/chlorophyle/energy cycle depends on it. So much of the surface facing creatures of the earth depend on it in fact, that in my mind, it would indeed be very /difficult/ to produce a meaningful CO2 percentage in the atmosphere. Does this figure of a 1000 years have a sound basis in science ? If so, how ?
But if you had something like an enormous padded sportshall in zero G, one party could throw something, while the other had to catch it. That is, thrust yourself forward with an accurate enough vector to intercept it. And if you fail, you just keep bouncing. Of course, if you don't fail, you keep bouncing as well, but there'd be things to hold on to on the sides of it. Or something.
Can you explain this a bit, please ? I'm honestly curious: I would have thought that the plant-cycle would clear CO2 out of the atmosphere in no time at all. I was under the impression that planting trees could actually be offset against car-production in real time, if you know what I mean.
Tbe fact that mere agriculture was possible, and that it enabled civilizations to prosper, should give us at least a hunch about temperatures for the last 6000 years, shouldn't it ? I mean, what about those Mayans, Egyptians and Chinese ?
You could 'obfuscate' the captcha by cutting the picture in n parts and using divs to realign them. The actual alignment could be part of a javascript algorithm, which changes and uses complex-to-parse math to get to its numbers. The javascript could be eval-ed out of a string, which is decrypted using a user supplied password (anybody implemented AES in javascript yet ?). Now I'm running away with myself; the point is, when you start to force scammers to take actual screenshots of browsers, and use replay of mouse movements to capture what needs to be done to get past the CAPTCHA, then maybe you could be a bit ahead of them. For now.
They also like to sell to many different regimes/nations, all of which are definitely not going to buy it when they other guy has access to their information. So it's in their own interest really, to be as backdoor-less as possible. Any /smell/ of favouritism toward an NSA-like entity anywhere, and their product is in the toilet.
Oh yes there is latency for software-encrypted hard-drives. My company won't allow any computer to run without an encrypted disk, and apart from the fact that it's a bitch to set up under Fedora, it /does/ slow down your access to the drive. Again, no benchmarks here, but the kcryptd process makes overtime on my machine.
This fine asteroid explosion was offered to you by Unilever for the viewing pleasure and the security of you and your children. Because at Unilever, we know what it feels like when you can't by our washing up liquid anymore. Or something.
So they'll give /two/ alarms instead of one, when the blond 17 year old with the giant but perky tits walks by.
I said: expand the current functionality with something that simply *must* have better performance. Think laying out functioncalls in shared memory and calling interrupts for local clients. Think transporting events back to the client in the same way. Think painting directly in the frame buffer using shared memory.
Also, I realize that there are a load of APIs on top of the X client library that paint beautiful (and sometimes less beautiful) widgets, but a) they can't be fast because they wrap both the way in (XCreateWindow) and the way out (XGetEvent), and b) it would be a lot nicer if the X server actually understood what you *meant* when you said: 'make a scrollbar'. It can implement a faultless scrollbar namely. And generate scrollbar specific events.
With respect to cut-n-paste; they exist in Gnome and KDE. Separately. And also, separately inside WindowMaker and XFCE. It is a royal *bitch* to program against in X client lib, it depends entirely on the cooperation of the various program- and windowmanager-makers and a few conventions, and it is *very* incomplete.
I'm not saying X should be more complex. I'm saying it should be simpler: local clients get the same functions, but are executed over IPC primitives, elementary widgets go in the server so that the server can be more apt when it goes and generates events, the server is standardly plugged in with widgets, but these can be replaced either hardcoded, or by using the protocol, and communication between clients is taken care of using a pipe and some sort of object serialization.
Various ways: currently, the use of a pipe makes the protocol very safe; there's just one way to 'enter' the X-server, and that way can be monitored byte for byte. You could imagine a more cooperative (but less 'safe') model for local clients; one that uses nothing but shared memory, messages, signals and semaphores to do its job; you could make a model a la kernel syscalls; fill up a piece of memory and call an interrupt. Or even a special build model which delivers a '.so' which is linked into the X server and runs as a separate thread. It all depends how much one attaches to process isolation. The main problem I see is how to safely run various processes with different uids in the same windowing environment. How to prevent leeching of data by X clients. That wouldn't be easy without a pipe, but then again, remote X client would still have to go through the pipe. And you'd have to re-invent the event-model to make a proper difference between an action that is user-instigated and one that is machine-instigated. The X event model would have to go as well; it now depends on the setting of 32 bits. I want the X server to be able to predefine drag-n-drop and mouse gestures. Scrollbar- and menu-retention behaviour should be intrinsic to it. Basically, anything I do with the mouse button pressed, should be understood by the X server already. Unless it doesn't (drawing prgrams, for example), in which case the event should be easy to program against.
I'm no proponent of the GP, but there *is* a 'third way', if you will - expand the X-library so that a) local connections don't necessarily use a protocol over a pipe, but make function-calls instead, and b) implement widgets in the X-client library much more detailed than the current window- and image-primitives; say a basic set of menu-bar, scrollbar, list, tabs etc. All pluggable in the X-server, of course, so that everybody can still 'skin' their desktop according to their taste. c) Do away - finally - with the silly ways that cut-n-paste and drag-n-drop, in short, IPC and buffers, have been implemented in X. Invent a serious way to communicate between X clients, not a tag-along.
Their snowballs can reach Bagdad now; they're planning on being able to reach Cyprus within the year !
I think you and I both know that that's not exactly what I had in mind ;-) And even if I don't get it on API level, such a thing could still be a standard UNIX subsystem. But it isn't. The farthest we got was NFS. And that's a joke. Well, it's a very useful joke in certain circumstances, but still, you wouldn't build your scaled database on top of it.
I like UNIX systems programming when it's complete; even when that surprises me. Recently, for example, I had to find a way to know how many processes had open file descriptors to a certain file. You know, the old shared database thing; so that I can make sure that I'm the only one in at a certain point (inside a file lock), to do some checks an'all. To no avail; UNIX basically said: 'if you can't do it with file locks, don't bother'. Then I discovered the good old sys/ipc.h and the associated sys/sem.h and sys/shm.h. Turns out that my issue *has* been thought about, and in a good way too. Sure, the APIs aren't all 'modern' feeling; lots of things are done with extremely short function-names, ellipsis and setting bits inside special structs, but it works. And it's fast too.
Now if they only had a good standard API to a versioned, networked filesystem. Then I would be in heaven. But a guy can dream...
Hey. What happens in the subconscious, STAYS in the subconscious.
Human consciousness only happened 3000-3500 years ago ? I wonder what he could mean with 'consciousness' then - there are 50000 year old cave drawings in France, does he know that ? Also, a lot of Chinese and Egyptian people might just be a tad offended by this notion.
The difference is more that when postgres has a drawback (which it does, many in fact - replication comes to mind, as well as certain configurability options, a reason why you always need a WAL (which you don't) and good caching) it will be plainly stated on their website; so-and-so is still lacking, we're working on it, if you want you can participate by either sending in your comments or implementing this-and-that. If, however, mysql has a drawback (which it has, many in fact) it will state nothing at their website, at first, and when people have been nagging them about it, it will say something like; 'that's never meant to be inside a database, solve it in the client. O by the way, it might be in the next version.'.
'Those domain can be shunted along this 'racetrack' and past read heads.'
What does that sentence even mean ?
The problem I see with C++ is this. I know it has been recounted over and over again above, but allow me to distill it to what I think is the crux of it: if I wanted to make a C compiler (which I don't) then I would know how to make one. Same goes for java, LISP, or even BASIC. I know C quite well, and java too, but I know only what needs to be known about the other two (that is, I've written some stuff in it). My point is that the languages are simple; the 'old testament' is about two hundred pages thick using a large font and a lot of whitespace. These languages, irrespective of how well you know them or how long ago you used them, fit in your head. Granted, there would be a few lookups here and there, but all in all, given a few days of extra time, access to a web-browser, lex and yacc (or the natural language-specific variety thereof), you could build a compiler or interpreter for them. And not only do they 'fit in your head', they also have an aura around them, a 'homely feeling', or a 'scent' of sorts. You'd know what extensions to the language would be natural for it and which wouldn't be.
Not so for C++. I know some of it; I know almost all of C, but the mind just boggles trying to fit all of that behemoth into one coherent picture. It just can't be done. Not only that, but I can't even begin to define what belongs to the 'scent' of C++ and what doesn't. And that's important, because real compiler builders and standard API watchdogs must also have this feeling. For languages with a super-human scale must also have super-human compiler-makers and standard API watchdogs. And not only that, but also programmers who can say, with some pride, 'I know quite a lot, if not all of C++'. The latter thing being impossible is not a good thing - it is a flaw.
Don't these people have mothers who tell them such things are in bad taste ? If not, why would someone who could be considered an adult be doing this ?
In Europe, some of the institutions that are easily on par with MIT are free (or as good as) ! I don't have to list them, you can just look them up in the various results lists.