Slashdot Mirror
Do Strongly Typed Languages Reduce Bugs? (acolyer.org)
"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?
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.
"There are a dozen opinions on a matter until you know the truth. Then there is only one." - CS Lewis (paraprhase)
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.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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.
Python and Javascript is to this decade the same as Basic was to the 80's.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
A friend of mine likes to say: "If you want to do something robust, code it in Ada. If you want to do something quick, code it in Python".
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.
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?
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
This observation doesn't make me wish to ditch a programming language, but it does make me glad I do test-driven development.
Warning: This signature may offend some viewers.
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.
The more you catch at compile time, the less there is to bite you on the ass at runtime. Cheaper in terms of development effort too to fix bugs before customer reports them.
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.
http://michaelsmith.id.au
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.
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 negative point, but I looked at the generated code and I found it good enough that at any point I could abandon using the compiler, and carry on in plain JS.
So what is you negative experience?
Easy enough to add strong typing in Python by adding a type check decorator to each function and method.
-- In the beginning was the WORD, and the WORD was UNSIGNED, and the main(){} was without form and void...
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 :)
I don't care if it's 90,000 hectares. That lake was not my doing.
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.
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.
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.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.
Starships were meant to fly, Hands up and touch the sky - Nicky Minaj
The title of this thread incorrectly conflates "strongly typed" with "statically typed".
They are two completely different things.
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.
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.
I am armed because I am free. I am free because I am armed.
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.
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.
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.
...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
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.)
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 in a dynamically typed language to be able to say that whatever duck I'm calling this argument with it's going to always be the same duck. If the first call used and int, then every other call had better use an int. Sure I could put in a lot of asserts but I'd rather just have this be a global debug setting.
I'd like to be able to optionally declare types in the function definition and have it enforce static typing.
Finally I'd combine these and have an option to have the code re-write the source to insert the static typing based on whatever the type of the calling args I'm using is.
Some drink at the fountain of knowledge. Others just gargle.
Refactoring came out from the Smalltalk subculture so the claim to usability of refactoring tools or the lack thereof appears dubious. Lack of documentation in APIs and protocols is a perennial problem, though.
Ezekiel 23:20
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.
Ezekiel 23:20
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.
~X~
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 turning off 'strip comments', building, and then throwing away the Typescript sources, so you're not going to get locked in.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
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.
"I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
If it's actually critical, "ordinary" static types won't save you and you probably need formal methods. Technically there's no reason you can't apply them to any language.
Ezekiel 23:20
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.
-- Will program for bandwidth
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
Somebody should invent -Werror
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
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.
Reality is a slackware box running on a 386 tucked away in god's sock drawer.
Absolutely! In my experience, statically typed languages are great when your goal is production; dynamically typed languages are great for quick demos.
Why did you think Dijkstra said, "Always debug the code, not the comments".
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
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.
Just cruising through this digital world at 33 1/3 rpm...
Obligatory XKCD
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
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.
What kind of bugs are prevented? What about the bugs introduced in strongly typed languages, like the diamond inheritance case?
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn
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.
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.
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.
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.
Typing isn't programming. You're saving twenty minutes a month by not declaring your types, and you're losing an opportunity to catch bugs sooner.
If you're spending more than 10% of your time typing code, you're either disabled, in which case I'm sorry, or you're typing with your forehead.
Professional developers spend 95% of their time trying to figure out if the shitty, broken code they're staring at us a bug or an accidental feature.
Type checking dramatically reduces the ability to write code that silently fails in production, meaning you never have something to unfound for a year, by which time the users will depend on the broken behavior and you'll need to preserve it for the rest of your life.
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.
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.
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 editor and learn to use it well), but I'd rather debug in just about any IDE than use most open source Linux tools.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
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.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
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. If you divide a "distance" by a "time", you'd better assign it to a variable of type "velocity".
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Alternate hard and soft layers.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
> 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, if I'm deploying production software to the web, where it will encounter unknown user input in different character sets thousands of times per day, I'd want to take a few more minutes of development time to have more robust software. That's when strong typing is good.
Sometimes "quick and dirty" is what you want, sometimes "careful and reliable" is what you want. Duct tape is famous for a reason, and high strength bolts are used for a reason. Each has their place.
> 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.
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.
I still have more fans than freaks. WTF is wrong with you people?
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.
I still have more fans than freaks. WTF is wrong with you people?
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.
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.
One of my assignments at Apple was cleaning up a framework that had thirty or more coders over the previous ten years. The first time I ran it through the static analyzer, there were over six hundred issues identified. I tracked down and fixed all of them over the next couple of months in the process of cleaning up the code to build under LLVM and pass the App Store rules.
Most of the easier cases were things like parameters of the wrong type being passed to methods, which caused no problem at runtime and hadn't been spotted before for that reason. The more difficult ones were mistakes in memory handling, and in a lot of cases, I found myself saying "holy shit, GCC lets you do THAT?"
Comparing Obj-C to Swift, I would say that easily 90% or more of those bugs can't be written in Swift at all unless you resort to the UnsafeMutablePointer types, which put it right in your face that you're doing something dicey.
I was a huge fan of loose coupling for all the years I was an Obj-c developer, but today I spend almost no time in LLDB, since almost all of the mistakes I make writing Swift are caught at compile time.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
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.
"Right tool for the job" basically sums up the answer to the entire comment section.
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.
We suffer more in our imagination than in reality. - Seneca
Some people use "rope" for Python refactoring without an IDE. PyCharm can probably do it too, a popular Python IDE.
My idea of refactoring is mostly vim's n.n.n.