Since when is not having a bug patentable?

You're thinking of COBOL (UGH!!).

-- "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." (Richard Feynman)

Reply to
Fred Abse
Loading thread data ...

On a sunny day (Sun, 10 Jun 2012 06:42:16 -0700) it happened Fred Abse wrote in :

That is not the point, The point is that Linux is written in C and asm and that it IS used in airospace.

You can write your apps in BASIC on it too. That still leaves C code and asm as the platform it runs on. Same if you write in ADA and run the app on a Linux system.

If the Alzheimer was right, it would be like runing a F1 on bike tyres. It is more (ADA) for wannebee programmers and like running a bike on F1 tires.

Reply to
Jan Panteltje

On a sunny day (Sun, 10 Jun 2012 06:42:18 -0700) it happened Fred Abse wrote in :

Yes, and COBOL still is used it seems.

Now you know why those wars are so expensive ...

Reply to
Jan Panteltje

Just because the underlying platform is Linux, doesn't mean that the applications running thereon will be written in C.

There is a *requirement* that certain defense- and aerospace- (note spelling) systems are written in ADA.

If you C-people don't like it, tough.

--
"For a successful technology, reality must take precedence 
over public relations, for nature cannot be fooled."
                                       (Richard Feynman)
Reply to
Fred Abse

Do you have any reference for this? Is it used for safety critical parts, which can cause airplane crashs if failing?

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

On a sunny day (Sun, 10 Jun 2012 08:05:13 -0700) it happened Fred Abse wrote in :

You can get an exception to that.

Language wars hey!

How about processor wars?

Reply to
Jan Panteltje

I don't do languages. Strictly hardware,

Boring!!

-- "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." (Richard Feynman)

Reply to
Fred Abse

Cobol is one of the more successful programming languages. It lets the bean counters write useful code. C lets programmers write useless code.

Programming shouldn't be a profession at all. Usually, all a programmer knows how to do is program. It makes more sense for people who know real stuff (FEA, finance, lawn care) to have an easy way to write applications.

My guess is that, some day soon, C-like procedural languages will be largely replaced by LabView-like GUI things, at least for Windows-y applications.

--

John Larkin                  Highland Technology Inc
www.highlandtechnology.com   jlarkin at highlandtechnology dot com   

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME  analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators
Reply to
John Larkin

You gone from discussing technology to flinging insults. Can't make an objective argument?

You are an amateur in more senses than one.

--

John Larkin                  Highland Technology Inc
www.highlandtechnology.com   jlarkin at highlandtechnology dot com   

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME  analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators
Reply to
John Larkin

I work with the guys who design FADECs, jet engine control computers. They use ADA, bare-metal, no OS. Their stuff has no bugs; people would die if it did.

We also build acquisition and simulation modules that are used in engine test cells, for both development and production/repair testing. The OS that hosts the test cell is generally a realtime LINUX. User tests are coded in a custom script language, and the interpreter is coded in C.

Some of our users run a real RTOS, VxWorks or some such, on x86 or PPC.

Our stuff is bare metal, 68K assembly or, lately, C on ARM.

--

John Larkin                  Highland Technology Inc
www.highlandtechnology.com   jlarkin at highlandtechnology dot com   

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME  analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators
Reply to
John Larkin

It is a disaster. Grace herownself said as much.

Bean counters don't write code. They especially don't write it in COBOL. At best, they write Excel macros.

Well, except for just about every thing in the entire world.

Desktop applications aren't the interesting part of programming. And you are free to implement any sort of "easy programming" solution you'd like.

Do your products actually *do* anything, or just sit on a shelf? Just wondering.

LabView? Seriously?

-- Les Cargill

Reply to
Les Cargill

On a sunny day (Sun, 10 Jun 2012 10:23:34 -0700) it happened John Larkin wrote in :

I am watching F1, so what your problem?

Boring twit :-)

Reply to
Jan Panteltje

On a sunny day (Sun, 10 Jun 2012 09:10:39 -0700) it happened Fred Abse wrote in :

OK.

Reply to
Jan Panteltje

On a sunny day (Sun, 10 Jun 2012 10:19:42 -0700) it happened John Larkin wrote in :

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

PLONK PLONK PLONK

Back to F1

Reply to
Jan Panteltje

Well, they get shipped and paid for. A decent amount lately; hope it keeps up. But the heart of what we do is electronics, real signals, and an ARM is usually just a data shuffler and manager, loading FPGAs and running self-test and blinking LEDs, stuff like that.

I don't especially like LabView, but something more graphical may well replace procedural stuff like C. C is ancient and very inclined towards bugs, especially for larger projects with multiple programmers. One of these days C will vanish like PL/1 and Pascal. So, what's next?

It's interesting that VHDL is a text language but it's not procedural, and tends to result in products with few bugs, and seems work well in team programming. Persistant procedural programs have, essentially, an infinite number of states, but seldom have explicit, much less complete, knowledge or control of the states. Across several programmers, state control is hopeless.

Our products are hard embedded, mostly bare metal programmed. The usual structure is a main loop that checks flags and does what needs doing, essentially running state machines when they have something useful to do, and one or more IRQs, typically a periodic timer thing and small i/o machines for serial, USB, or Ethernet. It's not persistant, in the sense that all paths return to the head of the loop quickly, and all state machines and IRQs run and finish directly. One person can handle a program for a product, which makes it managable and pretty safe.

--

John Larkin                  Highland Technology Inc
www.highlandtechnology.com   jlarkin at highlandtechnology dot com   

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME  analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators
Reply to
John Larkin

FPGAs? Or CPLDs? They are mostly programmed in languages, although there is a little schematic entry grudgingly allowed here and there.

--

John Larkin Highland Technology Inc

formatting link
jlarkin at highlandtechnology dot com

Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators

Reply to
John Larkin

Whom do you blame when you have your DMM in the ohms selection and probes connected to high voltage potential? The meter? Because it's in inadequate and should know better?

Certainly not the operator, I guess.

Jamie

Reply to
Jamie

Cheap DVMs are easy to blow up. Flukes aren't.

--

John Larkin                  Highland Technology Inc
www.highlandtechnology.com   jlarkin at highlandtechnology dot com   

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME  analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators
Reply to
John Larkin

The fairly cheap ones we got recently whine if you leave the probe in the current terminal and switch to volts.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Reply to
Spehro Pefhany

If you say so. I've seen a few 289's get destroyed. One of them actually separated the case when venting its magical blue smoke.

Jamie

Reply to
Jamie

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.