Which Programming Languages Are Most Prone to Bugs? (i-programmer.info)

Honorable Mention by Ukab+the+Great · 2017-12-31 19:01 · Score: 3, Funny

Brainfuck

Re:Honorable Mention by El_Muerte_TDS · 2017-12-31 20:01 · Score: 3, Funny

I have never heard of a large scale production problem happening in a application written in brainfuck. So by that metric it is not really error prone.
Re:Honorable Mention by K.+S.+Kyosuke · 2018-01-01 02:29 · Score: 1

Interestingly...

--
Ezekiel 23:20

In before Fractal of Bad Design by Waccoon · 2017-12-31 19:05 · Score: 4, Interesting

You already have to be a genius to understand functional languages, so of course those people make fewer mistakes.

I love it when functional fans insist it's more analogous to how the brain really thinks. That's why so few people can figure out how to do things that way.

Re: In before Fractal of Bad Design by Anonymous Coward · 2017-12-31 20:14 · Score: 1

LOL. Pascal and C are very similar. So your statement, "Pascal Hard, C easy" makes no sense. Pascal is just a stricter version of C. It also has a sane/simple object model compared to C++. There's a lot irrational hate towards Pascal whose sole flaw is using verbose keywords like "begin/end" instead of the concise "{ }".
Functional languages are convoluted and hard to read because they do simple things like "assigning a variable, like in a procedural language," by making a recursive function call.
Also, why is Java not mentioned in the summary? This is exactly the type of topic where we get to prove that a safe, statically typed language like Java can drastically reduce cost of "dangerous C/C++ bugs" that bring down services, help hackers steal data, or gain root access.
Re: In before Fractal of Bad Design by _merlin · 2017-12-31 20:25 · Score: 4, Informative

Pascal and ANSI C are very similar, but pre-ANSI C is a completely different beast, far more similar to BCPL. In fact, ANSI C could almost be described as Pascal with C syntax.
Pre-ANSI C didn't have prototypes - it assumed any undeclared name was an external function. It didn't automatically convert int to long if the function expected it, etc. - you had to explicitly cast. You had to be careful to cast results of functions correctly, too. All it had was a set of rules for how argument types were stacked, and it was up to you not to pass something a function wasn't expecting. This is closer to assembly language programming than Pascal or ANSI C.
Re:In before Fractal of Bad Design by angel'o'sphere · 2017-12-31 21:55 · Score: 2

Functional programming is not more complicated then other imperative programming styles.
But unfortunately functional languages like Haskell often have a strange syntax, that is all.

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Re: In before Fractal of Bad Design by Anne+Thwacks · 2018-01-01 00:00 · Score: 4, Informative

Assembly to C was quite easy as well.
Which is hardly surprising, since C is just PDP11 assembler tidied up a bit.
Which is interesting considering the PDP11 was "a hardware Fortran machine", and the i386 architecture is a close copy of the PDP11 - the 286 even copied the early (variable page size) PDP11 memory management scheme that was the fashion before people figured out it was not really good for virtual memory, and then the 386 copied the later (fixed page size) PDP11 MM which is needed for virtual page based memory. The PDP11 was designed on the assumption that memory bandwidth was the bottleneck in throughput.
The fact that C has been successfully ported to almost all more recent processors is largely because the concepts of what a CPU is and does have been developed by people who grew up on the PDP11 architecture. RISC architecture may be different, but, in reality, the RISC architecture is mostly just used to simulate CISC anyway. RISC was designed on the assumption that instruction decode was the bottleneck - which has not really been the case since the 1980's - hence the failure of RISC to displace CISC.
I am writing this on a Sparc64 (RISC) machine - the story is more complex that I describe here.

--
Sent from my ASR33 using ASCII
Re: In before Fractal of Bad Design by jeremyp · 2018-01-01 00:24 · Score: 1, Insightful

Which is hardly surprising, since C is just PDP11 assembler tidied up a bit.
Nope.
http://csapp.cs.cmu.edu/3e/doc...
The i386 architecture is not a close copy of the PDP11. You might be thinking of the 68000 which is a more plausible candidate.
C has been ported to most recent processors mainly because it was needed. The fact that it is relatively easy to port gives the lie to your assertion that it is "Macro-11 tidied up".
And, by the way, RISC sort of has displaced CISC. Modern CISC processors like the x86 and later tend to be implemented on top of a RISC core.

--
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
Re: In before Fractal of Bad Design by Anonymous Coward · 2018-01-01 00:58 · Score: 1

Compared to how horrible the original C compilers were (no type checking of parameters), Pascal is a huge improvement.
Let's look at the issues discussed in the paper:

2.1. If one declares
var arr10 : array [1..10] of integer;
arr20 : array [1..20] of integer;
then arr10 and arr20 are arrays of 10 and 20 integers respectively... Because arr10 and arr20 have different types, it is not possible to write a single procedure that will sort them both.

Delphi "open arrays" allow you to process both arr10 and arr20 arrays using the same procedure/function.
Section 2.5 repeats the array issue and the solution in modern pascal is to use open arrays.

2.2. There are no static variables and no initialization
Turbo Pascal and Delphi have static variables and initialization.

2.6. There is no way to override the type mechanism when necessary, nothing analogous to the ``cast'' mechanism in C.

Type casting is available in turbo pascal/delphi.

3. There is no guaranteed order of evaluation of the logical operators 'and' and 'or' - nothing like && and || in C. This failing, which is shared with most other languages, hurts most often in loop control:
while (i <= XMAX) and (x[i] > 0) do ...
is extremely unwise Pascal usage, since there is no way to ensure that i is tested before x[i] is.
TP/Delphi allow 'i <= XMAX) to be evaluated before x[i] > 0 if 'short-circuit' compilation is enabled.

The 'case' statement is emasculated because there is no default clause.

TP/Delphi have the default clause. And their case statement is less error prone than the horrible 'fall-through' semantics of C's switch statement.
Similarly, most issues the paper mentions have been solved in TP/Delphi. The only issue that remains is the "begin/end" thing. That's why Java's syntax reminds me of Pascal. Other than the superficial C-like syntax things like "{ }", method arguments like C, Java's syntax is mostly copied from Pascal, including the "import statement" (Pascal's 'uses' statement), single inheritance OOP similar to Object Pascal etc.
Pascal had the 'Boolean' type very early on and programming in C is painful because you have use non-zero values to simulate the boolean types. Pascal also has array bounds checking, no accidental assignment like in C's 'if' statement etc.
In short, there was a lot of bad-mouthing of pascal to destroy its reputation, when in reality it kicks C's ass 9 ways till Sunday.
Re: In before Fractal of Bad Design by Entrope · 2018-01-01 01:25 · Score: 1

And my 50 line Perl version is much more concise than both of those, but my co-workers keep complaining that it's actually modem line noise!
Re: In before Fractal of Bad Design by Z00L00K · 2018-01-01 01:42 · Score: 1

Different languages allow for different language-specific bugs.
However the worst bugs aren't the language specific bugs - it's system design bugs where the designer don't understand the business case that shall be solved.
The programming language bugs are usually found either by hand or by tools like FindBugs, Splint and other similar tools. But system design bugs are all in the brain of people - and some people have a very strange brain wiring resulting in "perfect solutions on non-existing problems".

--
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Re: In before Fractal of Bad Design by Z00L00K · 2018-01-01 01:50 · Score: 2

And one way around it was to declare the function before it was used - that did help a bit sometimes. Not always, but sometimes - and depending on compiler.
But Pascal, C, Java, C++ and Ada all belong to the same programming paradigm, with or without the object orientation twist.
Then we have Basic and Fortran which sometimes have the paradigms from Pascal et.al. but also other ways not related to them.
Cobol is in turn an animal of itself.
And then you can turn to Erlang, Haskell and Prolog for yet another way to do things.

--
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Re: In before Fractal of Bad Design by K.+S.+Kyosuke · 2018-01-01 02:16 · Score: 1

Most people need unnecessary small changes in program flow with copious context, and preferably description in intermediate variables and functions. This was at the heart of the Perl exodus and Lisp excommunication.
Not sure about Perl but Lisp thrives on intermediate variables and functions. You most likely don't want to write large expressions in Lisp without intermediate variables, unless those expressions are auto-generated (which, admittedly, is a programming style in itself).

--
Ezekiel 23:20
Re: In before Fractal of Bad Design by K.+S.+Kyosuke · 2018-01-01 02:32 · Score: 1

C++ is probably understood to be the C++ standard. Whether anyone thinks of Standard Pascal today when Pascal is being mentioned seems much more unlikely.

--
Ezekiel 23:20
Re: In before Fractal of Bad Design by Anonymous Coward · 2018-01-01 02:42 · Score: 1

Because being concise in a programming language is a secondary benefit of maintaining software. The primary benefit is the ability to come back and modify it, without having to start an effort as great as that of creating the software new. Perl is fast in the wrong parts (the typing) and slow in the wrong parts (thinking). That's why it sucks, and when you get tired of code golf, you too can join the rest of the software developers.
Re: In before Fractal of Bad Design by Entrope · 2018-01-01 03:07 · Score: 1

That was the joke. If you were less of a humorless scold, maybe you would have realized that the bit about co-worker complaints was a flag to indicate where the costs of that tradeoff come in.
One occasionally does have use for write-only source code, where the source code is small enough that changing the purpose of the program would inherently require rewriting such a large proportion of the code that it is just as efficient to start from a blank file, but that is seldom going to be the case for even a 500-line program.
Re: In before Fractal of Bad Design by Entrope · 2018-01-01 03:14 · Score: 1, Interesting

So you are saying that the years since BWK wrote that article have given us even more reasons to dislike Pascal, such as the fact that the only versions that are useful are either dead for 20+ years (Turbo Pascal) or need vendor-proprietary extensions (Delphi)?
Re: In before Fractal of Bad Design by K.+S.+Kyosuke · 2018-01-01 04:06 · Score: 1

Actually, I just found out that even Standard Pascal has conformant arrays, so it's more like that this article gives us even more reasons to dislike BWK. Although, the proper way to use Pascal is to use Modula-2/3 or Oberon, given that Pascal has limitations (that C++ shares) that made Wirth abandon it anyway.

--
Ezekiel 23:20
Re: In before Fractal of Bad Design by Joce640k · 2018-01-01 04:23 · Score: 1

Pascal, whose sole flaw is using verbose keywords like "begin/end" instead of the concise "{ }".

...most issues the paper mentions have been solved in TP/Delphi.
There have been several attempts to fix the "flawless" language, yes.
(despite even it's creator abandoning it for something better).

--
No sig today...
Re: In before Fractal of Bad Design by Tenebrousedge · 2018-01-01 04:54 · Score: 1

You didn't understand what was said. No one was suggesting that the PDP-11 instruction set is similar to i386, and it's irrelevant. There are a number of features of C which map directly to PDP-11 instructions, and to some degree it was also informed by how the PDP's registers work.

--
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Re: In before Fractal of Bad Design by redmasq · 2018-01-01 05:53 · Score: 1

Maybe that Perl of humor was the straw that broke the camel's back. That said, at the very least, Perl is still easier to read than Whitespace and easier to pronounce than INTERCAL.
Re: In before Fractal of Bad Design by Entrope · 2018-01-01 06:00 · Score: 1

You just don't see innovations like the "COME FROM" statement in modern languages. Now there's a language feature with a noteworthy impact on defect density.
Re: In before Fractal of Bad Design by imnotanumber · 2018-01-01 06:50 · Score: 3, Informative

So you are saying that the years since BWK wrote that article have given us even more reasons to dislike Pascal, such as the fact that the only versions that are useful are either dead for 20+ years (Turbo Pascal) or need vendor-proprietary extensions (Delphi)?
No. You have fallen prey to the common hype.
There is, the GCC of Pascal world, that is Free Pascal https://www.freepascal.org/ : an Open Source version with a modern syntax and concepts. The complaints on the article seem someone complaining about Linux arguing that you have to compile the Kernel to add mouse support.
Also, Lazarus https://www.lazarus-ide.org/ is a modern Open Source IDE that picked where Delphi stop and you can develop and compile applications for Windows, Linux and OSX.
Re: In before Fractal of Bad Design by imnotanumber · 2018-01-01 06:55 · Score: 1

Pascal, whose sole flaw is using verbose keywords like "begin/end" instead of the concise "{ }".

...most issues the paper mentions have been solved in TP/Delphi.
There have been several attempts to fix the "flawless" language, yes.
(despite even it's creator abandoning it for something better).
No. That branch is the fix for the original Pascal, the one that earned the outdated critique.
TP/Delphi and then Free Pascal/Lazarus are another branch that solved the earlier problems and do not have the original flaws.
Re: In before Fractal of Bad Design by Entrope · 2018-01-01 07:14 · Score: 1

So there is a hodgepodge of mutually incompatible dialects of Pascal that are available, some of which are useful?
This is not helping Pascal's case, and makes it look more and more like my C++.NET analogy was accurate.
Re: In before Fractal of Bad Design by Anonymous Coward · 2018-01-01 07:23 · Score: 1

Putting Prolog in the same category as Erlang and Haskell makes zero sense to me.
Re: In before Fractal of Bad Design by rnturn · 2018-01-01 07:25 · Score: 1

``Pre-ANSI C didn't have prototypes - it assumed any undeclared name was an external function. ... This is closer to assembly language programming than Pascal or ANSI C.''

Interesting you would note that. I still recall a comment made by a co-worker back in the early '80s that "C was like assembly language without the handcuffs".

--
CUR ALLOC 20195.....5804M
Re: In before Fractal of Bad Design by redmasq · 2018-01-01 09:46 · Score: 1

Especially since the GOTO statement is considered harmful.
Re: In before Fractal of Bad Design by kanly · 2018-01-01 10:37 · Score: 1

Which C++ standard? It really matters. They really are completely different languages.
C++98 was only a few steps past "C with Classes". Compare some C++98 code (which at this point looks like somewhat portable object-oriented assembly in terms of abstraction level) to some modern idiomatic C++14 code. Idiomatic C++14 is often closer to a functional language with compile-time computation than anything a C programmer would recognize. No raw pointers anywhere, first-class function objects, implicit dependency ordering on multithreaded computations with continuations, there's a lot to love there. (There's a lot of legacy baggage too, but the core language is actually becoming quite beautiful.)
Re: In before Fractal of Bad Design by imnotanumber · 2018-01-01 10:50 · Score: 2

So there is a hodgepodge of mutually incompatible dialects of Pascal that are available, some of which are useful?
Practically, Delphi and Free Pascal (with Lazarus being the IDE that uses Free Pascal as a compiler) have the majority of mind share in the Pascal World, and they are mostly compatible. A few years ago Delphi used the Free Pascal Compiler to target iOS. Of course, those who sell Delphi are not very keen to advertise the Open Source competitor...

This is not helping Pascal's case, and makes it look more and more like my C++.NET analogy was accurate.
Most criticisms come from people that are completely out of touch with the modern Pascal Compilers/IDEs. Just take a look at http://newpascal.org/assets/mo... to learn its current state.
Re: In before Fractal of Bad Design by K.+S.+Kyosuke · 2018-01-01 12:18 · Score: 1

What?

--
Ezekiel 23:20
Re: In before Fractal of Bad Design by pezezin · 2018-01-01 22:15 · Score: 1

Erlang syntax derives from Prolog. Other than that, they don't have much in common.
Re: In before Fractal of Bad Design by Wootery · 2018-01-01 22:38 · Score: 1

But Pascal, C, Java, C++ and Ada all belong to the same programming paradigm, with or without the object orientation twist.
But there are very significant differences regarding how bug-prone the languages are. Unlike C and C++, Java has no concept of undefined behaviour, and does a far more complete job of insulating the programmer from platform-specific quirks. It's night and day.
Unlike C/C++, Java enforces left-to-right evaluation order, always uses 2's complement arithmetic (not target-platform specific), always uses big endian (not target-platform specific), always initialises to zero (never UB), always performs array bounds checking (never UB), always checks for null when dereferencing (never UB), always checks for invalid casts at runtime (never UB), the list goes on and on.
Yes, both C++ and Java have object-orientation, but their philosophies are completely different. (Perhaps I'm just talking past you here though - you're right of course that they're both procedural/OO at the end of the day.)
Re: In before Fractal of Bad Design by Alioth · 2018-01-01 23:12 · Score: 1

Well, except RISC did end up doing overwhelmingly well: ARM (which originally meant 'Acorn RISC machine') is now the most popular architecture, and ARM ships more cores in a year than x86 variants have in all time.

--
Oolite: Elite-like game. For Mac, Linux and Windows
Re: In before Fractal of Bad Design by thogard · 2018-01-02 00:54 · Score: 1

There's a lot irrational hate towards Pascal whose sole flaw is using verbose keywords like "begin/end" instead of the concise "{ }".
There is a deeper problem than the names that is related to that in the early days of C, "{" was "create a new stack frame", where "begin" in Pascal was "create a new name scope block" as C keeps its local variables on the hardware stack and Pascal used to keep them in what would now be called heap memory because the real hardware stacks were very small.
Re: In before Fractal of Bad Design by Duhavid · 2018-01-02 04:33 · Score: 1

They were referring to being descendants of the algol programming language line, I believe.
"Unlike C and C++, Java has no concept of undefined behaviour, and does a far more complete job of insulating the programmer from platform-specific quirks."
Very true. Java, benefiting from the experience of the languages that came before it, does a better job of insulating.
"Unlike C/C++, Java enforces left-to-right evaluation order, always uses 2's complement arithmetic (not target-platform specific), always uses big endian (not target-platform specific),"
From the standpoint of error prone, I'm not certain on these.
"left-to-right", I presume you mean left to right within an operator's precedence level.
As long as the calculation result is correct, does this matter?
W.R.T. overflow/underflow and calculation precision, I would think strict l to r within a precedence level could
give worse results.
"2's comp arith"
As long as the calculation result is correct, does this matter?
On a machine that did not do 2's comp arith, ( assuming it did the arithmetic correctly ), I would think
that forcing 2's comp would lead to poor performance.
"big endian"
As long as the calculation result is correct, does this matter?
Forcing the internals to be big endian on a little endian machine would seem to lead sub-optimal calculations.
For stuff heading "off machine", converting to a common endian-ness would be good, but seems like a
handled problem
"always initialises to zero (never UB), always performs array bounds checking (never UB), always checks for null when dereferencing (never UB), always checks for invalid casts at runtime (never UB), the list goes on and on."
For the enumerated items, for most programmers, for most applications, these are all good things,
but they do have a cost.

--
emt 377 emt 4
Re: In before Fractal of Bad Design by Duhavid · 2018-01-02 04:36 · Score: 1

I think another flaw, the one that I recall as being "the showstopper" was the need to declare string lengths.
If you were writing code that needed to handle arbitrary length strings, having to declare a very long string or other workarounds seemed the biggest real complaint of the day.

--
emt 377 emt 4

2018 by AHuxley · 2017-12-31 19:08 · Score: 4, Insightful

Rediscovers how great Ada would have been for the consumer.

--
Domestic spying is now "Benign Information Gathering"

Re:2018 by romiz · 2017-12-31 20:04 · Score: 1

Perhaps if one day we get a compiler that does not require you to choose between an expensive license or coding only GPLv2 projects. Until then, all those GCC efforts only serve as an advertisement for GNAT Pro, and the only users will continue to be those avionics companies that are used to pay a lot.
Re:2018 by serviscope_minor · 2017-12-31 20:49 · Score: 2

Is that really the case? GNAT is part of GCC isn't it, which allows you to use the output and the libraries without counting as a derived work.

--
SJW n. One who posts facts.
Re:2018 by romiz · 2018-01-01 00:23 · Score: 1

It seems that I was confused: you don't have the same standard libraries when you use AdaCore's GNAT Libre, GNAT Pro, or Ada support in GCC. And the Ada support integrated into the GCC mainline supports the linking exception. There is a better explaintation, but all this is quite confusing...
Re:2018 by HiThere · 2018-01-01 05:33 · Score: 2

The first problem I had with Ada was that strings of different lengths were of different types. That could be solved with bounded or unbounded strings, but then you couldn't compare against literals. There were other problems, and there were always ways around them, but I had to used unchecked conversion too often for things that were perfectly safe. The entire thing was a mess due to over-concern with simple type conversions. Dynamically allocated storage is also a mess, though, given the original ideas, quite reasonable. Follow an Ada program through a simple addition of a node to a tree and you should see what I mean.
Another part of the problem was that the optional annexes couldn't be used as they usually weren't implemented. It's great to not have to load them if you don't need them, it's not so great if they aren't available when you need them.
There are lots of other minor design flaws. In a way you can forgive them, because this was being designed at about the same time as C++ was being written, and, unfortunately, it was designed by a committee. So the kitchen sink got thrown in. But they did design everything in a way that enabled maximal security...even where it didn't make any sense. (Why can't I compare two literal strings of different lengths? They've probably changed that by now, though.)

--

I think we've pushed this "anyone can grow up to be president" thing too far.
Re:2018 by TVmisGuided · 2018-01-01 05:43 · Score: 1

There's absolutely nothing wrong with writing GPLv2 code in Ada. I can think of one major issue that could have been avoided entirely had Ada been the language of choice for a GPL application: the Heartbleed bug in OpenSSL.
"If software is safe, it cannot harm the world. If software is secure, the world cannot harm it." -- John Barnes, author of several Ada programming texts

--
All the world's an analog stage, and digital circuits play only bit parts.
Re: 2018 by Zero__Kelvin · 2018-01-01 08:00 · Score: 1

What drugs are you on?

--
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Re:2018 by Tom · 2018-01-01 10:44 · Score: 1

It would actually be a good idea to rediscover some of the advances of the past that have been lost to history. My domain is information security, and in many areas we are worse than our ancestors in the early days of computing were. Updating some of the academic research that has fallen by the wayside could do wonders for us.

--
Assorted stuff I do sometimes: Lemuria.org
Re:2018 by david_thornley · 2018-01-02 05:58 · Score: 1

The Heartbleed bug would not have existed if the authors had used the safety features present in C. It relied on having access to memory allocated but not initialized, and so keeping the previous contents. If the authors had used calloc() instead of malloc(), or thrown a memset() in, Heartbleed would not have happened. In security software, letting what happens to be in memory stay there with a new allocation is a Bad Idea. Zeroing out the memory on free() would have been a better one, but you can't easily do that with standard C functions.
Given that the authors couldn't use obvious C safety features in their desire for execution speed, I have to think they'd have found some way to introduce bugs into a more hand-holding language.

--
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes

Mainstream languages, duh by Anonymous Coward · 2017-12-31 19:15 · Score: 1, Insightful

" On the other hand, Clojure, Haskell, Ruby and Scala"

Yeah, those are niche languages. Good, autistic programmers seek out niche languages and write clean code since they're the only ones working on it.

The mainstream languages are the ones you do at work, with a couple shitty coworkers, and an endless amount of scope creep and impossible deadlines that creates a spaghetti nightmare.

Re: Mainstream languages, duh by Dausha · 2018-01-01 00:01 · Score: 1

I know this is /. and RTFA is simply not done, but if you read the sample, you would see that Ruby was 2nd in developer count (after C), 4th in project counts (JS, python, C) and 5th in commits. Ruby represented 9.6k of the 28k developers; about a third. So, not so niche. In fact, C and Ruby together represented 22.4k of the 28k.
Java had about a third as many developers as Ruby with the same project count.
What is interesting is that Typescript had a 0.15 coefficient compared to Javascript's 0.03, meaning it is more error prone--tying Objective-C for first place in error-proneness. More error prone than C.
I was amazed at how well Go fared in all categories, with a high developer count and lowest coefficient.

--
What those who want activist courts fear is rule by the people.
Re:Mainstream languages, duh by vtcodger · 2018-01-01 00:11 · Score: 2

Yep, that was my thought when I read the article. Software used by a wide audience will generally require a lot more bug fixes than similar software used by only a few. Users find the damndest ways to use and abuse software. The more users, the more things they want changed and the more actual bugs they identify.
Face it -- most of the world runs on C, C++ and, increasingly, Python. Of course there are lots of bug fixes. And BTW I loath C++. IMO C++ code is almost always unreadable except possibly by its author. And C isn't that much better. I'm not defending my favorite languages here.

--
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
Re:Mainstream languages, duh by Anonymous Coward · 2018-01-01 02:01 · Score: 1

Worse, what if the programs are just as buggy, but the fixes aren't happening (for reasons, mostly the personality of people who write projects in uncommon languages).
Re:Mainstream languages, duh by david_thornley · 2018-01-02 06:00 · Score: 1

I've worked on large C++ codebases, the products of many people over time, and it's generally nice and readable. If you find it unreadable, you may be looking at bad code.

--
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes

Complexity by Anonymous Coward · 2017-12-31 19:24 · Score: 5, Insightful

Or could it be that the software written in C++ usually tends to be large complex software where performance is important along with various other complicating factors. While the software written in ruby for example tends to be simpler?

Sounds like this 'study' started with a conclusion already in mind.

Re:Complexity by Pseudonym · 2017-12-31 20:06 · Score: 1

That was my first thought. It turns out that they ranked popularity by number of stars.
When you think of popular pieces of open source written in each language, what do you think of? Here are the ones from the paper:
C projects: Linux, git, php-src.
Python projects: Flask, django, reddit.
JavaScript projects: Bootstrap, jquery, node.
Java projects: Storm, elasticsearch, ActionBarSherlock
If you didn't know, ActionBarSherlock is a piece of Android infrastructure. Given that, these all seem very reasonable.
How about C++? What do you think would be the most popular C++ open source projects? Here they are:
C++ projects: node-webkit, phantomjs, mongo
Mongo seems reasonable, but... those other two! There's no Mozilla, no Boost, no tensorflow, no LLVM... not even webkit, just two webkit clients, both of them javascript bindings.

--
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Re:Complexity by AuMatar · 2017-12-31 20:18 · Score: 1

ActionBarSherlock is a replacement for a piece of Android Architecture to backport functionality that existed in 4.0+ to 2.2+ (or thereabouts). Its been deprecated for years, as nobody writes for those old versions, and Google has been releasing their own backporting libraries for years. So no, its not reasonable.

--
I still have more fans than freaks. WTF is wrong with you people?
Re:Complexity by Pseudonym · 2017-12-31 21:41 · Score: 1

Fair enough, I didn't know that. Still, as Meat Loaf said, 2/3 ain't bad.

--
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Re:Complexity by Joce640k · 2017-12-31 23:43 · Score: 2

1993 just called and wants it C vs. C++ flamewar back.

--
No sig today...
Re:Complexity by Pseudonym · 2017-12-31 23:53 · Score: 1

Be fair. The argument still made sense before C++11 or so.

--
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Re:Complexity by Carewolf · 2018-01-01 00:04 · Score: 1

Or could it be that the software written in C++ usually tends to be large complex software where performance is important along with various other complicating factors. While the software written in ruby for example tends to be simpler?
Sounds like this 'study' started with a conclusion already in mind.
Yeah. Another possible conclusion from this data is that C++ is more commonly or easily debugged, and thus more bugs are found and fixed, where they are left unfixed in the other languages.
Re:Complexity by Carewolf · 2018-01-01 00:05 · Score: 1

C++ is generally faster than C these days, though ofcourse you can fuck it up like anything in C++ if you don't know what you are doing, or do and are just trying to "prove" your incorrect point.
Re:Complexity by Anne+Thwacks · 2018-01-01 00:10 · Score: 2

Truth is I've seen very few projects where using C++ actually resulted in decent code in the end and quite a few where it wasn't at all helpful.
Probably because a huge amount of C++ code is in massive embedded systems which are closed source and you can't see the code. I can't either in the general case, but in the cases I have seen, the quality of code is roughly what you would expect from the quality of the team. (In all probability, larger teams will need one or more specialists to do the more complex debugging).
Are there any large Open Source projects in Cobol? No. That is mostly because Cobol is not fashionable with the OSS crowd. My point is fashion is the biggest factor in language selection for OSS. Not so much for closed source (where the prejudice of the CTO is the biggest factor). I doubt actual performance of the language is relevant to language selection in more than 1% of projects - and those are mostly academic experiments, rather than commercial work.

--
Sent from my ASR33 using ASCII
Re:Complexity by K.+S.+Kyosuke · 2018-01-01 00:28 · Score: 1

a huge amount of C++ code is in massive embedded systems

You mean the systems that use "C++" instead of C++? As in, with significant restrictions? I'm reasonably sure the quality of those has more to do with the discipline of the programmers than with anything else.

--
Ezekiel 23:20
Re:Complexity by Entrope · 2018-01-01 01:41 · Score: 1

No one else has pointed out the old saw that there are three kinds of lies (lies, damned lies, and statistics)? Or that one could -- and someone actually did -- literally write a book on "How to Lie with Statistics"?
Re:Complexity by Anonymous Coward · 2018-01-01 01:48 · Score: 1

Another thing is that compiled programs typically get bug reports and fixes.
"A script on the page you are visiting have stopped working" just makes the user hit F5. It doesn't get fixed and doesn't show up in their statistics.
Re:Complexity by Joce640k · 2018-01-01 04:11 · Score: 1

It seemed to me like he was about to play the "'Hello, world' is bigger in C++ than C" card.
(and I'd like to see some evidence that C++ rarely results in "decent code" or where it's "not at all helpful").

--
No sig today...
Re:Complexity by jeremyp · 2018-01-01 05:15 · Score: 1

Mongo seems reasonable, but... those other two! There's no Mozilla, no Boost, no tensorflow, no LLVM... not even webkit, just two webkit clients, both of them javascript bindings.
Do any of those projects use GitHub as anything other than a mirror? LLVM, for example, is hosted in its own SVN repository. I imagine most people who want the source go direct to the source, as it were.

--
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
Re:Complexity by HiThere · 2018-01-01 05:47 · Score: 2

Sorry, that hypothesis doesn't fly. It may be harder to debug C or assembler than C++, but most other languages provide more usable debugging facilities than does C++, and most of them are easier to write unit tests for. The unit testing for C++ is basically an add-on. Even assert statements in C++ are crippled, unless you use an extension. (Assert statements should include an optional message that is printed with the error, and which can dump variables of interest in a formatted way.)
So C++ is more difficult to debug. There *are* more external tools that you can use to do the debugging, but that's because they are needed.

--

I think we've pushed this "anyone can grow up to be president" thing too far.
Re:Complexity by Pseudonym · 2018-01-01 12:55 · Score: 1

Oh I'm certain that there is a lot of C++ code out there that would be better written in some other language. And on github it probably isn't too hard to find.
But this is also true of your favourite language, assuming your favourite language has a critical mass of people who think they know how to use it.

--
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Re: Complexity by tigersha · 2018-01-01 16:39 · Score: 1

Are there any large Cobol projects out there? I mean this as a question, not sarcasm.

--
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
Re:Complexity by Pseudonym · 2018-01-01 18:45 · Score: 1

Fair point. It's also true that a lot of these projects don't have that many people working on them.
LLVM and tensorflow are good examples of software projects where you need to have a minimum level of knowledge of the problem domain to make any meaningful contribution. So while a lot of people use those projects, not very many contribute.
Boost, of course, has a very strict code review policy before it accepts new functionality.

--
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Re:Complexity by david_thornley · 2018-01-02 06:05 · Score: 1

No, it didn't. Any C program could be fairly trivially ported to C++ (C++ isn't quite a proper superset of C90, but it's close), and the C++ compiler would compile it pretty much as the C compiler would. The first C++ compiler used cfront, a C++ to C translator, and the C code would go through intact.
C++ has always been at least as fast as C, since it can always do what C does.
The C++ libraries were not necessarily as fast as the C ones (iostreams vs. stdio, for example), but that's a different matter.

--
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Re:Complexity by david_thornley · 2018-01-02 06:06 · Score: 1

By Darrell Huff, back (IIRC) in the 50s.

--
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Re:Complexity by Pseudonym · 2018-01-02 14:59 · Score: 1

I was specifically responding to the claim that C++ wasn't helpful. There is an argument that there was less of an advantage before Modern C++.

--
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Re:Complexity by ebvwfbw · 2018-01-02 15:27 · Score: 1

Used to be the C++ compiler was simply a pre processor to C. Therefore you clearly could go to C, going to C++ was a lot more problematic.
Side note, I found I could take my C code and end up with 1/3 the lines in Perl. It ran in every case but one without a difference in speed while the perl code was way more readable and maintainable. I still run some code in perl that was moved over from C in 1995.
Re:Complexity by david_thornley · 2018-01-04 04:19 · Score: 1

while the perl code was way more readable and maintainable

I just have to quote this, since it's something I'm not sure I've read on the net before.

--
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes

Any reasonably aged language by Anonymous Coward · 2017-12-31 19:25 · Score: 1

Despite every example online... it is possible to write clean perl. That said, I've not seen any reasonable dbi example. It's all the same bad garbage over and over. This led all the Python followers to declare there is no good perl and no bad Python.

Several years later, indeed there is now lots of bad Python in existence! As time marches on there are even more examples of this behavior.

I would argue any language of sufficient age will have an equally large sum of poor examples.

Languages can sing and it takes work to make them so so.

Haskell and C++ programmers are different. by shess · 2017-12-31 19:31 · Score: 4, Insightful

Something the linked article didn't seem to address it that the population for each language will differ. The average Haskell programmer is going to be very different from the average C++ programmer, or, god forbid, the average Python programmer.

Also, while they did try to address problem domains, I don't think they addressed systemic issues. For historical reasons, there are many projects which use C or C++ simply because of what they need to interface with to get the job done. For instance, there simply aren't going to be that many browser projects which aren't written in C++.

Personally, I think the interesting take-home is not the difference between languages, it's how small the number of commits for security and memory issues was.

Re:Haskell and C++ programmers are different. by serviscope_minor · 2017-12-31 20:58 · Score: 4, Interesting

Also, while they did try to address problem domains, I don't think they addressed systemic issues.
I don't think they do: none of them have things like zero overhead abstractions, zero cost memory allocation and so on. And some of them (like go) lack the kind of abstractions present in many modern languages.
For instance, there simply aren't going to be that many browser projects which aren't written in C++.
Of the three remaining extant enignes: Firefox, Webkit/Blink and Edge and Trident all except firefox are written in C++. Firefox is partly Rust now.
Rust I think is one of the very very few languages aimed a the same problem domain as C++ by people who understand enough C++ to know what the problem domain was. Look for example at Pike's rants on GO and how was designed to replace C++ and didn't: many C++ programmers sikmmed the features and said something like "oh that'll make my program slowe, more verbose, buggier and harder to write". Rust on the other hand is the same machine model as C++ but with a very very different type system.
It's never going to replace C++ across the board that's for sure but it's proven capable of replacing C++ in a niche where formerly there were no contenders.

--
SJW n. One who posts facts.
Re:Haskell and C++ programmers are different. by SwashbucklingCowboy · 2018-01-01 02:10 · Score: 1

I'd venture that the small number of commits for security issues is because many developers 1) don't mark issues as security issues (security not being foremost in their mind) and 2) many developers can't recognize issues as affecting security (which is even scarier).
Re:Haskell and C++ programmers are different. by Wookie+Monster · 2018-01-01 06:18 · Score: 1

Where are Pike's rants on Go? I tried a simple search but didn't find anything interesting.
Re: Haskell and C++ programmers are different. by tigersha · 2018-01-01 16:44 · Score: 1

Same here

--
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
Re:Haskell and C++ programmers are different. by serviscope_minor · 2018-01-01 23:56 · Score: 1

There:
https://commandcenter.blogspot...
Basically he's throwing a bit of a strop because C++ programmers didn't flock to go.

--
SJW n. One who posts facts.

Conclusions only valid on Open Source Projects? by mykepredko · 2017-12-31 19:58 · Score: 4, Interesting

This is an interesting study, but I don't know if the results can be extrapolated to include closed source software.

My problem with this is that I don't see any evidence of:
a) Projects in the study have a published project plan with somebody managing it at a high level (I would think the Linux Kernel could be thought of as having a plan with strong central management ). I tend to believe that projects in which multiple individuals (with varying levels of understanding of the software, the app's background and issues experienced during development) would be at a much lower quality level than something managed by a strong, continuous team - this doesn't seem to be a consideration when I RFTA (popularity of projects seems to be a bigger issue).
b) Different development tools used by different developers. In terms of the C/C++ typing issues, Windows software developed and built in Visual Studio, Eclipse Text Editor with MinGW or something like Komodo Edit with Cygwin and user written make files will identify different typing issues and may generate code that works differently, especially in regards to identifying and handling typing issues. I would like to know how many bug fixes are the result of something that isn't flagged and works fine on VS and doesn't work when built in MinGW, leading to a fix.
b.1) I'm not 100% sure of the methodology used in this study, but wouldn't a file that originally had tabs for indentation that an editor automatically changes it into spaces be misidentified as a "fix" if it's uploaded back into the repository? This is a combination of b) and c).
c) Different coding styles. I know of several Open Source projects in which a developer has re-formatted code simply because they don't think it's in the "correct" style and they have difficulty reading it resulting in them changing it so they can follow it better. To be fair, I'm sure a lot of us have done that because some people have very different and strongly felt ideas about how code should be formatted.
d) Lack of formal testing methodologies. I don't think many Open Source projects have strong, automated regression testing processes and methodologies before allowing a new release.
e) Difference in functional use of different languages. I would think that methods written in C, C++ and Objective C would be providing more low-level functionality than Clojure, Haskell or Scala. Ruby probably fits somewhere between the two groups.

Comments?

--
Mimetics Inc. Twitter

*Difficulty of task* by Anonymous Coward · 2017-12-31 20:03 · Score: 1

More like difficulty of task.

If your coding in C, you can pretty much guarantee you're doing something low level, complex threaded and difficult.
C++ and it could be some major app.
If you're using a nice fluffy wrapped language, it will often be used for some office 'form' style application.

The idea that bugs stem from the programming language and not from the complexity of the task being tackled is bogus.

Python by _merlin · 2017-12-31 20:16 · Score: 5, Insightful

I know I'll get flamed for this, but Python is really error-prone in a particular area, and that's its ridiculously weak name resolution rules. In a language like C, Perl, or even PHP, names are resolved during the compile phase. The compiler knows which definition of a name is going to be used at any point. Python doesn't have this - when it runs across a name, it walks up the scope hierarchy looking for a candidate.

This means that code can run happily for months or even years, until it just crashes with an undefined name error. This could be because of a rarely-used code path with a typo in it, botched refactoring of a rarely-used code path, or a particular set of rare circumstances where a global name isn't set before the code gets to a certain place.

The usual response is that unit tests should catch this. But let's face it, 100% unit test coverage is pretty rare, particularly for the kind of fast turnaround stuff that Python's frequently used for. Also, unit testing isn't necessarily going to simulate a corner case where a global doesn't get set before code that uses it executes. It also makes refactoring more risky because there's no point where the compiler can tell you you're referencing a name that's no longer defined, or no longer has a certain method/field.

This is the kind of area where it's really useful if the compiler can help you, and Python's ridiculously weak name resolution rules make that completely impossible.

Re:Python by vtcodger · 2018-01-01 00:30 · Score: 1

I don't think Python's name resolution is a major source of bugs. But I don't disagree that its name resolution sucks. At least for me using Python 2. I've always assumed that the problem is that I'm too damn dumb to understand whatever brilliant scheme underlies its name resolution/namespace logic.

--
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
Re:Python by Just+Some+Guy · 2018-01-01 04:09 · Score: 3, Interesting

In Python, static checkers like pylint and flake8 are astoundingly useful for finding the low hanging fruit you've described. I have both wired into Emacs so that potential errors are syntax highlighted. If you're writing Python and not doing the same, you're doing yourself a disservice.

--
Dewey, what part of this looks like authorities should be involved?
Re:Python by phantomfive · 2018-01-01 17:24 · Score: 1

There's another study that backs up your point, and finds that it could cause up to 15% bugs.

--
"First they came for the slanderers and i said nothing."
Re:Python by Walter+White · 2018-01-02 02:33 · Score: 1

The first time I tried `pylint` it produced gobs of messages that all seemed to relate to style more than potential problems. That was the last time I tried pylint. There are probably settings/flags/options that make the output more useful but at the time I didn't have the patience to research that at the time. My usage of Python is best described as 'light scripting.' I don't know if it warrants the effort to use some of these tools.
I just tried it again on a 64 line script. Either I'm really bad with white space or `pylint` authors are obsessed with white space. But it looks like the output has been reformatted and it might be useful. (15 comments about white space and style for constants before the first real warning.)
Re:Python by Just+Some+Guy · 2018-01-02 05:56 · Score: 1
You can safely turn off the style stuff. That said, it's there for a few reasons:
- It's nice when everyone formats their stuff similarly. You can open a file from Joe Stranger and expect it to look a lot like something you've personally written. This reduces the cognitive overhead of coming up to speed with new code.
- Although it's generally not possible for Python formatting bugs to invisibly change the code's meaning, it's easy enough to be consistent.
--
Dewey, what part of this looks like authorities should be involved?

APL Still A Write Only Language by Crashmarik · 2017-12-31 20:33 · Score: 1

source http://wiki.c2.com/?AplLanguag...

[6] L(L':')L,L drop To:
[7] LLJUST VTOM',',L mat with one entry per row
[8] S1++/\L'(' length of address
[9] X0/S
[10] LS((L)+0,X)L align the (names)
[11] A((1L),X)L address
[12] N0 1DLTB(0,X)L names)
[13] N,'',N
[14] N[(N='_')/N]' ' change _ to blank
[15] N0 1RJUST VTOM N names
[16] S+/\' 'N length of last word in name

As mangled as the above if you look at source link with it properly formatted with the correct characters it isn't any better.

Re:APL Still A Write Only Language by Crashmarik · 2017-12-31 20:35 · Score: 1

Actually thinking about it, it was always easier to just code a new function than try to read someone else's old stuff.

Languages aren't error prone. Programmers are by aglider · 2017-12-31 22:02 · Score: 1, Flamebait

The base concept is bulls**it on its own.

It's more like spoken or written human languages to me:
You need to study, learn and practice before being proficient.

If you think that you need a fast solution, then the language you know the best is among the right solutions.
Assembly isn't more error prone than English.
It just depends whether you are or not an idiotic programmer or a easy-going speaker.

--
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.

Re:Languages aren't error prone. Programmers are by TemporalBeing · 2018-01-01 17:44 · Score: 1

The base concept is bulls**it on its own.
It's more like spoken or written human languages to me: You need to study, learn and practice before being proficient.
If you think that you need a fast solution, then the language you know the best is among the right solutions. Assembly isn't more error prone than English. It just depends whether you are or not an idiotic programmer or a easy-going speaker.
Correct. No one language over another is more prone to bugs; it's the maturity of the programmers writing the code. Mature programmers won't have memory issues in C, C++, etc; immature programmers will have all kinds of bugs in any language - even memory errors in Java.

--
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)

"Errors should never pass silently" by munch117 · 2017-12-31 22:06 · Score: 2

Python program can be very self-diagnostic. Something goes wrong, it presents as an exception traceback from an uncaught exception.

A lot of bug reports I get go like this: Someone sends me a screenshot with a traceback, I look up the line of the error, find that the error is obvious, fix it, commit the fix, and I still have time for a cup of coffee before 5 minutes have passed. The reporter may not be happy because they can't get on with their work until I cut a new version, but other than that this sort of bug is of very little consequence: no data files have been corrupted or anything like that.

Then there's the other kind of bug, the subtle kind where everything seems to be working fine, but someone checked the output and it just isn't right: the totals on the report don't add up or something. These are the hard ones. And then you have to dig in and hypothesise and experiment and bisect and so on. Of course those bugs happen in Python programs as well.

But I bet the kind of bugs that put Python over average are the first kind, and that Python is below average on the second kind. Which is a good tradeoff.

Re:"Errors should never pass silently" by Anonymous Coward · 2018-01-01 00:43 · Score: 1

You're right that when a program doesn't do what it is supposed to do the bug is somewhat more severe than when you simply get hit by an uncaught exception. The latter kind can be attributed to mere sloppy coding, the first can be attributed to sloppy thinking and a severe lack of understanding of the problem domain.
For the user, both bugs result in the same conclusion: The program is broken. This has nothing to do with the language you use. Tracebacks are not exclusive to python, maybe the lack of compile time checks is, but that doesn't make a lot of difference.
A good programmer can handle his tools and solve problems correctly.
Re:"Errors should never pass silently" by Ihlosi · 2018-01-01 01:12 · Score: 1

Then there's the other kind of bug, the subtle kind where everything seems to be working fine, but someone checked the output and it just isn't right: the totals on the report don't add up or something.
Even worse are horrid bugs (think "buffer overflow") that in practice result in minor performance degradation (still well within the requirements).
Or, my favorite so far - using an unitialized variable that by complete coincidence is always zero at this point in this compile run, and zero is the value that it was supposed to be initialized to. It's an obvious bug in the source code that completely fails to manifest in any way - at least in this binary.
Re:"Errors should never pass silently" by Entrope · 2018-01-01 02:03 · Score: 1

No, that is a shitty tradeoff. If easily spotting a bug when someone tells you where to look is the most common situation, you are writing too much obviously bad code, and you should look at every line you write as a possible bug and write more (or better) unit tests.
In the group I work with, if you look at code that gets committed to shared repositories, the most common Python errors involve runtime detection of errors on code paths that only run in uncommon situations: in particular, use of undefined function or variable names, and putting a string-typed value where a number-typed value is expected (or vice versa). Statically typed languages avoid both of these problems, and loosely typed languages mostly avoid the second problem. Type confusion errors are often hard to trace their origin because the wrong-typed value can be passed through a long chain of function calls and storage.
Particularly annoying is a functional-style programming habit where my coworkers use tuples to hold strongly structured data, apparently mostly to avoid defining a class. They seem to think it is overall cheaper to write foo(1) than to write foo.job_id.
Re:"Errors should never pass silently" by munch117 · 2018-01-01 08:26 · Score: 1

In my line of work, silently computing the wrong value could easily cost my company millions. A minor production stop is manageable, but delivering bad product unnoticed is a disaster. So for me it's a good tradeoff. YMMV.
Statically typed languages often have some sort of default value system, e.g. default-construction in C++. I see that as an unacceptable risk: If I ever try to use the value of a variable that has not been explicitly assigned, then I want an error trap. I do not want the number zero, the empty string or an empty container object to be quietly and misleadingly supplied.
That's what a lot of the AttributeError's in Python are: Indicators of bugs that might have passed silently in a different language. Including some (but not all) statically typed ones.
As for NameError's, that's a tooling issue if you get those.
Re type confusion: yes, that can be annoying, and if you are dealing with undisciplined Python writers who never specify types in interfaces, then I understand how that can be a problem for you.
Re:"Errors should never pass silently" by _merlin · 2018-01-01 15:25 · Score: 1

A mistake in my line of work can cost millions in seconds. If you want a program to blow up on accessing an uninitialised member in C++, use boost::optional (or std::optional if you're using C++17), or a dynamically allocated object so it'll fault on a null pointer access. In python, an attribute error could be caused by a typo, incomplete refactoring, or an API change that you didn't deal with properly, besides a value being used before it's initialised.
At any rate, this is the kind of thing that you should be capturing in unit tests, and if you're getting it in production, you're not the kind of person I'd want working on software where mistakes cost money/lives.
The problem with relying on disciplined developers to specify types in interfaces is that it breaks down in the real world. Everyone's subject to time pressure, stress, and other reasons to compromise. There's also nothing enforcing the types specified in the interface, and there's nothing enforcing the interface provided by those types. You really need 100% unit test coverage to ensure every code path accepts/yields the specified types. C++ at least ensures you can't inadvertently supply/return an unexpected type before you even get as far as running the unit test.
Re:"Errors should never pass silently" by munch117 · 2018-01-01 18:58 · Score: 1

If you use boost::optional for every single declaration you make, then you get the same type of runtime errors as in Python. Except with lower quality tracebacks. I expect you don't, and my point stands.
Re:"Errors should never pass silently" by _merlin · 2018-01-01 19:25 · Score: 1

You can't see past the limitations of your favourite tool. In C++ or other sane languages, a lot of things can be scoped so they can't be used before they're initialised. You get an error at compile time rather than having it blow up when code path is hit in production. You actually get tools to reduce mutable state, which allows for better optimisation as well as identifying a whole class of errors at compile time. Functional languages (e.g. Erlang or F#) do this even better. Your whole point seems to be that you use Python's exception tracebacks (which are no better than Java or C++ with symbols) to compensate for inadequate unit testing and not being able to control scope.
Re:"Errors should never pass silently" by munch117 · 2018-01-02 05:38 · Score: 1

Having tools so that you could in theory do something is not the same as actually doing them.
Are you telling me that in your programs there are never any variables that are default-constructed, pending later acquisition of the proper value?
If that is so, then you are remarkably ... disciplined. Like it or not, you are relying on disciplined developers. But then I knew that as soon as you mentioned "C++".

Your whole point seems to be [...]
No, my whole point is that I believe that a relatively large proportion of the Python bugfixes measured in the article are for bugs that are relatively innocuous. That's all. Then you took the opportunity to attack my competency, because apparently someone can't disagree with you on the internet without being incompetent, but that's your problem, not mine.

Stupid comparison. by Qbertino · 2017-12-31 23:06 · Score: 2

Comparing PHP with Scala is like comparing "Game of Thrones" with "Ulysses".
Any n00b can program something useful in PHP within an hour. That's the whole point of PHP. That's why we have such amazingly feature complete systems like WordPress. Given, the architecture of these PHP systems is so bizarre any reasonably seasoned programmer will not believe his eyes when he looks at the actual code - but it does work (most of the time) and it is useful.

Scala is a programming language that forces you to know what you are doing. Yeah, no shit it has less bugs. If I don't know what a JVM and what bytecode is, there is little chance I'll even get started with Scala. Only an experienced Programmierung will get the point of Scala in the first place. Thus Scala code has less bugs. No surprise here.

My 2 cents.

--
We suffer more in our imagination than in reality. - Seneca

Re: Stupid comparison. by Anonymous Coward · 2018-01-01 01:00 · Score: 1

You even have bugs in your 1 sentence comments. Maybe you should calm down kid.
Re:Stupid comparison. by Tenebrousedge · 2018-01-01 05:17 · Score: 1

You apparently know little about PHP. That may or may not be a terrible thing, but holding up WordPress as a piece of the PHP ecosystem is unrepresentative, even disingenuous. It was obsolete when written and it can never be meaningfully improved. It's its own self-sustaining ecosystem that has nothing to do with anything written in PHP in the 15 years since then.
Modern PHP looks a bit like JavaScript, actually, and the frameworks are all very boring MVC. It's also (somehow) one of the faster scripting languages out there. You should update your prejudices.

--
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Re:Stupid comparison. by iggymanz · 2018-01-01 07:56 · Score: 2

You know little about the real world, the majority of web frameworks that use PHP such as drupal are badly written garbage. It is the language of the careless, the language used by builders of sites that get infected and that spread malware and cause identity theft.
PHP developers are like those that join the school band and want to play the triangle, blocks or cymbals.
Re:Stupid comparison. by Tenebrousedge · 2018-01-01 08:18 · Score: 1

Mentioning Drupal can be taken as an indication that you know nothing about PHP frameworks. You are simply displaying your prejudices.

--
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Re:Stupid comparison. by iggymanz · 2018-01-01 10:10 · Score: 1

take it as an indication that I have to deal with their incompetent code, the security breeches, data corruption, and resource problems they cause every fucking working day
Re:Stupid comparison. by Tenebrousedge · 2018-01-01 10:12 · Score: 1

If you work in an organization that used obsolete frameworks like Drupal, then you deserve what you get.

--
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Re:Stupid comparison. by iggymanz · 2018-01-01 10:33 · Score: 1

uh huh, but make a list of the top CMS systems and you find the top three and their market share is 60% Wordpress, 6% Joomla, 4.5% Drupal.
Re:Stupid comparison. by Tenebrousedge · 2018-01-01 10:57 · Score: 1

Weren't we talking about frameworks a minute ago? Joomla and Drupal are dead projects. I don't know why you're crying up a 4.5% market share. Well, except that you seem to be an idiot with an axe to grind.

--
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Re:Stupid comparison. by Tenebrousedge · 2018-01-01 15:56 · Score: 1

Framework != CMS, and I don't know how you can look at the clear downward trend for both of those and say, "Looks fine to me!", but the leaders of both of these projects are pretty well aware of the ground they've lost, and neither has the manpower to modernize their codebases. Search around for, "Jooma/Drupal dying" if you like, or you can take my word for it on the technical issues. I don't care to explain in detail because they're terrible and no one should even think about them.

--
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Re:Stupid comparison. by Tenebrousedge · 2018-01-02 08:26 · Score: 1

By whatever measure you want, they're dying. Ignore the writing on the wall all you like. And like I said, I really don't want to get into their technical issues, but neither project is particularly compatible with the rest of the PHP ecosystem or with modern workflows, and they're not likely to ever become so.
Now if we're done saying ignorant things about PHP, I have to go do some ritual cleansing and atonement for defending it.

--
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Re:Stupid comparison. by Tenebrousedge · 2018-01-02 15:06 · Score: 1

No, I said pick your favorite. Being willfully dense is just going to get you ignored.

--
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Re:Stupid comparison. by Tenebrousedge · 2018-01-02 18:29 · Score: 1

Holding steady meaning no new installations? Gotcha. We'll ignore those little downward trends too.

--
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.

Re:age of code by chrism238 · 2017-12-31 23:10 · Score: 1

True, but equally true that older code has been exercised for far longer, and may have been reviewed by many different people.

Re: age of code by Dausha · 2018-01-01 00:05 · Score: 2

FTFA:

"Project age is included as older projects will generally have a greater number of defect fixes; the number of developers involved and the raw size of the project are also expected to affect the number of bugs and finally the number of commits is bound to."

--
What those who want activist courts fear is rule by the people.

Re:The actual problem languages by Anne+Thwacks · 2018-01-01 00:15 · Score: 3, Funny

1) Javascript
2) C++
3) PHP
4) Javascript-based fameworks
5) Anything used to write an Excel or Word macro by the HR department

This is an unfair comparison: PHP specifically targets producing buggy products, and in the unlikely event that an HR compartment gets anything to work, it is even more unlikely to involve a computer.

--
Sent from my ASR33 using ASCII

Re:The actual problem languages by vtcodger · 2018-01-01 00:34 · Score: 1

Do javascript problems actually get fixed? Based on my experience with our ever deteriorating Internet, bugs in javascript "programs" live on forever.

--
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey

Re:APL Still A Write Only Language by vtcodger · 2018-01-01 00:41 · Score: 1

For whatever reason APL always reminds me of Arthur C Clarke's classic story "The Nine Billion Names of God." If anyone ever writes a readable APL program perhaps the stars in the sky will, without any fuss, go out.

--
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey

C, Perl, PHP, JavaScript, C++ by ReneR · 2018-01-01 00:55 · Score: 1

$subject says all, in that order, Not counting auto* script clusterf*ck ;-)

Re:C, Perl, PHP, JavaScript, C++ by serviscope_minor · 2018-01-01 03:17 · Score: 1

Not counting auto* script clusterf*ck ;-)
Are you complaining about the auto keyword or is "auto script clusterf*ck" some sort of distributed brainfuck?

--
SJW n. One who posts facts.
Re:C, Perl, PHP, JavaScript, C++ by gwjgwj · 2018-01-01 05:50 · Score: 1

Not counting auto* script clusterf*ck ;-)
Are you complaining about the auto keyword or is "auto script clusterf*ck" some sort of distributed brainfuck?
automake and friends, I suppose.
Re:C, Perl, PHP, JavaScript, C++ by serviscope_minor · 2018-01-01 23:50 · Score: 1

Oh I see.
I rather dislike automake. Gnu Make plus autoconf is fine though. Mostly autoconf gets a bad rap from very badly written scripts.

--
SJW n. One who posts facts.

typing by KeithConover · 2018-01-01 02:12 · Score: 1

As a long-time but hobbyist programmer (started with machine code before moving to A86 assembler), I found the discussion thoughtful and illuminating. I will therefore offer a snide comment that may contain a grain of truth, based on something I heard when I first began to code, but updated a bit. "Strong typing is for weak minds. But coders overestimate the strength of their minds."

Re:typing by f00zbll · 2018-01-01 03:08 · Score: 1

That was clearly spoken by someone that writes "new" code and doesn't have to maintain other people's code :)
Anyone that does integration work and has to glue together a dozen different systems written in a variety of languages will lean towards strong typing. Most of my co-workers that start out favoring weak-typing or duck-typing quickly realize maintaining code written by multiple people in weak-typing is a nightmare. Especially in an enterprise environment where every project "should have been delivered two months back". Quality is at the bottom of the priorities and you get shit code. At least with strong-typing, there tends to be fewer errors and the shit smells slightly better. Not that it ever smells good, but slightly better is still better.
Re:typing by Jeremi · 2018-01-01 08:33 · Score: 2

I'm pretty sure the "weak minds" quote was making an implicit argument for strong typing, not against it.

--

I don't care if it's 90,000 hectares. That lake was not my doing.

Whatever is used by inexperienced programmers... by Anonymous Coward · 2018-01-01 02:14 · Score: 1

In general, it will be whichever language is used most by new, barely literate programmers.

18 years worth of code? by SpinyNorman · 2018-01-01 03:18 · Score: 1

That in of itself makes the results next to useless.

In particular, considering C++ pre 2011 and after (c++11) as the same language from a prone-to-bugs POV is ridiculous. Sure, since it's backwards compatible you can continue to shoot yourself in the foot like it's 2010 (or 2000 - sheesh!) if you really want to, but if you're using C++ nowadays and having problems like memory leaks or dangling pointers then YOU are the problem, not the language.

I'm sure other languages have similar issues - if you don't use the latest features put there to help you, then who's fault is it?

This summary also makes me question the methdology:

The results? "The languages with the strongest positive coefficients - meaning associated with a greater number of defect fixes are C++, C, and Objective-C, also PHP and Python. On the other hand, Clojure, Haskell, Ruby and Scala all have significant negative coefficients implying that these languages are less likely than average to result in defect fixing commits."

Seems a bit suspicious that it's all the widely used languages, regardless of whether they are low level systems programming languages like C/C++, or high level scripting languages like Python, are per-their-way-of-measurement, more buggy than all the way more obscure ones such as Clojure, Haskell, Scala...

Shit. I think I've been trolled.

Re:18 years worth of code? by Entrope · 2018-01-01 03:39 · Score: 1

Well, they are using data from GitHub, so even though some of the projects go back 18 years, the projects should all be fairly well-maintained. However, the study's authors give no good reason to think that the kind of linear regression they use is appropriate. Even assuming a linear model is appropriate, their choice of variables seems arbitrary. For example, why is "log of project age" the right parameter to use, rather than some quantized version of age, or the square root of the age? Did they choose those by exploratory analysis (p-value fishing)?

good tinder for a flaming post war by v1 · 2018-01-01 03:35 · Score: 1

This is one of those flamebait topics that is basically pointless to debate. It's too general. There are too many ways to define a bug, and many of them depend heavily on indirect/abstract qualities of the language, such as what sort of people use it or what sort of problems it's most commonly used to solve. It's just impossible to remove enough of the unknowns and side-effects of one sort of bug to give a useful answer on any other.

For example. if you're going to judge a language on the code-to-fix ratio of commits, does that tell you how prone the code is to having bugs in the first commit, or how easy it is to find and commit fixes? Those two alone say very different (and somewhat opposite) things based on the same metric measurement.

I'm only going to scratch the surface here and try to list off a few of the things you could say make a language "more buggy":

- typical user has below-average coding skill in general
- typical user doesn't follow standards well
- poorly defined standards
- hides bugs with coercion, ignoring return values, and other methods of ignoring behaviors which could easily be either a shortcut or a bug
- scope is wide or unbounded (a very relative metric)
- tends to be used to solve more complex problems
- used in new fields where users are less educated in the problem they are trying to solve
- poor debugging feedback
- poor quality crash dumps
- poor quality of available or more commonly used compilers
- compiles directly to target platform rather than using an established post-compiler
- use of optimizers that haven't undergone rigorous testing (edge-bugs in optimizers are a PAIN to debug)
- poor documentation / built-in help
- average reliability of most common target platform

Even with this limited set, I don't see how you could assign weights to be able to get any more than even a rough comparison between two languages. I think I could compare any two languages and make a case for either being better with regard to bugs. (and instead of you suggesting two for me to try, do it yourself... take those two you have already jumped on after reading that last statement and go try for yourself instead of challenging me)

--
I work for the Department of Redundancy Department.

GTA III by epine · 2018-01-01 04:04 · Score: 1

But I bet the kind of bugs that put Python over average are the first kind, and that Python is below average on the second kind. Which is a good tradeoff.

It would be no different in C++ with end users programming in the modern idiom on top of mature application libraries that support and encourage the modern idiom.

C++ is the GTA III of programming languages.
cout << "Open, world!" << '\n';

Let's look at programmers by plopez · 2018-01-01 04:21 · Score: 1

Looking at programming languages is good but this report implies there are other factors more important at play. What is the demographic of a good programmer? What is the marker of a good programmer who does not produce bugs? Ivy league vs. "Scheme certificate in 90 days" training programs? Wyoming programmers vs. California programmers? Just graduated 20 somethings vs. 50 year olds? Traditional CS programs vs. explicit software development training programs?

We all have our biases, but let's see what, if anything, pops up.

--
putting the 'B' in LGBTQ+

Re:Perl? by OzPeter · 2018-01-01 04:40 · Score: 1

Perl is in there on the low side with the strictly typed languages. I guess this is because in perl no one can actually read the code in order to work out the bug later - hence a win for minimizing bug fixes.

Nah .. its' because even if you pound on the keyboard with sheer frustration at Perl EG %&%^@$#&%^&(* you still produce a valid program that solves a problem.

--
I am Slashdot. Are you Slashdot as well?

Toying with languages vs professional use by OrangeTide · 2018-01-01 05:08 · Score: 1

While there are professional Haskell programs, there are lots of amateur projects on github that don't get much love from the authors. There is certainly a real effort to filter out the many small and insignificant projects, I feel that someone learning Haskell that is a bit obsessed with lots of small git commits can create a large enough commit history to get through the survey's attempts to gather statistics on different languages.

Basically I think the differences between the languages can be explained by the differences in the behavior of the people who are drawn to those languages.

A moderately experienced programmer with a methodical approach should be able to write code with few bugs and detect and address those bugs quickly, no matter which language they use. Of course carefully writing your web blog back-end in Brainfuck is a lot more work than doing it in PHP and I'd expect it to take a lot longer time. In terms of quality it's hard to quantify it based on language alone, except perhaps in very large projects with many contributors.

--
“Common sense is not so common.” — Voltaire

As a programmer, what I do is this: by hey! · 2018-01-01 06:45 · Score: 1

convert problems I don't know how to solve into problems I *do* know how to solve. That's what programming is.

So using that methodology, I have to ask here: which programming languages are the most popular?

--
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.

I've tested software for over 25 years... by gestalt_n_pepper · 2018-01-01 07:50 · Score: 1

And the most buggy software is always C, C++, Objective C or anything else that encourages a human to manipulate pointers and/or memory.

Most buggy framework? WPF, by far. I haven't had to test UWP yet, but it looks like an even bigger, overly elaborate clusterfuck.

Sometimes newer is not better. I despised MFC, loved Winforms, which is inflexible and dull as dishwater, but simple, obvious and easily testable (everything Microsoft appears to hate). It's all been downhill after that.

And don't get me started on ASP. I'm pretty sure the rise of the recent spate of rather nicely designed javascript frameworks happened because the ASP collection ranges from mediocre to Godawful.

--
Please do not read this sig. Thank you.

Re:I've tested software for over 25 years... by david_thornley · 2018-01-02 06:23 · Score: 1

Modern C++ doesn't encourage manipulating pointers and/or memory. You can do it, but there's usually better ways.

--
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes

Language never mentioned in comparisons by eliphalet · 2018-01-01 08:49 · Score: 1

I'm stuck using MS PowerShell at work, but PowerShell never appears in these reports about popularity, bug avoidance, etc. Not sure whether it is low usage, type of projects, or that it's for Windose.

Quantity versus quality by Big+Bipper · 2018-01-01 09:55 · Score: 1

This survey can't tell us anything about how hard it was to find those bugs ( time between reporting and fixing ) though. That would be a very interesting statistic if it could be produced.

--
You live and learn, or you don't learn much.

Re:High level languages by K.+S.+Kyosuke · 2018-01-01 12:41 · Score: 1

Linux and gcc could never be written in a high level language. Imagine writing Linux in lisp.

Ehm...not sure about Linux, but wouldn't GCC in Lisp be merely extending the MELT framework and the RTL syntax into the rest of the compiler?

--
Ezekiel 23:20

Re: High level languages by tigersha · 2018-01-01 17:12 · Score: 1

I have written a compiler in Prolog, and I assure you it was better than writing it in C.

--
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism

Demonstrating Java is the best. by sproketboy · 2018-01-01 17:16 · Score: 1

keep crying fagbots

Re:Demonstrating Java is the best. by ebvwfbw · 2018-01-02 15:29 · Score: 1

Really. Go sit in the corner for 2 hours.
If you haven't learned your lesson, slap yourself 5 times and sit in the corner for another 2 hours. Repeat until you admit your error.
Re:Demonstrating Java is the best. by sproketboy · 2018-01-05 09:03 · Score: 1

keep crying fagbot
Re:Demonstrating Java is the best. by ebvwfbw · 2018-01-05 13:07 · Score: 1

Keep crying? It took you 3 days to even respond. Either you were crying from slapping yourself silly or you were sucking your mom's cock before she pegs you again.
Re:Demonstrating Java is the best. by sproketboy · 2018-01-05 15:09 · Score: 1

keep crying fagbot!
Re:Demonstrating Java is the best. by ebvwfbw · 2018-01-06 06:12 · Score: 1

Look in the mirror
Re:Demonstrating Java is the best. by sproketboy · 2018-01-06 08:42 · Score: 1

WAHH

Interesting, but not especially useful by cshark · 2018-01-01 23:45 · Score: 1

Here's the thing. It's sort of an open secret. Open Source code sucks. It's always sucked. The only time it doesn't suck is when rigid standards are applied, or you have huge groups of professional programmers working on it. IBM and Microsoft both contribute huge amounts of open source code every year. Most of it is pretty solid, well written by pros.

That's the exception though.

I've worked with hundreds of open source projects over the years, even tried to manage a couple of them. And the reality is that the code that comes in is generally learning code. Stuff written by guys and gals who are picking up the language, whatever language it is for the first time. And that's not bad. It gives them valuable experience on a living app, and it gets me the functionality I want to download and use. Hopefully, without having to redevelop it too much. See, at the end of the day, I'm a pragmatist. If it does what I want it to do, and it doesn't incinerate my hardware or cause my vm to stop responding... I just don't care anymore.

Anyway, that's why you can't depend on open source code, most of the time, for something like this. If you are going to use Github to do it, you're going to need a much larger sample, if it's even possible to come to the conclusions the premise of the survey is trying to figure out. I would be curious to know if projects with only one person on them were more likely to be buggy than projects with active teams. Or if there's a difference in the rate of defects with professional teams vs amateur programmers. I don't think looking at the language itself is ever going to yield anything actionable, but there's a lot of meta around this that could be interesting.

--

This signature has Super Cow Powers

Re:Interesting, but not especially useful by swilver · 2018-01-03 04:00 · Score: 1

I'll let you in another secret.
Closed source code is just as bad. Software is written by people. Sometimes it is better (as people get paid to make it good) and sometimes it is worse (as there are people working on it that only care about getting paid). Sometimes people don't care about getting paid and enjoy what they do (then it is *really* good).
Re:Interesting, but not especially useful by cshark · 2018-01-04 21:30 · Score: 1

Oh, absolutely. No disagreement at all.

--
This signature has Super Cow Powers

Is it the language or the programmers by lsatenstein · 2018-01-02 05:55 · Score: 1

A programmer is a programmer. Some are born to program, others are programming to implement an idea. Some look at the code as an atomaton, where others just look at code as a set of frequently travelled links, ignoring wrong (you should not do take those traversal states).

You can program badly in any language. If you report C or C++ has having the most errors, its for a few reasons vis:

Most used languages of all the languages is C and C++. As a percentage of bugs reported for number of lines of code, add a new measure, the dimension of programmer's skill, you should find no differences between them and frequency of errors.

C and C++ have advantages of portability, and minimal execution overhead. C and C++ are not going away soon. Rust is a new language which, if you do multi-tasking, has built-in safety / type / decendant call checks for variables that are constant and or mutable. But the number of github entries for Rust is insignificant, when compared to the C's.

I measure the quality of code by the skill of the programmer and inversely proportional to the number of lines in a module.

--
Leslie Satenstein Montreal Quebec Canada

You hit the nail on the head. by Qbertino · 2018-01-02 07:28 · Score: 1

WordPress is an insane mess. The simple task of migration to another domain is nigh impossible with WP. With relatively well built systems such as Joomla it's done in a few minutes.

However, unlike my attempt 7 years ago with Joomla, I've actually manged to make a decent living of WordPress in the last 4 years and continue to do so. Thus I have decided to deal with the mess. It's sort of like bloated ERP Setups. They may be expensive and they may be outdated, but they provide an endless opportunity for stuff that needs to be done and can get billed. ... And at least it is open source.

Bottom line: Count me in on the never ending WP craze.

--
We suffer more in our imagination than in reality. - Seneca

Re:Whatever is used by inexperienced programmers.. by KingBenny · 2018-01-02 15:05 · Score: 1

yes well statistics like that (like most actually) are usually pretty much built on incomplete datasets so they show (if at all at least) what 'might' be the common denominator. I could read (without rtfm) that the languages that are around the longest and used most have had more faulty code written over the time period in which they have been used and as you so eloquently say, it doesnt really seem to stat the skill / xp / yearsofservice and knowledge of one or multiple levels per specific dev involved per language per project per number of bugs (lawl) etc... its new year, i guess the news need something to write about but i suppose they read something else

--
Free speech was meant to be free for all... how can anyone grow up in a nanny state ?

Shouldn't the answer be by Veretax · 2018-01-03 03:03 · Score: 1

All the ones used by humans? Seriously, the survey taken in this manner is more than likely, biased. Just because someone uses Github doesn't mean they put all their bugs in Github (which skews the numbers), furthermore, its likely that newer languages may be using techniques which allow a lot more bugs, but they get found because of process and aren't being checked in with bugs because of it. Translation, modern methods have a lot more to do with lower bug counts in newer languages, then anything I'd imagine.

Re:APL Still A Write Only Language by DavidHumus · 2018-01-03 08:37 · Score: 1

Here we go again - people with their eyes closed saying how dark it is.

It's like saying that French is impossible to read or speak when you've never even tried to learn the language.

I've worked several large, complex systems written in APL and maintained by one or two people. I've also seen any number of failed attempts to re-write an APL-based system, usually with teams several times the size of the APL one.

Eye of the beholder by Tablizer · 2018-01-04 06:40 · Score: 1

What I'm hearing is that you're an idiot who can't handle more than a basic level of abstraction. I suppose those who prefer Java deserve what they get.

What's a "good" abstraction is often in the eye of the beholder. My favorite abstractions have driven others batzo. Generally one has to target something that is likely to be digestible to a typical developer. If you target the elite and/or only others who think like you, it gives the organization fewer hiring choices. It may be great job security for yourself, but it is not pleasant for the organization. Don't be selfish.

--
Table-ized A.I.

Missing Factor by herbierobinson · 2018-01-07 06:37 · Score: 1

The missing factor here is that they did nothing to factor in the exposure (how many hours the software has actually been used). That has a huge effect on the number of defects discovered. All this could really mean is that C++, C, and Objective-C, also PHP and Python are what most heavily used software written in.

--
An engineer who ran for Congress. http://herbrobinson.us

Slashdot Mirror

Which Programming Languages Are Most Prone to Bugs? (i-programmer.info)

160 of 247 comments (clear)