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

Welcome to IWETHEY!

New Interesting Article on Software Engineering
[link|http://www.rebelscience.org/Cosas/Reliability.htm|http://www.rebelscie...s/Reliability.htm]

...we must acknowledge that there is something rotten at the core of software engineering. We must understand that using the algorithm as the basis of computer programming is the last of the stumbling blocks that are preventing us from achieving an effective and safe componentization of software comparable to what has been done in hardware. It is the reason that current quality control measures will always fail in the end. To solve the crisis, we must adopt a synchronous, signal-based software model. Only then will our software programs be guaranteed free of defects, irrespective of their complexity.
----------
I (and most of the Smalltalk community probably) tend to agree with him.

Simulation is much more interesting than algorithms.



[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:08 AM EDT
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]
New The article is BS
I wrote a long essay explaining why, and then Sam got my computer to turn off so I lost it.

The long and short of it is that CPUs are more reliable than software for many reasons, including the following:

  1. The problem is very well-defined. That makes it easier to specify.
  2. CPU design is done by people who have solved this kind of problem many times. Software written by teams that have written the same kind of software several times is also more reliable.
  3. CPUs are designed on a 5 year schedule. Most of the time is devoted to finding and fixing bugs. If up front quality assurance was given that importance in software development, our quality would be higher as well.
  4. Even so CPUs come out with long errata lists. Compiler authors look at these errata lists and work around the remaining bugs in software. The average programmer is free to be blissfully unaware of this.
  5. Very importantly, Intel is liable for bad CPU bugs. Microsoft is not liable for software bugs. This helps keep Intel's priorities right.
  6. People care more about CPU bugs, even trivial ones. For instance how many of us know about the Pentium floating point bug? That despite the fact that it affected virtually nobody. While we're all aware of tons of Microsoft bugs, how many of them have been given widely recognized names?

The fact that the author doesn't want to accept is that people have known failure rates. We make very predictable kinds of errors at predictable rates in everything we do. This is true from spelling mistakes in essays to flipping the wrong switch in a power plant. Of the kinds of errors that we make, one of the more common categories in software development is logic errors. This is also the hardest category for the author to spot, and the psychological reasons for this are very well known.

Furthermore anyone who thinks that you can eliminate bugs by pushing software development to end users is an idiot. Take your pick, either completely ignorant and an idiot for talking on something they know nothing about, or else not ignorant and therefore an idiot for not noticing the obvious.

The technology itself might be a better fit for some kinds of problems. But it isn't a silver bullet.

Cheers,
Ben
The great masses of people ... will more easily fall victims to a big lie than to a small one. -- Adolf Hitler
New I don't agree
But I think it has to do with perspective.

Consider that I've been mostly working in Smalltalk lately. The Smalltalk class library has classes (and some objects!) that are over 25 years old. These classes are pretty much bullet proof and haven't changed in years.


The problem is very well-defined. That makes it easier to specify.

This should also be true at the component level. Like the Smalltalk collections and numerics classes. Also some classes that represent network protocols.

CPU design is done by people who have solved this kind of problem many times. Software written by teams that have written the same kind of software several times is also more reliable.

Like the Smalltalk collection and numerics classes.

CPUs are designed on a 5 year schedule. Most of the time is devoted to finding and fixing bugs. If up front quality assurance was given that importance in software development, our quality would be higher as well.

Languages/programming environments have about a 10+ year developmental life span. If you language is younger than that, its immature. Java, C++, Python, Ruby are all immature technologies. The class libraries may be frozen - but are not quite "right" so people continue to work around their shortcomings until it becomes intolerable and then they abandon them for something else.

The problem as I see it is the lack of stick-to-it-iveness in language users. Only LISP and Smalltalk have been continually improved for a long enough period of time to have reached the level of maturity of hardware (at some levels - other levels are less mature).

The only thing preventing this vision is Gilligan's Island syndrome and lack of maturity of developers.



[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, 06:01:56 AM EDT
New Er, what? It's 2006, dude.
  • Java 1.0 was released about 10.5 years ago.
  • C++ was started in 1979 and actually became C++ in 1983 (gee, that's 23 years. Whippersnapper!)
  • Python was started in the late 1980s and started seeing wider usage in the early 1990s.
  • Ruby was first released to the public in 1995.
So by your own argument, none of these languages (except possibly Java, right on the cusp) are "immature".

The problem is that your argument is simplistic and specious. Age counts for nothing if nothing happened in the intervening years. It also counts for a lot less if a particular language was intensely developed during that time.

Design counts for a lot more than age.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New C++ was never about components
It got reusable-ish components (STL) around 1997 and still hardly anything could compile them until 1999 or so.

Java remains immature because they hack stuff, ship it, and never reexamine it. So we keep working around the old bugs. Plus, it doesn't quite work, so they keep changing it don't they. Java 5 isn't a whole lot like Java 2 - lots of huge mods to it.

So I agree that design counts a lot - but being willing to continue hammering on the design and break old shit because its based on something that is wrong is key.

They'll never fix Java - just abandon it.



[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, 06:02:27 AM EDT
New ? in 97 useta write module compile in Borland
and (fergit the tool) compile samme module for for mac. Shop I worked at did, not me personally.Rational Rose had something to do with it?
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 1994, actually.
Original point still stands. You can't stereotype maturity based on age.

I'd hardly call STL necessary for components, anyway. You can do components without generic programming. The utility may be lessened, but it's still possible.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New That's a side issue
Point remains that we never bother to make stuff mature - we just abandon it for the next shiny thing every few years.

So no wonder its hard to get to components based software construction.




[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, 06:02:49 AM EDT
New Define "a few years"
First you said 10. As I pointed out, by that definition every one you listed was "mature". C++ has been around nearly as long as Smalltalk-80. Length of time has nothing to do with components.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New No
I haven't bothered to chart it out - I pulled "10" from my ass. Deal with it.

But the point (which you are working really hard to miss) is that software is inherently fashion oriented. we don't stick with stuff to perfect it, we abandon it after awhile.

C++ golden age was 1992-6. Java was 1997-2004. I see Java dying already (and I abandoned it a long time ago). XML was a little craze in there somewhere. etc.



[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, 06:04:25 AM EDT
New Hey, YOU'RE the one who made the stupid assertion.
Deal with it.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New I guess...
...the FORTRAN-77 that we maintain that was written on PDP-11s running RSX/11 just ain't hip enough for you.

People can and do (and, indeed, mostly do) write software that keeps the world turning in things other than SmallTALK.

I'd bet a pint that more C++ and Java is written every month than all the SMalLTaLK code in all the world.

But hey, they're dying.

You're a very clever man who says very silly things sometimes, Todd.


Peter
[link|http://www.no2id.net/|Don't Let The Terrorists Win]
[link|http://www.kuro5hin.org|There is no K5 Cabal]
[link|http://guildenstern.dyndns.org|Home]
Use P2P for legitimate purposes!
[link|http://kevan.org/brain.cgi?pwhysall|A better terminal emulator]
New wrongly
I used to work in F/77. For certain domains it is the right tool for the job. There are some wonderfully mature math libs written in it. Great stuff. Libraries - you know - components - tested, mature, solid, verified.

And yet - some years ago - Raytheon's Satellite management division ported all of their nice stable bullet proof tested F/77 libs to C++. Because that's the new thing don'tcha know. Never mind that you can just LINK to and CALL F/77 from C/C++. A useful property we used to have pre-C++ was library interoperability. Of course, that went the way of dodo with name mangling. The C++ versions run more slowly too.

Which really goes to prove my point on the fashion thing. When asked to select the right tool for a given job, 99.9999% of programmers will answer Mooooooo as their herd instinct kicks in.

I figured I'd point out the point given that point spotting has achieved Mr Magoo levels on this board. Thanks for the absolutely uninspiring exchanges all, I won't trouble you again.



[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, 06:05:49 AM EDT
New Don't leave.
Even when I don't agree with you, I usually enjoy your contributions.

Don't let the barbs get to you. This place would be very much less interesting if it was a mutual admiration society. Feel free to give as good as you get. :-)

Come back when you can.

Cheers,
Scott.
New Oh stop.
I dont have a clue what you guys are talking about with all this programming gibberish (it all sounds like blah blah blah to me) but I do know you're brillant, have strong opinions, and are very passionate and very good at what you do. Pull your nose back in joint. This place needs you around. And when I say this place, I of course, mean me. Dont bail, Todd.
Follow your MOUSE
New Wind your neck in.
You're being an oversensitive prima donna and all because some people dare to disagree with you.


Peter
[link|http://www.no2id.net/|Don't Let The Terrorists Win]
[link|http://www.kuro5hin.org|There is no K5 Cabal]
[link|http://guildenstern.dyndns.org|Home]
Use P2P for legitimate purposes!
[link|http://kevan.org/brain.cgi?pwhysall|A better terminal emulator]
New Just for the record:
The ANSI/ISO standard for C++ was ratified in 1995. It was in draft form since '91, and the so-called final draft was around for about two years (mostly awaiting Denmark's approval IIRC). It is now 2006. That's more than 10 years (as your Smalltalk numerics library will surely tell you), which makes it a "mature" technology by your own definition of the term.

HTH
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 I wish components worked like that everywhere
For instance according to GNU sort, the following list is sorted:
\n17402004,2006-02-12 20:16:48\n1740,2005-01-15 13:35:56\n17402006,2005-04-08 08:09:48\n

It didn't TRADITIONALLY do that. What happened?

The component changed.

(My not being aware of this caused a bug for me about 2 weeks ago.)

Cheers,
Ben
The great masses of people ... will more easily fall victims to a big lie than to a small one. -- Adolf Hitler
New What do you mean, traditionally?
GNU sort has worked like that for as long as I've been using it. Now Solaris sort, however, doesn't need the -n.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New I mean what they mean in their documentation
From "info sort"

*** WARNING *** The locale specified by the environment affects sort
order. Set LC_ALL=C to get the traditional sort order that uses native
byte values.

Cheers,
Ben
The great masses of people ... will more easily fall victims to a big lie than to a small one. -- Adolf Hitler
New That's character set, not numeric.
Two very different things.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New So we were talking past each other
The great masses of people ... will more easily fall victims to a big lie than to a small one. -- Adolf Hitler
New The example you gave was of numeric sort not working.
How is that related to character set?
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New No, it was not of *numeric* sort not working
It was an example of the alphabetical sort doing something that I had not expected. Since I didn't expect the behaviour, it lead to a bug.

Cheers,
Ben
The great masses of people ... will more easily fall victims to a big lie than to a small one. -- Adolf Hitler
New Nevermind me, I'm tired tonight.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New There's a lot of that going on



[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, 06:04:27 AM EDT
New No
I know what point you're trying to make. My point is that you picked an asinine way of making it. Stupid generalizations (that aren't even remotely accurate) only hurt your argument.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New Whatever
Thanks for making me sorry I posted.

Dickhead.

Poof



[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, 06:04:47 AM EDT
New Who says irony is dead?
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New The problem with hardware is deeper
No disagreement with what you point out. But hardware design with chips isn't the easy process the author thinks.

The author seems to think that IC's are a black boxes. You can slap them down on a PCB, hook them together, and get a working system - just like his software system (drop and connect components together). And, it should be possible to swap IC brands.

First, it's not that simple to connect design a PCB, especially at high speeds. How you route the signals can make a big impact on how well your design works. You have to add all kinds of little things that aren't obvious to software guys, like decoupling capacitors to maintain signal integrity. Designs often require rework to pass FCC/CE emission and susceptibility tests. Heck, designers often don't consider RFI concerns until the certification tests and then scramble to make bandage fixes - doesn't that sound a lot like common software developer attitudes towards testing and security?

Second, yes, with digital chips, it's typically possible swap manufacturers. But sometimes even then there can be trouble. But analog chips from different manufacturers, even with the same paper specs, often don't act the same and require design changes.

Third, sometimes chips don't live up to their specs. To give one example, one otherwise good chip, the TI 320F2812, has a 12-bit ADC that's so noisy you'll get around 10 bits of info. So if you need 12-bits, you'll have to either add an external ADC or try to work around the problem by using filtering (which has its problems, such as additional CPU time required). That sounds a bit like a software component that doesn't do quite what was promised. (BTW, TI's later models have better ADC's - but aren't drop in replacements).

So, yes, software developers can learn from the hardware guys; for example, one thing the chip guys are good at is simulation and testing (of course, the cost of that - in time and money - would make software project managers freak out). But the hardware world isn't easy, either.

One last note - analog simulation is as good as the model, so it's often wrong, and can cause more problems than it solves. Digital simulation is better, but getting harder because at high frequencies everything is analog (e.g. PCB traces become antennas whether you like it or not).

--Tony
New Good luck with that
When I see the word 'signal based', I think of the message-passing, change notifying, object-oriented designs I write. Synchronous sounds nice but current computers are serial, Von Neumann machines. It can be emulated with multithreading and the Active Object design pattern but that's not quite the same. If that's near enough for the author, then he's advocating that I do what I'm already doing except I don't have a visual assembler of components and I use far fewer Active Objects on a serial computer.

Drag-and-drop, component oriented programming is somewhere near possible for desktop GUIs but don't expect reliability and performance from the end-users that fiddle with them. As for back-end servers, good luck finding much commonality.

The synchronous bit seems like a good idea and more hardware support is needed. A mini-CPU per object with its own, private area of main memory. As there will be more objects than mini-CPUs, barely used objects get dropped from the registers and replaced. Object swapping and locating will be fun and even funner with huge databases. Wonderful, parameter passing overhead as well, as opposed to the stacks of conventional programs. And don't forget this must be between all the objects in all programs as all processes are active.
Matthew Greet


Choose Life. Choose a job. Choose a career. Choose a family. Choose a fucking big television, choose washing machines, cars, compact disc players and electrical tin openers. Choose good health, low cholesterol, and dental insurance. Choose fixed interest mortgage repayments. Choose a starter home. Choose your friends. Choose leisurewear and matching luggage. Choose DIY and wondering who the fuck you are on a Sunday morning. Choose sitting on that couch watching mind-numbing, spirit-crushing game shows, stuffing fucking junk food into your mouth. Choose rotting away at the end of it all, pishing your last in a miserable home, nothing more than an embarrassment to the selfish, fucked up brats you spawned to replace yourself. Choose your future. Choose life... But why would I want to do a thing like that? I chose not to choose life. I chose somethin' else. And the reasons? There are no reasons. Who needs reasons when you've got heroin?
- Mark Renton, Trainspotting.
     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)

I'm picturing tablizer on a laptop dragging around a 486 whitebox running Linux attached to a really long extension cord.
377 ms