I'm intrigured by the idea that learning "print" style writing can be a "lengthy" process, once you have already spent a few years writing. Isn't is quite natural - just draw the same letters, but separately instead of joined up and tidy them up a bit?
I learned cursive as a child and used it throughout university.
Print was occasionally required for filling in forms. I don't remember ever feeling challenged by that, even though it was only used for forms.
Maybe you felt you had to copy the awkward (not designed for writing) glyph shapes that computers and typewriters use, instead of simply using the cursive shapes you already learned minus the redundant flowy bits as long as it was legible?
Personally I use gel ink pens. Fountain pens have a tendancy to leak occasionally, needing blotting paper. Traditional ball points are too hard on the paper, tending to reap weak paper and they tend to jam up before half the ink is used too.
English uses fewer glyphs than almost every other language in the world.
That's why it's so well suited to computers and typing, while there are other languages whose computer typography is still inadequate.
The idea that 104 symbols is a lot to learn is a joke. It's a tiny number.
What tires you out with writing depends a lot on what you're used to. Neither you nor I can evaluate whether cursive or printing are least tiring from our own experiences - it has to be evaluated by comparing many people's experiences.
The same goes for reading. Cursive is harder to read than good printing, unless you're used to reading cursive. Then it's still harder to read than good printing:-)
Exactly. Any sufficiently complex system will have surprises. Which is why someone may develop an uber AI to foresee and avoid those surprises... There's no assurance that humans are better at it.
Productivity is nowhere near high enough for everyone to live comfortably doing nice things people like to do - like going to restaurants and nice holidays. So there's still a reason for the economy to force some people into doing those jobs, and that's what it does.
Basically you could say rich people want things that still require poor people to do the work.
With further technological progress, it may reach a point where almost everyone can do almost everything they want without requiring other people to work doing it.
Economists didn't just forget recent history. The theory behind the current big bail-outs is that the Japanese ones were done too late, which made them ineffective, and that's why there was so much pressure to issue the current bail-outs early in the recession cycle.
Or it could just be a big bluff to steal more of your money...
I worked at a games company where the MD told me that's exactly what they do - chuck all sent in demos and letters with 'a great idea for a game' in the bin.
Your observation about NDAs is exactly why I'm extremely wary of signing them. Quite often when I encounter an idea that's exposed to me under NDA, I've already been working on something quite similar myself to some extent, which puts me in a difficult position. Do I abandon my own work, or try to prove that I had already done it when/if I decide to go commercial or public? Do I continue my own work? The costs of losing access to my own work often outweigh the benefits of signing an NDA, even if I'm paid money.
I should note that I work on a lot of different things in my own time (I'm self-employed); maybe this doesn't apply to everyone.
He probably made more money by showing it to every car company than by being patient.
Sure, he lost a lot in attorney's fees.
But he got a lot of companies tempted to use his valve, by showing them the benefits in such a compelling way that those companies decided to risk building their own.
There's an obvious analogy with software companies who complain about piracy but encourage it at the same time because it gets people to know the product.
It's quite a clever strategy, if you can be sure of collecting from some of them in the end.
AIs might not need any of those emotions (it's not clear if they play a crucial role in intelligence), but they'll have whatever they are programmed to have...
That's right, but when you're forced by resource limitations to compare the probable future contributions of a machine against the probable future contirbutions of a human, a rational machine may well conclude that machines have more potential, and eliminating (or simply not protecting) the humans leaves more resources to increase that potential.
This already happens when humans compare groups of humans to decide how to allocate resources, after all.
IT industry is much larger than software engineering.
For example, most sysadmins don't do much in-depth software development, if any. Some write a lot of scripts, but some never do that either - it's plenty of work just, well, sysadmining.
There are a lot of professional programmers on here, but it's clear there are a lot of people who aren't - students, people interested in technology who aren't professionals, non-programmer roles like sysadmins (obviously some sysadmins do program), web designers (ditto), managers even:-)
And that's just the IT crowd. There's plenty of chemists, geophysists, biologists, novelists, historians, children, etc...
Radix sort is great for a subset of sorting problems. Sometimes it's better, sometimes it's worse, and sometimes it's not applicable.
If you've *really* studied sorting and searching, you'll know that even O(n) can be beaten sometimes.
How nice that you mention sorting polygons:-) I developed a commercial game in the 90s using a technique similar to what you've described.
Radix sort would have been too slow.
What we used was an ascending-run bottom-up merge sort with persistent ordering between frames. That algorithm was O(n log n) worst case, but ran faster than radix sort for 3D graphics - because the *average* run time was sublinear - less than O(n).
That took advantage of inter-frame persistance as well as natural clustering of the source data, while still being quite fast in the worst case. But in the same vein, radix sort takes advantage of fixed-size integers and arrays.
Another common misconception is that the O() well-known results are exact when real problems use finite types like 32-bit integers. They're a very useful tool, but more precise O() descriptions take into account more details like the number of bits in an integer, the non-linear relationship between memory access time and locality (think idealised cache hierarchy), and even whether the machine can do pointer arithmetic in constant time - array machine vs. pointer machine, which by the way is relevant to real embedded devices.
Then it becomes clear that O(n log n) and similar results are useful approximations which usually apply quite well, but not always, and never precisely to real machines.
Still, it is really important to know about algorithms, and O() notation and space/time complexity are very good things to learn about if you're serious about writing good code.
This discussion just goes to show that there's always more to learn after that:-) But it's quite advanced stuff, and shouldn't put anyone off learning about classical algorithms, which are extremely useful in "ordinary" programming work.
There is still patents bullshit with the Samba stuff.
The agreement means Samba can implement the protocols covered by patents without being sued by Microsoft, but You are not protected if you rip that code out of Samba and use it for something else.
Replaces "6 months ago" with "6 years ago (and got bored long before finishing)".
It takes a long time to optimize every feature and function in any interestingly sized program large enough to have competitors, and especially if you're not doing it full time.
I've programmed for 27 years, in a great many languages, starting with BASIC and several assembly languages at the beginning.
Honestly, I didn't learn properly about algorithms and algorithmic complexity until I had the chance to learn higher level languages, which weren't available on home computers when I started.
I *did* learn a lot about raw efficiency, from counting cycles and memory accesses and instructions; things like that. I learned how to write really fast graphics routines, and clever ways to squeeze the most out of a limited machine.
But learning that O(n log n) is the fastest you can do a sort and that it's worth it? How to do malloc efficiently and when to use a specialised allocator? When to use a balanced tree structure? When to use hash tables, or compare digests? When to cache things?
That sort of thing started for me with higher level languages, starting with Orwell (a precursor to Haskell), Lisp and C. And with university.
You don't learn about algorithms just by writing assembly language. Conversely, you do learn about algorithms by reading good tutorials which use clear languages like pseudo-code or Python to explain them.
So I do advocate some knowledge of assembly language for a feel for what's going on underneath. It's very useful, especially in teaching about memory. (I'd advocate hardware compilation, but it's not quite accessible enough yet;-)
But it's important to understand algorithms and to know about many classic ones, and how to put them together to make new ones. That's far easier with higher level languages.
Good algorithms written in Perl beat bad algorithms written in assembly language, or even compiled directly into hardware.
A practical and theoretical knowledge of algorithms and raw performance, now that is a great combination if you can teach it:-)
But then beware of becoming someone who can't resist writing fast code when the speed of writing the code itself, and it's clarity to other people afterwards, is more important than it's performance... Knowing when to write for other criteria, such as clarity, and how to do that well, is a very important skill indeed.
I have a colleague who has been programming assembly language on a variety of microcontrollers for about 15 years. He's good at it too. Recently he learned C.
He just could not get his head around objects and properties as found in Javascript and Lua. Last time I saw him, he'd just got the hang of associative arrays due to using Awk, and I explained that objects in those languages are basically the same, but don't have names...
The prospect of little fragments of code with memory of their context - lambda functions - rendered some Lua scripts completely incomprehensible to him and "made his brain hurt".
I'm sure he'll get those things when he has to. He's a very fast learner when he has to use something new.
Yet these concepts are basic, casual concepts for web designers writing little bits of Javascript. Something which isn't even regarded as programming by some people.
It humbles me to be reminded how much seems trivial and "always been obvious" when you've got the idea, but is baffling and new at first.
The right thing to do depends on the new programmer.
I was very happy learning how to write graphical programs from first principles. I even learned assembly language within a year of first touching a computer, at the age of 10.
But some of my friends would have given up quickly if they had to do that.
Those people learned better by having good examples of simple games they could edit, and learn how things work by gradually making bigger and bigger changes, until they could write a whole one themselves.
And that was in the days when you could get pretty results from the built-in BASIC language on most computers.
Nowadays, you can't do a lot of things without third-party toolkits in a realistic amount of time or effort, not even pretty graphics. Not even web pages: you still need a server, and writing one of those from scratch is not (imho) a good first project for a new programmer. It's good to do, but not as the first project.
C++ changed a lot in that decade. Not the language very much, but the way it is used.
I wrote a lot of C++ in 94-97, but I wouldn't recognise most of what is written nowadays: the STL wasn't usable back then, and anything complicated with templates would crash most compilers. Now STL is standard C++ and used in beginner's code.
I believe I understand the meaning of non-radiative and near-field, but I won't claim expertise.
As a simple thought experiment, a Witricity receiving coil connected by ordinary cable to a radiating antenna resonant at the same frequency, with all three components impedance matched, would clearly be a mechanical object which passively coupled with the transmitter and produced a (radiating) far field.
The transmitted field's shape is modified by antenna elements in the vicinity of the transmitter. With complex impedance, that is enough to make the whole assembly produce a far field component unless the transmitter has active compensation, i.e. it senses and adapts with a complementary field shape, which is not easy.
The question is whether the far field component so produced is so tiny as to be effectively zero, or not.
How unlikely is it?
I'm guessing it's very unlikely unless there's the equivalent of impedance matching components in just the right places in one's random household object. It's hard to judge the likelihood of that.
Perhaps "does not unintentionally couple with standardised wireless power sources" will become a design requirement for new electronic devices as they become more common:-)
Slashdot Mirror
I'm intrigured by the idea that learning "print" style writing can be a "lengthy" process, once you have already spent a few years writing. Isn't is quite natural - just draw the same letters, but separately instead of joined up and tidy them up a bit?
I learned cursive as a child and used it throughout university.
Print was occasionally required for filling in forms. I don't remember ever feeling challenged by that, even though it was only used for forms.
Maybe you felt you had to copy the awkward (not designed for writing) glyph shapes that computers and typewriters use, instead of simply using the cursive shapes you already learned minus the redundant flowy bits as long as it was legible?
Personally I use gel ink pens. Fountain pens have a tendancy to leak occasionally, needing blotting paper. Traditional ball points are too hard on the paper, tending to reap weak paper and they tend to jam up before half the ink is used too.
Gel pons, lovely stuff.
Fast typing is far slower than speaking vocally, unless you speak e x t r a s l o w l y.
Writing shorthand can be faster, but that's not typing or normal writing.
English uses fewer glyphs than almost every other language in the world.
That's why it's so well suited to computers and typing, while there are other languages whose computer typography is still inadequate.
The idea that 104 symbols is a lot to learn is a joke. It's a tiny number.
What tires you out with writing depends a lot on what you're used to. Neither you nor I can evaluate whether cursive or printing are least tiring from our own experiences - it has to be evaluated by comparing many people's experiences.
The same goes for reading. Cursive is harder to read than good printing, unless you're used to reading cursive. Then it's still harder to read than good printing :-)
Exactly. Any sufficiently complex system will have surprises. Which is why someone may develop an uber AI to foresee and avoid those surprises... There's no assurance that humans are better at it.
Productivity is nowhere near high enough for everyone to live comfortably doing nice things people like to do - like going to restaurants and nice holidays. So there's still a reason for the economy to force some people into doing those jobs, and that's what it does.
Basically you could say rich people want things that still require poor people to do the work.
With further technological progress, it may reach a point where almost everyone can do almost everything they want without requiring other people to work doing it.
That would be new.
If you get bought out for being first to implement an idea, you'll be in the history books for that...
Making money is unlikely to reduce your chance of an entry in the books.
Economists didn't just forget recent history. The theory behind the current big bail-outs is that the Japanese ones were done too late, which made them ineffective, and that's why there was so much pressure to issue the current bail-outs early in the recession cycle.
Or it could just be a big bluff to steal more of your money...
I worked at a games company where the MD told me that's exactly what they do - chuck all sent in demos and letters with 'a great idea for a game' in the bin.
Your observation about NDAs is exactly why I'm extremely wary of signing them. Quite often when I encounter an idea that's exposed to me under NDA, I've already been working on something quite similar myself to some extent, which puts me in a difficult position. Do I abandon my own work, or try to prove that I had already done it when/if I decide to go commercial or public? Do I continue my own work? The costs of losing access to my own work often outweigh the benefits of signing an NDA, even if I'm paid money.
I should note that I work on a lot of different things in my own time (I'm self-employed); maybe this doesn't apply to everyone.
He probably made more money by showing it to every car company than by being patient.
Sure, he lost a lot in attorney's fees.
But he got a lot of companies tempted to use his valve, by showing them the benefits in such a compelling way that those companies decided to risk building their own.
There's an obvious analogy with software companies who complain about piracy but encourage it at the same time because it gets people to know the product.
It's quite a clever strategy, if you can be sure of collecting from some of them in the end.
Which is why someone will try to build the uber AIs... to help design interactions we want instead of those we don't want, if it's possible at all.
AIs might not need any of those emotions (it's not clear if they play a crucial role in intelligence), but they'll have whatever they are programmed to have...
That's right, but when you're forced by resource limitations to compare the probable future contributions of a machine against the probable future contirbutions of a human, a rational machine may well conclude that machines have more potential, and eliminating (or simply not protecting) the humans leaves more resources to increase that potential.
This already happens when humans compare groups of humans to decide how to allocate resources, after all.
IT industry is much larger than software engineering.
For example, most sysadmins don't do much in-depth software development, if any. Some write a lot of scripts, but some never do that either - it's plenty of work just, well, sysadmining.
There are a lot of professional programmers on here, but it's clear there are a lot of people who aren't - students, people interested in technology who aren't professionals, non-programmer roles like sysadmins (obviously some sysadmins do program), web designers (ditto), managers even :-)
And that's just the IT crowd. There's plenty of chemists, geophysists, biologists, novelists, historians, children, etc...
So true.
Radix sort is great for a subset of sorting problems. Sometimes it's better, sometimes it's worse, and sometimes it's not applicable.
If you've *really* studied sorting and searching, you'll know that even O(n) can be beaten sometimes.
How nice that you mention sorting polygons :-) I developed a commercial game in the 90s using a technique similar to what you've described.
Radix sort would have been too slow.
What we used was an ascending-run bottom-up merge sort with persistent ordering between frames. That algorithm was O(n log n) worst case, but ran faster than radix sort for 3D graphics - because the *average* run time was sublinear - less than O(n).
That took advantage of inter-frame persistance as well as natural clustering of the source data, while still being quite fast in the worst case. But in the same vein, radix sort takes advantage of fixed-size integers and arrays.
Another common misconception is that the O() well-known results are exact when real problems use finite types like 32-bit integers. They're a very useful tool, but more precise O() descriptions take into account more details like the number of bits in an integer, the non-linear relationship between memory access time and locality (think idealised cache hierarchy), and even whether the machine can do pointer arithmetic in constant time - array machine vs. pointer machine, which by the way is relevant to real embedded devices.
Then it becomes clear that O(n log n) and similar results are useful approximations which usually apply quite well, but not always, and never precisely to real machines.
Still, it is really important to know about algorithms, and O() notation and space/time complexity are very good things to learn about if you're serious about writing good code.
This discussion just goes to show that there's always more to learn after that :-) But it's quite advanced stuff, and shouldn't put anyone off learning about classical algorithms, which are extremely useful in "ordinary" programming work.
There is still patents bullshit with the Samba stuff.
The agreement means Samba can implement the protocols covered by patents without being sued by Microsoft, but You are not protected if you rip that code out of Samba and use it for something else.
Not very GPL, that.
I agree. C++ has far too many arcane rules, which you must know to avoid bugs and understand other people's code, to be a good beginner's language.
I assure you, people who have written Lisp compilers are both masters of assembly language and can see through Lisp.
Replaces "6 months ago" with "6 years ago (and got bored long before finishing)".
It takes a long time to optimize every feature and function in any interestingly sized program large enough to have competitors, and especially if you're not doing it full time.
Re performance, you're describing algorithms.
I've programmed for 27 years, in a great many languages, starting with BASIC and several assembly languages at the beginning.
Honestly, I didn't learn properly about algorithms and algorithmic complexity until I had the chance to learn higher level languages, which weren't available on home computers when I started.
I *did* learn a lot about raw efficiency, from counting cycles and memory accesses and instructions; things like that. I learned how to write really fast graphics routines, and clever ways to squeeze the most out of a limited machine.
But learning that O(n log n) is the fastest you can do a sort and that it's worth it? How to do malloc efficiently and when to use a specialised allocator? When to use a balanced tree structure? When to use hash tables, or compare digests? When to cache things?
That sort of thing started for me with higher level languages, starting with Orwell (a precursor to Haskell), Lisp and C. And with university.
You don't learn about algorithms just by writing assembly language. Conversely, you do learn about algorithms by reading good tutorials which use clear languages like pseudo-code or Python to explain them.
So I do advocate some knowledge of assembly language for a feel for what's going on underneath. It's very useful, especially in teaching about memory. ;-)
(I'd advocate hardware compilation, but it's not quite accessible enough yet
But it's important to understand algorithms and to know about many classic ones, and how to put them together to make new ones. That's far easier with higher level languages.
Good algorithms written in Perl beat bad algorithms written in assembly language, or even compiled directly into hardware.
A practical and theoretical knowledge of algorithms and raw performance, now that is a great combination if you can teach it :-)
But then beware of becoming someone who can't resist writing fast code when the speed of writing the code itself, and it's clarity to other people afterwards, is more important than it's performance... Knowing when to write for other criteria, such as clarity, and how to do that well, is a very important skill indeed.
Last time I looked, you could only access OS features by writing C yourself and tying it into Lua.
Lua's native support for OS features was very weak, being a minimal language and all.
Even file I/O was quite limited.
Lua integrates with C in the sense that it's quite easy to write C code which can be called from Lua, and vice versa.
But that means you need to learn C too...
(Unless it has grown a new "can call ordinary C functions without you writing any glue" capability since I looked).
I have a colleague who has been programming assembly language on a variety of microcontrollers for about 15 years. He's good at it too. Recently he learned C.
He just could not get his head around objects and properties as found in Javascript and Lua. Last time I saw him, he'd just got the hang of associative arrays due to using Awk, and I explained that objects in those languages are basically the same, but don't have names...
The prospect of little fragments of code with memory of their context - lambda functions - rendered some Lua scripts completely incomprehensible to him and "made his brain hurt".
I'm sure he'll get those things when he has to. He's a very fast learner when he has to use something new.
Yet these concepts are basic, casual concepts for web designers writing little bits of Javascript. Something which isn't even regarded as programming by some people.
It humbles me to be reminded how much seems trivial and "always been obvious" when you've got the idea, but is baffling and new at first.
The right thing to do depends on the new programmer.
I was very happy learning how to write graphical programs from first principles. I even learned assembly language within a year of first touching a computer, at the age of 10.
But some of my friends would have given up quickly if they had to do that.
Those people learned better by having good examples of simple games they could edit, and learn how things work by gradually making bigger and bigger changes, until they could write a whole one themselves.
And that was in the days when you could get pretty results from the built-in BASIC language on most computers.
Nowadays, you can't do a lot of things without third-party toolkits in a realistic amount of time or effort, not even pretty graphics. Not even web pages: you still need a server, and writing one of those from scratch is not (imho) a good first project for a new programmer. It's good to do, but not as the first project.
C++ changed a lot in that decade. Not the language very much, but the way it is used.
I wrote a lot of C++ in 94-97, but I wouldn't recognise most of what is written nowadays: the STL wasn't usable back then, and anything complicated with templates would crash most compilers. Now STL is standard C++ and used in beginner's code.
I believe I understand the meaning of non-radiative and near-field, but I won't claim expertise.
As a simple thought experiment, a Witricity receiving coil connected by ordinary cable to a radiating antenna resonant at the same frequency, with all three components impedance matched, would clearly be a mechanical object which passively coupled with the transmitter and produced a (radiating) far field.
The transmitted field's shape is modified by antenna elements in the vicinity of the transmitter. With complex impedance, that is enough to make the whole assembly produce a far field component unless the transmitter has active compensation, i.e. it senses and adapts with a complementary field shape, which is not easy.
The question is whether the far field component so produced is so tiny as to be effectively zero, or not.
How unlikely is it?
I'm guessing it's very unlikely unless there's the equivalent of impedance matching components in just the right places in one's random household object. It's hard to judge the likelihood of that.
Perhaps "does not unintentionally couple with standardised wireless power sources" will become a design requirement for new electronic devices as they become more common :-)