And another thing...

Post #258,794 by jb4 6/13/06 2:35:50 PM Reply	And another thing... ..if "libraries of pre-build components" are this guy's panacea-du-jour, where "no new algorithmic code is ever allowed", why is it that the hottest, most expansive area of hardware design, (from whence this guy appears to come) is the FPGA? Where hardware jockeys get to roll-their-own components by (wait for it...) programming the "hardware"? Seems to me that this guy's own discipline is straying from his "no new [...] code is ever allowed" mantra. YMMV jb4 "So don't pay attention to the approval ratings that say 68% of Americans disapprove of the job this man is doing. I ask you this, does that not also logically mean that 68% approve of the job he's not doing? Think about it. I haven't." — Stephen Colbert, at the White House Correspondent's Dinner 29Apr06
Post #258,796 by Another Scott 6/13/06 3:10:35 PM Reply	He's talking about the "90%" of programming. You know, the business programming stuff that used to be done with COBOL: The use of libraries of pre-built components will automate over 90% of the software development process and turn everyday users into software developers. These plug-compatible components should snap together automatically: just click, drag and drop. Thus the burden of assuring compatibility is the responsibility of the development system, not the programmer. But he's also talking about reliability: When it comes to safety-critical applications such as air traffic control or avionics software systems, even a single defect is not an option since it is potentially catastrophic. Unless we can guarantee that our programs are logically consistent and completely free of defects, the reliability problem will not go away. In other words, extremely reliable software is just not good enough. What we need is 100% reliable software. There is no getting around this fact. One doesn't need bullet-proof software running a calculator as one does with an air traffic control system. All software doesn't need the same level of reliability. But I think he makes several good points. If you want reliable general-purpose software, you need (reasonably) bullet-proof components and you need to assemble your software from those components. (E.g., you don't want your programmers reinventing FindFirst/FindNext.) Whether that means using a new/different approach to building the components or simply using better, more carefully debugged tools, I can't say. I don't think that all software should be expected to meet the same reliability requirements. We don't require treehouses to stand up to earthquakes.... Cheers, Scott.
Post #258,801 by tonytib 6/13/06 3:27:47 PM Reply	I'm considerably more skeptical about components It's hard to find a component that does exactly what you need - software, electrical, or mechanical. Normally quite a bit of extra stuff is required to get it do what you want. Current software component technologies like DLL's, ActiveX, COM, etc have their issues. Versioning can be really fun. Getting everything registered and working can be lots of fun. Commercial components are often a major pain in the butt - not just the cost, but the headaches installing it on development machines, license keys, etc. The component model limits what can be done - for example, I can develop much quicker using only dynamic language such as Python than to split everything into COM objects, just because COM does not support Python's advanced features. That's why I think the way forward is dynamic languages that can be used to bind together existing libraries and components quickly - and add the necessary logic on top - not "drop and connect" of existing components. BTW, the "component vision" was promoted by Sandstone (Objective C guys) in the mid 80's. It was a failure then. It might work if everyone agreed on one language, and one way to do everything. But that's not reality. (And, yes, the world might be a better place if Objective C was dominant instead of C++. But there still is no silver bullet.) --Tony
Post #258,803 by Another Scott 6/13/06 3:48:39 PM Reply	Well said. I'm no programmer, but I know this component stuff has been a Holy Grail for a long time. As you say, they only go so far, and interoperability of components is a big problem. Maybe in 10 years computers will be fast enough and storage will be cheap enough that a GNU library of 10^10 robust components that can be extended easily in a bullet-proof manner will exist, but I'm not betting on it either. Maybe such components would cover 50% of standard business programming by then, but they won't cover the "cool" and "interesting" stuff that people enjoy working on. So there will always be a need for new custom code that doesn't exist in some drag-and-drop framework. At that point, robust tools and processes need to come into play. Cheers, Scott.
Post #258,953 by jb4 6/14/06 5:03:56 PM Reply	Well, we've already got 10^10 components... Have you taken a look at .NyET's CLR recently? jb4 "So don't pay attention to the approval ratings that say 68% of Americans disapprove of the job this man is doing. I ask you this, does that not also logically mean that 68% approve of the job he's not doing? Think about it. I haven't." — Stephen Colbert, at the White House Correspondent's Dinner 29Apr06

Welcome to IWETHEY!