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)
Didn't we go through this thing with Ada? Strongly typed languages end up with fewer bugs because they are caught at compile time, if not before. On the other hand, if the language isn't strongly typed, it's easier to write little programs super fast. Someone had to do a study on it again?
Strong typing is nice when people learn coding for the first time. Then they need to learn to do it without. The metric "less bugs in some code" is meaningless, just as the metric "fell over less" is with driving a bike. When you cannot do without training wheels than there is either something seriously wrong with you or you stopped learning way to early. The same applies to strong typing.
In essence, people that need strong typing do not have what it takes to get everything else right. They should stay away from professional coding altogether.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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".
C statically typed but weakly typed.
Java is statically and strongly typed.
Smalltalk is dynamically typed and strongly typed.
A strongly typed language doesn't let the type of an object change - that's a different thing to static typing.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Strongly-typing a language doesn't come at no cost.
Maybe the bugs that do get created are harder to fix?
Maybe the strong typing reduces productivity?
"Just use language X and your bug count will go down" is a meaningless statement in a vacuum.
Lots of Borland/Pascal programmers are saying we told you so though.
That I can see. ;)
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.
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.
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?
Jumpstart the tartan drive.
... 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?
Jumpstart the tartan drive.
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
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 of every possible codepath, I count that as a big win for static typing.
I don't care if it's 90,000 hectares. That lake was not my doing.
You mean you cannot code in user-space? That seems to be a pretty peculiar disability....
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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...
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.
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 programmers who don't often move between 8/16/32/64 bit environments. I know a lot of experienced C programmers who think strong typing is just a waste of their time, and any research like this is good ammunition against that way of thinking.
Dynamic or contextual type problems are a bigger source of problems I think. Ie, you were using a zero based counter but then later treat it like a one based counter; or it was a counter and now it is being used in arithmetic.
Beyond that I would love something that clearly marks a function as "this has side effects!" I've run across terribly buggy code that I passed through on a code review because I didn't realize that what seemed like innocuous calculation functions actually were updating global variables.
Sure, you can always solve this stuff with good coding style standards but those are so easily subverted or ignored.
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.
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?
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.
Mod parent up
Avantgarde Hebrew science fiction
I've been using Janson and Bookman lately. Futura for san-serif. What was the question, again?
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)
Why would Microsoft do that when they have been trying to push HTML5+Javascript as the best way to write "Modern" (Metro) apps?
Typescript - mentioned in TFS - is Microsoft's baby, too, and "compiles" to JavaScript.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
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 complexity overall, and that will give you a more stable product more quickly.
I stole this Sig
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.
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.
Which is why they now bundle Python and Cython with Visual Studio.
http://saveie6.com/
Really dumb question, but it got me to search for funny or insightful comments, since it's a target rich environment for both. Not surprised to be disappointed in the search, but it's early so I can pretend to be hopeful they'll appear later, eh? It's not like the editors (owners? secret masters?) of today's Slashdot would pick a story in hopes of starting a flame war.
A more meaningful question would be something along the lines of "Do the restrictions of strongly typed languages actually produce better programs?" or "Are the most productive programmers more or less productive when using strongly typed languages?" or "Does the prevalence of average and below programmers justify the use of restrictive and strongly typed languages?" Lots of others come to mind, though my own interest is more philosophic in the conflict between languages that try to drive programmers towards a best solution (which also tend to be strongly typed) versus languages that take a more neutral position towards ANY solution that works (thus fostering more open-ended creativity).
Hint of an answer? I think the quest for a best solution is good, but I doubt it exists in most cases. Are the best quests quixotic?
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.
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
The problem with rapid prototyping is that too often the prototype ends up being shipped as the actual product.
http://dilbert.com/strip/1996-...
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~
There's a story of this 1 MLOC AI war simulation program in Smalltalk that beat a crap out of its C++ competitor in DoD tests. Chances are that it's not for everyone, but most problems we're facing should not require anywhere near that. (One could even say that if they do, we've failed somewhere.) So most people should be fine.
Ezekiel 23:20
I know I make a lot more "easily caught" mistakes when writing ruby code than I did when I used to write Java. Referencing a variable before it enters scope, NPEs, etc. Passing wrong number (or types) of parameters to a method.
First of all, the issues with weakly typed language poorly designed overloading by developers used to strongly typed construction.
For example, a common error is writing something like this:
add_function (3, "1")
And the result is the string 31 instead of 4, because some idiot overloaded the + function so that while it adds numbers, it also concatenates strings.
This is a overloading problem, not a type problem, but some fools won't realize that. Yes, if the function had a requirement of only accepting numerical strings it would have caught the error, but that is not the problem cause. The problem was that you should never overload a numerical operation to do anything but return an error when it is fed something besides a number. That's asking for hidden bugs later on.
In addition, this study only went looking for errors caused by week typing, rather than also checking for the errors caused by strong typing.
Here is a simple thing - a week typing language can easily add an integer and a float. It comes out with a float. But a strong typed language should return an error as they are different numerical types. In a very strongly typed language, you can't add an integer and a float, you need to convert one from the other.
But this problem has occurred so often, people started overloading "strongly" typed language with auto conversion. In part because we have a loner history dealing with strongly typed languages - originally we didn't have the memory to deal with anything except strong typing. Now we do, but don't have the proper experience.
excitingthingstodo.blogspot.com
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.
Why? It's rubbish, anyway. Chuck Moore cares about writing totally bug free code, and he does it in Forth. Forth has no typing at all.
Ezekiel 23:20
Yeah but is it safe? I should have mentioned that my example was a safety critical real time system with actual lives at stake. Additionally it had hundreds of functions which might only get used in emergencies, and which would cost > $100 M to validate properly.
http://michaelsmith.id.au
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
Python allows too much fiddling with the standard library for static analysis to be reliable. The the same reason why java style just in time compilers won't work with python and precise locking for threads is so difficult.
http://michaelsmith.id.au
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
That comment was posted as AC, so I would guess it passed for the AC's idea of "stinky bait". Please don't feed the trolls.
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
If you want to willingly shoot yourself in the foot, there's no process in the world to prevent you from doing that. There's no reason why "java style just in time compilers" couldn't work with Python - after all, they have Strongtalk/Self legacy. Except for, of course, nobody willing to fork the really serious money needed for that. But admittedly, striving for a good Python compiler does seem like a misplaced effort for other reasons. Good Lisps (such as Chez or SBCL) are much more desirable and more easily achievable, for example.
Ezekiel 23:20
Somebody should invent -Werror
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
It has been well known that static typing reduces bugs for many, many decades. If they really thought they needed a study I wouldn't go putting any feathers in their cap.
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.
That's not a problem with the language. It's a process problem. When management doesn't understand Fredrick Brooks all bets are off.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Typescript doesn't do anything to fix the if (a = 1) { ... } class of bugs. These would go away if the compiler required a constant on the left hand side.
Typescript is a subset of javascript in the end, how is it a bad language?
Tired of my customary (Score:1)
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.
The study appears to answer the question "How many bugs slip through QA in statically versus dynamically typed languages". A better question to have tried to answer is "How much test/debug/fix time does it take to get non-trivial programs to production quality in statically versus dynamically languages".
... strings in pascal/delphi have length incorporated into 'em) unlike C/C++ deal with.
You can't lump C and C++ together in this regard. C does not have strings. It has character arrays and C arrays do not have an associated length. C++ on the other hand has a proper string type which does have a length associated with it. C++ also has various collection classes that can be used in place of arrays which also have count (or som other notion of bounds) associated with them.
In a strongly typed language, the type of an expression in the if condition would be boolean. Your statement wouldn't compile.
Also, in a strongly typed language, assignment would not be considered an expression or would be considered to have type void.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
Significate whitespace makes me avoid Python.
Python invites these misunderstandings. It has the everything and the kitchen sink in it, making it look attractive from afar. But it falls flat on its face with its syntactically meaningful whitespace. That little aesthetic choice makes it much much much harder to write large codebases in it, and part of the hit you take when you do so is make design compromises that favor readability but end up impacting performance.
This aesthetics bleeding into performance isn't unique to Python. Java makes it impossible to split a class definition over multiple files the way you can in C++. That means you either have big giant files that are hard to navigate by yourself and tricky to edit by multiple developers, or you "refactor" and split your logic into different classes, each of which take up a few more bytes of memory and a few more cycles of CPU time to create and destroy when they're needed. Not the sort of thing that ever happens in small programs, but happens plenty of times in large codebases that deal with tens and hundreds of millions of records or data points.
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...
Omg, stfu dude. Fake news... You have no idea what you're talking about. Have you ever even used a Microsoft development product? Or even a strongly typed language for that matter?
And that's a perfect world. The world I'm in you get ridiculous deadlines you have to meet, are on multiple projects at once, and have to rush in before understanding everything. Or in other cases everyone's spread too thin to inspect everyone else's work.
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.
I see that facts donâ(TM)t matter to you, only your ugly bias. My statement is not an endorsement of this study, but rather an indictment of your labeling this as fake news, because of the source.
"Does this make you want to avoid Python?"
No, not just this. If I ever loved it, this wouldn't matter. Since I never loved it, this still doesn't matter. If I have to use python, regardless of love or hate, this still doesn't matter. Overall, this just doesn't matter, at all.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
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.
What a lot of this commentary—not just yours—seems to be eliding over is the motivation to move away from strong typing. It's not merely—or rather, not only—convenience. There are a number of data-mangling jobs that are better handled outside of the strictures (and structures) of strong typing.
I don't want this to devolve into a relitigation of the relative dangers of buffer overflows vs type spoofing as attack vectors, but it is fair to say that programming is as programming does, and there will never be a world with only strong typing; and there will never be a world without it, too.
There are benefits to both, and though it's perfectly fair to say that the convenience factor of untyped languages is used more often out of laziness than because it's the right tool for the job, sometimes it actually is the right tool for the job.
Crumb's Corollary: Never bring a knife to a bun fight.
With PEP 484, you can annotate typed method signatures. And with PEP 526 you can annotate variable types too. If you're willing to go with straight up Python 3.6+ syntax, it's pretty nice looking. mypy can do pretty reasonable type-checking, which is supported in PyCharm and Atom via plugin now.
What's great is you can use it where you want extra checks (more complicated infrastructure code) and just stick with plain old duck typing where you don't (fast and loose scripts).
As others mention, strongly-typed languages reduce or eliminate a class of errors related to type.
However having used both strong and weakly typed languages extensively, I would argue that in terms of time spent there is a near constant amount of time taken by either dealing with coding around a strongly typed system, vs. finding flaws in using a weakly typed system...
An argument for a weakly typed system would be, if all developers are very experienced they can potentially write pretty solid code and therefore save time.
An argument for strongly typed systems would be, if you are going to have some less experienced developers working with the code, that it will eliminate some potential bugs they might otherwise introduce... possibly also it could be the case that if you prefer to not write may (or any) unit tests, strongly typed systems to some extent take the place of that.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
Out of curiosity, where do you find work that allows you to program in Scala?
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.
in order to try and supplant it with their Typescript crapola
Here we have a Visual Basic for Application developer talking about something he knows nothing about. He then tries to make him self sound more "pure" than he is by bashing Microsoft. Moronic and childish. Ignorant stupidity.
There simply is nothing crapola about Typescript. Simple as that. Anyone who thinks there is has never tried to develop applications in both Javascript and Typescript.
Lots of Borland/Pascal programmers are saying we told you so though.
Isn't "lots" and "borland/pascal programmers" a contradiction in terms?
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.
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.
I've worked on large (several MLOC) C++ codebases where the full rebuild time was over an hour. Admittedly this was 15+ years ago. Templates are better now.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
> 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.
Thank you sir
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
That says more about you than anything else. I use an IDE because its easier, but I'm quite capable of writing Java without an IDEIt's just more typing and scrolling up to check variable names without relying on autocomplete.
Then again, I can count the number of times Ive ever used the built in refactoring tools other than rename on one hand. And that could easily be replaced by search/replace.
I still have more fans than freaks. WTF is wrong with you people?
From interviewing around in the Bay Area, I've seen at least two companies with app backends coded in Scala. When doing similar app backend work myself, I've chosen Python, but it didn't have to do with it not being a strongly typed language. It had more to do with the available third-party libraries and compatibility with cloud providers.
Big apple, new Yorik, undig it, something's unrotting in Edenmark.
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?
There's different levels of strongly types languages. For example in ML, an if statement returns a value, must have an else, and the two must return the same type. I don't think anyone is arguing for that. Assignment returning void or equality returning boolean are additional levels not required to be considered strongly typed. (Although the boolean one is a good idea, the assignment one has a lot of arguments against it).
I still have more fans than freaks. WTF is wrong with you people?
It's not that I disagree, but that's actually pretty funny and more at the expense of Python.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
C++ is pretty strongly typed. It's only static type analysis though, but no weaker than Pascal or Ada.
This is why I avoid discussions about programming languages. C++ is absolutely NOT strongly typed. It does however have a weak variant of static type checking. That's not necessarily a bad thing but the simple fact that C++ has 5 different types of casting operators (C style cast, static, dynamic, const and reinterpret) should have clued you into to the fact that C++'s typing system isn't strongly typed. Cast operators are a really good indicator as to the mathematical strength of a language's type system. If you have no cast operators, then its (almost always) a strongly typed type system. If you do, then it can't be strongly typed (unless there is some way to trace an instance's type history that allows the compiler to ensure things about the instance at compile time) but the type system can still be stronger than a prototype chaining language like JS. Java, Scala and Kotlin would all fall into this category (as would most general purpose programming languages people use in real word settings). Some of those languages can have static type checking which helps but how often have you seen a ReflectionException in Java because that's the consequence of Java choosing dynamic type checking instead of static. The benefit of this trade-off is reflection and runtime classloading.
I have observed that language discussions usually misuse and incorrectly understand CS terms more than any other part programming. I think its that devs tend to defend the languages they use at all costs. Also the terms themselves are very complex and hard to understand and people misuse them more often than they use them correctly (eg strongly typed) in my experience.
"Those that start by burning books, will end by burning men."
Personally I dislike the current trends of types after arg names, the only argument I've heard is that it makes parsing easier. Isn't the whole point of a high level language is that the compiler does the work? Why are millions of developers dealing with crappy syntax to make it a bit easier on the handful of people writing a parser.
Because its gotten to the point that languages are fashion statements and whatever compiler writers say gets taking as absolute truth by some in the programming world. There is a language that I won't mention (I've spoken at their conferences on multiple occasions) where I've seen the compiler team outright lie to their programmer community on multiple technical issues because they are desperate to keep growing their language. Making up optimizations they claim their compiler does but doesn't. Lying about the horrible efficiency of their run-time library. Making claims about the types of semantics their Futures can implement that simply are not true. The lead dev on the compiler finally got fed up and quit while giving a talk at one of their conferences because he got tired of being on the hook for bugs in features that simply did not work. And this is one of the better "modern" languages, one that makes Python look like the braindamaged NodeJS clone that it really is.
"Those that start by burning books, will end by burning men."
Not "good languages"
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
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."
This is true. Just two days ago I did a medium sized refactoring on a Scala project.It's a personal project, and I started moving some stuff around, and then I did more and more, renaming things, changing method signatures. And right in the middle I thought "Damn, what's this mess I just made? You should have made this one little step at a time.". But I just went on fixing compile errors. And in the end everything worked again, and I was fine. With strong, static typing, you can just make the change you want to make, and then fix all the type errors–and most of the time it will work again. No way this is possible in a dynamically typed language. But then, I probably wouldn't have done this with Python.
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 didn't read past the first line of your post, which made it perfectly clear you lack the capability to enter into an intelligent discussion.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
Saving 30 minutes of typing a day isn't going to make development go any faster.
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 complexity overall, and that will give you a more stable product more quickly.
Correction - you'll have a product more quickly but it's unlikely to be stable.
I'm a minority race. Save your vitriol for white people.
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
AWS
Reality is a slackware box running on a 386 tucked away in god's sock drawer.
A strongly typed language doesn't make it less likely that you'll write bugs, but it does make it more likely that your bugs will prevent the program from compiling or running, thus forcing you to fix them.
I think much of it is actually due to experience.
Inexperience programmers will often start out with languages that don't have strong types. Because they can get the program to work quickly, the software is buggy, due to fast development time combined with inexperience.
Song typed langues for the inexperience means just to get the program to compile they will need a some understanding of basic data structures. That prevents the program from getting released without some skill and practice behind it.
I do not see any difference in my code quality from Strong Typed to weak typed. But I treat weak typed code much like strong typed avoid having the same variable change types. And putting extra attention during data type conversions.
That said I did have an interesting unexpected bug about 20 years ago converting some COBOL generated data to Javascript where integers had leading 0 in the data set. This did convert some of the data to Octal and created some unexpected values when I was adding data together.
00712+00066 = 01000 which took me about an hour to figure out what was happening as I was adding 2 numbers with a leading 0 and no numbers greater than 7 caused the data types to be octal. However if I didn't know about this number conversion and the leading 0 notation for octal I may not had found the problem so easily.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
I am sorry, must have been a language-related misunderstanding.
By "road sign" I meant any sign out there, such as speed limit indicators, one-way signs, etc. Any of them.
Most of those you don't even need if you apply common sense or you know what you are doing, but they're still there and useful.
Dismissing their presence as "unneeded for professionals" is shallow. Taken to the extreme, you get to that joke saying "all you need as a professional coding is two keys: 0 and 1".
...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
I shudder to think what your other conversations are like because I suspect they consist entirely of you running your mouth and not your ears.
Explain why.
Answer is: yes. You take out so many problems handling unexpected type mismatches from the word go. Seems like we hear a lot of stories about PHP being broken because of an unhandled fucked up type.
Chewbacon
The Bible is like Wikipedia: written by a bunch of people and verifiable by questionable sources.
So what is you negative experience?
He has none. You'll notice the people that bash TypeScript have no experience with it. OP was comparing it to Python...two languages which two different purposes. TypeScript isn't perfect, but it's a hell of a lot better than writing straight JavaScript. And hey, if you don't like Microsoft, try CoffeeScript.
Vim has nice IDE type features like autocompletion available as plugins which are quite nice...
We don't believe in radical loony monotheistic religions from the middle east -- we're Christians.
Jsish (http://jsish.org) walks a fine line with an implementation of javascript wherein type-checking is provided only for function signatures. This can improve module usability, without impacting the bulk of an implementation. And although Jsish is primarily embedded, it also provides in-Browser support that pre-processes just the function signature, rather than the entire code body (ie. like typescript).
Disclaimer: I am a Jsish developer.
Yes.
Entire categories of errors are simply not present in strongly typed languages, which are present in weakly types languages. The example of PHP is the worst, as this may be a retardedly typed language, but the example still is applicable.
I've also noticed that there is a tendency is for weakly typed languages to be interpreted, while strongly typed languages are compiled. This is another language attribute that moves the bug detection from compile time to run time, and introduces an entire category of run time only bugs which compiled languages do not have.
All of these are reasons that weakly typed languages allow for more bugs, which are detected later. I am not saying that strongly typed compiled languages are better than weakly typed interpreted languages, but they are different.
A crappy programmer with a good type system is not better than a good programmer with a crappy type system. I'm pretty sure this is a paraphrasing of something Donald Knuth must have said...
I hope to never have to deal with your code. :(
You won't. Most of it has already lasted in production for over twenty years. Long-since proven to not need you.
That said, if you can't read the equal sign that's plain-as-day, then you really aren't skilled enough to understand the system as a whole, so you wouldn't be the best person for the job.
And, since you aren't willing to put your name to your comments, you wouldn't be a good fit for any team.
Nobody, in my experience, does any offline testing. Thus my current sig line (your mileage may vary 5 years from now)
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
A computer language is either strongly typed, or not. Other types of errors, usually not based on "type" is another set of problems. If the compiler cannot evaluate Type Definitions created by the programmer, then the compiler fails at being strongly typed. This entire debate goes nowhere, if the compiler cannot handle checking type defs, then programmers work around it. And if the programmer tries to change the language, then most times, a new programmer is brought in.
Lets start reading what I've stated, did you see the word "only" at the END OF THE F**KING SENTENCE?
Yes, I saw the word "only" at the END OF THE FUCKING SENTENCE.
Cooking meat? The topic is Strongly Typed Language; try to stay focused, princess.
I created an analogy to generaliz the topic to:
using a tool (iestrongly typed language vs cooking thermometer) that prevents only one type of issue in a family of issues (ie type related errors from the set of all programming errors vs the food borne infection vs all infections).
My focus is fine, do try to keep up.
And my question stands: "Yes. And?"
What point were you trying to make? It appeared to me, and likely the people who modded me insightful, that you were disparaging the use of strongly typed languages because it "only" (there's that word again!) prevents one type of bug.
If that wasn't your intention, what was the point of your post? To just explicitly state the completely obvious?
I support your comment fully. As well, strongly typed languages help the compiler writer to produce a more precise, accurate and optimized compiler.
Yes, that is one reason why I absolutely avoid using Python. Or any of the other fad languages. I am using Object Pascal for pretty much all of my project and a lot of possible bugs won't even allow the program to compile. There are even type checks in more "open" languages, like C11, but then I noticed that a lot of people just turn off all the warnings about possible bad conversions, just to get their code compiled instead of fixing the problem properly...
A computer language is either strongly typed, or not.
Not really. There's no consensus on what the term "strongly typed" actually means.
But that's beside the point. Both Java and Haskell are "strongly typed", but it's much easier to bend Haskell's type system to the programmer's will so that the compiler will check domain-level constraints.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Is python having adoption problems that I'm not aware of? Last I checked, it was in the top 5 of most programming language popularity indexes.
If you take all the bug-prevention technologies, then add up all the "bugs not prevented" by this methodology, you'd surely account for all bugs at 3000% of totality, along the same lines that medical technologies have "prevented" more deaths than the total number of patients studied.
Furthermore, can you really count every memory management bug in C/C++ style languages as a "bug prevented" had automatic memory management been employed (ignoring that the translated applications would certainly not have met any original hard-performance criteria?)
What if one moved all software to the hardest of the hard languages (nominally Haskell)?
Well, we'd have a 99% reduction in bug production per unit of function, and a 99% reduction in total units of function delivered (far fewer employed programmers, working far more methodically)—for a whopping 99.99% reduction in total bughood.
Right. Sure.
Experience and training count for nothing, we'll enforce "correct programs" by compiler.
For amusement value, kiddies, go look up how OO, OOP, and esp. java were being talked about in the mid-nineties. Really, "java won't allow null pointer exceptions" I read over and over (tell that to me as I show you a 150 line tomcat dump with a null pointer exception).
It got so sold that on the cover of the Jan, 94 issue of the IEEE's Computer magazine,, OO was *literally* pictured as the silver bullet to solve the programming backlog.
I don't mean to be pedantic, but Python is inherently strongly typed.
It is difficult to be pedantic about strong typing because there is no clear definition of what it means. Wikipedia will tell you that Liskov gave a definition of "strongly typed" that is closer to our current usage of "statically typed".
Python has support for some basic types, but it does not support typing for lists, enumerations, structures or functions. You can test the class of an object, but you cannot tell if two objects have the same or related classes. And Python allows you change the members and methods of a class after it is declared, so knowing the class doesn't really help much anyway.
In my view Python lacks a sufficiently rich type system to be classed as "strongly typed", but YMMV.
[And before you decide, look at Scala to see a rich type system that supports both static and dynamic typing of all data types ]
Please, let's not use JavaScript as a representative of the pinnacle of dynamic languages. It's common primarily because most browsers support it, NOT because developers love it. QWERTY Syndrome. And sloppy library writers can ruin anything in any language.
Table-ized A.I.
Which is not my experience, any more than it's the GP's experience. Congratulations on getting (5, Insightful) for a short blatant assertion.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
It's not a matter of typing type declarations, it's a matter of dynamic languages being faster to program in, while allowing a class of errors that I've always found to be really easy to find and fix. Perhaps my style in Perl or Common Lisp is better suited for dynamically typed languages than most.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
You're saying that statically typed languages find a certain class of bugs better than dynamically typed, and you seem to think that a definitive argument. If dynamically typed languages have other virtues, they might be better anyway.
Not everything I cook requires a meat thermometer. There's one in the drawer for when it's useful, but it rarely leaves the drawer.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
You left out unions as a way to change type. Do you consider "int(expression)" to be a way of converting to int, or a constructor taking an expression and creating an int?
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Microsoft has written tons of software, but it's mostly in a certain style of language. Writing tons of code in C, C++, and C# is not going to get Microsoft comparable experience in other kinds of languages (like dynamically typed or statically strongly typed - unless C# qualifies). It's entirely possible, and many people believe, that there are better languages for writing large programs, and some of these are dynamically typed.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
If I have to change a widely used C++ header file, compilation will take a long time. This is necessary because C++ permits types to be instantiated as regular variables or by reference.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
For that environment, it's best to have as much static checking as you possibly can. Most programs aren't in that environment.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
I have to agree that gains in Python are lost in the long run as a project scales up and needs to be maintained. But it is bigger than the typing; basically the interpretation at run-time leaves a variety of pitfalls like unhandled exceptions, missing functions, and variables referenced before assignment.
I've lost most of my admiration for Python because of addressing these issues. (Also the switch to Python 3 seems to create confusion for me rather than fix it. I feel like I have to do much more mental gymnastics with strings and byte types.) People can say what they will that 'good' programmers don't make these mistakes, but whatever.
I lose the joy of Python after the first 100 lines of code.
I agree, I think this is one of the worst aspects of C (C++ and whatever else.)
I've personally never viewed an assignment to be an expression. (I've had my fun of debugging FOR loops and IF statement that do 'cute' things this way. Also the cutsie: aVar = bVar = cVar = 5; just drives me crazy.) But yet I've run into people that insist on it like it is somehow mathematically universal (it isn't, would not expect a math major to think that way.)
Manifest, static, strong typing (C++, Java) can catch some significant bugs.
However, dynamic, strong typing (Python) can catch almost all of the same bugs using a tool like pylint or pyflakes. These look for variables that are set but not used, or used but not set. Pyflakes doesn't do much else, but pylint catches a large number of additional problem types in Python code.
K&R C had lint. Python has pylint.
I prefer vim+syntastic+jedi myself, but I have met some pretty strong coders who like the pycharm IDE for Python.
Also, I know some strong Java coders who really love the IntelliJ IDE.
Commit testing is good, but static analysis is good too. They're complementary technologies.
I'm not sure what supposedly makes an IDE-based debugger superior to other debuggers, but pudb (curses, linux) and winpdb (wxWindows, cross-platform) are really pretty good for python.
I use vim+syntastic+jedi+supertab, and a simple macro that spawns make from inside the editor. Consider it a text editor with plugins.
.py or a .java. vim+plugins does files with a .sql extension pretty well, but it doesn't do SQL code that's embedded in some other language file. I tend to see ORM's as a good way around this.
vim does syntax highlighting for almost everything out of the box.
syntastic does static analysis for almost everything with deeper error detection than syntax highlighting alone can do.
jedi+supertab do completion for Python nicely.
The macro I mentioned looks in your CWD's Makefile and runs its default rule. I usually have this do heavier-weight static analysis, unit testing, and system testing - but if I'm up against a head scratching bug, sometimes I'll temporarily change it to start a debugger like pudb or winpdb. But to be honest, I don't use debuggers much - I'm more likely to use print's for most bugs
emacs likely has analogs to all of these.
The only thing I've heard of that one IDE does that vim+plugins doesn't, is error detection for SQL code embedded in strings within a non-SQL file, like a
2 words: "Static analyzer".
EG: pylint, pychecker or pylint.
I use vim, but supposedly pycharm can do a good job of this too.
Neither of these is a Python problem.
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.
Python is strongly, dynamically typed.
C is weakly, statically typed.
C++ and Java are strongly statically typed.
"Strongly typed" means "few to no implicit type conversions". Don't confuse it with "manifestly typed". A 100% strongly typed language won't allow you to do things like add a number to a string (java allows this) or multiply a string by a number (Python does this) - but it also won't allow you to implicitly convert an int to a float (almost everything does this).
"manifestly typed" means you have to spell out your types by typing them in.
Python 3.x (and to a lesser extent, Python 2.x) can be "gradually typed", which means you can declare some of your types if you want. This requires a tool like mypy or pytype.
Look at Haskell. It's strongly typed, even though it is implicitly typed. IOW, it's not manifestly typed. Sadly, its type system is a royal pain, IMO - at least in its main implementation, the Glasgow compiler.
1) There are degrees of type strength. A 100% strongly typed language will not allow you to implicitly convert an int to a float, for example.
2) K&R C had "lint", which wasn't part of the compiler, but really helped. Python has an array of such tools, that aren't part of the compiler, but are quite useful.
What editor are you using? vim+plugins can do this, and emacs probably can too.
.py to disk.
You probably should have automatic unit tests and automatic system tests, rather than manually retesting your code again and again.
pylint and pyflakes (both of which can be integrated easily into vim) can catch most variable name typos before you save your
You need a static analyzer.
Actually, this isn't an error when you run.
It's an error when you invoke mypy or pytype on the code, which should be done before you deploy to production, or even before you deploy to your test environment. These provide "gradual typing" for Python 3.x (nicely) and Python 2.x (kind of) - IOW, you can manifestly type some of your variables, but don't have to type all of them.
I converted one of my Python 3.x projects to use gradual typing with mypy. I manifestly typed my function/method formal parameters, and left most of the stuff inside them 100% dynamic. It seemed to work well.
This doesn't make your variables statically typed; the compiler knows nothing about the types you declare. It (mypy) enforces typing using an analysis tool that is separate from the compiler.
1) Using an IDE or Text Editor Plugin catches most bugs in Python before you save it to disk.
2) Using a whole-program static analyzer as part of your edit/"compile"/test cycle catches even more.
3) Using a gradual typing tool as part of your edit/"compile"/ttest cycle catches even more. Mypy, pytype can both do this, and I've heard PyCharm can too.
4) Using automated unit tests and automated system tests catches even more.
If you're using Python, you really should at least use the first 2, and I hope you use #3 and #4 as well.
Try these, then come back and relate your experiences with Python.
Python isn't weakly typed. It's dynamically typed. The 2 are not the same thing.
Not having to do type declarations is only part of what makes Python development fast. It's also a VHLL.
Remember that lines_of_code/bugs_in_code is roughly a constant, so the more concise a programming language is, the fewer bugs you tend to have in it.
Actually, I believe static languages exist in significant part because CPU time used to be more expensive than developer time. The manifest type checking is nice, but probably not their main reason for existence.
But Rust has this Python dev looking at it pretty enviously.
Assembler is untyped.
Perl is weakly typed.
Python is strongly, dynamically typed, and sometimes gradually typed.
Java is strongly, manifestly, statically typed.
Strong typing is pretty useful, but it isn't the opposite of dynamic typing.
Strong typing just means that your language has few to no implicit type conversions. A 100% strongly typed language wouldn't even implicitly promote an int to a float.
Java allows you to add a number to a string; this is an small example of weak typing.
Python is kind of similar with multiplying a string by an integer.
A type inferencing tool for Python helps a lot with this. EG pylint.
Also, the gradual typing available in Python 3.x+mypy helps even more.
Does't Haskell do this?
It's hobbled by a bad primary implementation though: The Glasgow Haskell Compiler. It's fast, it does impressive type inferencing, but the error messages from the compiler are rather poor.
LOL.
Static analyzers and gradual typing are available for Python.
Actually, I was forced to use PowerShell for about a year. It really was pretty poor - I compiled a list of the problems I found in it.
I suggested maybe using CPython or IronPython instead, but they wouldn't have it, because "nobody knows them".
Compilation with a static type system need not be slow.
If anything, the analog with Python's implicit compile step (the interpreter itself), type inferencing (pylint), gradual typing (mypy), and automated tests is slower.
Developer time is more expensive than machine time in the modern world, and a VHLL like Python (plus a reasonable assortment of tools and techniques) is the best way to optimize developer time.
Static typing is good for improving machine efficiency. It's also good for replacing the innermost loop of some Python programs.
Python's IDE's (PyCharm, vim+syntastic, emacs+I_bet_something_exists), type inference (pylint), gradual typing (mypy or pytype), and automated tests are more than adequate replacements for a static type system at catching bugs.
Editors for dynamically typed languages can only do very primitive checking. They don't know enough about your code. If you mistype a variable name, they can't tell because they don't know what symbols will be defined in the global scope. That isn't determined until runtime. If you mistype a method name, they can't tell because they don't know what type of object you're calling it on, so they don't know what methods are supposed to be there. That too is only defined at runtime. It's impossible for the editor to know whether the code is correct.
Editors for statically typed languages can do very sophisticated checking. If you mistype a variable or method name, they'll tell you instantly. Or if you pass the wrong number of arguments to a function. Or if you try to pass a value of the wrong type. Or if you assign a value of the wrong type to a variable. Or if you try to call a method on a reference that might be null. Or if you don't handle a checked exception. The editor knows lots more about your code, so it can do lots more for you.
"I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
Python isn't weakly typed. It's dynamically typed. The 2 are not the same thing.
I did not claim it was weakly typed. Of course, now that you bring it up, Python type errors are only discovered at run-time which makes the argument moot anyway - we use statically typed language to help catch type errors before a user sees them.
Not having to do type declarations is only part of what makes Python development fast. It's also a VHLL. Remember that lines_of_code/bugs_in_code is roughly a constant, so the more concise a programming language is, the fewer bugs you tend to have in it.
On static-typed languages I tend to write fewer lines of testing code - in python every single input to every single function or method has to be type checked and an appropriate error has to be displayed to the user. That is something I do not have to do in other languages which let me specify the types of the arguments and the return values.
In other languages the compiler will warn (or even outright stop me) if some function somewhere calls some other function somewhere else with a string when it was supposed to use an integer. In Python I have to write code to defend against that. There is no net win to supposed brevity.
I'm a minority race. Save your vitriol for white people.
This isn't rocket science and it should be easy to understand; it is literally inarguable. When types are dynamic a typo introduces a big that cannot happen with static type checking. There are other ways it reduces bugs but this is one of them. I am not against Python. I use C, C++, Python and a host of other languages. I am not saying dynamic typing is evil. But no matter what you say static typing will always have less bugs if you take the same reasonably large code and static type check it somehow. There is no way around this fact.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Actually, static analysis is pretty effective with python - see pylint.
Also, there's more than one JIT for Python - see Pypy and Numba, for examples.
Threading works fine on Jython and IronPython, but you're right that the threading in CPython is poor.
Yeah I integrate pylint with my editor so I get that information more or less as I type it, but python generally can't tell me that I am making the wrong assumption about a variable passed in to the local scope, whereas java can because arguments are always typed.
http://michaelsmith.id.au