USB microscopes for very small SMT

Yes, but I very much suspect that if the bulk of programmers (and hardware designers) weren't relatively "sloppy" it would actually slow down technological innovation -- if the guys who managed to fit, e.g., complete BASIC interpreters into 8kB were still running the show today, I very much doubt that you'd be able to buy 1TB hard drives for $99 and 16GB USB memory sticks for $19.99.

Software bloat doesn't bother me nearly as much as the fall in software quality (from the bug-free perspective)...

That depends on the particular Doctor primarily, the time they bill and the time they spend with a client has not been remotely correlated for decades. If they cannot figure this one out their income level will be about that of an salaried engineer.

Often it does boil down to this. In my line of work I often talk with cardiologists and one told me that his gross income was well north of $200k. But liability insurance costs him >$100k/year. And that's exactly one of the two main problems with our health "system": Ambulance chasers.

Thing is, then we wouldn't need 1TB hard drives. And downloading thousands of MP3 songs is something our society could live without. I never downloaded one song and I am still alive.

Even if the programmers exhibited the same level of diligence today as they did in the 80's, a code that is bloated 100-1000 times in size is bound to have a huge increase in the number of bugs.

Music is the newest narcotic.

John

Maybe I missed out on a lot in life. Never did drugs so I don't know how a narcotic feels ;-)

But I do need my daily dose of Country/Bluegrass/Americana in the evenings. Always did.

On a sunny day (Thu, 4 Dec 2008 09:19:50 -0800) it happened "Joel Koltner" wrote in :

Yes, much increase in size comes from using libraries. Sometimes where there is no need for one at all. Examples is Qt4 in Linux, it is huge, while for many if not most applications you could use for example xforms, that is very very small (I use nothing else). And other big joke is if people start using SDL for every application that has audio and or video. But the advantage of the libraries is that they are so often used that they are pretty much bug free. And they *can* add very powerful features. So indeed the increase of bugs may not be that big. If I was to code a formatted print in asm, or use C and libc with printf(), then clearly the last method is what gives least bugs (and development time).

It is the same with hardware I suppose, I re-use circuits I have designed and tested in the past. that saves time and increases reliability, although perhaps in some cases you could, if you started from scratch, save a transistor.... In fact all integrated circuits are like software libraries, you may not use all their features, but they provide instants solutions. I do still remember designing my own video ADC in the seventies.. It is only because of the ever smaller transistor sizes that it has not become 'hardware bloat'.

nothing else).

audio

are pretty much bug free.

tested in the past.

'hardware bloat'.

IMHO one of the more sorry examples is TLAVu for Tektronix logic analyzers. Using it right now. Slow as a tortoise, file sizes >3MB, panning on a dual-core with 2GB of RAM takes several seconds, plus the occasional crash. Man, the output of my old Dolch in a DOS window could run circles around that.

That's when you whip out your cell phone to call AAA.

:-)

Point taken, though. Map reading is an easy-to-learn skill that everyone should know -- I recall a few days of it back in 7th grade, alhough by that time I already knew how to do it from helping my parents "navigate" on road trips. Technological advancement continuously causes school curriculums to be revised, and time spent teaching kids how to publish a Blog means that they're not going to learn something else (grammar? :-) ), and figuring out which "old school" items to keep and which to toss is not at all an easy question.

(But map reading should definitely be kept...)

I can see never having purchased a new opener and thus never having an instruction manual to read that mentions it, but I'm always amazed that people don't wonder, "Why is that little rope hanging down from the track up there?" and start asking around in the first place.

Yep, nothing replaces being wary of any new route. James Kim found that out the hard way, unfortunately.

The main problem there is that people are used to working with PCs where, even if they don't bother de-allocating memory, it usually just gets turned into virtual memory or otherwise is never exhausted so they're never forced to become detail-oriented and start paying attention to all the memory their application is using. You place those people into an embedded programming environment and they suddenly face a lot of problems when their mallocs() start failing left and right...

That being said, a good argument can be made that for a very large amount of software out there, there's no good reason programmers should have to manually allocate and free memory anyway -- since doing so correctly does require a slightly more skilled programming than average. Hence the popularity of languages such as Java and C# where -- while it's still possible to create memory leaks -- it's definitely harder than in straight C.

---Joel

I think the sad thing is that there's a good chance the programmers of that software are *skilled* enough that it could be fast, use smaller files, and crash-free... but management has decided that those outcomes are not worth pursuing.

This often happens when the managers don't have enough of a technical background to *know* that what their charges are producing is sub-par.

Maybe you'd like to move back into technical management in another decade rather than retiring, Joerg? :-)

I've never used xforms, but I did use Tcl/Tk once for a test utility, and -- while it now looks a bit dated -- I was quite impressed with how flexible and reasonably easy to use Tk was for the size of the library.

Not sure about that. A decent programmer would quit should this happen a lot. I would. I cannot and could never bring myself to designing sub-par product.

It happens when they fail to talk to the group of people they should communicate with the most: Customers.

Actually I enjoyed those phases. Had to do it twice so far, the second time with full P&L responsibility and such. I would not mind doing it again, maybe some kind of "salvage case". I do get asked at times but the problem with self-employed folks like myself is that I cannot simply pack up and move. Can't alienate clients. More and more seem to depend on outside skills for analog these days because they either can't find any or don't want to have it in house. That was a huge problem last time I took over the helm somewhere. For one company I was the only "go to" guy when it came to analog and discrete stuff. Now it's 3-4 companies out of roughly a dozen.

Agreed. I think what happens in "the real world" is that you have many programmers who honestly believe that "good enough" is "whatever management says it is." When you and I say "decent programmer" we're thinking of people passionate about what they do: People who take it on themselves to figure out how, in relation to their competitors and historical offerings, their product performs, and strive to make sure what they're doing is near the top of the pack.

But passionate people -- in any industry -- are the exception. At least in any reasonably "mature" industry, which software and hardware development now are...

Cool... I'm sure you'll continue to have many offers if you decide to move out of active circuit development/troubleshooting one day. :-)

---Joel

On a sunny day (Thu, 4 Dec 2008 11:10:20 -0800) it happened "Joel Koltner" wrote in :

Do not want to sound like a commercial for xforms, but maybe I do. The size of libforms is l /usr/X11R6/lib/libforms.so.1.0

-rwxr-xr-x 1 root root 1580536 2008-02-04 14:42 /usr/X11R6/lib/libforms.so.1.0* so, say 1.6 MB

Here are some screen shots of simple applications I wrote: ftp://panteltje.com/pub/xdipo2.jpg

One thing that is cool, is that it has a GUI generator that outputs C code, all you have to do is place the various items on the form by drag and drop, and it will write all GUI code for you. It has various graphics, interactive plots, etc.. Been using it now for 10 years or so. You can write the code manually too, that is what I usually do. Even this news reader is written using xforms: ftp://panteltje.com/pub/NewsFleX.gif

It was fast on a 486, on modern machines it is instantaneous. You can find it here, there is also a demo directory in the tar.gz.

On a sunny day (Thu, 04 Dec 2008 20:41:34 GMT) it happened Jan Panteltje wrote in :

Forgot the link:

Thanks Jan, I'll take a closer look at xforms.

It does also have that "somewhat dated" look to it, but of course that doesn't matter in many cases.

Wow, documentation only in straight PostScript! Good thing I have a full version of Acrobat to turn it into a PDF? :-)

On a sunny day (Thu, 4 Dec 2008 13:38:23 -0800) it happened "Joel Koltner" wrote in :

I have the docs in html, here: ftp://panteltje.com/pub/xforms/forms.html you can download the whole directory. usually I use grep and even lynx (the text browser) to find something...

On a sunny day (Thu, 4 Dec 2008 13:26:12 -0800) it happened "Joel Koltner" wrote in :

I find one of its strength from a programming POV is the function 'idle_cb()'. I put a lot of stuff in there that needs continuous executing. From with that you can dynamically manipulate all the widgets, without having to start separate threads. For example in xdipo the DVB frontend is polled from idle_cb(), and the pie chart for signal to noise updated at the spot, causing the GUI to come alive.