So 5,000 being let go is still a > 5% layoff. 1-in-20 being let go.
Re:Comparison to WPF or other non stone-age tools?
on
Qt Becomes LGPL
·
· Score: 1
Using C++/Qt isn't torture - it's a genuine pleasure. The cross-platformity doesn't cost you anything in terms of inconveniece or even a moments thought - it comes for free with everything (including threads, SQL, XML, etc) in the Qt API. If you download the free version of Qt for Windows you even have the convenient option of downloading it togther with MinGW (basically GNU g++, tools and bash shell for Windows) so you can install it all in one go, for free Windows software development.
Re:time to port gnome!
on
Qt Becomes LGPL
·
· Score: 5, Informative
Just to clarify for anyone new to Qt...
Qt Designer and Qt Creator are two entirely different things.
Qt Designed is drag-n-drop interactive GUI design tool that lets you design the GUI portion if aplication windows, dialogs, etc without coding. You just drag widgets and layout managers off a menu and drop them into the interface your building. It's an awesome tool. Your interface gets saved as a ".ui" file from which Qt automatically generates the corresponding C++ code as clean C++ classes. To add callback/etc behavior, or to further customize the GUI, you just subclass the generated classes and take it from there. It's done very well so that almost always you can further change the user interface using Qt Designer without affecting the subclasses you've added. Qt Designer has been there since early on and just keeps getting better and more powerful.
Qt also includes a tool "qmake" that makes building Qt apps ridiculously easy - qmake takes a high level ".pro" file that lists the various types of file making up your project (source files, header files, Qt designer.ui files, resource files, etc) and what type of target you're building (application, DLL, etc), and from the.pro file generates a Makefile that you then run using your normal make program (e.g. GNU make, or mingw32-make under MinGW).
Qt Creator is an IDE for development of Qt based applications, and seems to deliver the expected functionality of an IDE. It's pretty much brand new, and I havn't personally used it (nor intend to since I don't find IDEs to help my productivity).
Re:time to port gnome!
on
Qt Becomes LGPL
·
· Score: 4, Interesting
Qt supports more than just Windows/Linux/Mac OSX... It also supports embedded applications (Qt/Embedded - used for Qtopia, which assumes nothing more than a framebuffer graphics interface), and most recently also Windows CE.
I think Google's decision to go with their own graphics API for Android is looking very much like "not invented here". The Qt API is excellent (I've been using the free version for years), and it's available pretty much everywhere. Now with LGPL licensing, any remaining objection has pretty much disappeared. Qt Jambi (the Java API for Qt) would be perfect for Android.
Even for 8 bit numbers, you're still talking about up to 255 loop iterations rather than 8 (maximum) with the shift method. You keep on referring to K.I.S.S. and the "complexity" of the shift method, but the "complexity" consists of precisely 3 extra instructions (2 shifts and a branch) compared to your naieve method, and this "complex" algorithm is nothing more than the long hand multiplication method you were taught at age 10, applied to binary numbers.
It's a bizarre games programmer that, working on a slow 8 bit processor thought it was a good design choice to throw away hundreds of clock cycles per multiply to save yourself 3 assembler instructions, and a totally unimaginative one that thinks that his own slow-as-molasses integer multiply routine has got any relevance whatsoever to the fast floating point math required by a spreadsheet.
With your programming skillz, I'd not be too insistent on ordering people off your lawn. In fact Dan Bricklen is probably in your front yard right now, dropping trou and taking a dump on your garden gnome.
Consider doing a 16 bit or 32 bit multiplication your way - we're talking a for loop of up to 64K or 4+ billion steps, vs a for loop of 16 or 32 steps for the shift way. On a processor with a 1MHz clock speed, your way would literally take hours to do a single 32 bit multiply! The fact that the shift method is doing shift and add per loop rather than just add hardly makes up for it!;-)
Yep - you're right. My memory is failing me! When you typed "*BASIC" to get into the BASIC interpreter, this was actually no different than using "*PASCAL" to get into our environment or any other ROM software. These commands were passed around to each ROM by the OS interpreter to see which one of them (if any) wanted to recognize it.
Yep, the built-in assembler (built into BBC BASIC) was great - this is what I used to develop this software. Two-pass assembly (required to figure forward jump addresses) was just a matter of putting a BASIC for-loop around your assembler section!
Sinclair was our major competitor at the time, but it was still friendly. I remember (nowadays "Sir") Clive Sinclair being invited to our company Christmas party one year.
No multiply of divide? So what? Multiplication is just serial addition, and division is simply serial subtraction. 4x4=4+4+4+4.
Not if you want to do it fast. Multiplying two binary numbers is basically a matter of shift-and-add.
Say you want to multiple 1101 by 1010 (13 x 10), this breaks down to:
0 x 1101 + 1 x 11010 + 0 x 110100 + 1 x 1101000
= 10000010 (130)
To implement this in assember you'd shift one number left one bit at a time so that the least significatn bit gets shifted into a processor flag where it can be tested (the 1's and 0's shown on the right), and shift the other number right one bit at a time for the corresponding multiplication by 2, and either add it or not to the running total depending on whether you're multiplying by a 1 or a 0.
Division is done basically the same as the long-hand division you'd do on paper.
Speaking of 6502 programming feats, back in 1982 I worked for Acorn computers in the UK, writing software for the 2MHz 6502 based BBC microcomputer, which incidently we also used as our development machines. The BBC micro had 16K of ROM for the built-in BASIC interpreter and low level "OS", another 16K of address space into which you could map any one (at a time) of the other 16K software ROMs in that machine, and 16K or 32K of RAM depending on the model. Much software was sold on ROM - there were four sockets built-in or you could get expansion boards to allow more - but only one at a time could be selected since there was only 16K of address space for these.
One project I did at Acorn (with another guy) was to implement a Pascal development system for the BBC micro that we crammed into two of these add-in 16K ROMs. This was no cut down version - is was a full-blown ISO certified version of Pascal, the first ever implementation for a Microcomputer to implement the standard and achieve ISO certification (ISO Pascal is different from P-system Pascal which had preceded it).
So, what we fitted into 32K was:
- An ISO Pascal compiler, which compiled programs down to a P-code like stack-based virtual instruction set - A virtual machine/interpreter for the instruction set - A 6502 machine code relocator - The complete Pascal run-time library (full floating point, IO library, heap, etc) - A full-featured full-screen editor with regex find/replace (with as-you-type syntax parsing and highlighting), block copy/move/delete, etc (in only 4K of code) - Command line interpreter
Now bear in mind that only 16K of this could actually be in the address space at one time...
The way we managed to squeeze all this in was to have the compiler in one 16K ROM, and the rest in the other. The compiler was written in ISO Pascal and self-compiled to our virtual instruction set. We had to add a few "macro" instructions especially for the compiler in order to get it under the 16K limit. The rest of the software (which I wrote) was all in 6502 assembler. Now consider that to run the compiler you also needed the virtual machine, but that was in a different ROM which could only be mapped into the same address space as the compiler (hence replacing it)... What I did was organize the VM/interpreter into pure code, pure data, and relocatable data (address tables), and implement a 6502 machine code relocator (recognize each instruction type, and know how many byyes they were, and whether they had an address component that needed relocating) which copied the VM out into RAM therefore allowing it to co-reside in the address space with the compiler.
It was a very fun project, not only because of the technical challenge (this was my first job out of college), but also very much because of the memory constraint. I had to use every 6502 trick in the book to eliminate every spare byte to squeeze the assember half of it into it's 16K ROM. Those from this generation may remember things like using XOR A, A as an alternative to LD A, 0 to save a byte, changing tail recursion/calls to jumps (JSR subroutine, RET -> JMP subroutine), taking advantage f known processor flag state to use 2 byte "conditional" (but not if you know the state) branches in place of 3 byte absolute jumps, etc, etc.
Jobs' cantankerous ways with the remaining employees, manufacturers and fans drove away so many, including major players and stock holders, that he was taken out of the spotlight and replaced by John Scully. It took a decade for him to grow up enough to be given back the reins.
Or maybe it had something to do with the fact that Apple floundered under Scully while Jobs created two brand new successful companies (NeXT and Pixar) while he was away. I don't think it was a matter of Apple's board waiting for Jobs to grow up, but rather of them realizing that Apple was failing, and Jobs was still successful, and do the math.
The problem isn't that Apple has no corporate identity, but almost the opposite. They have a very strong identity, and it's intimately tied to Jobs, not just in terms of his brilliant marketing and product launches but more importantly in terms of the (high design, cutting edge, minimalist) more-than-skin-deep design aesthetic he imposes on everything that Apple does.
The trouble is that while a generic bunch of (post-Jobs) suits may be able to run certain types of companies successfully (generally the type that Warren Buffet invests in - stable markets where all you need to do is execute competently), they're very unlikely going to be able to continue that design aesthetic - they don't teach design/style in bean-counting school, nor for that matter can it really be taught. Jobs not only has style, and the asshole micromanaging, yet inspirational, personality to enforce it ubiquitously at every level of the products Apple designs, but also a style that has widespread appeal.
When Jobs eventually leaves Apple, the company will almost certainly flounder the way it did under (ex. Pepsi CEO) Sculley. IBM did much better when it brought in a high powered generic suit (ex. Nabisco biscuit boy Louis Gerstner), because IBM didn't need a high priest of style as well as a manager. Apple best bet (but still no sure thing) post-Jobs will be to lure away someone who is already running a high tech company where style is a/the key element - you either have it or you don't and there's no chance of a generic suit learning to fulfill that roll.
Finally, your phrase "hardware mashup" is a fairly accurate way of looking at engineering design work.
I disagree...there's a spectrum, but a lot of the Make projects seem to be closer to systems integration (hardware mashups) than engineering design.
Contrast with something like Steve Ciarcia's Circuit Cellar... Back in the day I recall Steve doing an Apple II speech synthesizer project, with his starting point being a phoneme to speech IC. Everything else was built/designed around it, from the circuit design and circuit board to the text-to-phoneme software. This is design.
If Make were to do a speech synthesizer project, I get the impression the flavor of it would be to rip the circuit board out of a TI speak 'n' spell, and connect the keyboard inputs to an Arduino...This is systems integration.
Not that there's anything wrong with Make magazine - I'm sure may people enjoy it and benefit from it - I was just trying to characterize what it is and what it isn't.
Yeah, I only recently discovered Make magazine, so ordered (rip-off shipping charges - no media mail option) an interesting sounding back issue to see what it was like.
As you say, it's very light on depth - these generally aren't build-from-scratch projects that require much knowledge or attention span. They're more generally "hardware mashups" designed for instant gratification for the MTV generation. I guess it's a step up from pure consumer culture, but it's hardly really DIY.
Still, there are some interesting things you can do at this sort of level, and maybe these quick-gratification projects might spark an interest in really getting into electronics or whatever. e.g. One video on their site shows how to make a laser voice transmitter based on a laser pointer - sounds cool, and no doubt fun to use, but all it involved was modulating the laser pointers battery input voltage, hence output intensity, with a transformer attached to a microphone, and using a solar cell connected to a powered speaker as the receiving device.
Achieving the intelligence of a dog would certainly be a major accomplishment, but to be honest I don't think this type of architecture is ever going to be intelligent, anymore than Cyc achieved it.
I think you need to make the distinction between intelligence and cognitive/reasoning ability. General purpose symbolic reasoning ability - manipulating a set of knowledge and rules to solve problems - is easy enough and is a long-solved problem (e.g. Allen Newell's SOAR). Cyc just added a massive knowledge/rule base. This type of system is really nothing more than an expert system, albeit one with a broad domain. Ask it to solve a problem (e.g. "provide wife with tea") within it's capabilities and it performs fine, but nobody would confuse this with intelligence - it's just canned knowledge.
The major prerequisite for intelligence that is missing from a cognitive engine / expert system is the abiliy to learn, and I believe this is such a core requirement that you can't treat it as a bolt-on (symbolic) capability, not that it wouldn't be an interesting experiment to see how far you could get by trying that. Cyc was surely stymied by not being embodied and therefore not interacting with the world and having anything to learn from, although I'm not sure if they ever made any attempt to learn via experience as opposed to via comprehension.
It's interesting to hear a bit more about Basil - thanks for replying!
Obviously it's much more convenient to have Basil be able to form his own sensory templates/discriminators, but you're still left with the limitations of a pre-programmed ontology, as well as having to supervise this object learning process - associating multiple views of the same object to the same symbolic class. I don't know what your future plans are, but you could add much flexibilty by using something like Jeff Hawkin's HTM as a sensory front end so that it Basil could, without supervision, form his own sensory categories that are invariant to orientation, scale, etc. This way Basil's categories become more dynamic, and he could autonomously aquire categories separate from being trained about their ontological mapping... You could have him direct the learning process by asking what something is once he's formed a new unmapped sensory category, or when he splits (due to further sensory exposure) an already mapped category into sub-categories (e.g. animal -> cat, dog).
I was maybe being a bit unfair in calling this method of bridging the sensory-symbolic divide useless. It depends on what your goals are. What I really meant was that this isn't a path that will get you to a general purpose autonomous AI... But of course it's quite reasonable if you have shorter term commercial goals in mind, especially where having explicit (symbolically pre-programmed, even if flexibly invoked and executed) actions/behaviors is seen as a plus rather than a negative.
The difference between Basil's and a humans ability to discriminate objects (beer vs not-a-beer) that may at first present similar sensory patterns is that the human has the ability to learn. The human would rapidly form a different category for something that had a different temperature, smell, etc than a cold beer, even if with limited exposure they initially had fallen into the same category due to visual similarity. Of course Basil could do the same with the right sensors and a more flexible HTM-like sensory front end, but the human is also going to be able to bring to bear experience it has aquired itself to figure out that this isn't a liquid at all since it's center-of-gravity desn't shift in the can as expected, and it's anyway disgusting and not worth trying due to the smell... This is where the real limitations of the sensory mapping to pre-coded symbolic approach come in; you're always going to be in "Cyc" territory (a grand experiment, but apparently very little to show for it) of having to hard code all of this stuff and therefore be brittle as a result. Of course you could eventually try to autonomously aquire symbolic rules to augment/modify/delete it's built-in knowledge, but it's not obvious that would fundamentally be any different.
Congrats on understanding what it takes to make a successful slashdot post.
Commiserations on entirely failing to grok what this robot is all about.
The key principle this robot uses to sense/model it's surroundings is what it's builders are calling "reification", which they've just published a book about. This is a way to bridge the divide between fuzzy (and semantically empty) sensory data and a symbolic (and semantically rich, if you choose to make it so) model of it's environment. The idea is simple (and simplistic) - you program the robot with the symbolic objects it needs to recognize and use to create it's world model, then train/program it to map from the salient aspects of it's fuzzy sensory (sonar) data to these built in objects.
e.g. You laboriously hand analyse sonar sensory data from chairs, contrasting it to that from other objects, until you've identified one or more fuzzy sensory patterns that are unique to chairs. You than program the robot to detect these patterns and use them either individually or in combination to determine that it's seen the pre-programmed "chair" objects that it's got built-in knowledege about, and to place an instance of this chair object in it's internal symbolic model of it's environment at the appropriate place. Tada! You've bridged the sensory-symbolic divide (in a rather useless way)! The rest of your robot can now operate at the symbolic level of it's internal model and perform party tricks like fetching beer.
Unfortunately this approach is very brittle - it's just like Cyc preprogramming a bunch of real world data into an AI system in the hope that you can gain intelligent behavior without doing the hard work of actually having to REALLY interface with the real world. It may help you build a workable commercial robot with a limited repertoire of capabilities and responses, but it's not going to help you build something that's able to learn for itself. It may be able to fetch a beer, but it's not going to take over the world, or for that matter even recognize that the "beer" it's brought you is actually a rusty tin of dog shit with the same sonar signature as a beer.
Genius isn't normal - these are people who's achievements are way out on the thin end of the bell curve in terms of what normal people do. Genius and madness (maybe a touch of Aspergers') also go hand in hand, and I doubt that too many genius's were either created or suppressed by the educational system or socio-political norms of the day. Genius's are more likely people who are doing their own thing - going off on their own tangents - completely ignoring most of what is going on around them.
Maybe, but remember that Einstein didn't come up with the theory of relativity by studying the results of a multi-billion dollar LHC - he did it my concocting his own thought experiments.
There's nothing except your own priorities from stopping you doing fun stuff as a hobby at home! I'm sure you could pick up a cheap FPGA board if that's your interest, and it's easy to do software development using free tools under both Linux and Windows.
Most jobs come with a trade off of interesting work (more rare) and good pay/commute/environment/etc. A reasonable compromise is to take the good pay/etc (gotta pay the bills), then do the fun/interesting stuff at home. You never know - you may be able to make it pay one day too.
This fembot is no doubt not as capable as the human body and pop press would make you believe, but I'd not be surprised if below the media generated hype there's some real achievement also.
OOP isn't an alternative to imperative programmg - it's a form of it.
OOP is contrasted with procedural design - also a type of imperative programming. The classic description of the difference between the two is that to implement a written specification, for OOP you implement the nouns (objects), else for procedural you implement the verbs (procedures).
No, competition is usually involved, but evolution isn't about competition.
Wrong. It's competition (more fit wins) that introduces the population bias towards greater fitness. Without competition you've just got a single random walk who's direction is unrelated to fitness.
Evolution is about competition, and ultimately about the long term not the short term. so...
1) It's not about meeting any fixed threshold of fitness (although obviously you leave to leave a least one descendent to still be in the game), but rather about how your fitness compares to the rest of the population. If you're fitter than average then the percentage of your DNA will be increasing in the communal genepool, else it will be decreasing.
2) Evolution is optimizing long term success rather than short term success. It doesn't matter how many descendents you directly leave if they all die out in a few generations, but alternatively you may only leave a few descendents that then become incredibly successful in the future. Note Homo Sapiens "Genetic Eve" for example, or similar evolutionary bottlenecks... the reproductive success of all females predating her, but not on her bloodline, was ultimately for nought (you could say they were climbing a local fitness peak, while Genetic Eve was ascending a higher one that ended up assuring her survival).
Slashdot Mirror
Not quite as insignificant as you think.
Microsoft's June 2008 worlwide head count 91,259
was http://www.microsoft.com/presspass/inside_ms.mspx
So 5,000 being let go is still a > 5% layoff. 1-in-20 being let go.
Using C++/Qt isn't torture - it's a genuine pleasure. The cross-platformity doesn't cost you anything in terms of inconveniece or even a moments thought - it comes for free with everything (including threads, SQL, XML, etc) in the Qt API. If you download the free version of Qt for Windows you even have the convenient option of downloading it togther with MinGW (basically GNU g++, tools and bash shell for Windows) so you can install it all in one go, for free Windows software development.
Just to clarify for anyone new to Qt...
Qt Designer and Qt Creator are two entirely different things.
Qt Designed is drag-n-drop interactive GUI design tool that lets you design the GUI portion if aplication windows, dialogs, etc without coding. You just drag widgets and layout managers off a menu and drop them into the interface your building. It's an awesome tool. Your interface gets saved as a ".ui" file from which Qt automatically generates the corresponding C++ code as clean C++ classes. To add callback/etc behavior, or to further customize the GUI, you just subclass the generated classes and take it from there. It's done very well so that almost always you can further change the user interface using Qt Designer without affecting the subclasses you've added. Qt Designer has been there since early on and just keeps getting better and more powerful.
Qt also includes a tool "qmake" that makes building Qt apps ridiculously easy - qmake takes a high level ".pro" file that lists the various types of file making up your project (source files, header files, Qt designer .ui files, resource files, etc) and what type of target you're building (application, DLL, etc), and from the .pro file generates a Makefile that you then run using your normal make program (e.g. GNU make, or mingw32-make under MinGW).
Qt Creator is an IDE for development of Qt based applications, and seems to deliver the expected functionality of an IDE. It's pretty much brand new, and I havn't personally used it (nor intend to since I don't find IDEs to help my productivity).
Qt supports more than just Windows/Linux/Mac OSX... It also supports embedded applications (Qt/Embedded - used for Qtopia, which assumes nothing more than a framebuffer graphics interface), and most recently also Windows CE.
I think Google's decision to go with their own graphics API for Android is looking very much like "not invented here". The Qt API is excellent (I've been using the free version for years), and it's available pretty much everywhere. Now with LGPL licensing, any remaining objection has pretty much disappeared. Qt Jambi (the Java API for Qt) would be perfect for Android.
Even for 8 bit numbers, you're still talking about up to 255 loop iterations rather than 8 (maximum) with the shift method. You keep on referring to K.I.S.S. and the "complexity" of the shift method, but the "complexity" consists of precisely 3 extra instructions (2 shifts and a branch) compared to your naieve method, and this "complex" algorithm is nothing more than the long hand multiplication method you were taught at age 10, applied to binary numbers.
It's a bizarre games programmer that, working on a slow 8 bit processor thought it was a good design choice to throw away hundreds of clock cycles per multiply to save yourself 3 assembler instructions, and a totally unimaginative one that thinks that his own slow-as-molasses integer multiply routine has got any relevance whatsoever to the fast floating point math required by a spreadsheet.
With your programming skillz, I'd not be too insistent on ordering people off your lawn. In fact Dan Bricklen is probably in your front yard right now, dropping trou and taking a dump on your garden gnome.
Consider doing a 16 bit or 32 bit multiplication your way - we're talking a for loop of up to 64K or 4+ billion steps, vs a for loop of 16 or 32 steps for the shift way. On a processor with a 1MHz clock speed, your way would literally take hours to do a single 32 bit multiply! The fact that the shift method is doing shift and add per loop rather than just add hardly makes up for it! ;-)
Yep - you're right. My memory is failing me! When you typed "*BASIC" to get into the BASIC interpreter, this was actually no different than using "*PASCAL" to get into our environment or any other ROM software. These commands were passed around to each ROM by the OS interpreter to see which one of them (if any) wanted to recognize it.
Yep, the built-in assembler (built into BBC BASIC) was great - this is what I used to develop this software. Two-pass assembly (required to figure forward jump addresses) was just a matter of putting a BASIC for-loop around your assembler section!
Sinclair was our major competitor at the time, but it was still friendly. I remember (nowadays "Sir") Clive Sinclair being invited to our company Christmas party one year.
No multiply of divide? So what? Multiplication is just serial addition, and division is simply serial subtraction. 4x4=4+4+4+4.
Not if you want to do it fast. Multiplying two binary numbers is basically a matter of shift-and-add.
Say you want to multiple 1101 by 1010 (13 x 10), this breaks down to:
0 x 1101 +
1 x 11010 +
0 x 110100 +
1 x 1101000
= 10000010 (130)
To implement this in assember you'd shift one number left one bit at a time so that the least significatn bit gets shifted into a processor flag where it can be tested (the 1's and 0's shown on the right), and shift the other number right one bit at a time for the corresponding multiplication by 2, and either add it or not to the running total depending on whether you're multiplying by a 1 or a 0.
Division is done basically the same as the long-hand division you'd do on paper.
Speaking of 6502 programming feats, back in 1982 I worked for Acorn computers in the UK, writing software for the 2MHz 6502 based BBC microcomputer, which incidently we also used as our development machines. The BBC micro had 16K of ROM for the built-in BASIC interpreter and low level "OS", another 16K of address space into which you could map any one (at a time) of the other 16K software ROMs in that machine, and 16K or 32K of RAM depending on the model. Much software was sold on ROM - there were four sockets built-in or you could get expansion boards to allow more - but only one at a time could be selected since there was only 16K of address space for these.
One project I did at Acorn (with another guy) was to implement a Pascal development system for the BBC micro that we crammed into two of these add-in 16K ROMs. This was no cut down version - is was a full-blown ISO certified version of Pascal, the first ever implementation for a Microcomputer to implement the standard and achieve ISO certification (ISO Pascal is different from P-system Pascal which had preceded it).
So, what we fitted into 32K was:
- An ISO Pascal compiler, which compiled programs down to a P-code like stack-based virtual instruction set
- A virtual machine/interpreter for the instruction set
- A 6502 machine code relocator
- The complete Pascal run-time library (full floating point, IO library, heap, etc)
- A full-featured full-screen editor with regex find/replace (with as-you-type syntax parsing and highlighting), block copy/move/delete, etc (in only 4K of code)
- Command line interpreter
Now bear in mind that only 16K of this could actually be in the address space at one time...
The way we managed to squeeze all this in was to have the compiler in one 16K ROM, and the rest in the other. The compiler was written in ISO Pascal and self-compiled to our virtual instruction set. We had to add a few "macro" instructions especially for the compiler in order to get it under the 16K limit. The rest of the software (which I wrote) was all in 6502 assembler. Now consider that to run the compiler you also needed the virtual machine, but that was in a different ROM which could only be mapped into the same address space as the compiler (hence replacing it)... What I did was organize the VM/interpreter into pure code, pure data, and relocatable data (address tables), and implement a 6502 machine code relocator (recognize each instruction type, and know how many byyes they were, and whether they had an address component that needed relocating) which copied the VM out into RAM therefore allowing it to co-reside in the address space with the compiler.
It was a very fun project, not only because of the technical challenge (this was my first job out of college), but also very much because of the memory constraint. I had to use every 6502 trick in the book to eliminate every spare byte to squeeze the assember half of it into it's 16K ROM. Those from this generation may remember things like using XOR A, A as an alternative to LD A, 0 to save a byte, changing tail recursion/calls to jumps (JSR subroutine, RET -> JMP subroutine), taking advantage f known processor flag state to use 2 byte "conditional" (but not if you know the state) branches in place of 3 byte absolute jumps, etc, etc.
Toot toot!
Jobs' cantankerous ways with the remaining employees, manufacturers and fans drove away so many, including major players and stock holders, that he was taken out of the spotlight and replaced by John Scully. It took a decade for him to grow up enough to be given back the reins.
Or maybe it had something to do with the fact that Apple floundered under Scully while Jobs created two brand new successful companies (NeXT and Pixar) while he was away. I don't think it was a matter of Apple's board waiting for Jobs to grow up, but rather of them realizing that Apple was failing, and Jobs was still successful, and do the math.
I totally disagree.
The problem isn't that Apple has no corporate identity, but almost the opposite. They have a very strong identity, and it's intimately tied to Jobs, not just in terms of his brilliant marketing and product launches but more importantly in terms of the (high design, cutting edge, minimalist) more-than-skin-deep design aesthetic he imposes on everything that Apple does.
The trouble is that while a generic bunch of (post-Jobs) suits may be able to run certain types of companies successfully (generally the type that Warren Buffet invests in - stable markets where all you need to do is execute competently), they're very unlikely going to be able to continue that design aesthetic - they don't teach design/style in bean-counting school, nor for that matter can it really be taught. Jobs not only has style, and the asshole micromanaging, yet inspirational, personality to enforce it ubiquitously at every level of the products Apple designs, but also a style that has widespread appeal.
When Jobs eventually leaves Apple, the company will almost certainly flounder the way it did under (ex. Pepsi CEO) Sculley. IBM did much better when it brought in a high powered generic suit (ex. Nabisco biscuit boy Louis Gerstner), because IBM didn't need a high priest of style as well as a manager. Apple best bet (but still no sure thing) post-Jobs will be to lure away someone who is already running a high tech company where style is a/the key element - you either have it or you don't and there's no chance of a generic suit learning to fulfill that roll.
Finally, your phrase "hardware mashup" is a fairly accurate way of looking at engineering design work.
I disagree...there's a spectrum, but a lot of the Make projects seem to be closer to systems integration (hardware mashups) than engineering design.
Contrast with something like Steve Ciarcia's Circuit Cellar... Back in the day I recall Steve doing an Apple II speech synthesizer project, with his starting point being a phoneme to speech IC. Everything else was built/designed around it, from the circuit design and circuit board to the text-to-phoneme software. This is design.
If Make were to do a speech synthesizer project, I get the impression the flavor of it would be to rip the circuit board out of a TI speak 'n' spell, and connect the keyboard inputs to an Arduino...This is systems integration.
Not that there's anything wrong with Make magazine - I'm sure may people enjoy it and benefit from it - I was just trying to characterize what it is and what it isn't.
Yeah, I only recently discovered Make magazine, so ordered (rip-off shipping charges - no media mail option) an interesting sounding back issue to see what it was like.
As you say, it's very light on depth - these generally aren't build-from-scratch projects that require much knowledge or attention span. They're more generally "hardware mashups" designed for instant gratification for the MTV generation. I guess it's a step up from pure consumer culture, but it's hardly really DIY.
Still, there are some interesting things you can do at this sort of level, and maybe these quick-gratification projects might spark an interest in really getting into electronics or whatever. e.g. One video on their site shows how to make a laser voice transmitter based on a laser pointer - sounds cool, and no doubt fun to use, but all it involved was modulating the laser pointers battery input voltage, hence output intensity, with a transformer attached to a microphone, and using a solar cell connected to a powered speaker as the receiving device.
Achieving the intelligence of a dog would certainly be a major accomplishment, but to be honest I don't think this type of architecture is ever going to be intelligent, anymore than Cyc achieved it.
I think you need to make the distinction between intelligence and cognitive/reasoning ability. General purpose symbolic reasoning ability - manipulating a set of knowledge and rules to solve problems - is easy enough and is a long-solved problem (e.g. Allen Newell's SOAR). Cyc just added a massive knowledge/rule base. This type of system is really nothing more than an expert system, albeit one with a broad domain. Ask it to solve a problem (e.g. "provide wife with tea") within it's capabilities and it performs fine, but nobody would confuse this with intelligence - it's just canned knowledge.
The major prerequisite for intelligence that is missing from a cognitive engine / expert system is the abiliy to learn, and I believe this is such a core requirement that you can't treat it as a bolt-on (symbolic) capability, not that it wouldn't be an interesting experiment to see how far you could get by trying that. Cyc was surely stymied by not being embodied and therefore not interacting with the world and having anything to learn from, although I'm not sure if they ever made any attempt to learn via experience as opposed to via comprehension.
It's interesting to hear a bit more about Basil - thanks for replying!
Obviously it's much more convenient to have Basil be able to form his own sensory templates/discriminators, but you're still left with the limitations of a pre-programmed ontology, as well as having to supervise this object learning process - associating multiple views of the same object to the same symbolic class. I don't know what your future plans are, but you could add much flexibilty by using something like Jeff Hawkin's HTM as a sensory front end so that it Basil could, without supervision, form his own sensory categories that are invariant to orientation, scale, etc. This way Basil's categories become more dynamic, and he could autonomously aquire categories separate from being trained about their ontological mapping... You could have him direct the learning process by asking what something is once he's formed a new unmapped sensory category, or when he splits (due to further sensory exposure) an already mapped category into sub-categories (e.g. animal -> cat, dog).
I was maybe being a bit unfair in calling this method of bridging the sensory-symbolic divide useless. It depends on what your goals are. What I really meant was that this isn't a path that will get you to a general purpose autonomous AI... But of course it's quite reasonable if you have shorter term commercial goals in mind, especially where having explicit (symbolically pre-programmed, even if flexibly invoked and executed) actions/behaviors is seen as a plus rather than a negative.
The difference between Basil's and a humans ability to discriminate objects (beer vs not-a-beer) that may at first present similar sensory patterns is that the human has the ability to learn. The human would rapidly form a different category for something that had a different temperature, smell, etc than a cold beer, even if with limited exposure they initially had fallen into the same category due to visual similarity. Of course Basil could do the same with the right sensors and a more flexible HTM-like sensory front end, but the human is also going to be able to bring to bear experience it has aquired itself to figure out that this isn't a liquid at all since it's center-of-gravity desn't shift in the can as expected, and it's anyway disgusting and not worth trying due to the smell... This is where the real limitations of the sensory mapping to pre-coded symbolic approach come in; you're always going to be in "Cyc" territory (a grand experiment, but apparently very little to show for it) of having to hard code all of this stuff and therefore be brittle as a result. Of course you could eventually try to autonomously aquire symbolic rules to augment/modify/delete it's built-in knowledge, but it's not obvious that would fundamentally be any different.
Congrats on understanding what it takes to make a successful slashdot post.
Commiserations on entirely failing to grok what this robot is all about.
The key principle this robot uses to sense/model it's surroundings is what it's builders are calling "reification", which they've just published a book about. This is a way to bridge the divide between fuzzy (and semantically empty) sensory data and a symbolic (and semantically rich, if you choose to make it so) model of it's environment. The idea is simple (and simplistic) - you program the robot with the symbolic objects it needs to recognize and use to create it's world model, then train/program it to map from the salient aspects of it's fuzzy sensory (sonar) data to these built in objects.
e.g. You laboriously hand analyse sonar sensory data from chairs, contrasting it to that from other objects, until you've identified one or more fuzzy sensory patterns that are unique to chairs. You than program the robot to detect these patterns and use them either individually or in combination to determine that it's seen the pre-programmed "chair" objects that it's got built-in knowledege about, and to place an instance of this chair object in it's internal symbolic model of it's environment at the appropriate place. Tada! You've bridged the sensory-symbolic divide (in a rather useless way)! The rest of your robot can now operate at the symbolic level of it's internal model and perform party tricks like fetching beer.
Unfortunately this approach is very brittle - it's just like Cyc preprogramming a bunch of real world data into an AI system in the hope that you can gain intelligent behavior without doing the hard work of actually having to REALLY interface with the real world. It may help you build a workable commercial robot with a limited repertoire of capabilities and responses, but it's not going to help you build something that's able to learn for itself. It may be able to fetch a beer, but it's not going to take over the world, or for that matter even recognize that the "beer" it's brought you is actually a rusty tin of dog shit with the same sonar signature as a beer.
Genius isn't normal - these are people who's achievements are way out on the thin end of the bell curve in terms of what normal people do. Genius and madness (maybe a touch of Aspergers') also go hand in hand, and I doubt that too many genius's were either created or suppressed by the educational system or socio-political norms of the day. Genius's are more likely people who are doing their own thing - going off on their own tangents - completely ignoring most of what is going on around them.
Maybe, but remember that Einstein didn't come up with the theory of relativity by studying the results of a multi-billion dollar LHC - he did it my concocting his own thought experiments.
There's nothing except your own priorities from stopping you doing fun stuff as a hobby at home! I'm sure you could pick up a cheap FPGA board if that's your interest, and it's easy to do software development using free tools under both Linux and Windows.
Most jobs come with a trade off of interesting work (more rare) and good pay/commute/environment/etc. A reasonable compromise is to take the good pay/etc (gotta pay the bills), then do the fun/interesting stuff at home. You never know - you may be able to make it pay one day too.
FWIW the inventor, Le Trung, does appear to be somesort of prodigy, and has previously produced an awesome artificial hand.
You can see some videos of him here:
http://blogs.spectrum.ieee.org/automaton/2008/08/12/robot_builder_profile_aiko.html
This fembot is no doubt not as capable as the human body and pop press would make you believe, but I'd not be surprised if below the media generated hype there's some real achievement also.
OOP isn't an alternative to imperative programmg - it's a form of it.
OOP is contrasted with procedural design - also a type of imperative programming. The classic description of the difference between the two is that to implement a written specification, for OOP you implement the nouns (objects), else for procedural you implement the verbs (procedures).
No, competition is usually involved, but evolution isn't about competition.
Wrong. It's competition (more fit wins) that introduces the population bias towards greater fitness. Without competition you've just got a single random walk who's direction is unrelated to fitness.
You've got that exactly backwards.
It's OpenCL that's trying to follow in the footsteps of OpenGL, not vice versa.
OpenGL is an open specification that has many implementations taking rather good advantage of graphics hardware! ;-)
OpenCL wants to establish a similar standard but for GPU based kernel execution rather than graphics rendering.
Evolution is about competition, and ultimately about the long term not the short term. so...
1) It's not about meeting any fixed threshold of fitness (although obviously you leave to leave a least one descendent to still be in the game), but rather about how your fitness compares to the rest of the population. If you're fitter than average then the percentage of your DNA will be increasing in the communal genepool, else it will be decreasing.
2) Evolution is optimizing long term success rather than short term success. It doesn't matter how many descendents you directly leave if they all die out in a few generations, but alternatively you may only leave a few descendents that then become incredibly successful in the future. Note Homo Sapiens "Genetic Eve" for example, or similar evolutionary bottlenecks... the reproductive success of all females predating her, but not on her bloodline, was ultimately for nought (you could say they were climbing a local fitness peak, while Genetic Eve was ascending a higher one that ended up assuring her survival).