Just because a body of code is huge and written in C/C++/Java/.NET does not mean that the code is any good. Bad, and more particularly indifferent, programmers write awful code in whatever language they use. (Bad programmers have trouble writing code that recognizably belongs to any particular programming language!) Doesn't matter if the language is a scripting language, a systems language or machine code toggled in on the front panel.
OTOH, the pointyness of the boss's hair does seem to be inversely proportional to the quality of the code...
Therefore, in a serious project, with millions invested, scripting can be a dangerous shortcut that may plague the project a year later.
Given that one of the major problems for the computer industry is the sheer number of projects not delivering anything, your concern is not the only one that project managers should be looking out for...
Abstractions are both good and bad things. They are good because they let you accomplish complex tasks without understanding every last detail of it (just as I shouldn't have to know the details of how a fuel injection system works in order to drive a car). They are bad in that they almost inevitably lead to inefficiency as you have to add code on both sides of the abstraction layer itself to work to that abstraction.
On the whole, I prefer to have those abstractions even in languages like C. Hell, even assembler is an abstraction over reality, and a really nice one (computing relative jump offsets by hand was one of my least favourite tasks when writing machine code directly.) Similarly, not having to worry about memory allocation and deallocation at all because of the use of a higher-level language than C is really nice, even though there is definitely some sacrifice of control for this. And when you've got to join bits of programs together that were never designed to do so, that scripting language comes into its own since at least then the types won't be actively conspiring against you.
C is not a scripting language, because the end result, after compiling and linking, is an executable that can be run by the OS w/o a separate runtime (I'm including linked-in runtimes, such as the old dbase runtime kit, as 'separate', b/c the end result still goes thru the run-time interpreter).
In other words, you're defining things exactly so that you get the answer that your prejudices against scripting have biased you to believe in the first place.
I don't know about you, but I don't like playing games where the rules say "You lose, I win!"
Organize yourself as an oligarchy; people should be on the committee because they are believed to be likely to do a creditable job there. I'd advise seeking a 2/3 consensus on whatever you do (while seeking to achieve 100% where possible) as this stops cliques from doing very much unless they have a genuinely good idea, while not letting single hold-outs stall things indefinitely. And listen to the wider community.
All modern processors - heck, all processors from 25 years ago - can handle 64-bit integers. But only a 64-bit processor can perform arithmetic with them in a single instruction. Otherwise, you have to use the add-with-carry (and its friends) instruction quite a few times.
That expertise, and a few hours rented time with an electron microscope to pull on the Palladium's keys, and suddenly MS is no longer the sole source or vendor of their Palladium platform.
It's quite possible to build chips that are virtually impregnable even with a handy electron microscope. Balanced rail logic (where each bit is represented by two electrical signals) is significantly tougher to decode from a scan of the chip than more conventional CMOS elements, and can easily be made resistant to other tricks like controlled power supply glitches...
OTOH, I keep having this sneaking feeling that Palladium sucks rocks technically. I just think that the flaws lie elsewhere...
Speaking as a European, I find the whole system of sales taxes in the US strange and baroque. Why not have a single federal sales tax, and cut back on federal income taxes instead? Like that, with a single collecting authority it'd be much easier for small businesses to comply with their legal duties...
Go is the Holy Grail, and they ain't even close. To date no one has made a Go playing program that can reasonably hold it's own against even a relative novice.
Hmm. I always get pasted by Go-playing programs. Guess this means I fail the Turing test...
But that doesn't take away from the fact that an intelligent human could look at a source printout and figure out if it halted or not, but no general algorithm can be deduced that would do so.
Presuming you claim to be intelligent, are you saying that you could look at any program (in a language you know) and determine whether it halts? Because that'd be impressive if verifiable. I suspect that Kurt Gödel and Alan Turing would probably beg to differ, but they're only dead mathematicians, so what do they know!
What properties, other than mass and trajectory, are of interest? It's not like they're going to find harmless ones made out of rubber or whatever.
How about "How easy it is to push into a different orbit that misses the Earth?" I don't know about you, but that's a property that I'm very interested in, and it'd be silly to think that all asteroids are the same...
Grr! Everything's left-handed on Earth because everything's left-handed (i.e. it just happened that way and there's nothing special about it.) Or are you suggesting that the atoms themselves have a preference?!
The feature's usually turned off for security reasons. The only variations on FTP where it is turned on that I've heard of have had an absolutely vicious encrypted authentication protocol on top.
Just because someone in a National Laboratory has put a paper up on the web doesn't mean that they are right. We find (alas, not yet in papers that I can easily locate online) that parallelized HTTP does just as well as pFTP for large (i.e. multi-gigabyte) data transfers.
For small stuff, avoiding that extra data-connection-setup overhead is a real winner.
While performance might be the product of clock-rate and efficiency, you need to be careful about what is meant by efficiency. The problem is that the efficiency of the Intel architecture has sucked mightily for, what, the last two decades or so? These days the chips might be going at 2.5GHz but the data isn't getting onto or off the chips at anything like the speed required to keep up. It's like attaching ever more powerful engines while having a transmission made of cinnamon muffins; you don't get a lot more power to the wheels which is where it really matters.
Anyone serious about wanting to do high-performance computing will only consider PCs because they are so cheap, 'cos they're still (after all these years) awful, no matter which manufacturer actually built the CPU.
Re:The John Ashcroft implantable microchip
on
Going Cyberpunk
·
· Score: 5, Insightful
I've no problem with this so long as we screen all our elected representatives, judges, lawyers and police officers before starting on anyone else...
Well, let's be quite honest. Even render farms don't really need the high-end computing platforms. After all, the job can be broken up into bits and reassembled at the end, and so is suitable for cluster processing. And it's quite feasable to throw really large numbers of processors at a job using distributed clustering software like Condor.
It's the very high end scientific and medical stuff that really benefits from high-end computing, though at that point you also have issues relating to shipping the data involved about. And security too. (What fun!)
IIRC, this was tried in the UK. Tried, and dropped when it was found that streetlights made excellent broadband transmitters at the frequencies they were using...
From time to time, people ask for Tcl.NET though I've never been quite sure what they want from such a beast. Porting to run on the CLR? Massive job, and doesn't make us more portable (we already run in more places than.NET does!) Ability to access components within the.NET framework? We already do (with suitable extensions) SOAP and COM (both as a component provider and consumer.) I find it hard to imagine that any other sensible scripting language will be substantially different...
Ah, but vim is not intuitive. You are just used to it. Not that this is bad, but in UI design you have to distinguish between being used to something and it actually being intuitive.
I think part of the problem is fear or lack of real desire to learn in or something pyschological that prohibits them from picking it up quickly.
No, the problem is that you're not watching and listening to your users properly. GUI design is very hard and you can't do it properly without feedback from end-users. If you find out what they want to do and how they want to do it (especially watching out for those surprising disconnects in metaphors) then you'll have a good chance to create a program that they can really use.
Don't forget the people doing documentation. Programmers (and that definitely includes me) are rubbish at writing documentation; when we are doing it, we have to hire someone specially for the task.
Slashdot Mirror
Just because a body of code is huge and written in C/C++/Java/.NET does not mean that the code is any good. Bad, and more particularly indifferent, programmers write awful code in whatever language they use. (Bad programmers have trouble writing code that recognizably belongs to any particular programming language!) Doesn't matter if the language is a scripting language, a systems language or machine code toggled in on the front panel.
OTOH, the pointyness of the boss's hair does seem to be inversely proportional to the quality of the code...
Given that one of the major problems for the computer industry is the sheer number of projects not delivering anything, your concern is not the only one that project managers should be looking out for...
Abstractions are both good and bad things. They are good because they let you accomplish complex tasks without understanding every last detail of it (just as I shouldn't have to know the details of how a fuel injection system works in order to drive a car). They are bad in that they almost inevitably lead to inefficiency as you have to add code on both sides of the abstraction layer itself to work to that abstraction.
On the whole, I prefer to have those abstractions even in languages like C. Hell, even assembler is an abstraction over reality, and a really nice one (computing relative jump offsets by hand was one of my least favourite tasks when writing machine code directly.) Similarly, not having to worry about memory allocation and deallocation at all because of the use of a higher-level language than C is really nice, even though there is definitely some sacrifice of control for this. And when you've got to join bits of programs together that were never designed to do so, that scripting language comes into its own since at least then the types won't be actively conspiring against you.
Horses for courses...
In other words, you're defining things exactly so that you get the answer that your prejudices against scripting have biased you to believe in the first place.
I don't know about you, but I don't like playing games where the rules say "You lose, I win!"
Organize yourself as an oligarchy; people should be on the committee because they are believed to be likely to do a creditable job there. I'd advise seeking a 2/3 consensus on whatever you do (while seeking to achieve 100% where possible) as this stops cliques from doing very much unless they have a genuinely good idea, while not letting single hold-outs stall things indefinitely. And listen to the wider community.
All modern processors - heck, all processors from 25 years ago - can handle 64-bit integers. But only a 64-bit processor can perform arithmetic with them in a single instruction. Otherwise, you have to use the add-with-carry (and its friends) instruction quite a few times.
People that want to do serious number crunching use supercomputers, which have been 64-bit systems for a long time. There's a reason for this...
Average college students aren't set research problems. There's a reason for this too...
The problem is that Global Warming will likely make it much harder to predict where all the disaster-prone areas of the world are.
It's quite possible to build chips that are virtually impregnable even with a handy electron microscope. Balanced rail logic (where each bit is represented by two electrical signals) is significantly tougher to decode from a scan of the chip than more conventional CMOS elements, and can easily be made resistant to other tricks like controlled power supply glitches...
OTOH, I keep having this sneaking feeling that Palladium sucks rocks technically. I just think that the flaws lie elsewhere...
Speaking as a European, I find the whole system of sales taxes in the US strange and baroque. Why not have a single federal sales tax, and cut back on federal income taxes instead? Like that, with a single collecting authority it'd be much easier for small businesses to comply with their legal duties...
Hmm. I always get pasted by Go-playing programs. Guess this means I fail the Turing test...
Presuming you claim to be intelligent, are you saying that you could look at any program (in a language you know) and determine whether it halts? Because that'd be impressive if verifiable. I suspect that Kurt Gödel and Alan Turing would probably beg to differ, but they're only dead mathematicians, so what do they know!
One problem with this: it doesn't scale all that well to hundreds of thousands of entries. Guess how many virtual hosts there are...?
How about "How easy it is to push into a different orbit that misses the Earth?" I don't know about you, but that's a property that I'm very interested in, and it'd be silly to think that all asteroids are the same...
Grr! Everything's left-handed on Earth because everything's left-handed (i.e. it just happened that way and there's nothing special about it.) Or are you suggesting that the atoms themselves have a preference?!
The feature's usually turned off for security reasons. The only variations on FTP where it is turned on that I've heard of have had an absolutely vicious encrypted authentication protocol on top.
For small stuff, avoiding that extra data-connection-setup overhead is a real winner.
<sigh>
While performance might be the product of clock-rate and efficiency, you need to be careful about what is meant by efficiency. The problem is that the efficiency of the Intel architecture has sucked mightily for, what, the last two decades or so? These days the chips might be going at 2.5GHz but the data isn't getting onto or off the chips at anything like the speed required to keep up. It's like attaching ever more powerful engines while having a transmission made of cinnamon muffins; you don't get a lot more power to the wheels which is where it really matters.
Anyone serious about wanting to do high-performance computing will only consider PCs because they are so cheap, 'cos they're still (after all these years) awful, no matter which manufacturer actually built the CPU.
I've no problem with this so long as we screen all our elected representatives, judges, lawyers and police officers before starting on anyone else...
It's the very high end scientific and medical stuff that really benefits from high-end computing, though at that point you also have issues relating to shipping the data involved about. And security too. (What fun!)
IIRC, this was tried in the UK. Tried, and dropped when it was found that streetlights made excellent broadband transmitters at the frequencies they were using...
From time to time, people ask for Tcl.NET though I've never been quite sure what they want from such a beast. Porting to run on the CLR? Massive job, and doesn't make us more portable (we already run in more places than .NET does!) Ability to access components within the .NET framework? We already do (with suitable extensions) SOAP and COM (both as a component provider and consumer.) I find it hard to imagine that any other sensible scripting language will be substantially different...
Ah, but vim is not intuitive. You are just used to it. Not that this is bad, but in UI design you have to distinguish between being used to something and it actually being intuitive.
No, the problem is that you're not watching and listening to your users properly. GUI design is very hard and you can't do it properly without feedback from end-users. If you find out what they want to do and how they want to do it (especially watching out for those surprising disconnects in metaphors) then you'll have a good chance to create a program that they can really use.
Don't forget the people doing documentation. Programmers (and that definitely includes me) are rubbish at writing documentation; when we are doing it, we have to hire someone specially for the task.