You're thinking of COBOL (UGH!!).
-- "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." (Richard Feynman)
You're thinking of COBOL (UGH!!).
-- "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." (Richard Feynman)
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.
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 ...
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)
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
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?
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)
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
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
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
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
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 :-)
On a sunny day (Sun, 10 Jun 2012 09:10:39 -0700) it happened Fred Abse wrote in :
OK.
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
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
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
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
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
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
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
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
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.