Why are they getting the phone that close to their brain? I can't see the keys to type when I hold the phone there. And I can't read the responses either! Someone doesn't know how to use their phone right.
Greek fire [http://en.wikipedia.org/wiki/Greek_fire]. Quite the rage a few years ago in the Byzantine navy. Can't find it anywhere today.
Damascus steel [http://en.wikipedia.org/wiki/Damascus_steel] is, almost, another example but diligent research by a second source has made it available once again.
"literally ANYTHING?" How about a character 0 (null terminator)? Perhaps "anything" is too strong. I guess you can "describe it", just don't try to encode it. (try it, you won't like it.)
How about "documents"? For documents it qualifies as... ok, verbose, but better than it's predecessors (html, sgml). But it's a seriously lame data format, even as a container or transport format. It's verbose, slow, complex, and yet... still incomplete. For the time and energy that's gone into XML we could have had something useful.
My favorite endorsement of XML technology (XQuery) was the statement (I paraphrase only as a result of time - both available and elapsed): "if you're using XML you'll have to use a tool like XQuery. XML is so complex and has so many edge cases you have to use a tool, like XQuery, that can deal with it or you'll get bit by one of them". Now, to be clear, this was in *support* of XML and XQuery.
Obviously I am confused, because, for me, this sounds more like a Very Good reason to Not use XML, rather than a reason to use XQuery. This is the level of clear headed thinking, practical wisdom, and experience that has gone into XML.
OTOH - I guess XML (and its ilk), fully, support the "consultants full employment" act.
A fellow developer taught me an approach that's been especially useful to me. Certainly you get as much detail as possible about what you are expected to do. Certainly you break that down into as detailed a set of tasks as possible. But don't estimate in hours or days, estimate in lines of code (yeah, yeah, lines of code don't mean squat, tough it's all you've got). Do all the estimates in lines of code. When that's done convert to time (say 500 lines per month, maybe you even know you net lines of code per unit time - remember from start to finish - designed, coded, tested, and deployed).
The biggest advantage of this technique is that you change the way you think about the problem. Instead of thinking "how long should this take", you are force to think "what do I have to do". You can look at blocks features and say... "they're 10 of them, and they look like about 200 lines each... 2000 lines".
The change in point of view is crucial. Need to know your (or your teams) "lines of code": go back to a previous (preferably similar) project and measure it. How many lines of code were there at the end, how long did it take (elapsed time, don't take out the garbage it'll be there next time), and there you have it.
For your intro work - go ahead and use an IDE. Let the students get something up and running, with as little overhead as possible. It's a chance for them to see they can make something happen. What you achieve, hopefully, is to whet their appetite for more.
In the end however, they won't know what's going on. Not in any comprehensive sense of the word. Java or Python won't let them know what's going on either, so you've lost very little by using an IDE. Using command line tools will only change the focus of leaning from the code to the tools. Just make sure the program (the education program) gives them an oppertunity to get a real understanding through a language that makes what's actually happening visible.
I've watched with dismay the level of understanding drop year over year. I don't see anything checking the fall. The poor showing of US schools in the recent ACMprogramming contest is a reflection of this problem.
Watching my daughter learn programming leaves me with no question about this issue. When she went from Java to C her understanding of what was actually taking place went up dramatically. It reinforced my belief that learning a low level language - C or assembly - is necessary for real computer literacy. (Please, not C++, with C++ you end up with the worst possible combination: tremendous complexity and no support. And the addition Object Orientation doesn't really help.)
While there are few programs (at least by line count) that require C today, the deeper understanding of what's happening pays off. It pays off in being able to know what to expect. It pays off in better code in any language. Understanding the details allows you make informed choices. It seems the academic community has lost this perspective. There seems to be a belief that the "details" are beneath them. "You shouldn't have to think about memory management" is a popular comment to this effect. Unfortunate this is simply out of touch with reality - perhaps one too any levels of indirection.
Any computer education program should require a significant investment in low level coding. Demanding academic programs should require most of the work be done this way. The quality of the graduates would increase substantially. What we're getting instead, as Alan Kay put it in an recent interview, is "java certification" which is a much lower standard. And, as a standard, it's simply too low.
It looks like google displayed their name with a new font. As it turns out you can't copyright a font (nor patent it). You can trademark the name of a font (or not in MS's case, but not the shape of the glyphs (characters) themselves. That's the reason you see a font named "times new roman" and it looks just like "times roman". (The hints that are what make a font look good as it is redered are separate from the shape and a different story.) Of course IANAL (I just ended up learning more about fonts and IP than you'd think was necessary working on a publishing system).
There's a substantive difference between the nature of the failures in software and the car that rolls over - the hacker. The software defect, in and of itself, is not harmful. It is the person who exploits it that is at fault here.
This doesn't excuse incompetance, but as has been mentioned, the market will take care of defects - as long as there is a viable alternative. Who would buy a lock that doesn't keep a door closed, as long as you can get one that can.
It would be a grave error for the software industry in any form to take resposibility for keeping everyone who wants to cause trouble from doing so. No one will win, and softare will end up as over regulated and lawsuit scared as airplanes and medical equiptment - for the wrong reasons.
This was written up as a solution years ago in SciAm's Amateur Scientist column (back when they had science in the column).
At the time it was the accuracy of a quartz crystal. Basically the author put a magnet on the bottom of the pendulum and an electro magnet on the bottom of the case (of a grandfather clock). He pulsed the electro magnet in sync with what the pendulum should be. If the pendulum had "fallen behind" it would be pulled to center - speeding it up. If it was ahead it would be pulled to center - slowing it down.
Very simple and effective. This seems sufficient in its own right but could be adapted to run off a... more reliable time source.
Way cool - a turbine, but (sadly) the jet has nothing to do with the cooling. It's just a way to burn off the propane. (so, technically, the jet engine is actually a safety feature!) Basic thermodyanics is doing the cooling - a gas cools as it expands (and heats as it is compressed). Opening the valve on the propane tank will work as well (better even, with a bit more risk).
Classic hack - lots of noise and a nearly overlooked feature lost (or even hidden) inside.
If the turbine ran a compressor you could really cool it! But then you'd have to call it engineering.
Slashdot Mirror
Why are they getting the phone that close to their brain? I can't see the keys to type when I hold the phone there. And I can't read the responses either! Someone doesn't know how to use their phone right.
Greek fire [http://en.wikipedia.org/wiki/Greek_fire]. Quite the rage a few years ago in the Byzantine navy. Can't find it anywhere today.
Damascus steel [http://en.wikipedia.org/wiki/Damascus_steel] is, almost, another example but diligent research by a second source has made it available once again.
Shades of "clippy". By all means lock this away and bury it. We can trust MS to that at least.
No. It was, in the words of Tom Lehrer, "good old American know how. Supplied by good old Americans like Wernher Von Bruan".
Clearly we can depend on the British software community to make the right technical choices ...
http://www.independent.co.uk/news/uk/politics/the-16357m-efficiency-drive-that-cost-16381m-1128203.html
That's why I prefer Go ... at least there's a little time left before the machines beat me. Wait ... damn it ... 1-3kyu
http://en.wikipedia.org/wiki/Computer_go
"literally ANYTHING?" How about a character 0 (null terminator)? Perhaps "anything" is too strong. I guess you can "describe it", just don't try to encode it. (try it, you won't like it.)
... ok, verbose, but better than it's predecessors (html, sgml). But it's a seriously lame data format, even as a container or transport format. It's verbose, slow, complex, and yet ... still incomplete. For the time and energy that's gone into XML we could have had something useful.
How about "documents"? For documents it qualifies as
My favorite endorsement of XML technology (XQuery) was the statement (I paraphrase only as a result of time - both available and elapsed): "if you're using XML you'll have to use a tool like XQuery. XML is so complex and has so many edge cases you have to use a tool, like XQuery, that can deal with it or you'll get bit by one of them". Now, to be clear, this was in *support* of XML and XQuery.
Obviously I am confused, because, for me, this sounds more like a Very Good reason to Not use XML, rather than a reason to use XQuery. This is the level of clear headed thinking, practical wisdom, and experience that has gone into XML.
OTOH - I guess XML (and its ilk), fully, support the "consultants full employment" act.
A fellow developer taught me an approach that's been especially useful to me. Certainly you get as much detail as possible about what you are expected to do. Certainly you break that down into as detailed a set of tasks as possible. But don't estimate in hours or days, estimate in lines of code (yeah, yeah, lines of code don't mean squat, tough it's all you've got). Do all the estimates in lines of code. When that's done convert to time (say 500 lines per month, maybe you even know you net lines of code per unit time - remember from start to finish - designed, coded, tested, and deployed).
... "they're 10 of them, and they look like about 200 lines each ... 2000 lines".
The biggest advantage of this technique is that you change the way you think about the problem. Instead of thinking "how long should this take", you are force to think "what do I have to do". You can look at blocks features and say
The change in point of view is crucial. Need to know your (or your teams) "lines of code": go back to a previous (preferably similar) project and measure it. How many lines of code were there at the end, how long did it take (elapsed time, don't take out the garbage it'll be there next time), and there you have it.
For your intro work - go ahead and use an IDE. Let the students get something up and running, with as little overhead as possible. It's a chance for them to see they can make something happen. What you achieve, hopefully, is to whet their appetite for more.
In the end however, they won't know what's going on. Not in any comprehensive sense of the word. Java or Python won't let them know what's going on either, so you've lost very little by using an IDE. Using command line tools will only change the focus of leaning from the code to the tools. Just make sure the program (the education program) gives them an oppertunity to get a real understanding through a language that makes what's actually happening visible.
I've watched with dismay the level of understanding drop year over year. I don't see anything checking the fall. The poor showing of US schools in the recent ACM programming contest is a reflection of this problem.
Watching my daughter learn programming leaves me with no question about this issue. When she went from Java to C her understanding of what was actually taking place went up dramatically. It reinforced my belief that learning a low level language - C or assembly - is necessary for real computer literacy. (Please, not C++, with C++ you end up with the worst possible combination: tremendous complexity and no support. And the addition Object Orientation doesn't really help.)
While there are few programs (at least by line count) that require C today, the deeper understanding of what's happening pays off. It pays off in being able to know what to expect. It pays off in better code in any language. Understanding the details allows you make informed choices. It seems the academic community has lost this perspective. There seems to be a belief that the "details" are beneath them. "You shouldn't have to think about memory management" is a popular comment to this effect. Unfortunate this is simply out of touch with reality - perhaps one too any levels of indirection.
Any computer education program should require a significant investment in low level coding. Demanding academic programs should require most of the work be done this way. The quality of the graduates would increase substantially. What we're getting instead, as Alan Kay put it in an recent interview, is "java certification" which is a much lower standard. And, as a standard, it's simply too low.
It looks like google displayed their name with a new font. As it turns out you can't copyright a font (nor patent it). You can trademark the name of a font (or not in MS's case, but not the shape of the glyphs (characters) themselves. That's the reason you see a font named "times new roman" and it looks just like "times roman". (The hints that are what make a font look good as it is redered are separate from the shape and a different story.) Of course IANAL (I just ended up learning more about fonts and IP than you'd think was necessary working on a publishing system).
There's a substantive difference between the nature of the failures in software and the car that rolls over - the hacker. The software defect, in and of itself, is not harmful. It is the person who exploits it that is at fault here.
This doesn't excuse incompetance, but as has been mentioned, the market will take care of defects - as long as there is a viable alternative. Who would buy a lock that doesn't keep a door closed, as long as you can get one that can.
It would be a grave error for the software industry in any form to take resposibility for keeping everyone who wants to cause trouble from doing so. No one will win, and softare will end up as over regulated and lawsuit scared as airplanes and medical equiptment - for the wrong reasons.
This was written up as a solution years ago in SciAm's Amateur Scientist column (back when they had science in the column).
... more reliable time source.
At the time it was the accuracy of a quartz crystal. Basically the author put a magnet on the bottom of the pendulum and an electro magnet on the bottom of the case (of a grandfather clock). He pulsed the electro magnet in sync with what the pendulum should be. If the pendulum had "fallen behind" it would be pulled to center - speeding it up. If it was ahead it would be pulled to center - slowing it down.
Very simple and effective. This seems sufficient in its own right but could be adapted to run off a
Way cool - a turbine, but (sadly) the jet has nothing to do with the cooling. It's just a way to burn off the propane. (so, technically, the jet engine is actually a safety feature!) Basic thermodyanics is doing the cooling - a gas cools as it expands (and heats as it is compressed). Opening the valve on the propane tank will work as well (better even, with a bit more risk). Classic hack - lots of noise and a nearly overlooked feature lost (or even hidden) inside. If the turbine ran a compressor you could really cool it! But then you'd have to call it engineering.