APL is probably the least verbose language ever. Not used much, these days: https://en.wikipedia.org/wiki/... In this context, APL would have a lot going for it. However, understandability is probably none of those....
ISO/IEC JTC1/SC22 has had a group looking at programming language vulnerabilities, including (a) how to define a 'vulnerability'; (b) how to assess languages against those definitions; (c) an assessment of languages (that have de-jure standards) for vulnerabilities, and related work. There is an introduction here http://www.open-std.org/jtc1/s... and the work is documented here: http://grouper.ieee.org/groups...
(Do you suppose the authors of this report are aware of the ISO work?)
The normal metric for languages like Ada, Pascal and yes C or C++ (those should not be considered the same language!) is "statement" as defined by the grammar, and usually simplified by counting "semicolons". If you figure out how to add preprocessor/header files, you'll probably see that for equivalent applications, the statement count between C and Ada is about the same. That's based on my real-world experience working with both languages over the last 30 years, I have no idea if the parent poster has much real experience in Ada (I kinda doubt it.)
There are some things that are very concise in C or C++. There are also some things that are very concise in Ada (imagine how many hundreds of lines of C and threads packages you need to code to get the equivalent of Ada tasking rendezvous.)
True story: as part of an experiment we implemented part of TCP (in particular, the timeout provisions associated with NAK) in both Ada95 and C. It took me 5 lines of Ada95 (Asynchronous Transfer of Control) to do what the other developer (who had experience coding protocols) did in 300 lines of C. His code had a bug in it, too.
Are "iOS" or "Android" the same as "PHP" or "C++"? I didn't hand in my personal informatoin to get the full study, but the stuff shown on this story's link pegged my bs-meter. Also, I'd hope there's a discussion of 'number of occurrences,' finding 10 bugs, 8 of which are null pointer dereference, should be different from finding 10,000 bugs where 'only' 7,500 of them are null pointer dereference.
And wouldn't it be even more useful to know which languages generate the least number of bugs, per line of code?
I've had both residential and now business grade internet with Cox, and I've been generally happy with the service. It's been reliable, tech support when I've needed it has actually been helpful and on-site repairs are usually same-day or early the next day. The only real problem I had was when their repairmen mis-coded a service call and I got billed for it. But Cox billing fixed it right away.
So it doesn't surprise me that Cox is bucking the anti-consumer wave by challenging music industry subpoenas. And it's also good business, so they don't have a bunch of lawyers poking around their data, while paying their own lawyers to watch over them.
It's one thing to use ">" for "less than". It's a whole nuther thing to use it for things like bit shift ">>" or dereference "->" And then there's the various uses of "+" and worst of all "=" vs "==".
I'm firmly convinced someone will write a paper on "C Syntax Considered Harmful," and symbol misuse is one aspect of C that causes bugs.
ACM came out in opposition, and I'm not sure if IEEE has taken a formal position on this. The arguments I've participated in have been in the context of ACM and IEEE. IEEE developed the Software Body of Knowledge in part to serve as a basis for what a Software Engineer should know (and be tested on.)
In some jurisdictions, you cannot call yourself an Engineer without a license. Civil Engineers, for example, have to take the EIT exam, gain some experience, and then apply for the Professional Engineer designation and license.
Having a diploma that says "Medical Doctor" doesn't entitle you to practice medicine, either.
Nothing new here, move along... We've been debating this for most of my 35 year professional career.
(Personally, I'm in favor of distinguishing 'software engineers' from 'programmers', and licensing 'software engineers' -as a means to establish professional liability.- But I can assure you that very few companies are interested in the idea of liability for software products. Nor are they interested in paying the substantial costs for professional liability insurance.)
And that's what makes Ada95 (and subsequent versions) so interesting from a language design perspective. Ada95 built on the Ada83 language (which itself built on Pascal, as well as CLU and other research languages), adding OOP (including supporting concurrent objects in a way that I haven't seen in other "modern" programming languages in this era of multi-core processors). There are design trade-offs, and these are well-documented. If you're interested in such things, the published design team rationale documents (for both Ada83 and Ada95) should be required reading. Ada83: http://www.adahome.com/Resourc... Ada95: http://www.adahome.com/Resourc...
What Ada95 accomplished was to graft a full OO design mechanism (i.e. inheritance) , while preserving type-safety (for scalar types, as well as "objects" or classes), keeping the safety properties (e.g. impossible without unchecked conversion to dereference a null pointer), and providing nearly 100% backwards-compatibility with Ada83. (There were a few inconsistencies, but these were at the edges of the language.)
Oh, and Ada2005 adds support for pre-conditions and post-conditions that matches what Eiffel now provides for defining and enforcing contracts. And it does so while providing the SPARK subset that supports theorem-proving for proof-of-correctness (including concurrent programs), starting with "cannot generate runtime error". See https://en.wikipedia.org/wiki/... A lot of this grew out of David Luckham's work at Stanford on annotation languages such as ANNA and TSL, see http://www.springer.com/us/boo...
That "piece of shit" is in most modern commercial aircraft these days, as well as the ground ATC systems. Guess maybe you shouldn't fly, then, if that's your opinion, Mr Coward.
There are legitimate criticisms that can be levied against any programming language, as well as against the Ada program. But this comment addresses none of them.
Ada95 added OO features including clear mechanisms (enforced by the compiler) on how to get OO design benefits without runtime performance costs or risks for dispatching.
Much of what I've seen in C++ is a response to problems in the original language design, particularly gaps or errors of omission.
Computer Science in the 21st Century seems to be full of stuff we knew about in the '80s and '90s, but forgot.
Pontiac was 'just a brand,' there was really not much difference between Pontiacs and other GM cars (although in my experience renting cars, Pontiac had worse than average fit and finish.) Saturn showed both new auto technologies and a different approach to sales. The original Saturn polycarbonate side panels had a lot of advantages, including no rusting and more ding resistance than metal.
But much more important was Saturn's "no hassle/no negotiation" approach to sales. That alone got Saturn a lot of traffic and sold a lot of cars to a lot of people who were pretty disgusted with the auto industry's "high hassle/high pressure" sales tactics (including me, proud owner of a '94 Saturn. We sold that car with almost 100k miles to a friend for a couple bucks, who put another 40k-50k on it himself.) As the saying goes, "your mileage may vary," particularly if you're driving a VW diesel.
What about the spam sent by the big email providers? It's a really interesting question what to do when you get -recurring- spam from these. (I get an offer for "Sun Microsystems User Lists" once a month from a chronic spammer sent either through Gmail or now Outlook. I report them to the abuse@xxx, but they keep on coming.) Do you blacklist a chronic spam source, that also has legitimate users? Do you quarantine everything from them, placing the burden on users/administrators to inspect and release legitimate mail from quarantine?
There are certainly lots of IP addresses that can be 'safely' rejected. Unfortunately, the growth of outsourced email makes it increasingly hard to depend on DNS information for sanity checks (e.g. there's an MX or SPF record that associates the "From" domain with the domain actually establishing the SMTP connection.)
Well that just goes to show how little you know about programming languages as a topic. Ada is one of many languages that guarantees array bounds are checked and null pointers cannot be dereferenced. (If either of those are attempted, an exception is thrown.)
Most contemporary aircraft have significant amounts of flight-critical software in Ada, some train control systems use Ada, some air traffic control systems use Ada, and of course there's a lot of Ada in US (and other country's) weapon systems. There's the SPARK subset that has been used for provably correct systems (does your software vendor provide a no-bugs warranty?). And there's production-quality code available under Open Source. http://www.adacore.com/ (no connection with AdaCore, other than I have lots of friends who work there.) All of my production code after 1980 was written in Ada. There's substantial anecdotal/unpublished evidence that shows large Ada systems have substantially lower life-cycle/software maintenance costs. Your Mileage May Vary, of course.
Well, I've been running Macs as my primary office automation/desktop (vice development) machine for 29 of the last 30 years, and haven't had these problems. And I routinely get 5 years out of my home Macs (and between 3 and 4 years from the corporate machines.)
Microsoft, since its only product is software, has to go to great lengths to protect and extend that property base. "Extend" here is Googly data mining.
Apple, on the other hand, makes money by selling you the hardware. The protection is the physical ownership of the device. You might not believe Apple when it says "we don't want your personal information", but you have to respect that they're not depending on either data or software to make the great majority of their revenue.
This may not be a popular opinion, but I trust Microsoft more than Google, Apple -way more- than Microsoft, and the NSA more than any commercial company.
The best single book I know to get started in the hobby is Dave Frary's "Pennsylvania Railroad, Middle Division" which you can buy as a downloadable PDF here http://www.ebay.com/itm/Pennsy...
There are good videos on YouTube. Dave Frary also has some good quality DVDs on his website, http://www.mrscenery.com/
Slashdot Mirror
APL is probably the least verbose language ever. Not used much, these days: https://en.wikipedia.org/wiki/... In this context, APL would have a lot going for it. However, understandability is probably none of those....
ISO/IEC JTC1/SC22 has had a group looking at programming language vulnerabilities, including (a) how to define a 'vulnerability'; (b) how to assess languages against those definitions; (c) an assessment of languages (that have de-jure standards) for vulnerabilities, and related work. There is an introduction here http://www.open-std.org/jtc1/s... and the work is documented here: http://grouper.ieee.org/groups...
(Do you suppose the authors of this report are aware of the ISO work?)
The normal metric for languages like Ada, Pascal and yes C or C++ (those should not be considered the same language!) is "statement" as defined by the grammar, and usually simplified by counting "semicolons". If you figure out how to add preprocessor/header files, you'll probably see that for equivalent applications, the statement count between C and Ada is about the same. That's based on my real-world experience working with both languages over the last 30 years, I have no idea if the parent poster has much real experience in Ada (I kinda doubt it.)
There are some things that are very concise in C or C++. There are also some things that are very concise in Ada (imagine how many hundreds of lines of C and threads packages you need to code to get the equivalent of Ada tasking rendezvous.)
True story: as part of an experiment we implemented part of TCP (in particular, the timeout provisions associated with NAK) in both Ada95 and C. It took me 5 lines of Ada95 (Asynchronous Transfer of Control) to do what the other developer (who had experience coding protocols) did in 300 lines of C. His code had a bug in it, too.
Are "iOS" or "Android" the same as "PHP" or "C++"? I didn't hand in my personal informatoin to get the full study, but the stuff shown on this story's link pegged my bs-meter. Also, I'd hope there's a discussion of 'number of occurrences,' finding 10 bugs, 8 of which are null pointer dereference, should be different from finding 10,000 bugs where 'only' 7,500 of them are null pointer dereference.
And wouldn't it be even more useful to know which languages generate the least number of bugs, per line of code?
I've had both residential and now business grade internet with Cox, and I've been generally happy with the service. It's been reliable, tech support when I've needed it has actually been helpful and on-site repairs are usually same-day or early the next day. The only real problem I had was when their repairmen mis-coded a service call and I got billed for it. But Cox billing fixed it right away.
So it doesn't surprise me that Cox is bucking the anti-consumer wave by challenging music industry subpoenas. And it's also good business, so they don't have a bunch of lawyers poking around their data, while paying their own lawyers to watch over them.
Mea culpa! :-)
It's one thing to use ">" for "less than". It's a whole nuther thing to use it for things like bit shift ">>" or dereference "->" And then there's the various uses of "+" and worst of all "=" vs "==".
I'm firmly convinced someone will write a paper on "C Syntax Considered Harmful," and symbol misuse is one aspect of C that causes bugs.
ACM came out in opposition, and I'm not sure if IEEE has taken a formal position on this. The arguments I've participated in have been in the context of ACM and IEEE. IEEE developed the Software Body of Knowledge in part to serve as a basis for what a Software Engineer should know (and be tested on.)
In some jurisdictions, you cannot call yourself an Engineer without a license. Civil Engineers, for example, have to take the EIT exam, gain some experience, and then apply for the Professional Engineer designation and license.
Having a diploma that says "Medical Doctor" doesn't entitle you to practice medicine, either.
Nothing new here, move along... We've been debating this for most of my 35 year professional career.
(Personally, I'm in favor of distinguishing 'software engineers' from 'programmers', and licensing 'software engineers' -as a means to establish professional liability.- But I can assure you that very few companies are interested in the idea of liability for software products. Nor are they interested in paying the substantial costs for professional liability insurance.)
The famous Westinghouse sign in Pittsburgh that went through permutations: https://en.wikipedia.org/wiki/...
And that's what makes Ada95 (and subsequent versions) so interesting from a language design perspective. Ada95 built on the Ada83 language (which itself built on Pascal, as well as CLU and other research languages), adding OOP (including supporting concurrent objects in a way that I haven't seen in other "modern" programming languages in this era of multi-core processors). There are design trade-offs, and these are well-documented. If you're interested in such things, the published design team rationale documents (for both Ada83 and Ada95) should be required reading. Ada83: http://www.adahome.com/Resourc... Ada95: http://www.adahome.com/Resourc...
What Ada95 accomplished was to graft a full OO design mechanism (i.e. inheritance) , while preserving type-safety (for scalar types, as well as "objects" or classes), keeping the safety properties (e.g. impossible without unchecked conversion to dereference a null pointer), and providing nearly 100% backwards-compatibility with Ada83. (There were a few inconsistencies, but these were at the edges of the language.)
Oh, and Ada2005 adds support for pre-conditions and post-conditions that matches what Eiffel now provides for defining and enforcing contracts. And it does so while providing the SPARK subset that supports theorem-proving for proof-of-correctness (including concurrent programs), starting with "cannot generate runtime error". See https://en.wikipedia.org/wiki/... A lot of this grew out of David Luckham's work at Stanford on annotation languages such as ANNA and TSL, see http://www.springer.com/us/boo...
That "piece of shit" is in most modern commercial aircraft these days, as well as the ground ATC systems. Guess maybe you shouldn't fly, then, if that's your opinion, Mr Coward.
There are legitimate criticisms that can be levied against any programming language, as well as against the Ada program. But this comment addresses none of them.
Ada95 added OO features including clear mechanisms (enforced by the compiler) on how to get OO design benefits without runtime performance costs or risks for dispatching.
Much of what I've seen in C++ is a response to problems in the original language design, particularly gaps or errors of omission.
Computer Science in the 21st Century seems to be full of stuff we knew about in the '80s and '90s, but forgot.
Thanks, didn't know that. Too bad Pontiac didn't capitalize on that innovation as a brand advantage.
Dear Mr Lutz, Two Words: Pontiac Aztek
Pontiac was 'just a brand,' there was really not much difference between Pontiacs and other GM cars (although in my experience renting cars, Pontiac had worse than average fit and finish.) Saturn showed both new auto technologies and a different approach to sales. The original Saturn polycarbonate side panels had a lot of advantages, including no rusting and more ding resistance than metal.
But much more important was Saturn's "no hassle/no negotiation" approach to sales. That alone got Saturn a lot of traffic and sold a lot of cars to a lot of people who were pretty disgusted with the auto industry's "high hassle/high pressure" sales tactics (including me, proud owner of a '94 Saturn. We sold that car with almost 100k miles to a friend for a couple bucks, who put another 40k-50k on it himself.) As the saying goes, "your mileage may vary," particularly if you're driving a VW diesel.
What about the spam sent by the big email providers? It's a really interesting question what to do when you get -recurring- spam from these. (I get an offer for "Sun Microsystems User Lists" once a month from a chronic spammer sent either through Gmail or now Outlook. I report them to the abuse@xxx, but they keep on coming.) Do you blacklist a chronic spam source, that also has legitimate users? Do you quarantine everything from them, placing the burden on users/administrators to inspect and release legitimate mail from quarantine?
There are certainly lots of IP addresses that can be 'safely' rejected. Unfortunately, the growth of outsourced email makes it increasingly hard to depend on DNS information for sanity checks (e.g. there's an MX or SPF record that associates the "From" domain with the domain actually establishing the SMTP connection.)
Well that just goes to show how little you know about programming languages as a topic. Ada is one of many languages that guarantees array bounds are checked and null pointers cannot be dereferenced. (If either of those are attempted, an exception is thrown.)
I use C++ all day, every day. Every time the C++ standardization committee meets, the language gets more obscure to me.
Someone with mod points mod parent up +1 either funny or insightful.
(I've already contributed to this thread, so I'm disqualified.)
Would you fly in an airplane whose flight control software was written in Javascript?
Most contemporary aircraft have significant amounts of flight-critical software in Ada, some train control systems use Ada, some air traffic control systems use Ada, and of course there's a lot of Ada in US (and other country's) weapon systems. There's the SPARK subset that has been used for provably correct systems (does your software vendor provide a no-bugs warranty?). And there's production-quality code available under Open Source. http://www.adacore.com/ (no connection with AdaCore, other than I have lots of friends who work there.) All of my production code after 1980 was written in Ada. There's substantial anecdotal/unpublished evidence that shows large Ada systems have substantially lower life-cycle/software maintenance costs. Your Mileage May Vary, of course.
Well, I've been running Macs as my primary office automation/desktop (vice development) machine for 29 of the last 30 years, and haven't had these problems. And I routinely get 5 years out of my home Macs (and between 3 and 4 years from the corporate machines.)
Your mileage may vary.
Microsoft, since its only product is software, has to go to great lengths to protect and extend that property base. "Extend" here is Googly data mining.
Apple, on the other hand, makes money by selling you the hardware. The protection is the physical ownership of the device. You might not believe Apple when it says "we don't want your personal information", but you have to respect that they're not depending on either data or software to make the great majority of their revenue.
This may not be a popular opinion, but I trust Microsoft more than Google, Apple -way more- than Microsoft, and the NSA more than any commercial company.
The best single book I know to get started in the hobby is Dave Frary's "Pennsylvania Railroad, Middle Division" which you can buy as a downloadable PDF here http://www.ebay.com/itm/Pennsy...
There are good videos on YouTube. Dave Frary also has some good quality DVDs on his website, http://www.mrscenery.com/
There are multiple groups on Facebook, and also some discussion boards such as http://www.railroad-line.com/ (tends to be pretty serious) and http://www.modelersforum.com/ (a bit less serious).
Finally, don't buy a cheap locomotive! There's nothing more frustrating than getting everything set up and then having your loco break.
dave (in the hobby for almost 50 years...)