OT: Presbyopia, or "Old Guy Eyes"

Last escape from muslims?

Reply to
Vladimir Vassilevsky
Loading thread data ...

Retirement homes for politicians, of course. ;-)

--
Politicians should only get paid if the budget is balanced, and there is
enough left over to pay them.
Reply to
Michael A. Terrell

Strangely, I find myself agreeing with Gunner...

I'm old enough to remember the "English System", largely established to cope with WW2 veterans returning to society after long-term morphine use due to battlefield injuries, when specialist doctors would prescribe morphine and heroin as a long-term treatment to addicts rather than either force them onto the black market or (in a small number of cases) prescribe methadone and similar substitutes. There was a much smaller pool of opiate dependent drug users back then, and they went to the pharmacy and got their legal drugs once a week for the price of a few aspirin, got on with their (largely productive) lives, and bothered nobody, wheras we now see far more abuse of the opiate drugs, a flourishing criminal industry providing them, and far more crime associated with the drug users - it's estimated that the average heroin user in the UK goes through something more than £50,000 in stolen goods in order to supply their yearly dosage, compared to (if they had and paid for weekly prescriptions) around £350 in actual drug costs. This level of petty crime of course has a major effect on the quality of life of the general population, increases insurance costs and taxes to provide for their imprisonment (during which they're completely unproductive) and has many in the inner cities feeling that they are prisoners in their own homes.

One factor in the increased abuse of the opiates etc. has to be the current illegality of cannabis and MDMA, which pushes those who choose to use into the hands of criminals who stand to gain far more by selling the more addictive drugs (heroin, crack cocaine, meth etc.) with their higher profit margins and repeat business, a situation very similar to the US's experiment with Prohibition when the organised criminals found more profit in bathtub gin than beer and on the back of those profits rose to far greater power (and influence) than when they had no market to serve.

It seems to me that we could actually kill several birds with one stone here: Afghanistan has always been a major opium producer and if, rather than burning the poppy fields and telling them to grow low (financial) yield crops, we were to buy their opium at a fair price we could stabilise their economy and give the Taliban and other warlords a much-reduced influence on the hill farmers (traditionally opium producers) from whom they draw a great deal of their support; a stable supply of opium of a consistent quality for processing and medically-controlled supply to the west's addicts at affordable cost would reduce our own crime levels at home and cut off a lot of funding for crime syndicates and domestic terrorism which is often funded by the illegal drugs trade. There would also be an improvement in the rates of survival of addicts, as one of the main causes of death is the arrival on the market of unusually-pure (i.e 75% or so) heroin available to users who are typically supplied with adulterated drugs of very low (15 - 25%) purity and the consequent overdoses - unlikely to happen if controlled, consistent doses were available.

Just my ha'pence-worth,

Dave H.

--
(The engineer formerly known as Homeless)

"Rules are for the obedience of fools, and the guidance of wise men" -
Douglas Bader
Reply to
Dave H.

Sure, potted opamp modules.

And before that...

ftp://jjlarkin.lmi.net/Philbricks.jpg

Software could come in modules. Each module could run on its own processor in a multi-core machine. Need an FFT, or a database, or a PID controller? Plug it in. It would be, vaguely, a Labview sort of thing, but executed by known-reliable quasi-hardware modules that don't share any code space with anything else.

That's not The Answer of course, but there will eventually be a better way to program than the nightmare we have now. The fix might even be cultural rather than technical: teach C programmers how to write solid code and how to design rational higher-level structures.

John

Reply to
John Larkin

Prisons with no guards required ;-) ...Jim Thompson

-- | James E.Thompson, CTO | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona 85048 Skype: Contacts Only | | | Voice:(480)460-2350 Fax: Available upon request | Brass Rat | | E-mail Icon at

formatting link
| 1962 |

I can see November from my house :-)

Reply to
Jim Thompson

The cure? Do you know of a drug treatment therapy that works?

I personally know of a couple of addicts, kids of wealthy parents, who have been "cured" multiple times and will most likely kill themselves with cocktails of illegal drugs. They have pretty much destroyed their veins, noses, brains, and lives already.

And even "better" designer drugs are on the way. Things that feel so good, and are so addictive, practically nobody can resist, or quit.

I doubt that.

John

Reply to
John Larkin

Maybe even better: don't use C :-)

But I think the solution to avoid writing millions of lines of code for each new bigger project is code reuse. One reason for the success of Visual Basic was the very large collection of easy to use third party components, which works (most of the time) nicely together, e.g. a database and a report generator, so the application developer has not to reinvent the wheel for standard functions.

The same works for FPGAs and ASICs: there are many IPs for free or which you can buy and even integrated SoC builders, and you need to write only the non-standard parts of your application.

So it's not that bad, but could be better, e.g. for software a platform independant component concept, or for FPGA IPs one standard bus, instead of the multiple choices you have today, like AMBA AHB, Wishbone and Avalon. But today it is much better than e.g. 10 years ago and I hope it will evolve in future to even better concepts.

--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss
Reply to
Frank Buss

On a sunny day (Sun, 10 Oct 2010 19:46:09 +0200) it happened Frank Buss wrote in :

Larkong has been anti-C all the time. He does now understand or trust libraries (C) either. His unvisual BASIC has no such thing, and is the only language he can express himself in.

Visual BA-SIC is something that is only created so they can sell expensive books about it. I once bought VB ,, and I have a book on the shelf about it called Visual BA-SIC

6.0 that I should really burn if it really gets cold in the winter. I dunno what happened to the VB disk though, I never managed to create a useful program with it. IIRC it even ran on windhose. hehe
Reply to
Jan Panteltje

"Jim Thompson" wrote in message news: snipped-for-privacy@4ax.com...

Isn't that what he said?

tm

Reply to
tm

That was trued already. Windows way, hehe. A zillion of incompatible components with bazillion of versions with just enough of difference to be incompatible, with a kazillion of standards. In order to make your module compatible with A, you have to be a member of the association of XYZ. A module A needs a module B to operate, but module B is incompatible with the latest revision of module C.

I was a proponent of modular approach before I realized that been modular implies significant overhead. There are only so many hw/sw applications were modularity is justified.

Just allocate about x3 of time and money for the projects; and you will be amazed how much better the quality could be :-)

If all people would be good, smart, kind to each other, creative and honest, beautiful, healthy, the place would be called Heavens.

VLV

Reply to
Vladimir Vassilevsky

Space tourism for the idle rich who actually _want_ to go there, and are willing to pay millions of their own dollars to get there.

Like I've said, I understand your position. Tax money shouldn't be used on expeditions that don't accomplish very much but show that at micro-G, muscles atrophy.

But playing at zero-G looks like a helluva lot of fun! And for short periods of zero-G, there's always the Vomit Comet. ;-)

But if someone is willing to spend their own money on such a foolish endeavour[SIC], I wouldn't want to use government force to block them.

Cheers! Rich

Reply to
Rich Grise

I'm just anti buggy code. Most code is buggy, and most is written in C.

Some libraries can be trusted, mostly because they have been thoroughly tested (ie, debugged by many, many victims)

himself in.

I've programmed in lots of languages: Fortran, Focal, C, maybe 8 flavors of Basic, and maybe a dozen different assemblers, including one for a CPU that I designed. And I wrote compilers for several n/c machining controllers, which might or might not be considered programming languages. Dozens of microengine and pseudo-machine things, too, which all involved inventing the architecture and instruction set and typically hacking some sort of script assembler.

Macro-11 was cool. Its macro facility was so geberal that you could write cross assemblers for different machines, all as macros. Cross32 is nice, too, a general table-driven assembler.

I write pretty good code in any language because I'm careful, and print/read/review/debug/refine my programs before I ever run them. That sort of discipline is more important than what language is used. I don't like C and especially the culture of C because it discourages being careful. Most C programmers hack code quickly, flame test it, fix the more obvious bugs, and ship. Even then, most spend a lot more time debugging than coding. I spend very little time debugging, and usually ship products with zero bugs.

What's wrong with that?

John

Reply to
John Larkin

Yes, the DLL structure (to dignify it with that word) is a bizarre mess. Most are only documented by the uncommented source code itself... if they can still find it. Microsoft just writes bad code, and probably always will.

Overhead is ceasing to matter. The mindset of saving hardware resources is pretty much obsolete. We should focus on reliability. If wasting CPU cycles, or scores of entire CPUs, helps, we should do it.

No. What most people are doing now is inefficient and expensive.

Beats Hell.

John

Reply to
John Larkin

Modules are designed to be compatible and universal. A lot of effort is spent developing, testing and documenting the module interface for all possible cases. In 99% of occasions, this effort is wasted.

Everybody gets exactly what he paid for.

In the older days, the Heavens was called a Communist Society.

VLV

Reply to
Vladimir Vassilevsky

On a sunny day (Sun, 10 Oct 2010 11:23:29 -0700) it happened John Larkin wrote in :

First I must apologise, I think I had a moment of irritation. Nothing against your personal capabilities, I appreciate those. But I do not agree that you single out 'C' as the bad guy. Yes, much of the world's software is probably written in C, maybe even more in C++, if you count the Mircoflop environment, C++ is not C, but is a language disability, sort of pushed by the Ballmer clan. We all know what that has created, a big bloated lot of useless incompatible ever changing resource hungry buggy heap of crap.

I rely on libc (from gcc). I VERY strongly recommend you to read the Linux libc.info files: ftp://panteltje.com/pub/libc.info.txt Better documented and more reliable is hardly possible. That for a start gives you all the math, all the networking, and all the file operations you will ever need, pus many others, string operations, time operations, what not. But there are thousands of very good libraries, from libjpeg to almost anything you can imagine, and those are maybe not 100% bug free, but work good enough for normal use. Most of Linux has been written in C, and Linux (unlike windhose) has been used in satellites. It is hard to go up there and fix things, or even reboot, or upload a fix. It was found reliable enough for that purpose, and did its job.

himself in.

I do not get it, that is your idea, how many of those developers do you really know? The ones I know work very precise. More precise perhaps than me. There is a tradeoff in developing a program, sitting there in the evening in your bed with a printout with eyes falling because you are sleepy may have been the way to do it in the old days, but these days testing is on the computer with real code. Programs can be so complex these days that not everything can be tested, so bugs will stay there, sometimes for a long time. It is often better to release something that you can actually use, than to spend years trying to write the perfect code, as by then it will no longer be needed. For example I needed to measure temperature with thermocouples, NOW, so I wrote some code. Improved it, found the limitations, made a new version, and actually have a useful new tool. Thanks to Linux [scripting or calling it from a pipe in a program] it can be used as a building block. I am sure you can sit in the chair and think about it for years what is a better way, but what good is that. If an error is found fixing it takes a few minutes, less then releasing a new version.

Reply to
Jan Panteltje

ever changing resource hungry

operations

not.

you

normal use.

in satellites.

himself in.

know?

your bed with a printout

old days,

You can't find all the bugs by testing. Open source code finds most of the bugs by having thousands of people test and review the code. That's not practical for a niche or an embedded application.

Reading the code may be old-fashioned, and it's cretainly tedious, but it does find bugs that testing likely wouldn't.

bugs will stay there, sometimes for a long time.

If you take the Microsoft line, "all code has bugs", yours will.

spend years trying to write the perfect code,

It depends on how many people a bug might kill.

some code.

Which kind strangers, in this group (including myself), pointed out wasn't very right. Why didn't you read and check it yourself? Run some test cases? Zero degrees C should produce zero millivolts, for Pete's sake. That's a cardinal calibration point.

useful new tool.

But if you hadn't been made to fix it, and it went into a critical embedded system, things would not be good.

What if the temperature overshoots a little past one of the end points, where the polynomials go nuts and perhaps change slope? A closed-loop control system could run away.

used as a building block.

better way, but what good is that.

version.

It's harder to upgrade the firmware in an embedded system. And more embarassing, after you've blown up a refinery, or killed a few kids, or have to tell some people that their megabucks of jet engine test data is bad.

We just can't afford to ship bugs. We must read and check our code carefully.

formatting link

John

Reply to
John Larkin

Well stated.

Indeed.

Gunner

I am the Sword of my Family and the Shield of my Nation. If sent, I will crush everything you have built, burn everything you love, and kill every one of you. (Hebrew quote)

Reply to
Gunner Asch

On a sunny day (Sun, 10 Oct 2010 13:24:01 -0700) it happened John Larkin wrote in :

spend years trying to write the perfect code,

Yes it depends on the application.

wrote some code.

useful new tool.

I was not 'made' to fix it, and it was not even wrong, it just had a bigger tolerance. It was some test code, and a request for comments. I made the new code available for free under open source, something I do not see you do or have the guts to do, else I am sure your 'perfect code' would all of the sudden appear to not be so perfect. For example I claim my current version of thermocouple code is more accurate then yours. Prove me wrong. I bet you a box of chocolates of your choice, Now how is that for reality check? (I think this is better than playing the Lotto, I just stopped my automatic playing, now at least I have a good chance to win something).

You get an out of range message, the program will exit with error (exit 1).

Yes and a bird cannot swim under water. This was not for a closed loop system, although it will be used in that, but in that case no way can it go past the ranges, as the hardware is not capable of that. And even if it did it would cause an auto shutdown because of exit 1. You are deliberately putting up a strawman.

used as a building block.

better way, but what good is that.

version.

Yes,

You are over estimating yourself and just doing sales talk, your code is even buggier then the average Linux release. Show your code.

Yes, things happen, often also because of operator error, bad training of technicians etc. Anybody who claims 'perfectness' as you do is very suspicious in my view, as neural nets are not precise, errors are human, and WILL happen.

But I do not think I ever caused a disaster with my code. Some pretty big industrial installations ran on it. lives of some thousands of people depended on some of the hardware I designed. Also millions of dollars worth of hardware.

I do remember somebody once asked me to write a compiler for some PLC like system in the oil industry. They asked me how long it would take, and I was very hesitant, several weeks at least, if not month I replied. They did not like that, had somebody else do it (I met the guy), and something blew up a few weeks later, made the papers. I am not 100% sure if it was that guys fault, but coincidences I do not believe in either.

Reply to
Jan Panteltje

Microsoft sells Windows 7 for $100. It would be interesting to know what product can you (or your company) offer for $100.

VLV

Reply to
Vladimir Vassilevsky

A couple of cables. Some wall warts. The cheapest actual product is an electrical to optical converter for $180. But the million-piece price would be well below $100. The most expensive is a laser modulator for about $50K.

But firmware upgrades are always free. And if any product has a bug, a hardware or software design defect, we'll fix it for free. Forever.

John

Reply to
John Larkin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.