IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 1 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New off the cuff without reading the article
"To solve the crisis, we must adopt a synchronous, signal-based software model. " event driven rules based architecture is as fine as the developer of it. This is assembler at the signal layer.
thanx,
bill
Any opinions expressed by me are mine alone, posted from my home computer, on my own time as a free american and do not reflect the opinions of any person or company that I have had professional relations with in the past 50 years. meep
New Same as it ever was
... as fine as the developer of it ...
"Man, that method has been used to produce some utter cack. But if you look here at my preferred method -- oh, and I'm really good at it -- you'll see how much better the output is."

Yes, there are some methods and languages that are more powerful than others. Yes, there are some that are less error-prone than others, saving you from common mistakes. But I still think the quality of the programmer is orders of magnitude more important than the particular language or process you're using.

There are exceptions, of course. [link|http://www.fastcompany.com/online/06/writestuff.html|The way NASA does things], they simply can't accept errors in flight controls for human flight. They spend whatever time and money they need to get it right. They've got a process that wouldn't allow a loose cannon to damage things.
===

Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
New He doesn't mention language at all
he mentions conceptual models as basis for design.

The point he tries to make is modeling complex systems algorithmically produces rotten systems. Modeling them as devices with componenets with signal flows produces better results.




[link|http://www.blackbagops.net|Black Bag Operations Log]

[link|http://www.objectiveclips.com|Artificial Intelligence]

[link|http://www.badpage.info/seaside/html|Scrutinizer]
Expand Edited by tuberculosis Aug. 21, 2007, 05:57:51 AM EDT
New Everything always looks better from the outside
as far as I can tell, Louis Savain is a Software Engineer. If he were a hardware engineer, he might feel differently.

Just to put it briefly, chips have bugs too. They often don't perform to spec. They are often late. And they're a lot harder to rev than software. Just like at Intel.

Maybe we should all program in Verilog.

--Tony
Who sometime really does want to get one of [link|http://www.actel.com/products/tools/demoboards/Fusionstarterkit.aspx|these cool toys] and learn to program in Verilog
New Hardware design is getting to look a lot like...
...Software design these days. Indeed, the PL of choice for a lot of hardware design is C++.

Also, hardware design is very much based on math - though it tends to be either discrete mathematics of the binary logic kind (using matrix algebra for the more more complex variations), or integration of the calculus kind for analog signals.
New I was replying to Bill's comment, not really to the article
The skill of the programmer has always been orders of magnitude more important than the advantages of the language or programming philosophy. For instance, I happen to think OO offers benefits over pure procedural. I also think it's a better fit to the way I think. How much of the perceived superiority is due to that, I can't say. What I can say for sure is that there are people who do strictly procedural who produce far better results than I ever would with OO. That was my point.



Now that I've read (most of) the article, I do have a comment on that. What is he smoking?
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... As mentioned previously, in a synchronous software system, no new algorithmic code is ever allowed.
I could agree with everything else he said -- which I don't -- and he'd still lose me here. The only "everyday users" who could build reliable systems are the ones who already could be good programmers, if they chose to learn a programming language.

Is it possible that a system could be created with components that allowed these not-so-everyday users to build new business tools? Possibly. But it would never replace general-purpose programming. If there is no code, what are the pieces made of that users are going to snap together?

[edit]

Just read some more of it. He took another hit:
The use of snap-together components (click, drag and drop) will automate a huge part of the development process while preventing and eliminating all sorts of problems associated with incompatible components. In addition, development environments will contain debugging tools that will find, correct and prevent all the internal design bugs automatically. A signal-based, synchronous environment will facilitate safe, automated software development and will open up computer programming to the lay public.
That's a grand set of assertions. I'll believe it when I see it.
===

Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
Expand Edited by drewk June 13, 2006, 12:11:20 PM EDT
New I know where he is going with that
MS Access is a "poor" example
Years ago TI had a product called "circus?" that was similar to his description, a bidness type would drag and drop what goes where and a developer would ensure the glue worked. A program called dapple is trying to do the same thing
[link|http://dabbledb.com/|http://dabbledb.com/]
thanx,
bill
Any opinions expressed by me are mine alone, posted from my home computer, on my own time as a free american and do not reflect the opinions of any person or company that I have had professional relations with in the past 50 years. meep
New I know the authors of dabbledb
Its written in Squeak/Seaside.

As for snap-together stuff - check out [link|http://squeakland.org|http://squeakland.org].

More can be done, but it should be possible to build "software schematics" that simply behave according to some rules.



[link|http://www.blackbagops.net|Black Bag Operations Log]

[link|http://www.objectiveclips.com|Artificial Intelligence]

[link|http://www.badpage.info/seaside/html|Scrutinizer]
Expand Edited by tuberculosis Aug. 21, 2007, 05:58:23 AM EDT
New Note that the h/w folks Savain loves don't love schematics
Verilog, VHDL, and stuff like SystemC are where it's for chip design. Text does have some real advantages for designing systems.

If you like graphical, the only truly successful example I can think of is [link|http://www.ni.com/labview/|this dataflow language]. Maybe you could add its [link|http://www.home.agilent.com/USeng/nav/pd.html?CT=PRODUCT&ID=588957&cmpid=95203|competitor] and [link|http://www.measurementcomputing.com/cbicatalog/cbiproduct.asp?dept%5Fid=333&pf%5Fid=1357|former competitor]

The analogy to hardware design (electrical and mechanical) doesn't work well, either. I don't see secretaries designing circuit boards. And, despite part libraries of [link|http://www.misumi-europe.com/|over 500000 parts] I don't see secretaries designing mechanical machines either. It still takes a lot of skill, and a lot of custom mechanical parts to glue everything together -- I see it happen every day.

--Tony
New Does noone use circuit simulators?



[link|http://www.blackbagops.net|Black Bag Operations Log]

[link|http://www.objectiveclips.com|Artificial Intelligence]

[link|http://www.badpage.info/seaside/html|Scrutinizer]
Expand Edited by tuberculosis Aug. 21, 2007, 05:58:45 AM EDT
New Circuit simulators are no silver bullet, esp for Analog
New 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
New 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.
New 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
New 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.
New 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
New The problem with user-built programs
After seeing what users did with the likes of Lotus-123 macros and Excel, I see something in common:

A. They are horribly factored, repeating concepts over and over.

B. They have no feel for long-term maintenence and likely change paths, making it very fragile.

Getting a program to run is only 1/3 of the battle. If it is of any use you want it maintainable. I was generally impressed with that they did with such tools, but I would rather lick the restroom floor than maintain those contraptions.
________________
oop.ismad.com
New you expect anything different?
A) WTF does factored mean?

B) Maintainability? See A!

Typical users aren't programmers and don't give a flying patootie about factoring, maintainability or fragility. And rightly so. The financial analyst getting that report to the CFOs office in 1/2 and hour had damn well better know finance - and enough about the tools they use to get the job done. If it needs to be better than that, then it needs to get properly built and the company needs to step up to the plate and make that investment.
--
Steve
[link|http://www.ubuntulinux.org|Ubuntu]
     Interesting Article on Software Engineering - (tuberculosis) - (48)
         off the cuff without reading the article - (boxley) - (17)
             Same as it ever was - (drewk) - (16)
                 He doesn't mention language at all - (tuberculosis) - (15)
                     Everything always looks better from the outside - (tonytib) - (1)
                         Hardware design is getting to look a lot like... - (ChrisR)
                     I was replying to Bill's comment, not really to the article - (drewk) - (12)
                         I know where he is going with that - (boxley) - (4)
                             I know the authors of dabbledb - (tuberculosis) - (3)
                                 Note that the h/w folks Savain loves don't love schematics - (tonytib) - (2)
                                     Does noone use circuit simulators? -NT - (tuberculosis) - (1)
                                         Circuit simulators are no silver bullet, esp for Analog -NT - (tonytib)
                         And another thing... - (jb4) - (4)
                             He's talking about the "90%" of programming. - (Another Scott) - (3)
                                 I'm considerably more skeptical about components - (tonytib) - (2)
                                     Well said. - (Another Scott) - (1)
                                         Well, we've already got 10^10 components... - (jb4)
                         The problem with user-built programs - (tablizer) - (1)
                             you expect anything different? - (Steve Lowe)
         The article is BS - (ben_tilly) - (28)
             I don't agree - (tuberculosis) - (26)
                 Er, what? It's 2006, dude. - (admin) - (12)
                     C++ was never about components - (tuberculosis) - (11)
                         ? in 97 useta write module compile in Borland - (boxley)
                         1994, actually. - (admin) - (9)
                             That's a side issue - (tuberculosis) - (8)
                                 Define "a few years" - (admin) - (7)
                                     No - (tuberculosis) - (6)
                                         Hey, YOU'RE the one who made the stupid assertion. - (admin)
                                         I guess... - (pwhysall) - (4)
                                             wrongly - (tuberculosis) - (3)
                                                 Don't leave. - (Another Scott)
                                                 Oh stop. - (bionerd)
                                                 Wind your neck in. - (pwhysall)
                 Just for the record: - (jb4)
                 I wish components worked like that everywhere - (ben_tilly) - (11)
                     What do you mean, traditionally? - (admin) - (10)
                         I mean what they mean in their documentation - (ben_tilly) - (9)
                             That's character set, not numeric. - (admin) - (8)
                                 So we were talking past each other -NT - (ben_tilly) - (7)
                                     The example you gave was of numeric sort not working. - (admin) - (2)
                                         No, it was not of *numeric* sort not working - (ben_tilly) - (1)
                                             Nevermind me, I'm tired tonight. -NT - (admin)
                                     There's a lot of that going on -NT - (tuberculosis) - (3)
                                         No - (admin) - (2)
                                             Whatever - (tuberculosis) - (1)
                                                 Who says irony is dead? -NT - (admin)
             The problem with hardware is deeper - (tonytib)
         Good luck with that - (warmachine)

You... shall not... pass!
177 ms