the hot new programming language

C was described as designed by geniuses to be used by geniuses. But most programmers aren't geniuses. Most people need hard typing and runtime bounds checking and proper memory management to keep out of trouble; they need verbose. I cite basically all Microsoft products.

C is just an instruction set independent assembler. If you can program a computer using native assembler. you can as well write the program in C.

The other way around, knowing C doesn't imply that knowing platform depended assembler is not that obvious.

Most of the coding dudes I know will happily talk your ear off slurring dynamically-typed languages six ways from Sunday. They seem to really like pure functional programming languages, or at least languages with functional aspects, such as Rust, Go, and Haskell - which take great steps to encourage type safety, thread safety, concurrency and re-entrant coding style. Languages whose primary elements are functions which are designed to have limited side-effects.

And you are going to pay a heavy performance price for not supporting pointers, at least in some form, on most modern processor architectures. Most processors have tons of opcodes in their ISA that support or require indirection, so if your language isn't using pointers even the best compiler is going to have some difficulty optimizing your code to efficiently make use of machine primitives.

I would feel fairly hard-pressed to use a Microsoft product as some kind of archetypical example to give insight into what "Programmers" think, haha

Den torsdag den 2. juli 2015 kl. 22.12.14 UTC+2 skrev John Larkin:

if you make sure your soldering iron never get over 50'C you won't burn you fingers if you grap the wrong end

-Lasse

I once dropped an iron and caught it in mid-air. Only once.

Some people can write bug-free, really solid c. Most programmers can't. It's easier in embedded systems than in OSs and OS-level apps.

My people really like Python lately, for Windows and Linux engineering and test software and such, not embedded. As an interpreter, it trades performance for safety. We can always buy faster CPUs.

I don't get your opinion. You profess to having little experience with programming so I can't imagine you actually know much about ADA or other languages. You can spout off about all sorts of crap that you find on the web about software, but you don't know diddly about it and that is very obvious in everything you say, especially this.

I have worked with VHDL which is very similar to ADA and it is *no* panacea to producing bug free software. The sorts of bugs that are found by the ADA compiler are also found by C compilers if you just allow the tool to work for you instead of ignoring it. They are *far* from preventing all sorts of bugs.

Stick to things you actually know something about, eh?

That is literally the stupidest thing I've ever seen come from you.

On Thu, 02 Jul 2015 15:03:28 -0700, John Larkin Gave us:

I helped a boss way back in '79 use chains and a hydraulic jack to pull a nine inch triple pulley off of a down machine 2.5 inch shaft.

When it popped off, it really 'popped'. I caught it from banging the ground a mere few inches from costing them several hundred 1970s era dollars. He liked me from that day forward.

A few months later, a stuck button on a decades old chain hoist caused me to crash one of their main machines, taking it down for a couple days. He cussed himself for keeping that hoist in service for so long after they knew it was screwed up. I did not know the button could ride under the controller housing and get stuck. I was pissed at myself for that.

You are being a jerk again. That seems to be your nature.

In the day, I was one of the many programmers who suffered through Ada83. I made a little career of making Ada run fast enough to be plausible in realtime applications like radars.

The method was simple but brutal - remove all of Ada that didn't look exactly like Pascal, and if that wasn't enough, resort to assembly. This was still Ada enough to qualify as Ada, and to meet the DoD mandate.

Datapoint: My team implemented what would now be called middleware in a severe subset of Ada83 plus some assembly code on a DEC VAX to replace a pure-Ada message communications infrastructure. The subset Ada plus assembly approach was literally ten times faster than the pure Ada, and saved the project.

By the time Ada95 came out, it was too late - C/C++ had won.

Ada died because it was designed by academics who had no notion of realtime, and thus made blunder after blunder, such that not even a DoD Mandate could save Ada.

Joe Gwinn

Pascal had the same problem. But they both had the idea that a computer language should be safe. So now we have a nearly $100 billion anti-virus industry, and lots of products that have had thousands of security bugs.

It's not just the language c that is dangerous, it's the programming culture that surrounds it. Rockets crash and planes fall out of the sky because of bad code. Programming is the worst thing that technology does, and nobody seems to care much.

None, because some more careless company would have put Microsoft out of business. We have the "quality" we were prepared to pay for, more or less.

Clifford Heath.

Really? Are you going to try to defend such a statement? There is no limit to the speed CPU you can buy? No real limit? No practical limit? No limit to what you can use in a given design?

I'm not being a jerk. I'm just trying to get you to see what you just said. Care to comment on *your* statement?

If you are an Ada expert, I will defer to your judgement. But was the speed problem with Ada inherent in the language (therefor the fault of the language designers) or was it just the shortcomings of the implementations? What could have changed in Ada95 that would speed up implementations? I know C has gotten faster over the years to the point where it is hard to write hand optimized assembly that is faster. At least that is what I read. I don't use C much these days and I can't remember the last time I wrote assembly other than for stack machines with a very simple assembly language.

I use mostly VHDL for hardware design which is very Ada like and Forth for apps which is like a stack machine assembly language. A bit of a strange dichotomy, but there is no Forth like HDL.

I haven't called you stupid before, but I do now.

Lol. Whatever. Have a nice evening. :)

It was the design of Ada83 the language, which forced all Ada83 compilers to be clumsy, and to emit slow code. There are many details.

Fixing the many blunders of Ada83 was a large part of it. (There was lots of field experience by then.) Adding true multiprocessor support and the ability to control hardware was another. Adding support for object-oriented programming (borrowed from C++). Etc.

All successful programming languages so far have had the following things in common: Developed by a handful of people who wrote the compiler at the same time. Not a committee writing a 300-page language description in a vacuum. The early language and compilers co-evolved as real users (typically the colleagues of the handful) used the language for real work, and brought the problems back to the handful, who fixed the problem by changing the language if needed., for a few full versions. Full darwinist selection in the marketplace beyond the handful and their colleagues - hundreds of languages qualify for the common characteristics named before, but only a few languages achieve more than a few hundred users. After such a language has succeeded in the marketplace for some time, and has matured, it is formally standardized (and thus frozen).

Ada83 violated all of the above.

Assembly language is always faster than compiled language, if competent assembly programmers are used. And assembly can do things that are very difficult in any compiled language, with direct hardware control being a traditional area. But the cost is about four times that of compiled C, so assembly is used sparingly. The UNIX kernel was about

There is also a nasty trick: write the code in C, and look at the resulting generated assembly code. If it's worse than what one can write manually, paraphrase the C code and try again. Eventually, the optimum paraphrase will be found. In practice, C compilers are sufficiently alike the a good paraphrase works on most compilers.

VHDL was expressly based on Ada, and Verilog on C.

FORTH is a pure stack language, most resembling a HP calculator (with RPN), and was developed for machine control by an astronomer. The machines being controlled are such as large telescopes.

I was very interested in FORTH when it went public and they were being very close-mouthed. I ended up developing my own prototype language, which I called Fifth. The interpreter core was written in assembly, as that was how to get the necessary speed. But I found Fifth to be too limiting for what I was then doing, and never pursued it.

Joe Gwinn

And you'll find that many gear head coders will jump fast to point the finger at some user or user's PC having issues among otherthings, instead of actually looking at their code and admitting to error. And when they find bad code, they still won't admit to it. They also go as far as getting a few people to collaborate with them. Leading them down that dark alley. I find it ironic how easy the public has become blinded by those that write software and then load you day after day with security fixes, when really it's their buggy code they are fixing, before too many Figure it out.

Yes, the viruses, security threats, pumped up as much as possible makes a nice cover story for bad code, written by lazzy coders, stealing it from others while not being to concerned about it having bugs or some back door injected in it.

You can say, it's the blind leading the blind !

Jamie