You must have a real problem with Transmeta, then, since their entire concept is to keep people from programming to the actual hardware - they translate the input instruction set (x86 now, more later?) into whatever their hardware eats - just like Java bytecode is translated into the target machine's instructions.
Obviously, these concepts and platforms are just too inefficiecient for you to waste your time on. Go back to hand-coding your assembler.
It's an open-source world, right? So why shouldn't they build a tool that has the benefits of both?
The gnu world has some cool tools, but they're often not so user-friendly (I have better use for those brain cells than memorizing emacs ctrl-meta-alt-shift codes), while the "Office" type apps often (usually? almost always?) put style and presentation before substance.
The gnumeric engine behind the Office spreadsheet - maybe, for once, we can have both.
Uh, huh. And do you believe corporations will stop polluting, politicians will tell the truth at all times and keep all their promises, and that girl you're about to sleep with really is disease-free and on the Pill?
Remember - the techies may be "young blood," but a lot of the "senior hands" in the management slots are good, old-fashioned, corporate-trained folk who've just happened to find jobs in a quickly growing area. Bean-counters are bean-counters, whether they work for Arthur Andersen, Exxon, GM, or (your startup name here). The same goes for advertising, inventory control, sales... a lot of the "new economy" folks got their experience in the "old economy," so we shouldn't be surprised when the old bad habits show up. It's still what they know how to do.
Why are we moving the X Window System to laptops, palmtops, PDAs, etc.? It's not meant for that - it's designed to window across networks. The core APIs are 15-20 years old, and it's humongous overkill to try to implement it for a simple display (IMHO, of course).
Is anyone out there even thinking of an alternative to X for those of us who want a GUI, but don't want to drag along 15 years' of backward compatibility, inherent networking assumptions, and layered APIs?
One of the things I learned in college, Way Back When, was that the OS should NEVER allow an "application" to lock it up. NEVER EVER.
So, if an app causes a crash of itself - bad app. If an app causes a crash of itself and other apps (say, through data sharing or IPC or file lock problems) - baaad apps. If an app causes the operating system to lock up, or even worse, BSOD (or that OS's equivalent) - BAD OS!
Of course, this is rarely seen in modern software practice - but that's the philosophy I was taught, and I like it - I'll stick with it.
One of the things that's saved my neck a couple of times is talking things through with another programmer. I get a lot more our of collaborative design than just sitting in front of a tube bashing at something... if I can come up with an elegant solution, then I can implement it, but if all I can come up with is a "get a bigger hammer" solution, I'll go have a chat with one of the other guys who's been around a while, and show him the problem, and see what he comes up with. And of course, I reciprocate when others bring their little issues to me... that's one of the reasons I don't like telecommuting (waits for gasps and howls to die down) - I need interaction with other human/semihuman/geek types to keep me from just staring at the screen (or even worse, banging my head against it). Even my good designs get better when other eyes look at it - ever had one of those bugs you couldn't find, but as soon as someone else looked at it, there it was? Software design's like that, to me... the first pass is never the best.
Oh - but most of what all these other folks have said helps, too. Pick an outdoor activity and play with it (I've gotten into whitewater kayaking - what a rush!), or get involved with a Significant Other (and get ready to have your life completely modified), or just get out from in front of the tube and walk around the park for a while. Coding may be Life, for some of us... but Life is not Coded.
I saw this written somewhere: "I always try to write my code as if the guy who has to maintain it is a psychotic axe-murderer who has my name and address." - the same approach should be taken to documentation.
My first out-of-college job was writing Ada on an Air Force contract, where the requirement was to write code that could be maintained by airmen with a 7th grade reading level. Ever tried to describe generics to someone at the 7th grade reading level? How about nexted SQL selects? Some parts of our software had three and four times the lines of comments as lines of code (plus all the USAF's required MIL-STD 2167A documentation).
I very much liked Riel's book - didn't agree with all of his heuristics, but it was valuable brain training. There's more to the Heuristics book than just "where the patterns come from" - it catalogues and defines lots of pitfalls of OO design. Patterns + Heuristics = Better Design.
I must be doing something right - I have all of those books except "Refactoring" on my bookshelf now (and it's been in my group's reference section).
How much of that article addressed encryption at all? How many of today's exploits even care?
Ok, so ssh will keep the script kiddies from reading your password, and telnet won't. That doesn't help a bit if they've done a bind exploit, gotten root, used a rootkit to replace ssh, and now own your server.
Well, I've read it - I own it. I've met and talked with Mr. Coad hisownself, and used his tool... the tool's better than the book. Hereafter is my opinion of the book, as an OO designer/developer of several years' experience:
Chapter 1 is the concept he's describing, modeling in color. Coad defines four archetypes, and associates a color with each. He gives examples of how to classify your classes according to these archetypes, and works into thinking in terms of them. He then introduces another abstraction, the "domain-neutral component," which is a large diagram template which can be customized to fit your particular situation(s). I had a bit more of an issue with this one. It seems useful, but I'm not sure that it doesn't stunt your thinking.
Chapters 2-5 are examples, in gory detail. He and his coauthors have defined 61! different domain-neutral components (which I honestly would call domain specializations of his overall Domain-Neutral Component). It's a catalogue, with fair descriptions, but I wouldn't put this into the category of Design Patterns, quite... I'm really not sure how to classify these things. (Have to think about that some more.) If you're familiar with OO, reading through this will educate you on the thought processes used to generate these things, and if you happen to have a problem that has pieces that fall into these 61 bins, you're set!
Chapter 6 is a departure. Feature-Driven Development is a "how to build what you've designed" process, and really doesn't fit the tone of the rest of the book. I found it useful (as I've posted elsewhere), but it's a jarring departure from the monotony of reading the catalogue of components. Well worth reading on its own - but not worth the cost of the book.
Appendices have large (readable) versions of the archetypes, and modeling tops.
Now - a bonus tip from Me to You. Go to Coad's company's web site ( Togethersoft ) and download their modeling tool (IMHO, beats the tar out of Rational Rose). Then, ask them nicely for a 30-day evaluation license, and do their tutorials. The tool does these components, and GOF Patterns, and lots of other fun things, and has a tutorial and examples of the Modeling in Color (although not Feature-Driven Development) from much of the book. Save your cash and do it in software:-).
Seconded. He really is very good at explaining things in person (although he's expensive as hell). I've used Feature Driven Development (chapter 6 of the book) - I thought it was useful, it made our bean-counters happy (we had easily identifiable earned-value milestones, and suitable checkpoints), was understandable by both techies and management, and it integrated well with our company's Official Software Development Process. Don't use it for design - use it for implementing the design.
I've heard Coad give his 1-hour talk on this, and used his tool (Together, which makes Rational Rose look very obsolete). It can add some context to UML diagrams, and we were able to communicate pretty well with a graphics-brained UI designer using the color models.
I own this book, and I was honestly disappointed. I'd like to see this combined with "Java Design" and given some more fundamentals-of-OO/UML, maybe a sprinkling of component-based architecture, and then I think he'd have a heck of a book. On its own - it's thin.
IMHO, the GOF book is THE reference for patterns, but it's not easy, especially for beginners. Folks need a good grounding in OO concepts and implementation to be able to understand what's going on. Other folks have come out with other "Patterns" books, esp. Mowbray and friends - check them carefully and assess whether they talk about what you think they talk about ("Antipatterns," especially, is more of a "examples of bad software process" book, (again IMHO)).
I have yet to see an "Intro to UML and Patterns" book that I liked... any suggestions?
The 6Bone already exists, and is being used to hammer on the protocol and work out the kinks, plus figure out how to let v4 and v6 coexist.
That crisis point you talk about is coming - just wait until all those new top level domains come on line and folks start realizing we're almost out of IP addresses (and given the trend of new IP allocations, we're lucky if IPv4 lasts another 24 months). IPv6 isn't something ISPs and the backbone will move to voluntarily (with a few farsighted exceptions) - it's going to be one of those gun-to-the-head-of-the-business situations that makes life so enjoyable for us spectators.
Well - additional IPv6 info is available all over the place - try starting at IPv6.com or the IETF IPNG Working Group. The 6Bone is a network of Internet hosts running IPv6 already, and there's a transition planning working group that's arguing, er, discussing, the transition. UNFORTUNATELY, their schedule/roadmap on the transition planning page ends at March of 2000, with an entry to evaluate the state of their roadmap.
Organists are solo performers - organists accompanying choirs pay CLOSE attention to the conductor to keep in sync.
You're still missing the electricity of having the others around you performing, the eye contact from the conductor as he cues your section, the buzz of the audience... *sigh*. Ahh, to be young and in the college chorale again.
Right - you could do "studio-type" work, but not "performance." Problems in the sync are worked out by the producer in post-processing, but for live performance... the Olympic example the other guy gave is good, they were synced (I believe to atomic clocks (GPR receivers)) and the TV producers mucked about with the lags and delays to get the "simultaneous performance" effect, but I've performed with large choirs and orchestras - the feedback from the people around you matters, a lot. The lag from folks singing the same thing from around the world (maybe a quarter second, if you're lucky, varying a lot from site to site) could REALLY screw up that feeling of unity and coherence that makes a live performance great (for the performers as well as the audiences).
The example in the story is good - Master's classes where they can "teleperform" to Big Names, and listen to the Big Names perform back, and get feedback - valuable stuff. Would I want to be trying to accompany Yo-Yo Ma in London from the opera house in Sydney? Ummm.... no.
I just thought of another use for this - imagine the Who's studio sessions getting piped out over the Internet, so anyone who wanted could jam "with them." Be hard to get the feedback to them and have it mean anything, but all of us wannabes could really ruin our guitars that way:-D.
Musicians performing together from around the world? How, pray tell, are they going to be synchronized?
You might be able to let people watch a performance where all the musicians are sync'd by the "performance coordinator," but if you're piping the sound of a drummer in Montreal to a bass player in LA and a guitarist in Geneva, the noises those two make will NOT be in sync with each other, let alone the keyboardist in Hong Kong. As a collaborative tool for live performances, this ain't gonna work - for studio work, it sounds great, though. One question - is a week of this kind of bandwidth and technology any cheaper than just putting the performers on a 747 and flying them to Mussel Shoals?
OOUI, I'll grant you - and I sorta liked OS/2 by the time it had evolved into Warp... but it wasn't an OO-OS. The underlying components weren't - components, that is. The concept allowed UI developers, and users, to do lots of cool stuff - but if you wanted to write software for it, it was really procedural, even though they had OO jargon coating parts of it.
Much as I hate to say it, COM is doing good things for the Windoze development community. I know of programs constructed out of COM/DCOM components, with some smart glue and logic making them do interesting things. Can we do the same in the [Li/U]nix community? I don't see it, yet... and I don't think the underlying technology lends itself to that purpose well (well, neither does M$'s, IMHO, but they can throw 100 programmers at it for a year and make it work - the Get A Bigger Hammer school of software architecture).
OOP is hot, COP (component-oriented programming) is getting hot, and OOA/COA (the A is for Architecture) is starting to emit steam heat... so who's going to design an operating system for Intel systems on these principles?
One of the things that bugs me about all this is the principle of critical mass. Linux got a lot of its critical mass from (1) being based on Unix (2) being taught in colleges (3) being free. Windoze got its critical mass through corporate purchasing departments and sharp (sometimes shark-like) marketing and business tactics. Are the Linux devotees willing to listen and try a new OO-OS concept?
Hmmm... sounds like something someone should be doing in a grad school, somewhere....
Next was cool - but they were Apple all over again, after Apple was failing. They had a great OS, nice software architecture (in many ways, the forerunners of today's "Component-based software" fad), and neat technology - BUT they had proprietary hardware that couldn't keep up!
Apple already had a core base of devoted followers - Jobs sold them so hard on the Mac he couldn't resell them on his new toy. If only someone would come up with this cool, innovative, NEW technology on the platform that the vast majority of us are using... any takers?
NT's lineage includes an incredible amount of influence from DEC VMS, sort-of-crossbred with the Mach kernel, but made to work with the DOS/Win3.1 legacy. Is there any wonder that the code's bloated? (like a whale carcass on a desert beach).
Think in terms of the big apps running these days, and the machinery behind them. Can our OSs handle these huge drives? Can Oracle or Informix or Sybase effectively use this much space? Or will we have to partition these physical drives into 8-10 smaller spaces, thereby pandering to the limitations of our software technologies?
I can forsee a whole lot of wasted space as folks start defining multi-meg partitions. I'm pretty sure my BIOS won't understand it, either (but I'm sure there's a nice CDROM with the drive package that'll take care of that for me).
Wonder when the software folks (OSs, DBs) are going to start building products that will be able to use the hardware of their futures, and not their pasts?
For an Anonymous Coward, that was a remarkably lucid, thoughtful, well-constructed comment. Are you sure you're not a Responsible Figure?
Thanks for the quick history of the GNU/Open Source disconnect. I missed that schism as it happened, so I was inferring things from context about ESR and RMS and the other players. I may not agree with 'em - but I respect the work they've done.
Slashdot Mirror
Obviously, these concepts and platforms are just too inefficiecient for you to waste your time on. Go back to hand-coding your assembler.
The gnu world has some cool tools, but they're often not so user-friendly (I have better use for those brain cells than memorizing emacs ctrl-meta-alt-shift codes), while the "Office" type apps often (usually? almost always?) put style and presentation before substance.
The gnumeric engine behind the Office spreadsheet - maybe, for once, we can have both.
Riigghhtt
Remember - the techies may be "young blood," but a lot of the "senior hands" in the management slots are good, old-fashioned, corporate-trained folk who've just happened to find jobs in a quickly growing area. Bean-counters are bean-counters, whether they work for Arthur Andersen, Exxon, GM, or (your startup name here). The same goes for advertising, inventory control, sales... a lot of the "new economy" folks got their experience in the "old economy," so we shouldn't be surprised when the old bad habits show up. It's still what they know how to do.
Why are we moving the X Window System to laptops, palmtops, PDAs, etc.? It's not meant for that - it's designed to window across networks. The core APIs are 15-20 years old, and it's humongous overkill to try to implement it for a simple display (IMHO, of course).
Is anyone out there even thinking of an alternative to X for those of us who want a GUI, but don't want to drag along 15 years' of backward compatibility, inherent networking assumptions, and layered APIs?
So, if an app causes a crash of itself - bad app. If an app causes a crash of itself and other apps (say, through data sharing or IPC or file lock problems) - baaad apps. If an app causes the operating system to lock up, or even worse, BSOD (or that OS's equivalent) - BAD OS!
Of course, this is rarely seen in modern software practice - but that's the philosophy I was taught, and I like it - I'll stick with it.
Oh - but most of what all these other folks have said helps, too. Pick an outdoor activity and play with it (I've gotten into whitewater kayaking - what a rush!), or get involved with a Significant Other (and get ready to have your life completely modified), or just get out from in front of the tube and walk around the park for a while. Coding may be Life, for some of us... but Life is not Coded.
My first out-of-college job was writing Ada on an Air Force contract, where the requirement was to write code that could be maintained by airmen with a 7th grade reading level. Ever tried to describe generics to someone at the 7th grade reading level? How about nexted SQL selects? Some parts of our software had three and four times the lines of comments as lines of code (plus all the USAF's required MIL-STD 2167A documentation).
I must be doing something right - I have all of those books except "Refactoring" on my bookshelf now (and it's been in my group's reference section).
Ok, so ssh will keep the script kiddies from reading your password, and telnet won't. That doesn't help a bit if they've done a bind exploit, gotten root, used a rootkit to replace ssh, and now own your server.
Chapter 1 is the concept he's describing, modeling in color. Coad defines four archetypes, and associates a color with each. He gives examples of how to classify your classes according to these archetypes, and works into thinking in terms of them. He then introduces another abstraction, the "domain-neutral component," which is a large diagram template which can be customized to fit your particular situation(s). I had a bit more of an issue with this one. It seems useful, but I'm not sure that it doesn't stunt your thinking.
Chapters 2-5 are examples, in gory detail. He and his coauthors have defined 61! different domain-neutral components (which I honestly would call domain specializations of his overall Domain-Neutral Component). It's a catalogue, with fair descriptions, but I wouldn't put this into the category of Design Patterns, quite... I'm really not sure how to classify these things. (Have to think about that some more.) If you're familiar with OO, reading through this will educate you on the thought processes used to generate these things, and if you happen to have a problem that has pieces that fall into these 61 bins, you're set!
Chapter 6 is a departure. Feature-Driven Development is a "how to build what you've designed" process, and really doesn't fit the tone of the rest of the book. I found it useful (as I've posted elsewhere), but it's a jarring departure from the monotony of reading the catalogue of components. Well worth reading on its own - but not worth the cost of the book.
Appendices have large (readable) versions of the archetypes, and modeling tops.
Now - a bonus tip from Me to You. Go to Coad's company's web site ( Togethersoft ) and download their modeling tool (IMHO, beats the tar out of Rational Rose). Then, ask them nicely for a 30-day evaluation license, and do their tutorials. The tool does these components, and GOF Patterns, and lots of other fun things, and has a tutorial and examples of the Modeling in Color (although not Feature-Driven Development) from much of the book. Save your cash and do it in software :-).
Seconded. He really is very good at explaining things in person (although he's expensive as hell). I've used Feature Driven Development (chapter 6 of the book) - I thought it was useful, it made our bean-counters happy (we had easily identifiable earned-value milestones, and suitable checkpoints), was understandable by both techies and management, and it integrated well with our company's Official Software Development Process. Don't use it for design - use it for implementing the design.
I own this book, and I was honestly disappointed. I'd like to see this combined with "Java Design" and given some more fundamentals-of-OO/UML, maybe a sprinkling of component-based architecture, and then I think he'd have a heck of a book. On its own - it's thin.
I have yet to see an "Intro to UML and Patterns" book that I liked... any suggestions?
That crisis point you talk about is coming - just wait until all those new top level domains come on line and folks start realizing we're almost out of IP addresses (and given the trend of new IP allocations, we're lucky if IPv4 lasts another 24 months). IPv6 isn't something ISPs and the backbone will move to voluntarily (with a few farsighted exceptions) - it's going to be one of those gun-to-the-head-of-the-business situations that makes life so enjoyable for us spectators.
Well - additional IPv6 info is available all over the place - try starting at IPv6.com or the IETF IPNG Working Group. The 6Bone is a network of Internet hosts running IPv6 already, and there's a transition planning working group that's arguing, er, discussing, the transition. UNFORTUNATELY, their schedule/roadmap on the transition planning page ends at March of 2000, with an entry to evaluate the state of their roadmap.
You're still missing the electricity of having the others around you performing, the eye contact from the conductor as he cues your section, the buzz of the audience... *sigh*. Ahh, to be young and in the college chorale again.
The example in the story is good - Master's classes where they can "teleperform" to Big Names, and listen to the Big Names perform back, and get feedback - valuable stuff. Would I want to be trying to accompany Yo-Yo Ma in London from the opera house in Sydney? Ummm.... no.
I just thought of another use for this - imagine the Who's studio sessions getting piped out over the Internet, so anyone who wanted could jam "with them." Be hard to get the feedback to them and have it mean anything, but all of us wannabes could really ruin our guitars that way :-D.
Of course, Lars would hate it.
You might be able to let people watch a performance where all the musicians are sync'd by the "performance coordinator," but if you're piping the sound of a drummer in Montreal to a bass player in LA and a guitarist in Geneva, the noises those two make will NOT be in sync with each other, let alone the keyboardist in Hong Kong. As a collaborative tool for live performances, this ain't gonna work - for studio work, it sounds great, though. One question - is a week of this kind of bandwidth and technology any cheaper than just putting the performers on a 747 and flying them to Mussel Shoals?
Much as I hate to say it, COM is doing good things for the Windoze development community. I know of programs constructed out of COM/DCOM components, with some smart glue and logic making them do interesting things. Can we do the same in the [Li/U]nix community? I don't see it, yet... and I don't think the underlying technology lends itself to that purpose well (well, neither does M$'s, IMHO, but they can throw 100 programmers at it for a year and make it work - the Get A Bigger Hammer school of software architecture).
OOP is hot, COP (component-oriented programming) is getting hot, and OOA/COA (the A is for Architecture) is starting to emit steam heat... so who's going to design an operating system for Intel systems on these principles?
One of the things that bugs me about all this is the principle of critical mass. Linux got a lot of its critical mass from (1) being based on Unix (2) being taught in colleges (3) being free. Windoze got its critical mass through corporate purchasing departments and sharp (sometimes shark-like) marketing and business tactics. Are the Linux devotees willing to listen and try a new OO-OS concept?
Hmmm... sounds like something someone should be doing in a grad school, somewhere....
Apple already had a core base of devoted followers - Jobs sold them so hard on the Mac he couldn't resell them on his new toy. If only someone would come up with this cool, innovative, NEW technology on the platform that the vast majority of us are using... any takers?
NT's lineage includes an incredible amount of influence from DEC VMS, sort-of-crossbred with the Mach kernel, but made to work with the DOS/Win3.1 legacy. Is there any wonder that the code's bloated? (like a whale carcass on a desert beach).
I can forsee a whole lot of wasted space as folks start defining multi-meg partitions. I'm pretty sure my BIOS won't understand it, either (but I'm sure there's a nice CDROM with the drive package that'll take care of that for me).
Wonder when the software folks (OSs, DBs) are going to start building products that will be able to use the hardware of their futures, and not their pasts?
Thanks for the quick history of the GNU/Open Source disconnect. I missed that schism as it happened, so I was inferring things from context about ESR and RMS and the other players. I may not agree with 'em - but I respect the work they've done.