Do Strongly Typed Languages Reduce Bugs? (acolyer.org) 456
"Static vs dynamic typing is always one of those topics that attracts passionately held positions," writes the Morning Paper -- reporting on an "encouraging" study that attempted to empirically evaluate the efficacy of statically-typed systems on mature, real-world code bases. The study was conducted by Christian Bird at Microsoft's "Research in Software Engineering" group with two researchers from University College London. Long-time Slashdot reader phantomfive writes:
This study looked at bugs found in open source Javascript code. Looking through the commit history, they enumerated the bugs that would have been caught if a more strongly typed language (like Typescript) had been used. They found that a strongly typed language would have reduced bugs by 15%.
Does this make you want to avoid Python?
Does this make you want to avoid Python?
Bug Conservation (Score:5, Insightful)
I suspect that there is something like a "law of conservation of bugs" or something in software - you take away one vector for bugs to originate and you just move them into another place.
Dynamic languages do have an easy way to introduce bugs - especially languages like javascript that simply create new variables if you have a typo.
But there is the old adage in statically typed compiled languages "Hey, my code compiles! Now I get to find out where all my bugs really are."
This also applies to other aspects of programming languages. Consider the arguments about manual vs automatic memory management. Managed code still has bugs, just not memory management bugs.
Re:Bug Conservation (Score:4, Insightful)
I fully agree. Bugs are just getting more destructive and harder to find the less permissive a language is. Also, if you cannot make type-errors, then any random person can write type-error free code. Type-errors simply cease to become a quality-metric in that case. That does not mean that the code is better in any way though.
Re:Bug Conservation (Score:5, Insightful)
That does not mean that the code is better in any way though.
It doesn't mean it is good, but of course its "better". A certain class of bugs eliminated.
All the subtle bugs and shitty coding practices may remain, but at least one issue is taken care of.
I despise javascript because in code of any complexity, a stupid typo in an infrequently used if-then-else clause explodes at runtime, possibly weeks or even months later. Sure its simple and easy to fix, but holy shit how can anyone want to use a language that doesn't catch just catch this stuff for you before it even tries running it.
Re: (Score:3)
Sure, if you ignore the cost of re-testing and redeploying, plus the cost of lost business caused by the bug and so on. The earlier a bug is detected, the cheaper it is to fix [wikipedia.org], by orders of magnitude.
Re:Bug Conservation (Score:5, Informative)
But the destructive hard to find bugs are still there with the weakly typed languages. It just takes you longer to get around to dealing with them.
Re:Bug Conservation (Score:5, Interesting)
If there is some truth to what you I suspect its for tangental reasons. I'd hypothesize that languages that solve many of those categories of errors have much lower barriers to entry and therefor you get more cowboys using them who are making other kinds of mistakes because they're idiots and not because a programmer must make some fixed number of mistakes somewhere. Those people wouldn't be trusted with languages that didn't prevent them from introducing certain types of bugs because they would be counter productive for their team and create more problems than they solve, but languages that cut down on the potential types of mistakes that can be made mean there are entire categories of bugs that they can't introduce and that they can probably be productive.
It's another old adage: "Make something foolproof and the universe will invent a better fool."
Re: (Score:2)
That is pretty much how the argument goes. And if you look at the abysmal state of competence of most modern "web coders", you can see a very nice example of this idea in practice.
Re:Bug Conservation (Score:5, Interesting)
And I suspect there is no such law at all as it seems based on nothing.
Better languages do result in less bugs. They may open vectors for a different type of bug, but that does not mean they are as frequent or as dangerous.
Take memory management. One misstep and your program gets killed or crashes because it reads or writes from memory that does not belong to it. Very easy to do in some languages, while other languages completely eliminate this class of bugs. Of course poor memory management can then result in memory leaks, but it won't crash, and not all such problems become memory leaks.
Some languages also practically eliminate arbitrary code execution and injection attacks, making them inherently more secure, at the cost of having bounds checks compiled into your program. This again eliminates a whole class of problems and introduces no new problems (maybe performance problems, but those are not bugs).
Then there is code maintenance and refactoring, something which is near impossible with loose languages. This is often why is not even attempted, leaving your with a code base that, if not planned in excruciating detail, will wither away and die. Just look at all those Javascript frameworks that rise and fall and don't even try to maintain backwards compatibility... I think it is because they all turn into unmaintainable pieces of spaghetti code that no sane programmer wants to keep working on for long.
It happens often enough that people write hundreds of lines of new code in a compiled language and actually find it runs correctly the first time. Perhaps you haven't experienced it yet... I have on many occasions.
Re: (Score:2)
It is funny how code written in your "inherently more secure" languages gets exploited at the same or higher rates these days. What actually happens when languages get "safer" is that coder competence drops and bugs just move to a higher level, without being any less destructive. If you cannot see that happening over the last few decades, then you seem to be blind to what is going on.
Re:Bug Conservation (Score:5, Insightful)
Incorrect. What actually happens is that with safer languages, more people can write software and the *average* competency drops. It does not however affect the competency of already competent coders when they use more secure languages.
You'd think that be obvious, but please keep convincing yourself.
Re: (Score:2)
I know, with the same degree of certainty that there is an objective universe that exists independently from my perception, that what you just said is bullshit.
There is correct code, and there is flawed code. It is possible to write software that doesn't crash, that can't be exploited, and does precisely what it is supposed to do for all possible inputs. The only thing standing in the way of that is incompetence
Re:Bug Conservation (Score:5, Insightful)
This is not true. Sure, strongly typed languages won't eliminate all the bugs and the ones that are left may be quite tricky to find, but it is absurd to suggest that the ability to run a program where you typed a variable name wrong means that those tricky bugs are magically not there.
Language matters (Score:2)
What a silly question (Score:5, Interesting)
This observation doesn't make me wish to ditch a programming language, but it does make me glad I do test-driven development.
Well duh (Score:4, Insightful)
Python solves this with decorators (Score:4, Informative)
Re: (Score:2)
I do that whenever it matters. In many places it does not, but sometimes it is really worthwhile.
Re:Python solves this with decorators (Score:5, Informative)
I don't mean to be pedantic, but Python is inherently strongly typed.
What it is not is "statically typed".
I think there is a general confusion in this thread between strong vs weak typing, and dynamic vs static typing.
Title of this thread is messed up. (Score:5, Informative)
They are two completely different things.
Makes sense to me (Score:4, Informative)
As someone that has had to program in a number of languages I can say that strongly typed languages can catch a lot of trivial bugs quickly. One example is an if/then statement that allows non-Boolean arguments. If I mistype a comparison in an if/then statement then I should expect an error on compile. If I type an assignment "if (foo = bar)" instead of a comparison "if (foo == bar)" I expect this to get flagged, but some languages don't see this as a problem.
I prefer strongly typed languages as it can catch a lot of typographical errors and sloppy logic. It can also be frustrating at times since it can mean nesting type conversions to near absurdity. VHDL comes to mind in this. It can also be frustrating if trying to do something quickly and the compiler complains on what I would think is a pretty obvious implied type conversion.
It's interesting to see someone try to get an idea on how many errors strongly typed languages would catch. I'm not sure this makes an argument for one language over another. It might make an argument for testing, coding style, and such though.
Re:Makes sense to me (Score:4, Insightful)
"if (foo = bar)" isn't a bug in the code. It's only a bug in your brain.
bar = ;
if( foo = bar )
{
foo += 2;
}
so foo is bar+2 if bar is true, otherwise foo is the same false as bar, be it undef, zero, null, or blank. And if you add some local scoping, being able to manipulate foo without manipulating bar often makes a lot of sense, especially with complex objects, and especially with functional logic like if(foo = dclone(bar)) -- or the much more routine if( record = dbgetrow(statement) ) which I'm absolutely certain you've done more than 100 times.
The bug in your brain is actually not a programming one. It's a visual one. Why are "=" and "==" so visually similar when they are functionally different? I might suggest using instead of == in perl, although the boolean would be reversed. At least cmp covers you for strings. .
By the same token (Score:3)
Have they also looked at bugs that typically plague statically typed languages but dynamically typed languages usually don't suffer?
For example, many statically typed languages do little or nothing to help you avoid integer overflows, which can result in severe crashes and vulnerabilities. Many dynamically typed languages, such as Python, gracefully switch to big integer types as needed.
Strong types (Score:2)
I've been using Janson and Bookman lately. Futura for san-serif. What was the question, again?
type errors in scalars (int, etc) (Score:3)
In my experience, type errors are a lot more likely for scalars than for composite objects, i.e. I'm less likely to "add apples to oranges" than I am to add "count of apples" to "count of oranges". (Or horizontal pixels to vertical pixels, a real mistake I made once.)
I suppose it's possible to do typed scalars in C++, not sure about Java (without tool extensions). But making a scalar into a full 'class' is probably overkill (with runtime impacts).
The combination of typed scalars and named parameter associations that languages like Ada have can catch a lot of errors at compile-time (with good quality diagnostic messages). And this supports refactoring by making it easier to find the impacts when an interface changes (for instance, if you go from a single type 'pixel location' to separate types for 'horizontal pixel location' and 'vertical pixel location'), you just find and work off the type errors reported by the compiler. (Been there, done that.)
Of course, it's not Politically Correct to favorably mention Ada (so often a technology is panned by those without substantial experience using it.)
Pascal fan (Score:3)
After the initial introduction to computing via BASIC, I picked up Pascal (Turbo, of course) and fell in love with it. I prefer a language where you have to declare all your variables and won't let you assign one type to another type without type casting or properly converting. I also want it to be case insensitive because I've seen code where the idiot used "foo", "Foo", and "FOO" as different variables.
I haven't touched Pascal in years, but I miss it occasionally.
Preference. (Score:3, Interesting)
I prefer strongly, statically typed programming than programming in e.g. Python. Like even Java, which is in many ways a horrible language, is more understandable for me. You need to understand the importance of the first two and last two words in that sentence though.
Why is it better for me to catch stuff at compile time? Because I prefer it that way.
Why is it preferable for Pythonistae to do whatever they do? Because they prefer it that way.
I have a very intelligent and productive friend who loves Python and has no problem with the way it handles types. I find Python annoying and avoid it, partially for that reason. But what would it even mean for him to be "wrong", or for me to be "wrong", or for either of us to be "right"? Nothing, that's what.
Stop bitching at each other and having stupid arguments like the "other side" is trying to steal your toys or come in your ice-cream.
Oblig: "LambdaConf 2015 - Dynamic vs Static Having a Discussion without Sounding Like a Lunatic" https://www.youtube.com/watch?v=Uxl_X3zXVAM
They're asking the wrong question (Score:5, Insightful)
The question isn't really "Does a strongly typed language reduce bugs?", because the obvious answer is: Yes, it does. If you went to the logical extreme and created a language that only had 3 commands, you could eliminate whole classes of bugs. The more strict the rules, the harder it is to do the wrong thing.
But the question is really: Would developers spend more time fighting against the type system in a strongly typed language or against type related bugs in a dynamic one?
The answer to that question seems much murkier, and I don't think a study looking at the types of bugs checked in on GitHub can answer it.
strong typing != static typing (Score:5, Insightful)
The article talks about static typing, not strong typing; the two are different concepts. Strong typing means that type errors are always caught, static typing means that if type errors are caught, they are caught at compile time. JavaScript is both weakly typed and dynamically typed; weak typing is probably a bigger problem than dynamic typing. In any case, whatever conclusions you derive about type systems from experimenting on particular languages really only apply to that language. TypeScript is nice for JavaScript; that doesn't mean that adding static typing to Python would be as useful.
In addition, there is a price to pay for static typing: software becomes more complex, people tend to implement their own "dynamic type light" libraries, etc. So, even when static typing reduces bugs, it's not clear that it results in a better product at a lower cost, which is what you ultimately care about.
Perl is strongly typed (Score:3, Interesting)
The article shows javascript as buggy and untyped with 3 + "0" = "30" -- the classic stupid example.
Everyone likes to say that Perl is weekly typed, because "1.5" + 1 = 2.5.
Everyone is incorrect. Perl is very very very very strongly typed. Not the variables, the operators. Not the nouns, the verbs. Developer says "add these two variables", and perl adds them. Because the developer said so. If the developer said "concatenate these two variables" then perl will concatenate them. Every time.
That sounds strongly-typed to me. "3" + "1" = 4; 3 . 1 = "31". Every time.
I dare you to find out what perl does with 3 + "information". Go ahead. I dare you.
My point is this. Human beings don't care about type. An apple is an apple, and an orange is an orange, and I can eat them together, cook them into a sauce, bake a pie, cut them up, juice them, or put them into a basket. Whatever I tell you to do with them, you'll never respond with "but apples can't do that because they aren't oranges". Just bake the g.d. pie, because I told you to.
Now, if you can explain to me why any language would ever use the same symbol for "add" and "concatenate", then you're smarter than I am. For the life of me, I've spent 30 years trying to understand that one. What idiot makes one symbol do two things, and then builds the language to guess which one to do based on the values themselves, at the language-level no less? Idiotic.
Re:Perl is strongly typed (Score:5, Informative)
Thats still weakly typed, just a different kind of weak. Strongly types is when you fail; "a" . 1 would throw an exception and say "i dont know how I can possibly proceed" if it was strongly typed.
Strong typing vs weak is a minor detail anyway; the real meat is dynamic vs static.
Comment removed (Score:5, Interesting)
That's easy: Yes. (Score:3)
I basically program exclusively in PLs with sloppy typing and no compiling and stuff. Python, PHP, JavaScript the works. The speed at which you get stuff done is notable, especially compared to classic "Type Nazi" languages. However, the trade-off is clear as can be: Write critical code beyond a certain scale in sloppy type PLs, and you're asking for trouble. Type Nazi languages force you to think before typing ... errrm ... hitting the keys ..., and that is a good and useful thing if the use case isn't a trivial scripting stuff that you can debug and modify on your Smartphone willst sitting on the bus.
Sloppy typed PLs have some stopgaps (code standards, frameworks, hacks, transpired dialects (such as JavaScripts TypeScript) but those are things intended to cover the gap and cater to specific needs.
Long story short: Nazi typing is more work to front but prevents lots of trouble downstream of large non-trivial projects, including a specific subset of bugs.
Re:You have to look at the source (Score:5, Informative)
Since I have programmed in many different languages I have personally discovered that strongly statically typed languages do solve a lot of problems because the problems are encountered already at compile time, not during runtime. The problems are also less elusive.
There are of course still bugs around, but they are more often on the strategical level than on a pure sloppiness level caused by misspellings and mismatching methods where a method is changed but one caller isn't.
Re: (Score:3, Informative)
I find it easier to refactor strongly typed languages as the compiler does most of the work for you before even running the program.
I also get the feeling that strongly typed languages have better support for IDE based refactoring as more can be safely inferred about their structure.
Re: You have to look at the source (Score:5, Insightful)
I normally try to avoid personal attacks, but you, sir, are an idiot bitch.
The number of times I've fixed a god damn typo in a variable name made by someone who refused to stop coding in vim like it's the god damn dark ages is well beyond what I can count on my fingers, even in binary.
And if the language had been strongly typed, the code never would have been able to build on the first place. But it did. And it silently failed for years.
Terrible programmers always think they're the best and don't need help. Grow the fuck up and realize you need all the help you can get, same as everyone else.
Re: (Score:3)
Some languages (e.g. Java) are basically unusable without modern IDEs. Whether it's code completion or refactoring editing, I'm pretty sure that it's impossible to get any work done in Java without the toolchain.
More seriously, though, for languages like C++, the state of debugging is absolute shit outside of IDEs. You will never to back to pain GDB and LLDB once you've used a real IDE-based debugger.
I'd rather program in Vim (if you would rather program in Emacs or whatever, good for you; get one decent ed
Re:You have to look at the source (Score:5, Interesting)
Two additional advantages of strongly typed languages: ability to use refactoring tools, and easier code maintenance - particularly in code reading to recover business logic.
I am currently working with a Python (sub)program, part of a large web system that I do not have access to. The data comes in in messages of an undocumented JSON format, so from beginning to end the type of a variable is whatever the type it is, and the name of the 'variable' is whatever the label string associated with the data was. It is very difficult to deduce what any part of the processing means.
Re:You have to look at the source (Score:4, Interesting)
Re: (Score:2, Informative)
Exactly what I was thinking. It isn't just that the end code might have 15% fewer bugs development will be quicker/more confident because a bunch of the stupid little mistakes you make while coding are automatically checked for and swigglies tell you fix them right away.
Re: (Score:2, Insightful)
Exactly what I was thinking. It isn't just that the end code might have 15% fewer bugs development will be quicker/more confident because a bunch of the stupid little mistakes you make while coding are automatically checked for and swigglies tell you fix them right away.
Except that weakly typed languages, Python, JS, and Perl, tend to more concise and quicker to write than strongly typed languages such as C, C++, and Java.
It really depends on the resources you're willing to invest in the project. If you have a good staff and are willing to invest the time then a strongly typed language can give you something more reliable.
But if you're investing fewer resources than weakly typed might be the way to go, you'll miss some dumb bugs due to the typing but you have less complexi
Re:You have to look at the source (Score:5, Insightful)
That used to be true, but I don't think it is so much anymore. Modern languages like Swift, Scala, Kotlin, etc. do a good job of being concise while still keeping full type safety. And that ends up making them faster to write. I also do a lot of Python programming, and spend way too much time running my code over and over just to discover typos and similar mistakes that my editor would have instantly highlighted for me if I'd been working in a statically typed language.
Re: (Score:3)
> Besides, if your unit tests are not testing things sufficiently to catch any of these, they you're already doing things wrong.
My main take away form this whole thread is that strongly types language people dont write unit tests and spend lots of time debugging.
I use both static and dynamic languages out of necessity, and in my experience the dynamic languages take significantly less time to produce working code.
Re:You have to look at the source (Score:5, Insightful)
No they take slightly less time to get kind of working code- and significantly more time fixing the bugs in it and significantly more time in maintenance to understand what those bugs are and what data an algorithm is working on.
Re:You have to look at the source (Score:5, Insightful)
The idea that you develop more rapidly in weakly typed languages (and, implicitly, the importance of maximizing development time) seems to stem from two erroneous assumptions.
The first is that we spend the majority of our time developing. This may be true for hobbyist programmers and possibly even consulting work for small projects. For any effort beyond that, which is the majority of paid programming work and popular open source products, the majority of time is spent fixing bugs.
The second is that strongly typed languages have to be slower to develop. In almost every domain at almost every level of complexity, I find Scala faster to develop in than Python. It gives me strongly typed error-checking as I write the language by using the presentation compiler (assuming modern IDE) to highlight issues early on. It also gives me type inference so I do not often have to specify the types I'm working in at many declaration sites. Finally, it gives me a terse transformation of collections using the combination of strong typing and type inference. I also spend less time thinking about how to express what I want to do.
For any large scale project, if the IDE can allow you to click through to a definition of a complex type or method definition, this saves oodles and oodles of time because we need to understand what we're calling and reading the code often is faster than reading the manual and deducing where it lied to you. If you're not calling code you didn't write, you're not doing something sufficiently complex as to really be interesting or you're writing something embedded in which case the focus on reducing bugs is even more important. Statically typed languages do a much better job of giving you this reference automatically.
Of course, this is all predicated on the types of development we're doing, because no language anywhere can beat the development speed of another language that has a popular, mature domain-specific library to solve a problem. If the language itself has operators or constructions which excel in a specific domain, it's also difficult to beat that language with any language that lacks that focus.
Re: (Score:3)
Your assumption that the idea stems from assumptions is erroneous.
The idea that you develop more rapidly in dynamically (FTFY) typed languages stems from observation and measurement. Like this one [fu-berlin.de].
So, maybe Scala would do better than Java and C++ in such a study, I'm not saying it wouldn't. It would be interesting to see a newer study with contemporary languages.
Re:You have to look at the source (Score:4, Insightful)
This is where you're wrong. The complexity exists, regardless of the language. Type exists, whether your language is loosely or strongly typed. In one you just ignore it, which causes a class of errors. In the other you get free error checking. Pretending that complexity doesn't exist saves you no time, and causes errors. It's a net loss.
Re: (Score:3)
Except that weakly typed languages, Python, JS, and Perl, tend to more concise and quicker to write than strongly typed languages such as C, C++, and Java.
I think this is precisely TFA's point. Part of the reason why JS programs are quicker to write is that fewer bugs are removed before shipping.
In a language like C++ or Haskell, that time spent getting the compiler to accept your code is credited to "programming". A similar amount of time is spent in well-written Python or JS, but it's credited to "testing" or "debugging" instead.
Less stable product more quickly (one-time use) (Score:3)
> will give you a more stable product more quickly.
Weakly typed will more quickly produce less robust software, which is perfect for one-time use scripts, small programs written for well-known, well-defined inputs, etc.
As an example, suppose I have a log file of the format:
URL - bytes - epoch - username
If I want to produce some summary statistics from that particular log file, to use in my year-end presentation, a weakly typed language will let me whip up a simple script very quickly.
On the other hand, i
Re:You have to look at the source (Score:5, Interesting)
If one uses Strongly Typed Languages, one gets fewer Strongly Typed Language errors; only.
Yes. And?
Catching type errors during compile is worlds better than finding at runtime, perhaps by an end user. Does it prevent logic errors, or memory leaks, or failure to sanitize inputs, or race conditions? No. It doesn't. So what?
If one uses a thermometer to check the temperature of cooked meat, one only reduces one type of infection vector. Are you suggesting the use of thermometers to check cooked meat isn't a good idea, because it won't prevent malaria or syphilis? Because that is how ridiculous your argument is.
Re: (Score:3)
That's only partly true. Modern strongly typed languages make it very cheap to create a new compiler-checked type and free to use at run-time. This encourages the use of "strong typedefs" which a programmer can use to get the type checker to check other kinds of bugs.
So, for example, you can get the compiler to check physical units [haskell.org]. If you divide a "distance" by a "time", you'd better assign it to a variable of type "velocity".
Of course strongly typed reduces bugs (Score:3)
The answer is obvious that for identical code strong typing will reduce bugs. And yet does typing force people to write in ways that lead creating bugs?
More importantly why isn't there some gray scale on typing that I could slowly turn on as my program design matures? THis is what I would dearly love. Let me abuse polymorphism to add calling arguments during my exploratory phase but then don't make me switch to a different language when I want to tighten the screws.
What I'd like for example is an option
Re:Of course strongly typed reduces bugs (Score:5, Interesting)
The answer is obvious that for identical code strong typing will reduce bugs. And yet does typing force people to write in ways that lead creating bugs?
More importantly why isn't there some gray scale on typing that I could slowly turn on as my program design matures?
-Wall
-Wall -Werror
-Wall -Werror -Wextra
Also when writing in C++ mark sloppy convenience functions and constructors as deprecated so the scale above will complain and force you to fix them when the program matures.
Re: (Score:3)
More importantly why isn't there some gray scale on typing that I could slowly turn on as my program design matures?
You might be interested in type hints in Python [python.org].
Re:You have to look at the source (Score:5, Insightful)
This study is one of those "Well, duh!" type studies. Strongly typed languages are easier to refactor, maintain, and debug. It's also easier for someone else to understand as they can see exactly what types of objects are being used at any given point in the code.
Weakly typed languages are easier to do short, quick, dynamic programming. And arguably, that's what they were designed for. I'm not going to haul out a C++ toolchain just to write a few simple REST services when I can write a few short Python/Flask scripts in a fraction of the time.
As always, use the right tool for the right job. Well, unless all there are is shitty tools for the job in which case you're stuck using a shitty tool. I'm looking at you Javascript, you worthless piece of Turing complete trash.
Re: (Score:3)
Alternate hard and soft layers. [c2.com]
Re: (Score:3)
Yeah, these threads always attract large amounts of vocal idiots. People who assume "their way" is "the best way" and yet they've never actually spent _significant_ time using both languages.
To everyone else, the answer is obvious, so they don't feel the need to comment. Static languages exist BECAUSE they solve a myriad of types of bugs. Dynamic languages exist because they're easier to rapidly develop--but they fall apart at medium-to-large scale projects. And there are probably dozens more tradeoffs.
"Rig
Re:You have to look at the source (Score:5, Informative)
Microsoft's big platforms are C,C++,C# this really doesn't do much for them.
Lots of Borland/Pascal programmers are saying we told you so though.
Re: You have to look at the source (Score:2)
Yup. Many errors are detected at compile time. And, given the speed of the Borland Pascal and Delphi compilers, there was little time wasted. This resulted in most errors being of the run time variant. Strong debugging tools make it a breeze to knock them out.
Needless to say, neither the compiler nor debugger saved you from a piss poor algorithm or design.
Re: (Score:2)
C++ is pretty strongly typed. It's only static type analysis though, but no weaker than Pascal or Ada.
A lot of the bugs I see aren't messing up static types, but when you do see static typing problems then that means the programmer needs better training (not just experience since a lot of "experienced" people are stuck with bad habits). In particular the static type errors often come from sloppy thinking, a rush to get code checked in quickly, a misunderstanding of types, and so forth. Especially programm
Re:You have to look at the source (Score:5, Interesting)
Personally, I think strong typing is vastly overrated and those that need it should not be coding professionally.
Oblig. car analogy: those who need road signs shouldn't be driving professionally.
Re:You have to look at the source (Score:4, Insightful)
Anyone with a complete picture of their project is working on a toy. Leave college and you might find the world doesn't work the way you want.
Re: (Score:2, Insightful)
Urgh, Typescript. Well, MS has creates some truly bad languages and they are still hard at it. Of course, the only aim MS ever had with its own languages was to chain people to its equally horrible platforms. This study seems to be just another element of this strategy.
Re: (Score:3, Interesting)
What is wrong with Typescript?
I used JS for some of my hobby projects, but then switched to TS.
I found that the compiler catches a LOT of bugs. Type-Os, incompatible type assignments, incomplete branching (not all cases covered). At the end I even switched on the NULL checking, and I was astonished how many possible problems were still hiding in my code with regards to possibly NULL objects...
During my use, I did not see any real drawback.
The dependency on the compiler (external tool) was of course a negati
Re: (Score:3)
Urgh, Typescript.
If you need to write for web browsers, node.js etc. (and like it or lump it, those are important platforms at the moment) Typescript is far from "Urgh".
Not only is it an improvement over Javascript (type checking for starters, plus backward compatibility for a lot of 'new' Javascript features that aren't in all browsers yet) but - unlike some other compile-to-javascript languages - outputs perfectly readable, manageable Javascript code. Transitioning a TS project to plain Javascript would be a matter of t
Re: (Score:3)
Well, MS has creates some truly bad languages and they are still hard at it
They have. VB being a prime example. However, C# is what Java would be if it ever made it out of committee. It blows Java away in every way. Seriously. I've developed commercial Java apps since the late 1990s, and C# is leagues ahead of Java at this stage. Typescript is also, quite objectively, the very best way of developing JavaScript applications.
Interestingly the two mentioned are the brain children of one Anders Hejlsberg, the inventor of the (once quite nice, but today quite broken) Delphi.
Re:You have to look at the source (Score:5, Insightful)
Perhaps so. On the other hand, Microsoft has written tons of software over the years and perhaps this study might be born out of decades of experience?
From my own ~20 years of experience writing software (never at Microsoft, mind you), I'd tend to agree with them that dynamic typing is a very good way to introduce subtle errors that would have been easily detected in a static typed system. God knows how many man hours of my life were burned hunting down such bugs created by people before me in my software engineering career.
On the other hand, static typing generally induces a slow compilation step that you have to wait through hundreds of times when developing a significant application. Dynamically typed languages are generally interpreted and forgo compilation at the expense of some runtime performance.
For whipping out some throwaway code to get something up in a hurry, nothing beats dynamically typed and interpreted. But when I want to make something seriously strong, high performance, and lasting the test of time, I'll reach for my static typed compiler every time, thank you very much.
As usual, use the best tool for the job at hand, whichever tool that may be.
Re: (Score:2)
On the other hand, static typing generally induces a slow compilation step that you have to wait through hundreds of times when developing a significant application.
Hopefully the compilation step isn't that slow -- if it is, ask your boss for a faster development computer, it will pay for itself many times over. In my C++ coding, a partial recompile (just of the files I've edited recently) rarely takes longer than 10 seconds. (A full recompile could take several minutes, but that generally isn't necessary).
When that 10-second recompile step immediately catches newly-introduced bugs that would have taken me minutes or hours to detect and diagnose via run-time testing
Re: (Score:3)
On the other hand, static typing generally induces a slow compilation step that you have to wait through hundreds of times when developing a significant application. Dynamically typed languages are generally interpreted and forgo compilation at the expense of some runtime performance.
As shown by Smalltalk, Lisp, LuaJIT and others, neither long compilation times nor slow interpretation are necessary.
Re: (Score:3)
My experience with Swift is that type inference is the time killer. I know the Swift compiler itself is still immature, but you can see huge speedups in compilation when adding type annotations to declarations the compiler can infer correctly.
Re: (Score:2)
Ignoring the fact Microsoft sponsored this paper, could you point out the specific issues you have with Typescript and why you would avoid it?
I am a NodeJS developer, who has been considering Typescript, so I would be curious by your insight. I just want to make sure you aren't judging with a similar bias?
Re: (Score:2)
you speculate grandparent in writing his comment used "zero thought, logic or investigation whatsoever".
and your use of "most likely", "hit job", "living in his mom's basement ", etc., expose your prejudices.
that is your idea of rational thoughtfulness?
Re: (Score:2)
Why would Microsoft do that when they have been trying to push HTML5+Javascript as the best way to write "Modern" (Metro) apps?
Typescript [wikipedia.org] - mentioned in TFS - is Microsoft's baby, too, and "compiles" to JavaScript.
Re: (Score:3)
Python and Javascript is to this decade the same as Basic was to the 80's.
Re: (Score:2)
Spoken like a true cretin. While JavaScript is admittedly a really bad programming language, Python is a very good one. But both are real in any sense that matters and a competent coder can do real work of any size in both of them. The actual problem is that many people writing code these days are not "real" coders, but incompetent wannabees that like to blame the tools used for their personal limitations.
Re: (Score:2)
While JavaScript is admittedly a really bad programming language, Python is a very good one.
You sound like one of those weenie user-space developers.
Re: (Score:2)
You mean you cannot code in user-space? That seems to be a pretty peculiar disability....
Re: (Score:3)
Just imagine where Python could have been if it had static typing and delimited blocks which are the main problems opposed developers have with it. It would not have reduced the language in usability much at all, and it would still be highly suitable for scripting tasks.
I think it could then have been a real contender in the language space and would have been far more widely adopted. It could have been the default language for Android for example.
Re: (Score:2)
... real programming languages. They are for idiot kids who like to play dress-up and pretend to be real developers.
They are also great for rapid prototyping and cases where you only need something basic. They have issues, but I am wondering whether you are just rocking your high horse?
Re:Python and Javascript are not... (Score:5, Insightful)
Current python programmer, and former C programmer here. Dynamic typing is great for a small to medium sized code bases but I would hate to work on anything really big and mature without static type checking. I have worked on large code bases with maybe 100 megabytes of code and C and Ada, a lot of it dating back 20 years or so. You can't safely refactor code that old, and you can't allow data of the wrong type to get in to it, so type checking at compile time is an important line of defense.
You can do that in python with run time checks of data types and thats what you would have to do at the entry point of your libraries, but it eats into your performance doing that. Python is too malleable for static type checking.
Re: (Score:3)
Re: (Score:3)
Considering there are tens of thousands of people making shitloads of money every day coding some serious, useful applications in in Python, I'd say you're mistaken.
Re: (Score:2)
Yes, it's easy to throw together something quick, but this also means that it's common that something that was intended to be quick and dirty will become what's going into production - full with bugs and security holes.
Re: (Score:3)
This. Somebody builds a perfectly good Tom Sawyer raft which is fine - until it gets extended, enhanced and fuck knows what, bit by bit, into an aircraft carrier.
Re: (Score:2)
same number of bugs, just caught in a different way. In defense of the dynamically typed languages they do allow some quick progress to be made finding flaws in algorithms while the syntax nazi languages are still griping about non static thingamajigs being called from static whatchamacallits.
I'd be interested to see if languages like clojure tend to reduced bugs in the compiled code, the only reason I think that it might is because it took me so much effort to get event the most trivial program to even ap
Re: (Score:3)
It's cute that you need a language altogether. When you're ready to be a real programmer, you can learn how to write all your own op-codes in assembler, like a grown-up developer.
Re: (Score:2)
And fail. Assembler is a language (or rather a family of languages). You probably meant machine code.
Re:Strong typing is like training wheels (Score:4, Informative)
FUCK! I had hex-editor in my head and I fucked it up. Fuck me. I failed. And fuck you, too, for sinking to my level. We all fail together.
Re: (Score:2)
Hehehehehehehehehe ;-)====)
Re: (Score:3)
It's cute that you need a language altogether. When you're ready to be a real programmer, you can learn how to write all your own op-codes in assembler, like a grown-up developer.
Assembly language is also a language. Toggle in the bits directly via the front panel switches, like a real man :)
Re: (Score:3)
Obligatory XKCD [xkcd.com]
Re:Strong typing is like training wheels (Score:5, Insightful)
On the contrary - strong typing is preferred by those that have coded a long time and have to maintain systems that has been around for a long time.
As soon as you inherit code written by someone else you will waste a lot of time to understand how it works - and if it's not strongly typed you can easily miss something that previous coders did introduce. A strongly typed system will tell you quite fast that the code you changed the method header on was actually used by 200 subroutines. On a system written in a language not forcing strong typing you may discover that routines you didn't know existed are using it - and they are used only once per year at new years eve - guess who has to put in overtime then?
Re:Strong typing is like training wheels (Score:5, Insightful)
Yes, the language it was written in was broken.
Or are you suggesting that the people that actually write in these loose languages "because it saves me typing 5 characters" actually will write documentation saying that said function is called at new years eve? And will spend time on proper architecture? Perhaps in your fantasy world they also wrote unit tests with 90+% coverage?
No. You get the code dumped in your lap, and you will be praising the gods if there's an old completely outdated Confluence site that describes what some junior on the team thought that the software is supposed to do.
If that code is Javascript, then you might as well throw it away and rewrite it, it will be faster. If that code is Java, you can make modifications and refactorings to it and be reasonably sure that you didn't break anything totally unrelated.
Re: (Score:3)
Why did you think Dijkstra said, "Always debug the code, not the comments".
Re: (Score:2)
C/C++ suffers from a complexity problem, which it needs to do low level stuff. Often this the result of just too many types, too many #ifdefs, just too many edge cases. However its static typing and the amount of errors it catches at compile time is something to be praised.
Python has much less types and does away with compiler directives, and is generally a bit more expressive. This removes a lot of complexity, but it is not perfect. It could have been statically typed as well, without losing much in e
Re: (Score:2)
I found that C++ is not worth it for me. Far too complicated and most of its features are not needed. I use Python as glue and C for the heavy lifting these days. That works pretty well. Of course, this is not an approach a beginner can take, as you rightfully point out. And, of course, somebody experienced and competent can indeed write good code with almost anything.
Re: (Score:2)
I see the "incompetent coder" faction on Slashdot had mod-points today. Mod me down all you like, does not make what I said any less true.
Re: (Score:2)
No, I assume it is code written by competent people. Sure, if the developers that wrote the code needed those training wheels, then removing them will have them fall over all the time. But leaving the wheels on is the wrong place to fix things.
Re: For fuck's sake, YES! (Score:2)
Mod parent up
Re: (Score:3)
Absolutely! In my experience, statically typed languages are great when your goal is production; dynamically typed languages are great for quick demos.
Re: (Score:3)
Honestly, I'm more worried about strongly mistyped languages.