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?

Comments

You have to look at the source

[Heebie]

>>> The study was conducted by Christian Bird at Microsoft's...

This came from Microsoft, so most likely the premise for the study was specifically designed to generate results that would strongly suggest that one of Microsoft's horrid, awful, crap, packages would be superior to some free open-source package. (It looks like Python and Javascript are being targeted by Microsoft, in order to try and supplant it with their Typescript crapola.)

As far as I'm concerned, the source of this study makes it "fake news" and junk-computer-science.

Re:You have to look at the source

[Z00L00K]

Since I have programmed in many different languages I have personally discovered that strongly statically typed languages do solve a lot of problems because the problems are encountered already at compile time, not during runtime. The problems are also less elusive.

There are of course still bugs around, but they are more often on the strategical level than on a pure sloppiness level caused by misspellings and mismatching methods where a method is changed but one caller isn't.

Re:You have to look at the source

[Crashmarik]

Microsoft's big platforms are C,C++,C# this really doesn't do much for them.

Lots of Borland/Pascal programmers are saying we told you so though.

Re:You have to look at the source

[Anonymous Coward]

Why would Microsoft do that when they have been trying to push HTML5+Javascript as the best way to write "Modern" (Metro) apps?

You obviously just don't want to admit what everyone else knows - that statically-typed languages are superior.

Re:You have to look at the source

[gweihir]

Urgh, Typescript. Well, MS has creates some truly bad languages and they are still hard at it. Of course, the only aim MS ever had with its own languages was to chain people to its equally horrible platforms. This study seems to be just another element of this strategy.

Re:You have to look at the source

[Heebie]

Lots of Borland/Pascal programmers are saying we told you so though.

That I can see. ;)

Re:You have to look at the source

[Anonymous Coward]

This came from Microsoft, so most likely the premise for the study was specifically designed to generate results that would strongly suggest that one of Microsoft's horrid, awful, crap, packages would be superior to some free open-source package

And this comment came from a Slashdotter, so most likely it was a knee-jerk, Microsoft-hating hit job performed by someone living in his mom's basement with precisely zero thought, logic or investigation whatsoever.

See how that works? Don't mod parent up.

Re:You have to look at the source

[zilym]

Perhaps so. On the other hand, Microsoft has written tons of software over the years and perhaps this study might be born out of decades of experience?

From my own ~20 years of experience writing software (never at Microsoft, mind you), I'd tend to agree with them that dynamic typing is a very good way to introduce subtle errors that would have been easily detected in a static typed system. God knows how many man hours of my life were burned hunting down such bugs created by people before me in my software engineering career.

On the other hand, static typing generally induces a slow compilation step that you have to wait through hundreds of times when developing a significant application. Dynamically typed languages are generally interpreted and forgo compilation at the expense of some runtime performance.

For whipping out some throwaway code to get something up in a hurry, nothing beats dynamically typed and interpreted. But when I want to make something seriously strong, high performance, and lasting the test of time, I'll reach for my static typed compiler every time, thank you very much.

As usual, use the best tool for the job at hand, whichever tool that may be.

Re:You have to look at the source

[Midnight Thunder]

Ignoring the fact Microsoft sponsored this paper, could you point out the specific issues you have with Typescript and why you would avoid it?

I am a NodeJS developer, who has been considering Typescript, so I would be curious by your insight. I just want to make sure you aren't judging with a similar bias?

Re:You have to look at the source

[Darinbob]

I'm not entirely sure. The Code Complete book was written for Microsoft employees to help them write better code (too bad they didn't learn too much from it). Given the abysmal state of Microsoft quality I could believe that there's a group languishing and underfunded at Microsoft that is hoping to improve their own quality.

Re:You have to look at the source

[Jeremi]

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.

Re:You have to look at the source

[Anonymous Coward]

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?

Re: You have to look at the source

[Anonymous Coward]

You sound like an idiot.

Re: You have to look at the source

[Ronin Developer]

Yup. Many errors are detected at compile time. And, given the speed of the Borland Pascal and Delphi compilers, there was little time wasted. This resulted in most errors being of the run time variant. Strong debugging tools make it a breeze to knock them out.

Needless to say, neither the compiler nor debugger saved you from a piss poor algorithm or design.

Re:You have to look at the source

[Darinbob]

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.

Re:You have to look at the source

[Anonymous Coward]

I find it easier to refactor strongly typed languages as the compiler does most of the work for you before even running the program.
I also get the feeling that strongly typed languages have better support for IDE based refactoring as more can be safely inferred about their structure.

Re:You have to look at the source

[sittingnut]

you speculate grandparent in writing his comment used "zero thought, logic or investigation whatsoever".
and your use of "most likely", "hit job", "living in his mom's basement ", etc., expose your prejudices.

that is your idea of rational thoughtfulness?

Re:You have to look at the source

[careysub]

Two additional advantages of strongly typed languages: ability to use refactoring tools, and easier code maintenance - particularly in code reading to recover business logic.

I am currently working with a Python (sub)program, part of a large web system that I do not have access to. The data comes in in messages of an undocumented JSON format, so from beginning to end the type of a variable is whatever the type it is, and the name of the 'variable' is whatever the label string associated with the data was. It is very difficult to deduce what any part of the processing means.

Re:You have to look at the source

[Anonymous Coward]

Exactly what I was thinking. It isn't just that the end code might have 15% fewer bugs development will be quicker/more confident because a bunch of the stupid little mistakes you make while coding are automatically checked for and swigglies tell you fix them right away.

Re:You have to look at the source

[gweihir]

Well, in that sense "gcc -Wall" is strongly typed. In actual reality, it is not. Strong typing means the language stands actually in your way when you want to type anything dynamically, not that it only warns you that you may be doing something wrong.

Personally, I think strong typing is vastly overrated and those that need it should not be coding professionally. Warnings by the compiler about suspicious things are a whole different matter, as long as they can be turned off selectively. These are useful for double-checking things.

Re: You have to look at the source

[Anonymous Coward]

Zoom

Right over your head

Re:You have to look at the source

[Anonymous Coward]

I am a strongly typed bug, you insensitive clod

Re:You have to look at the source

[Anonymous Coward]

Best thing that ever happened to me in my Python career was finding an IDE (PyCharm) that at least attempted to enforce some semblance of type strictness, even if only superficially.

Re:You have to look at the source

[war4peace]

Personally, I think strong typing is vastly overrated and those that need it should not be coding professionally.

Oblig. car analogy: those who need road signs shouldn't be driving professionally.

Re:You have to look at the source

[itsdapead]

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.

Re:You have to look at the source

[quantaman]

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.

Re:You have to look at the source

[Billly Gates]

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.

Re:You have to look at the source

[MightyMartian]

I don't really care what the source of the report is, since my first day of Pascal programming, I've firmly believed strongly typed languages impose a level of planning and discipline, and this makes at least certain kinds of bugs much less likely.

Re:You have to look at the source

[K. S. Kyosuke]

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.

Re:You have to look at the source

[K. S. Kyosuke]

On the other hand, static typing generally induces a slow compilation step that you have to wait through hundreds of times when developing a significant application. Dynamically typed languages are generally interpreted and forgo compilation at the expense of some runtime performance.

As shown by Smalltalk, Lisp, LuaJIT and others, neither long compilation times nor slow interpretation are necessary.

Re:You have to look at the source

[Xyrus]

This study is one of those "Well, duh!" type studies. Strongly typed languages are easier to refactor, maintain, and debug. It's also easier for someone else to understand as they can see exactly what types of objects are being used at any given point in the code.

Weakly typed languages are easier to do short, quick, dynamic programming. And arguably, that's what they were designed for. I'm not going to haul out a C++ toolchain just to write a few simple REST services when I can write a few short Python/Flask scripts in a fraction of the time.

As always, use the right tool for the right job. Well, unless all there are is shitty tools for the job in which case you're stuck using a shitty tool. I'm looking at you Javascript, you worthless piece of Turing complete trash.

Re:You have to look at the source

[itsdapead]

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.

Re:You have to look at the source

[LifesABeach]

If one uses Strongly Typed Languages, one gets fewer Strongly Typed Language errors; only.

Re:You have to look at the source

[SoftwareArtist]

That used to be true, but I don't think it is so much anymore. Modern languages like Swift, Scala, Kotlin, etc. do a good job of being concise while still keeping full type safety. And that ends up making them faster to write. I also do a lot of Python programming, and spend way too much time running my code over and over just to discover typos and similar mistakes that my editor would have instantly highlighted for me if I'd been working in a statically typed language.

Re:You have to look at the source

[Anonymous Coward]

C# is their most popular language, and it is definitely strongly typed.

Re:You have to look at the source

[Anonymous Coward]

> Beyond that I would love something that clearly marks a function as "this has side effects!"

Like some sort of "global_vars_const" qualifier for function declarations? That would be pretty neat, and I don't see anything stopping it happening at a technical level - next standard, maybe?

Re: You have to look at the source

[Entrope]

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.

Re:You have to look at the source

[Anonymous Coward]

Compiling doesn't have to be slow. I remember that Turbo Pascal could compile code just about as fast as it could read it off the disk.

Some compilers are slow because they are simply not designed to be fast. They have poor algorithms, multiple passes, and so on.

Some compilers are slow because they are doing a lot of work, usually optimizations. Whole-program analysis is just a big task that takes a long time on on-trivial programs.

And some compilers are slow because the language requires it. C and C++ have semantics that require recompiling hundreds of thousands of lines for every file in your project because of includes, macros, and templates.

dom

Re: You have to look at the source

[Zero__Kelvin]

Somebody should invent -Werror

Re:You have to look at the source

[Anonymous Coward]

Python is actually strongly typed, so I'm not sure why the summary had that comment. It won't automatically convert types for you, instead it'll give an error. Unless the object overloads an operator to specifically support that (eg truthiness).

"1.0" + 2

Perl will automatically convert "1.0" to 1.0 and give 3 as the result. Therefore it's weakly typed.

Python would raise "TypeError: cannot concatenate 'str' and 'int' objects", therefore is strongly typed.

Python is also dynamically rather than statically typed though. Possibly why the submitted didn't consider it strongly typed.

Re: You have to look at the source

[Zero__Kelvin]

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.

Re:You have to look at the source

[gweihir]

And that is complete nonsense. Road-signs warn you of things you cannot anticipate. In coding, you have (or should have) the complete picture. So no analogy, just a sign of non-understanding.

Re:You have to look at the source

[scdeimos]

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.

Re:You have to look at the source

[PmanAce]

Typescript is a subset of javascript in the end, how is it a bad language?

Re:You have to look at the source

[naubol]

The idea that you develop more rapidly in weakly typed languages (and, implicitly, the importance of maximizing development time) seems to stem from two erroneous assumptions.

The first is that we spend the majority of our time developing. This may be true for hobbyist programmers and possibly even consulting work for small projects. For any effort beyond that, which is the majority of paid programming work and popular open source products, the majority of time is spent fixing bugs.

The second is that strongly typed languages have to be slower to develop. In almost every domain at almost every level of complexity, I find Scala faster to develop in than Python. It gives me strongly typed error-checking as I write the language by using the presentation compiler (assuming modern IDE) to highlight issues early on. It also gives me type inference so I do not often have to specify the types I'm working in at many declaration sites. Finally, it gives me a terse transformation of collections using the combination of strong typing and type inference. I also spend less time thinking about how to express what I want to do.

For any large scale project, if the IDE can allow you to click through to a definition of a complex type or method definition, this saves oodles and oodles of time because we need to understand what we're calling and reading the code often is faster than reading the manual and deducing where it lied to you. If you're not calling code you didn't write, you're not doing something sufficiently complex as to really be interesting or you're writing something embedded in which case the focus on reducing bugs is even more important. Statically typed languages do a much better job of giving you this reference automatically.

Of course, this is all predicated on the types of development we're doing, because no language anywhere can beat the development speed of another language that has a popular, mature domain-specific library to solve a problem. If the language itself has operators or constructions which excel in a specific domain, it's also difficult to beat that language with any language that lacks that focus.

Re:You have to look at the source

[jeremyp]

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.

Re: You have to look at the source

[PoopJuggler]

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?

Re:You have to look at the source

[Darinbob]

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.

Re:You have to look at the source

[Dog-Cow]

Anyone with a complete picture of their project is working on a toy. Leave college and you might find the world doesn't work the way you want.

Re:You have to look at the source

[Dog-Cow]

My experience with Swift is that type inference is the time killer. I know the Swift compiler itself is still immature, but you can see huge speedups in compilation when adding type annotations to declarations the compiler can infer correctly.

Re: You have to look at the source

[CustomBuild]

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.

Re:You have to look at the source

[Stinky Cheese Man]

+1 for your user name.

--another JMJ fan

Re:You have to look at the source

[grcumb]

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.

Re: You have to look at the source

[Anonymous Coward]

Perhaps the problem is not the language but IDE-dependent coders.
Come on, who needs IDE, learn make and git already. No serious code I see done with IDE.

Re:You have to look at the source

[Anonymous Coward]

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 find this an interesting thread. In my career I've probably worked with 20-30 languages, including a good long stint with python. A compiler catching bugs for me is nice, but IMO conciseness & elegance are far more important. All those "gotchas" worry about for python (a) don't occur [for me] & (b) would be offset by developer productivity.

Besides, if your unit tests are not testing things sufficiently to catch any of these, they you're already doing things wrong.

Re:You have to look at the source

[vux984]

If one uses Strongly Typed Languages, one gets fewer Strongly Typed Language errors; only.

Yes. And?

Catching type errors during compile is worlds better than finding at runtime, perhaps by an end user. Does it prevent logic errors, or memory leaks, or failure to sanitize inputs, or race conditions? No. It doesn't. So what?

If one uses a thermometer to check the temperature of cooked meat, one only reduces one type of infection vector. Are you suggesting the use of thermometers to check cooked meat isn't a good idea, because it won't prevent malaria or syphilis? Because that is how ridiculous your argument is.

Re:You have to look at the source

[tzanger]

Out of curiosity, where do you find work that allows you to program in Scala?

Re: You have to look at the source

[Anonymous Coward]

I normally try to avoid personal attacks, but you, sir, are an idiot bitch.

The number of times I've fixed a god damn typo in a variable name made by someone who refused to stop coding in vim like it's the god damn dark ages is well beyond what I can count on my fingers, even in binary.

And if the language had been strongly typed, the code never would have been able to build on the first place. But it did. And it silently failed for years.

Terrible programmers always think they're the best and don't need help. Grow the fuck up and realize you need all the help you can get, same as everyone else.

Re:You have to look at the source

[terjeber]

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.

Re:You have to look at the source

[terjeber]

Lots of Borland/Pascal programmers are saying we told you so though.

Isn't "lots" and "borland/pascal programmers" a contradiction in terms?

Re: You have to look at the source

[Anonymous Coward]

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.

Re:You have to look at the source

[terjeber]

Well, MS has creates some truly bad languages and they are still hard at it

They have. VB being a prime example. However, C# is what Java would be if it ever made it out of committee. It blows Java away in every way. Seriously. I've developed commercial Java apps since the late 1990s, and C# is leagues ahead of Java at this stage. Typescript is also, quite objectively, the very best way of developing JavaScript applications.

Interestingly the two mentioned are the brain children of one Anders Hejlsberg, the inventor of the (once quite nice, but today quite broken) Delphi.

Re: You have to look at the source

[Anonymous Coward]

In compiled languages that's generally a warning. If you're leaving warnings unaddressed, they're eventually going to find out about that and kick you out of the union.

Re: You have to look at the source

[Pseudonym]

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.

Re:You have to look at the source

[Pseudonym]

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.

Re:You have to look at the source

[Anonymous Coward]

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.

Re:You have to look at the source

[Pseudonym]

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".

Re: You have to look at the source

[Anonymous Coward]

It transpiles fancy, modern ECMAScript into shitty but universally supported ECMAScript 3, and it gives you optional type safety on top of it. It's a godsend. If your hatred of Microsoft forces you to use something else, swell, but you're shooting yourself and your developers in the foot.

No, I don't get paid by Microsoft. Yes, I have had to fix upwards of a trillion type-related JS errors.

Re:You have to look at the source

[Pseudonym]

Alternate hard and soft layers.

Re:You have to look at the source

[quantaman]

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.

I wasn't ignoring maintenance costs.

My argument is about complexity, strongly typed languages eliminate a category of bugs at the cost of more complexity. Complexity increases both development and maintenance costs.

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.

This may be true, I was speaking to my general experience but different languages can change the equation.

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.

This is one of the reasons I shy away from weakly typed languages on larger projects, the ambiguity starts adding complexity.

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.

It depends on the task, one thing I really like python for is it's a cheap way to build complimentary programs to a main project. I can build those programs much faster than C/C++ and with fewer bugs. Of course I don't have any experience with Scala, it might be an even better language for those tasks.

Re:You have to look at the source

[Pseudonym]

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.

Re:You have to look at the source

[Srin Tuar]

> Besides, if your unit tests are not testing things sufficiently to catch any of these, they you're already doing things wrong.

My main take away form this whole thread is that strongly types language people dont write unit tests and spend lots of time debugging.

I use both static and dynamic languages out of necessity, and in my experience the dynamic languages take significantly less time to produce working code.

Re: You have to look at the source

[tigersha]

Thank you sir

Re: You have to look at the source

[AuMatar]

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.

Re:You have to look at the source

[AuMatar]

No they take slightly less time to get kind of working code- and significantly more time fixing the bugs in it and significantly more time in maintenance to understand what those bugs are and what data an algorithm is working on.

Re:You have to look at the source

[AuMatar]

My argument is about complexity, strongly typed languages eliminate a category of bugs at the cost of more complexity. Complexity increases both development and maintenance costs.

This is where you're wrong. The complexity exists, regardless of the language. Type exists, whether your language is loosely or strongly typed. In one you just ignore it, which causes a class of errors. In the other you get free error checking. Pretending that complexity doesn't exist saves you no time, and causes errors. It's a net loss.

Re:You have to look at the source

[AuMatar]

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).

Re: You have to look at the source

[Anonymous Coward]

weakly typed, or reasonable data type inference/promotion?

is SQL weakly typed if you get different results from ;with t as (
select 3 as a, 1.5 as b, 2 as c)
select (a*b)+c as x , a*(b+c) as z
from t
-- does x=z?

(yes, it's a trick question that is not a math bug, just an indicator of a human-assumption bug with respect to sql. the results will probably be implementation dependent, too).

strong typing doesnt prevent this, unless someone believes that adding floats and ints together without casts should generate an error at some point, whether compile- or run-time generated.

Re:You have to look at the source

[Z00L00K]

It's not that I disagree, but that's actually pretty funny and more at the expense of Python.

Re:You have to look at the source

[sfcat]

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.

Re:You have to look at the source

[sfcat]

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.

Re: You have to look at the source

[Anonymous Coward]

Maybe you should try them some more; I had the same attitude, but now I find extracting methods, modifying method signatures, and moving code (often inner classes out of a class) to be very useful a lot of the time...

Re:You have to look at the source

[munch117]

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.

Re:You have to look at the source

[ziggystarsky]

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.

Re:You have to look at the source

[ckatko]

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.

Re: You have to look at the source

[Anonymous Coward]

That depends on what type the assignment returns. In C, it returns the type of the assigned variable...

Re: You have to look at the source

[Anonymous Coward]

You are actually retarded.

Re:You have to look at the source

[goose-incarnated]

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.

Re:You have to look at the source

[Anonymous Coward]

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.

If you were keeping up with Python, you'd know that Python 3 has some form of static typing:

def foo(a: int, b: int): # parameters can have types in Python 3
    return a + b

# error when you run because of type mismatch with function parameters
foo('a', 'b')

Re:You have to look at the source

[naubol]

AWS

Re: You have to look at the source

[Anonymous Coward]

Sorry, but that is illogical.
Any issue that an IDE can find in real-time (because that's as much time it gets) surely can be found by dedicated offline testing.
Admittedly vim + dynamic typing + no commit testing (testing at least as much as an IDE would) will end badly.
But that's on the idiot who thought not having testing is ok, not the vim user.

Re: You have to look at the source

[Anonymous Coward]

It depends on what you are doing, but the thing is most of the time a debugger is a shit tool for debugging.
At least until such time as you can smoothly go back 20 minutes in time in an instant, printf is a much better solution a lot of the time.
And don't get me started on Java debuggers, where setting a breakpoint even in an unused piece of code will slow down execution of the whole program...
gdb certainly can be a pain to use, but at least it has little overhead and you can fairly easily set watchpoints wherever you want (even before that address is valid). That usually doesn't work well in IDEs.

Re: You have to look at the source

[Anonymous Coward]

"Error when you run", the "run" part is the problem, and that means it is NOT static types. That said, pylint is fairly good at preventing most of the everyday issues.

Re:You have to look at the source

[Anonymous Coward]

Exactly this. Plus beginner programmers make a ton of simple mistakes in dynamically typed languages. Students literally spend hours tracking down bugs because of a typo that would have been instantly caught by a statically typed language.

Re:You have to look at the source

[Anonymous Coward]

You need to upgrade your developer tools then or your code has way too many "giant" functions that need to be split up. With 16 core workstations at a reasonable price available for about a decade now, what on earth could cause changing a few lines of code make you wait a long time for a recompile?

Re:You have to look at the source

[jellomizer]

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.

Re: You have to look at the source

[Anonymous Coward]

That is a logical fallacy. Just because something came from somewhere, it doesn't mean that that was the ideal circumstance for that something to arise. I.e. refactoring may have come out of a dynamic typing language, but that doesn't mean that it isn't better in a static typing language. I'm not saying it is or isn't, but just pointing out to be careful of the logical fallacies.

Re:You have to look at the source

[war4peace]

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".

Re:You have to look at the source

[Chameleon Man]

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.

Re: You have to look at the source

[Bonobo_Unknown]

Vim has nice IDE type features like autocompletion available as plugins which are quite nice...

Re: You have to look at the source

[Anonymous Coward]

What???

Do Strongly Typed Languages Reduce Bugs?

YES! In what World would they NOT??!

Re: You have to look at the source

[Anonymous Coward]

When plain text editors get auto-completion, syntax highlighting, and debugger integration, Iâ(TM)ll consider voluntarily using one.

Re: You have to look at the source

[Anonymous Coward]

They are both type INT, why can't you add them together?

Re:You have to look at the source

[Anonymous Coward]

You may be interested in hearing that there's a static analyzer for Python that can catch trivial mistakes: pyflakes. There's integration with common editors so you get a red line under misspelled identifiers.

There are even more sophisticated analyzers, but pyflakes takes 90% of these bugs in my experience. Only downside is that you can't do * imports. But honestly, those are bad anyway - get back to a project a year later, and you've forgotten where an identifier comes from.

Re: You have to look at the source

[Marxist Hacker 42]

Nobody, in my experience, does any offline testing. Thus my current sig line (your mileage may vary 5 years from now)

Re:You have to look at the source

[Anonymous Coward]

My argument is about complexity, strongly typed languages eliminate a category of bugs at the cost of more complexity. Complexity increases both development and maintenance costs.

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.

Watching people talk past each other is amusing.

Re:You have to look at the source

[Anonymous Coward]

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.

Python is strongly typed. You can't add an integer and a string, for example, because you'll get a TypeError.

I've always found it laughable that C is touted as a classic example of strong and statically typed, because a lot of the C code I've worked with in the past did so much casting between types that it might as well be dynamic and weak. It would probably be less error-prone as a result.

Re:You have to look at the source

[LifesABeach]

You just happen to touch upon 2 things I know something about. Lets start reading what I've stated, did you see the word "only" at the END OF THE F**KING SENTENCE? Modded Insightful? Duh. You do realize the Critical Thinking happening here gets more complex as we proceed? Cooking meat? The topic is Strongly Typed Language; try to stay focused, princess.

Re:You have to look at the source

[LifesABeach]

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.

Re:You have to look at the source

[vux984]

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?

Re: You have to look at the source

[leslie.satenstein]

I support your comment fully. As well, strongly typed languages help the compiler writer to produce a more precise, accurate and optimized compiler.

Re:You have to look at the source

[Anonymous Coward]

Personally, I think strong typing is vastly overrated and those that need it should not be coding professionally.

No competent professional needs strong (preferably static) typing, but getting to production quality code will probably happen a lot faster on a big real-world project if you have strong typing in the language used to build the main system. The associated tools (code generators, build scripts, and so forth) can be (and often are) written in simpler languages.

At the professional level, it is (or should be) a given that if one has strong typing in the language one is using, then one will know how to best take advantage of that. The script-kiddies tend to fail this test.

Re:You have to look at the source

[Pseudonym]

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.

Re: You have to look at the source

[Anonymous Coward]

Another "dev" working on toy projects by himself wants to tell professionals that they aren't as smart as him.

Once you've worked with code written by thirty guys hired right out of college who think 100% coverage means it's perfect, you'll understand why we're all ignoring you.

Re:You have to look at the source

[david_thornley]

Which is not my experience, any more than it's the GP's experience. Congratulations on getting (5, Insightful) for a short blatant assertion.

Re: You have to look at the source

[david_thornley]

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.

Re:You have to look at the source

[david_thornley]

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.

Re:You have to look at the source

[david_thornley]

C++ has 5 different types of casting operators (C style cast, static, dynamic, const and reinterpret)

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?

Re:You have to look at the source

[david_thornley]

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?

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.

Re:You have to look at the source

[david_thornley]

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.

Re:You have to look at the source

[Euler]

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.

Re:You have to look at the source

[Euler]

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.)

Re: You have to look at the source

[Anonymous Coward]

I have a couple of projects in java. I write unit tests for all my modules. When I deploy something, it usually works. When it doesnt work, my exception handling and log messages are usually enough to figure out the problem without having to use a debugger. I can quickly fix the problem, redeploy, and retest to confirm the fix because I have scripted everything but the coding. I am a lot more productive than other java and python programmer on the team who don't do any of those things. Especially more productive than the python programmers who think that, because it's just a script, they can edit and retest "live" and then bring back the code after its working. They always forget some change they did or some manual configuration, and end up spending a lot of cycles on easy stuff. I guess "good" python programmers don't make those mistakes. It's not really about the language, it's about the skill and discipline of the programmer. The language just makes certain things easier or harder. Like finding 15% of bugs early, or anonymous functions, etc.

Re:You have to look at the source

[strombrg]

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.

Re: You have to look at the source

[strombrg]

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.

Re: You have to look at the source

[strombrg]

Commit testing is good, but static analysis is good too. They're complementary technologies.

Re: You have to look at the source

[strombrg]

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.

Re: You have to look at the source

[strombrg]

I use vim+syntastic+jedi+supertab, and a simple macro that spawns make from inside the editor. Consider it a text editor with plugins.

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 .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.

Re:You have to look at the source

[strombrg]

2 words: "Static analyzer".

EG: pylint, pychecker or pylint.

I use vim, but supposedly pycharm can do a good job of this too.

Re:You have to look at the source

[strombrg]

There are 2 problems here:

1. Bad/incomplete documentation
2. Large JSON files without a JSON schema

Neither of these is a Python problem.

Re:You have to look at the source

[strombrg]

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.

Re:You have to look at the source

[strombrg]

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.

Re:You have to look at the source

[strombrg]

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.

Re:You have to look at the source

[strombrg]

What editor are you using? vim+plugins can do this, and emacs probably can too.

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 .py to disk.

Re:You have to look at the source

[strombrg]

You need a static analyzer.

Re:You have to look at the source

[strombrg]

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.

Re: You have to look at the source

[strombrg]

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.

Re:You have to look at the source

[strombrg]

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.

Re:You have to look at the source

[strombrg]

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.

Re:You have to look at the source

[strombrg]

Assembler is untyped.
Perl is weakly typed.
Python is strongly, dynamically typed, and sometimes gradually typed.
Java is strongly, manifestly, statically typed.

Re:You have to look at the source

[strombrg]

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.

Re:You have to look at the source

[strombrg]

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.

Re:You have to look at the source

[strombrg]

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.

Re:You have to look at the source

[strombrg]

LOL.

Static analyzers and gradual typing are available for Python.

Re:You have to look at the source

[strombrg]

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".

Re:You have to look at the source

[strombrg]

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.

Re: You have to look at the source

[strombrg]

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.

Re:You have to look at the source

[SoftwareArtist]

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.

Re:You have to look at the source

[goose-incarnated]

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.

Re: You have to look at the source

[Zero__Kelvin]

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.

Bug Conservation

[ThosLives]

I suspect that there is something like a "law of conservation of bugs" or something in software - you take away one vector for bugs to originate and you just move them into another place.

Dynamic languages do have an easy way to introduce bugs - especially languages like javascript that simply create new variables if you have a typo.

But there is the old adage in statically typed compiled languages "Hey, my code compiles! Now I get to find out where all my bugs really are."

This also applies to other aspects of programming languages. Consider the arguments about manual vs automatic memory management. Managed code still has bugs, just not memory management bugs.

Re:Bug Conservation

[gweihir]

I fully agree. Bugs are just getting more destructive and harder to find the less permissive a language is. Also, if you cannot make type-errors, then any random person can write type-error free code. Type-errors simply cease to become a quality-metric in that case. That does not mean that the code is better in any way though.

Re:Bug Conservation

[Anonymous Coward]

Main causes of bugs with API's seems to be getting enumerated types mixed up with integers and each other. Then there is refactoring where different programmers work on refactoring different levels of code at the same time, and suddenly a new option or state is added to one layer, which is not informed to the other. Then leading to either merge pain or strange errors where no output appears.

Re:Bug Conservation

[Anonymous Coward]

That seems a bit like a child saying "Why should I shower now when I'll get dirty afterwards?"

Re:Bug Conservation

[alvinrod]

That seems to imply that the number of bugs is (relatively) constant. Adding automatic bounds checking to a language prevents a whole category of bugs, particularly ones that can be quite nasty. Sure if you had only skillful and exceptionally careful programmers, you wouldn't get those types of bugs either, but that's wishful thinking in most cases.

If there is some truth to what you I suspect its for tangental reasons. I'd hypothesize that languages that solve many of those categories of errors have much lower barriers to entry and therefor you get more cowboys using them who are making other kinds of mistakes because they're idiots and not because a programmer must make some fixed number of mistakes somewhere. Those people wouldn't be trusted with languages that didn't prevent them from introducing certain types of bugs because they would be counter productive for their team and create more problems than they solve, but languages that cut down on the potential types of mistakes that can be made mean there are entire categories of bugs that they can't introduce and that they can probably be productive.

It's another old adage: "Make something foolproof and the universe will invent a better fool."

Re:Bug Conservation

[swilver]

And I suspect there is no such law at all as it seems based on nothing.

Better languages do result in less bugs. They may open vectors for a different type of bug, but that does not mean they are as frequent or as dangerous.

Take memory management. One misstep and your program gets killed or crashes because it reads or writes from memory that does not belong to it. Very easy to do in some languages, while other languages completely eliminate this class of bugs. Of course poor memory management can then result in memory leaks, but it won't crash, and not all such problems become memory leaks.

Some languages also practically eliminate arbitrary code execution and injection attacks, making them inherently more secure, at the cost of having bounds checks compiled into your program. This again eliminates a whole class of problems and introduces no new problems (maybe performance problems, but those are not bugs).

Then there is code maintenance and refactoring, something which is near impossible with loose languages. This is often why is not even attempted, leaving your with a code base that, if not planned in excruciating detail, will wither away and die. Just look at all those Javascript frameworks that rise and fall and don't even try to maintain backwards compatibility... I think it is because they all turn into unmaintainable pieces of spaghetti code that no sane programmer wants to keep working on for long.

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."

It happens often enough that people write hundreds of lines of new code in a compiled language and actually find it runs correctly the first time. Perhaps you haven't experienced it yet... I have on many occasions.

Re:Bug Conservation

[gweihir]

That is pretty much how the argument goes. And if you look at the abysmal state of competence of most modern "web coders", you can see a very nice example of this idea in practice.

Re:Bug Conservation

[gweihir]

It is funny how code written in your "inherently more secure" languages gets exploited at the same or higher rates these days. What actually happens when languages get "safer" is that coder competence drops and bugs just move to a higher level, without being any less destructive. If you cannot see that happening over the last few decades, then you seem to be blind to what is going on.

Re:Bug Conservation

[0xdeadbeef]

I suspect that there is something like a "law of conservation of bugs" or something in software

I know, with the same degree of certainty that there is an objective universe that exists independently from my perception, that what you just said is bullshit.

There is correct code, and there is flawed code. It is possible to write software that doesn't crash, that can't be exploited, and does precisely what it is supposed to do for all possible inputs. The only thing standing in the way of that is incompetence and the tolerance of failure.

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."

People who were excited by their code compiling were morons in their first year classes. No professional programmer talks like that. And every kind of bug that is not prevented by static type checking still exist in loosely typed languages.

Re:Bug Conservation

[Darinbob]

This is true, there is no way to automatically catch bugs, other than shipping the product to paying customers. The best tools out there still have to be learned properly. There is always a dumb developer that will screw up in ways that a tool can't catch. Even the best developer on an off day will introduce bugs.

So you have to learn to catch bugs systematically. Always do the code reviews, never treat them as bureaucratic hoops to jump through, get more than one pair of eyes on them. Get mentors for all new developers, and even experienced people should never be left alone with no oversight. Always test your own code, don't rely on QA to catch everything, add unit tests, etc. An in QA, don't trust the developer, I've seen too many cases recently where the QA person says "but that's the way the developer said it was supposed to work..." QA should not just test the feature but be sure there is a full regression, even with minor releases.

The old wisdom is right: the later a bug is found the exponentially more expensive it is to fix. If you catch a bug when it's still in your editor then it costs almost nothing to fix it, if a big customer catches the bug you can lose customers and people get fired and laid off. Something that seems innocuous can end up bricking products or causing loss of data or worse, and sadly I have experienced this stuff first hand.

Re:Bug Conservation

[cstacy]

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.

Yes, the article is more fake news: We Compared Static to Dynamic And You'll Never Guess What Happened!!! Overblown generalizations of the results, of an ill-conceived experiment. Actual Results: Without controlling for much of anything, our random comparison of some programming languages with many features (of which type checking may be one), without getting into specifics, we find that some programmers have more bugs than others, Film at 11

Re:Bug Conservation

[ThosLives]

It seems you missed the half-joking nature of my OP... or perhaps didn't care?

Yes, it is possible to create flawless software - if you have no constraints on budget or time and the requirements are actually unvarying and correct.

Code itself isn't the problem, which is why the language du jour never eliminates the problem. It is very rare that a project is willing to even attempt to produce "flawless" software. And even our best efforts (MISRA, RTCA, ISO, and the like) at "safety critical" software processes fail to prevent seemingly trivial flaws - so there is something that is beyond technology.

So yes, perhaps calling it "conservation of bugs" is a bit trite. I don't know what else to call it though.

Re:Bug Conservation

[SoftwareArtist]

The problem is that the dynamically typed code also has all those bugs. You get the same bugs you would in a statically typed language, plus a bunch of others on top.

There's no magic solution to get rid of all your bugs. Static typing won't do it. Automatic memory management won't do it. Unit testing won't do it. But each of those helps. They do catch a lot of bugs, and catch them sooner, and that means fewer bugs left in the end.

Re:Bug Conservation

[Tablizer]

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."

There's also turn-around time. If you can get more done in a dynamic language, then you have more time for testing and code review.

Re:Bug Conservation

[swilver]

Incorrect. What actually happens is that with safer languages, more people can write software and the *average* competency drops. It does not however affect the competency of already competent coders when they use more secure languages.

You'd think that be obvious, but please keep convincing yourself.

Re:Bug Conservation

[vux984]

That does not mean that the code is better in any way though.

It doesn't mean it is good, but of course its "better". A certain class of bugs eliminated.

All the subtle bugs and shitty coding practices may remain, but at least one issue is taken care of.

I despise javascript because in code of any complexity, a stupid typo in an infrequently used if-then-else clause explodes at runtime, possibly weeks or even months later. Sure its simple and easy to fix, but holy shit how can anyone want to use a language that doesn't catch just catch this stuff for you before it even tries running it.

Re:Bug Conservation

[Anonymous Coward]

A study I read a while ago (can't find it now) found that the number of bugs is relatively constant per 100 lines of code. This is why programs written in Python tend to have fewer bugs than the same application written in Java; whatever advantage you might get get from static typing you more than lose in the end due to the added verbosity.

Re: Bug Conservation

[Zero__Kelvin]

No you don't. You never have enough time for those things, and management never says "oh ... it's dynamically typed? Feel free to spend extra time on code reviews then!"

Re:Bug Conservation

[gweihir]

Ahem, what? Is there even any type of argument in there? Or do you believe having more people able to code (and the additional ones being of significant lower competency) is somehow desirable?

Re:Bug Conservation

[jeremyp]

This is not true. Sure, strongly typed languages won't eliminate all the bugs and the ones that are left may be quite tricky to find, but it is absurd to suggest that the ability to run a program where you typed a variable name wrong means that those tricky bugs are magically not there.

Re:Bug Conservation

[jeremyp]

But the destructive hard to find bugs are still there with the weakly typed languages. It just takes you longer to get around to dealing with them.

Re: Bug Conservation

[Anonymous Coward]

Exactly. The fact that it doesn't crash when you do account_balance = "sandwich" + 1.00 doesn't make anybody's life better. Especially not the guy working in the bank's call center.

Re:Bug Conservation

[Anonymous Coward]

And these 3000 lines of Java has the same functionality as my 10 lines in Python.

And this was real case but without some nasty logic bug they had.

But their code compiled.

Re: Bug Conservation

[Anonymous Coward]

read "GÃdel, Escher, Bach". the book is all about formal systens vs reality. no formal system can fully cover the whole domain it professes to fully explain.

Some of us are happy only working within the bounds of our formal systems (bureaucracy, strongly-typed languages, etc). "if your only tool is a hammer..."

Some of us want some flexibility to be able to try and deal with bad data (according to the formal system) and make sense of that data, even if it's imperfect...

Re:Bug Conservation

[Anonymous Coward]

Of course it is.
If you are not able to get a job in a language, then that language is dead -- or at least, trapped in a negative feedback loop. Managers won't allocate money to a project in that language. That is because they can't hire any decent programmers in that language. And there are no decent programmers of that language, because there are no projects in that language that hire decent programmers of that language. And that is less programmers learn the language in the first place, or have any professional experience in it. Which of course makes it even less likely for managers to hire people knowing that language.

But it gets even worse than that -- think about libraries. You can create a language during the course of a weekend -- if You like lisp, that is. Javascript took two weeks. Language is meaningless next to its libraries. As an example of that, You can think of the multitude of jvm languages, some of which hold on because people think java to be obnoxious or ugly -- but they still want to use the throng of libraries that have already been written for it. The more people writing code (whatever the competency), the more it is likely that somebody has already written a good or partially useful library for Your use case. And writing it is half the battle -- since there are a lot of people (even cretins) using it, it is also more likely that a bug has been found. You need to have a system that takes in cuneiform script? Much more likely to have in python, java or C, than k, elixirscript or Fjölnir.

How about Fortran or COBOL? They are not used because the languages are perfect, but because there is a secure job market in maintaining old software, and adapting it to match the changing world. In essence, a million monkeys writing code that people use to make money generates a market for life.

Re:Bug Conservation

[Anonymous Coward]

Poor memory managment can result in memory leaks that won't crash Your system? I hope that's a joke.
All garbage collected language have a particualrly nasty range of memory allocation bugs, that might result in system destabilization due to automatic memory allocations. In essence, You might get an out of memory exception on a VM that has plenty of free memory left -- with which You can't really do anything sensible. You can manage that in C by knowing precisely how and when memory is allocated and deallocated in Your system -- at the cost of a higher chance of fucking up, and crashing everthing when it does.

Not only that, what about synchronizing multi-threaded accesses to memory? Whatever bounds-checking You do doesn't help if You have race conditions. And that does lead to bad data which leads to crashes. But don't worry, there is a software sollution! Go ahead, and try it -- it's called immutable data structures. It really helps, and solves a myriad of problems -- at the cost of much more convoluted data synchronization logic and shitty performance. Really, try them -- see if You still bitch about performance not being a factor.

On that note -- performance problems are not bugs? Not in my field, mate. We have a situation where adding a "virtual" to just one of a multilude methods lowers the efficiency of code by a substantial procent (worst case, even in double digits) -- which is an unacceptable bug, since the system cannot compute nearly fast enough.

As for maintenance and refactoring, I can write shorter and far more general functions in looser languages. In fact, I have had more problems refactoring stricter languages, precisely because of a lack of simple higher-order logic that would allow shorter code to be written. Generally, I think that You are misattributing causes to the spaghetti mess that is usually generated by using looser languages. I agree with You that looser languages tend to attract spaghetti -- but my personal experience is that spaghettiness of the code is much more correlated to a prototype being taken into production or a necessity of creating something workable fast and dirty. What I mean by that is that a prototype written in a looser language is much more likely to be written and actually finished before arbitrary management deadlines, and then pushed into production by hapless idiots who don't know what is the cost of pushing bad code. Every part of that has actually painfully happened to me -- but there is a silver lining in that cloud. Since prototypes were made rapidly, my management was able to attract and actually serve more customers, and allocate more funds to that prototype -- which should be utilized for a rewrite, but is much more likely to be used to implement new features and take on more technical debt that is necessary. In essence, by the time You have finished writing a prototype in C, You can already have a bad but workable and tested product written in python, integrated with other systems and being sold to customers -- even already making a return on an investment.

Re:Bug Conservation

[Anonymous Coward]

That does not mean that the code is better in any way though.

It doesn't mean it is good, but of course its "better". A certain class of bugs eliminated.

Just because one class of bugs is eliminated doesn't mean the code is better. Other bugs may be introduced. In eliminating some bad code, you also eliminate perfectly legitimate good coding practices and that may mean you have to write longer code. For example, if you write a function in good Python to put an item as second last in a list, the same function will work on any object which behaves like a list, so you won't have to write a second copy of it. In a statically typed (N.B. Python is strongly typed; it's just strongly dynamically typed) language you may have to write a second function which will introduce bugs.

Alternatively you may use features like Haskell typeclasses in your strong/statically typed language. These are useful for bug detection but slow the coding down considerably. This means you have less time for testing left so, for a given period of time you produce either less code or, more likely, less properly checked code, which again introduces the possibility of bugs.

All the subtle bugs and shitty coding practices may remain, but at least one issue is taken care of.

Always ask yourself, "at what cost" if the cost is too high then you may be better forgoing it.

I despise javascript because in code of any complexity, a stupid typo in an infrequently used if-then-else clause explodes at runtime, possibly weeks or even months later.

A proper compiled, typed language would pick this up. However, so would checking that you have 100% line (not even branch) coverage of your code through test cases. If you concentrate on that instead of spending time on the compilation and fighting the type system you might end up with better code in the same time because you will also test the logic of your program.

Of course, sometimes you get the chance to do both.

Sure its simple and easy to fix, but holy shit how can anyone want to use a language that doesn't catch just catch this stuff for you before it even tries running it.

The real benefit of a weakly typed language can come when you start refactoring. You can now change and redesign without going through the vast, needless complexity of things like generics and interfaces. If you can fix things faster due to avoiding static & strong typing you might find that your overall code is better even though you are able to make more mistakes.

Re:Bug Conservation

[Anonymous Coward]

You have all jumped to a conclusion that may or may not be incorrect.
We have yet to establish that the "more secure" languages actually are more secure.

Of course no-one is willing to say what language they actually mean since it would then be easy to disprove them.
They probably mean python or java but they phrase their statement so that it could be erlang or haskell.

Re:Bug Conservation

[Anonymous Coward]

Many methods for creating safe code doesn't attempt to produce bug-free code.
The intent is to make sure that the parts that are critical for the safety works as intended and that if they fail they do so in a safe manner.
In many cases it is perfectly acceptable that safety critical software crashes as long as that leads to the machinery coming to a full stop.
Parts of the code that aren't involved in safety only needs to be written so that they can't interfere with the critical parts.
This means that pointer usage could be a big no while it is perfectly acceptable that a division by zero that kills that particular thread is acceptable.

Re:Bug Conservation

[Anonymous Coward]

Do not underestimate human laziness. If a language promises less bugs then the human is going to rely on that. And the human is going to get incrementally lazier until there will be enough bugs that the human has to fix some of them.

The amount of bugs will stay constant, regardless of the language used. If nothing else, the bugs will be similar to what caused the failure of Mars Climate Orbiter mission. No language protects from the effects of the human laziness.

Re:Bug Conservation

[Anonymous Coward]

...a stupid typo in an infrequently used if-then-else clause explodes at runtime, possibly weeks or even months later. Sure its simple and easy to fix, but holy shit how can anyone want to use a language that doesn't catch just catch this stuff for you before it even tries running it.

This is exclusively caused by poor programming habits, not by typed vs non-typed. Firstly, relying on auto-completion would probably solve 90% of this problem - I do not remember a single time in the last year that I had a typo in a variable name and I rarely use a linter. Linting however, solves 100% of the problem. 'Use Strict;' solves 100% of this problem. Unit tests solve 99% of this problem. Manually testing your code branches when you make a change solves 100% of this problem. All of these things should probably happen regardless of typed debates, and all of them create a *really* strong safety net for this problem among many others. Expending mental effort on type-casting (both the infrastructure of the language itself and the implementation costs of those who use them) detracts from other things you probably should be focusing on. It's like worrying about manual memory management - garbage collection takes the issue off your plate. Bothering with the implementation details of iterating over different types is solved by having type-less all-iterable objects.

Re:Bug Conservation

[Anonymous Coward]

It cuts both ways... as a type-less convert coming from over a decade of a typed ecosystem (and being a proponent of them as well) I discovered that as I no longer used my multi-threading skills they became average - I can still do it and solve problems well with threads, but it takes me longer and I make more basic mistakes when I'm scaffolding an application. I suspect both issues in these points are problematic based on what you are used to and practiced at.

As a type-less proponent today, I've discovered there are a lot of strategies that you can take to make JavaScript *very* refactorable. But the practices typed developers use are not compatible in a type-less world so on the onset it appears as if the language is merely flawed. Learning to accept the nature of the type-less world and defensively coding for it solves this problem. Simplifying the number and complexity of your data types as well as just reducing the boilerplate of type boxing and type definitions makes more meaningful of an improvement to language design than type-checking in my experience. Extracting that logic from the compiler into a linter makes a better separation of concerns and makes the respective code bases easier to understand and work with. An AST ensures the proper API between the two projects so they aren't out of sync with each other.

For instance - it's very common to see function names like Foo.create() or "delete" or "process" etc in a typed world because you *know* what objects those methods refer to in the type analysis. But when Foo is contained in an instance variable you can't grep for all "Foo.create" or even all "create"s because of the false-positives in a type-less world. Grepping for those namespaces in code doesn't work for refactoring. But if you pick a unique namespace up-front - moniker.createFoo() you're very much likely to find all of the "createFoo" instances. While this won't find invoke("create" + xType) usage where xType == "Foo" that too is just another practice that you limit in a typeless world. These aren't meticulous details to pre-design, they're just habits you develop and apply without thinking. Going back to a typed language from this mindset is just as foreign after enough time has passed.

You are correct in that the competent people scale codebases in the languages they're most experienced in regardless of the strengths and limitations of the language. I've even seen QBasic applications that were monstrously large and very well designed by competent coders.

Re:Bug Conservation

[SixMinutes]

I use ESLint with editor integration, which will tell me if I have unused, misspelled, or shadowed variables, among a hundred other code correctness issues.

For people who really want type checks in Javascript, there are also tools like Flow and transpiled languages like Typescript. It's more of a 'types optional' thing now.

Re:Bug Conservation

[gweihir]

Ah, I see. You are one of the morons responsible for the current mess with insecure and unreliable software. Great job!

Re:Bug Conservation

[myowntrueself]

I fully agree. Bugs are just getting more destructive and harder to find the less permissive a language is. Also, if you cannot make type-errors, then any random person can write type-error free code. Type-errors simply cease to become a quality-metric in that case. That does not mean that the code is better in any way though.

In other words, programmers will just innovate and find new ways to make mistakes.

Re:Bug Conservation

[myowntrueself]

It is funny how code written in your "inherently more secure" languages gets exploited at the same or higher rates these days. What actually happens when languages get "safer" is that coder competence drops and bugs just move to a higher level, without being any less destructive.

Citation needed.

If you cannot see that happening over the last few decades, then you seem to be blind to what is going on.

Yeah, citation still needed.

Re:Bug Conservation

[arglebargle_xiv]

Also... they studied Javascript. Probably 80% of the bugs would have gone away if they'd gone with someone who doesn't do their development in Javascrpt.

Re:Bug Conservation

[vux984]

I use ESLint with editor integration, which will tell me if I have unused, misspelled, or shadowed variables, among a hundred other code correctness issues.

Will it tell you that these are mistakes?

newX = coord1.x + coord2; //should be coord2.x
newX = coord1.GetX; // should be coord1.GetX()
console.Log(coord1+ ", " + coord2);

Yes they are truly stupid mistakes; which is why I called them typos. They are the sort of error you'd make in a hurry, or that might be left behind after some maintenance/edits but they are automatically caught by type checking.

transpiled languages like Typescript

Yeah, but that's another language. I actually like Typescript.

It's more of a 'types optional' thing now.

Sure, but where is the good argument for not using them? It's like advocating writing javascript without "use strict;" because uh... i can't really think of a good reason for doing that either.

Re:Bug Conservation

[Anonymous Coward]

The compiler of strongly typed languages find the type of bugs such as mistyping variable names. The statement made above: "Hey, my code compiles! Now I get to find out where all my bugs really are" means that the developer is now looking for logical bugs that are hard to find and fix regardless of the language. Where is there any evidence that bugs are more destructive and harder to find in a less permissive a language (i.e. strongly typed)?

Re:Bug Conservation

[Anonymous Coward]

Ah I see, You are the cunt who can only provide insults instead of reasoned arguments. Great job!

Re:Bug Conservation

[Ichijo]

in code of any complexity, a stupid typo in an infrequently used if-then-else clause explodes at runtime, possibly weeks or even months later. Sure its simple and easy to fix

Sure, if you ignore the cost of re-testing and redeploying, plus the cost of lost business caused by the bug and so on. The earlier a bug is detected, the cheaper it is to fix, by orders of magnitude.

Re:Bug Conservation

[Anonymous Coward]

Most of the really seroius memory management bugs are exactly in managed code. Anyone that has evevr developed anythign really gigantic knows that.

Re:Bug Conservation

[Anonymous Coward]

That is true, good coders write safe,e fficient and stable code evenon the first version of C. But badp rogrammers cannot even delude themselves into thinking they are capable of anything. The result of the " easy mode languages"is that more people THINK they are capable of coding.

Re:Bug Conservation

[vux984]

I was just saying that once eyes were on the bug, that the bug itself was easy to fix.

I agree completely about the cost of testing/deployment/downtime; and think its batshit insane to advocate a language that doesn't catch these automatically at 'build' time.

Re: Bug Conservation

[Tablizer]

If owners/bosses want to trade quantity for quality, that's up to them. Don't like it? Tough.

Re:Bug Conservation

[Anonymous Coward]

Not true. If you move from something like C to Java, yes, I'd be inclined to agree with you. But if you move from something like Java (which is arguably not a very safe language) to something like Ocaml or Haskell, you will see a sharp decline in the number of people who can write software: The average competency increases drastically.

Re: Bug Conservation

[Zero__Kelvin]

I'm glad you agree your comment was bullshit. Good for you owning up to it!

Re:Bug Conservation

[dkasak]

So you're saying a whole class of bugs gets eliminated, but also maintain the code is not necessarily better in any way? I fail to follow your logic.

Re:Bug Conservation

[Anonymous Coward]

This indeed. Strict typing hands a set of crutches to code monkeys who couldn't hope to stand on their own feet without them.

Strict typing still doesn't prevent anyone from using float/double as a type for money.

Re:Bug Conservation

[sg_oneill]

There's also turn-around time. If you can get more done in a dynamic language, then you have more time for testing and code review.

Look I love Python as much as the next guy (Javascript can go and die in a fire), but not specifying types is a false economy. Hurrah you saved seven or eight key strokes, now watch in horror as the edge case that jams an int into a float triggers during commissioning.

Good type checking (And I dont mean C or Java, I consider those at best Typo checking, useful, but 80s safe, not modern safe), the sort that pops up and says "Hey, theres a code path here that could put a null into your code, you'll either need to fix that or specify in the type that a null is valid" can be perfectly fast to work with , assuming you have a modern IDE (or even a decent emacs plugin I guess) as static analysis is fast enough these days to work with your editor and autocomplete the boilerplate out for you.

And heres the thing, you might have less time for bug fixing. Fortunately your IDE caught most of the forehead slappers before you mashed build, because thats a thing you can do with modern type safety.

Re: Bug Conservation

[Tablizer]

Sorry, I don't follow you. Dynamic languages may give an org more choices about allocating resources (quality vs. features, etc.). If an org chooses to allocate those extra choices/options different then mine or your ideal, that's another matter and is NOT the "fault" of the language itself. I'm just describing the choices it gives. Boss/owner decisions are another matter. You seem to be arguing that compiled/static languages force quality on an org, and that's why they are allegedly better (at the possible expense of features-per-hour). If that's not what you meant, please clarify.

The study itself says nothing about productivity (features per hour), it's only counting bugs after the fact.

Re:Bug Conservation

[microbox]

Using both statically and dynamically typed languages extensively for my day job, I much prefer statically typed languages when it comes to maintaining and refactoring code. Makes little difference when writing.

Re:Bug Conservation

[Tablizer]

It can be a lot more than 8 keystrokes. In some frameworks you have to pass "rows" around a lot, and type-centric languages make you keep stating the same type info over and over repeatedly redundantly. (AKA anti-DRY.) Often you only need to check types at certain key points, and that's what dynamic languages do best.

And yes, perhaps such row-passy frameworks are poorly designed, but they are what they are. I didn't make them, I'm just payed to use them.

Re:Bug Conservation

[david_thornley]

It doesn't mean it is good, but of course its "better". A certain class of bugs eliminated.

Which is good, all other things being equal. It isn't clear to me that all other things are equal.

I'm willing to believe that Javascript would do better with a static type system, but there are dynamically typed languages that work better than Javascript.

Re:Bug Conservation

[david_thornley]

Then there is code maintenance and refactoring, something which is near impossible with loose languages.

I find these work just fine with Common Lisp. Given a problem I know how to solve, C++ is very tempting. Given a problem I'm going to have to experiment with, I prefer Common Lisp, because I find it a lot easier to try things. I'm more likely to come up with an excellent solution.

Re:Bug Conservation

[sg_oneill]

We're not discussing frameworrks, we're discussing modern Type safe languages, and your confusing type explicit with type safe. One current language I'm kind of fond of is Crystal. Its a ruby variant that compiiles to hard machine code via llvm. All variables absolutely resolve to a type (Int, Float, etc),, but largely this is infered by the compiler, so you dont HAVE too speciify it much of the time, but only if the compiler can say "Ok, this must be an integer, and no other type is possible, so I got this homey". But if for instance type inference say an integer OR a null is possible (Ie its not initialized),, it'll hit the breaks and tell you too fix it. Now you COULD say "Ok, this is a union type of Integer and Null, so calm down" or you could fix it by initializing the variable properly. Unless you really mean for a null to be iin there foor some reason, theres no needd to specify the type, you just need to fix the bug, Unless you really do want nulls to be possible for some reason, in which case you can declare the type as something like Int32|Nil , but you know your code your garbagefire

Re:Bug Conservation

[strombrg]

Lines_of_code / number_of_bugs is roughly a constant across programming languages.

That's why programs written in VHLL's tend to have fewer bugs.

Re:Bug Conservation

[strombrg]

The earlier a bug is detected, the cheaper it is to fix, by orders of magnitude.

Agreed, but I'll point out that Python IDE's (or text editors with appropriate smarts like vim+syntastic), type inferencers (like pylint), gradual type systems (like mypy), and automated tests go a long way toward making it very cheap to catch Python bugs before deploying to test.

Combine that with the "fewer words per idea expressed" of Python, and you've got a winning combination.

Re:Bug Conservation

[strombrg]

Weakly typed languages are a little scary, and Untyped languages are even worse.

But Python is pretty strongly typed.

Re:Bug Conservation

[strombrg]

Even a laissez faire bug checker like pyflakes can quickly and painlessly find most misspelled variable names in Python code.

I prefer pylint over pyflakes; pylint is more stringent. And I'm starting to like to like mypy, which adds gradual typing to Python.

Re:Bug Conservation

[strombrg]

I'm a big Python fan, but I can't stop looking enviously at Rust. It sounds pretty promising at catching bugs up front. I wish I could rewrite Python's innermost loops in Rust instead of Cython or C.

With appropriate software engineering tools, Python can do pretty well at catching bugs up front, but it sounds like Rust takes it to a whole other level: beyond pylint and mypy, beyond C++, beyond Java.

Re:Bug Conservation

[mz721]

Nope; what's conserved is your time. You can spend it on new lines or fixing old ones, but you lose it at a rate of one second per second, regardless.

If we plot 'dev time per line of code' against project size, the small project will be quicker in a less stringent language, the large project relatively quicker in a stricter one. (Assuming in both cases the object is to get the program working correctly (as reasonable), not just working.)

Also, I am inclined to disagree with your 'conservation of bugs' argument in that I think fewer vectors means fewer bugs get in. If we allow that a more structured language will tend to be more verbose (defining things, explicitly converting types, etc), we might end up with fewer _ways_ for bugs to enter but more lines of code in total, so more lines that might be wrong -- but I don't think this will entirely cancel out the benefit of fewer types of error being possible/likely.

I'm old and dumb. I can only keep so many things in my head, so I like static typing. There's enough to keep track of without that extra layer of variability. Each to their own. I've mostly written numerical methods and modelling code, where logic errors are really important, and can be insidious. They can be there in any type of language, and I find static typing helps me discard one class of problems and focus on the important but subtle ones.

Python and Javascript are not...

[Anonymous Coward]

... real programming languages. They are for idiot kids who like to play dress-up and pretend to be real developers.

Re:Python and Javascript are not...

[Z00L00K]

Python and Javascript is to this decade the same as Basic was to the 80's.

Re:Python and Javascript are not...

[gweihir]

Spoken like a true cretin. While JavaScript is admittedly a really bad programming language, Python is a very good one. But both are real in any sense that matters and a competent coder can do real work of any size in both of them. The actual problem is that many people writing code these days are not "real" coders, but incompetent wannabees that like to blame the tools used for their personal limitations.

Re:Python and Javascript are not...

[sunderland56]

While JavaScript is admittedly a really bad programming language, Python is a very good one.

You sound like one of those weenie user-space developers.

Re:Python and Javascript are not...

[Midnight Thunder]

... real programming languages. They are for idiot kids who like to play dress-up and pretend to be real developers.

They are also great for rapid prototyping and cases where you only need something basic. They have issues, but I am wondering whether you are just rocking your high horse?

Re:Python and Javascript are not...

[MichaelSmith]

Current python programmer, and former C programmer here. Dynamic typing is great for a small to medium sized code bases but I would hate to work on anything really big and mature without static type checking. I have worked on large code bases with maybe 100 megabytes of code and C and Ada, a lot of it dating back 20 years or so. You can't safely refactor code that old, and you can't allow data of the wrong type to get in to it, so type checking at compile time is an important line of defense.

You can do that in python with run time checks of data types and thats what you would have to do at the entry point of your libraries, but it eats into your performance doing that. Python is too malleable for static type checking.

Re:Python and Javascript are not...

[gweihir]

You mean you cannot code in user-space? That seems to be a pretty peculiar disability....

Re:Python and Javascript are not...

[Anonymous Coward]

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.

JS has closures and introspection. Python is easy to write in, but not a good language. That's why there are so many tools to convert Python source to real languages like JS and C++.

Re:Python and Javascript are not...

[swilver]

Just imagine where Python could have been if it had static typing and delimited blocks which are the main problems opposed developers have with it. It would not have reduced the language in usability much at all, and it would still be highly suitable for scripting tasks.

I think it could then have been a real contender in the language space and would have been far more widely adopted. It could have been the default language for Android for example.

Re: Python and Javascript are not...

[Anonymous Coward]

but not a good language

LoL... ok sure, whatever. Ok now go back to your play area, the adults are talking.

Re:Python and Javascript are not...

[Darinbob]

The problem with rapid prototyping is that too often the prototype ends up being shipped as the actual product.
http://dilbert.com/strip/1996-...

Re:Python and Javascript are not...

[K. S. Kyosuke]

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.

Re:Python and Javascript are not...

[MichaelSmith]

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.

Re:Python and Javascript are not...

[K. S. Kyosuke]

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.

Re:Python and Javascript are not...

[MichaelSmith]

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.

Re:Python and Javascript are not...

[K. S. Kyosuke]

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.

Re: Python and Javascript are not...

[Zero__Kelvin]

That's not a problem with the language. It's a process problem. When management doesn't understand Fredrick Brooks all bets are off.

Re:Python and Javascript are not...

[cdreimer]

That's funny. I finished rewriting my shell scripts in Python because FreeNAS 11 has Python 3.6 installed.

Re: Python and Javascript are not...

[RightwingNutjob]

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.

Re:Python and Javascript are not...

[JustAnotherOldGuy]

Considering there are tens of thousands of people making shitloads of money every day coding some serious, useful applications in in Python, I'd say you're mistaken.

Re:Python and Javascript are not...

[Anonymous Coward]

Well well well. Slashdot's highly valued commentator and moderator and submitter is posting at -1. Look at that.

Re:Python and Javascript are not...

[Anonymous Coward]

You fucking ignorant Chritopher Dale Reimer, shell script are not written in python you dumb fool!

Creimy Dumpty sat on the wall,
Creimy Dumpty had a great fall.
All the king's horses
And all the king's men
Couldn't put Creimy Dumpty
Together again.

https://www.youtube.com/watch?...

Guy who thinks he can write shell scripts in python:
https://school.discoveryeducat...

And his chair, of course:
http://www.keynamics.com/image...

Re:Python and Javascript are not...

[Anonymous Coward]

For the valuable /. users that might already have read the following, please note that there is an important update.

IMPORTANT UPDATE:
Special Education for the Santa Clara County Office of Education has invested money to buy Chris a new chair:
http://www.keynamics.com/image... [keynamics.com]

Information about Christopher Dale Reimer and autistic people:

Autistic people have obsessions about things normal people don't care. For example, one of our autistic patient went haywire when he realized that there was a penny missing in his pocket change.

To calm him down, one of our educator pretended to have found it on the floor and gave a penny to him.

The autistic patient condition went even worse because he realized it wasn't the same penny!

Chris has an obsession with budgeting every penny. He doesn't understand that most people do not budget to the penny and have a flexible amount they allow for miscellaneous items.

I am Nancy Guerrero and I am Director of Special Education for the Santa Clara County Office of Education. We use Chris' (a.k.a. creimer,cdreimer) picture in our document because he is the hardest case we have ever had to handle:
http://www.sccoe.org/depts/stu... [sccoe.org]

Our artists were inspired by the low carb diet that Christopher follows scrupulously for the small lunch box and by the picture linked below for the rest. I am sure that you will notice the similarities such as the bump on the side of his chest and more:
https://ibb.co/gVad65 [ibb.co]

Please be easy on Christopher although, I am aware that some of our staff handling Chris post joke comments here and obvoiusly, the Santa Clara County Office of Education disapprove that behavior vehemently:
https://school.discoveryeducat... [discoveryeducation.com]

But it isn't Chris' fault if he is the way he is. We do the best we can do with him and he is partially integrated into society. We try to cure his abnormal need for attention but he is kind of stubborn and won't listen to anybody.

Thank You dear users,
-Nancy Guerrero

Re:Python and Javascript are not...

[Anonymous Coward]

There you are you disgusting fat sexist tube of lard, Christopher Dale Reimer!

You can be sure I will be watching this fake account too. I know this is you because you told me you were working on your freepass 11 file server and you are so dumb that you can't even masquerade yourself properly.

Now, I told you I was out of meds last week and you didn't even care to contact me you lazy fucker.

How many time do I have to express the emergency of the situation??????

The python click script you wrote for my pheromone revenue stream web site suddenly stopped to work!!!!!!

You fucking incompetent python script writer!!!

When it works, I get 4000+ clicks a day on my pheromone revenue stream web site but only 5 or 6 without it!!!!

Now, it seems like you dont care and that you have abandoned me you heartless fucking pig!

Bonus:
Here is a story that creimer told me when convincing me what a hard life he had:

The tree was him and the tree knot was his butt hole!

So, his uncle packed his fat ass with lard and with his cock! Not that it makes much of a difference but anyway, there it is!

Signed:
The girl that used to love you and now hates you, burn in hell where you belong you sexist pig!

Re:Python and Javascript are not...

[Anonymous Coward]

Hey Creimy-Dumpty,

Since you always talk about "enterprise-level" closets, "enterprise-level" offices, "enterprise-level" chairs, "enterprise-level" snacks, etc.:

Why don't you just use an "enterprise-level" language you silly? Applications written for java 1.0 in 1997 still run fine without a change on a 2017 java 8 installation.

"enterprise-level" chair:
http://www.keynamics.com/image...

Maybe "enterprise-level" goofs are unable to use "enterprise-level" languages!:
https://school.discoveryeducat...

Re:Python and Javascript are not...

[Anonymous Coward]

Indeed, indeed, Creimy-Dumpty had a great fall.

Re:Python and Javascript are not...

[Anonymous Coward]

You fucking ignorant Chritopher Dale Reimer, shell script are not written in python you dumb fool!

1. Create script file, example.py

#!/usr/local/env python
print(49 - 7)

2. Set executable bit on example.py.

chmod +x example.py

3. Execute example.py.

./example.py

4. Result is...

42

Re: Python and Javascript are not...

[Zero__Kelvin]

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.

Re: Python and Javascript are not...

[RightwingNutjob]

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.

Re: Python and Javascript are not...

[Anonymous Coward]

They don't involve complete fucking idiots, so you'll never know :-)

Re:Python and Javascript are not...

[wept]

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.

Re:Python and Javascript are not...

[david_thornley]

For that environment, it's best to have as much static checking as you possibly can. Most programs aren't in that environment.

Re:Python and Javascript are not...

[strombrg]

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.

Re:Python and Javascript are not...

[MichaelSmith]

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.

80s all over again?

[Anonymous Coward]

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?

Re:80s all over again?

[Z00L00K]

Yes, it's easy to throw together something quick, but this also means that it's common that something that was intended to be quick and dirty will become what's going into production - full with bugs and security holes.

Re:80s all over again?

[bugs2squash]

same number of bugs, just caught in a different way. In defense of the dynamically typed languages they do allow some quick progress to be made finding flaws in algorithms while the syntax nazi languages are still griping about non static thingamajigs being called from static whatchamacallits.

I'd be interested to see if languages like clojure tend to reduced bugs in the compiled code, the only reason I think that it might is because it took me so much effort to get event the most trivial program to even approximate working that by the time I was done the program was concise and beautiful, shame it took me hours to get there (it would have taken me minutes in my sloppy python).

Re:80s all over again?

[Anonymous Coward]

Every generation of programmers have to relearn the same lessons. Maybe something should be done to this cultural waste? Standard notations, ontologies and languages to describe the wheel so that everybody recognize it as it is perhaps? Maybe the time would be right for something like that a few decades into future.

Re:80s all over again?

[Hognoxious]

This. Somebody builds a perfectly good Tom Sawyer raft which is fine - until it gets extended, enhanced and fuck knows what, bit by bit, into an aircraft carrier.

Re:80s all over again?

[david_thornley]

In other words, languages with strong static typing are more pointy-haired-boss-compatible? I can accept that.

Re:80s all over again?

[strombrg]

Python is strongly typed. It's also dynamically typed.

You can easily catch Python bugs analogously to how you would with a statically, manifestly typed language, using an IDE (or editor with plugins n- I like vim+syntastic), using a whole-program static analyzer (like pylint), using gradual typing (like mypy) and using automated tests.

Strong typing is like training wheels

[gweihir]

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.

Re:Strong typing is like training wheels

[halivar]

It's cute that you need a language altogether. When you're ready to be a real programmer, you can learn how to write all your own op-codes in assembler, like a grown-up developer.

Re:Strong typing is like training wheels

[Z00L00K]

On the contrary - strong typing is preferred by those that have coded a long time and have to maintain systems that has been around for a long time.

As soon as you inherit code written by someone else you will waste a lot of time to understand how it works - and if it's not strongly typed you can easily miss something that previous coders did introduce. A strongly typed system will tell you quite fast that the code you changed the method header on was actually used by 200 subroutines. On a system written in a language not forcing strong typing you may discover that routines you didn't know existed are using it - and they are used only once per year at new years eve - guess who has to put in overtime then?

Re: Strong typing is like training wheels

[Anonymous Coward]

The big assumption you're making here is that it's your code. I've worked on several projects requiring refactoring of both Java and JS components from someone else (with no documentation), and having the Java compiler type check made what was very frustrating task in JS mostly effortless in Java.

Re:Strong typing is like training wheels

[gweihir]

And fail. Assembler is a language (or rather a family of languages). You probably meant machine code.

Re:Strong typing is like training wheels

[gweihir]

I see the "incompetent coder" faction on Slashdot had mod-points today. Mod me down all you like, does not make what I said any less true.
 

Re:Strong typing is like training wheels

[halivar]

FUCK! I had hex-editor in my head and I fucked it up. Fuck me. I failed. And fuck you, too, for sinking to my level. We all fail together.

Re:Strong typing is like training wheels

[gweihir]

If you have these problems, then something else is rather badly broken, like, say, the architecture of your code and the documentation that came with it. Sure, this sad state of affairs is the norm, but it is not a good state at all as it stems from developer incompetence.

Also you are quite wrong about "those that have coded a long time". You would be probably right if you had said "have coded for a long time and still cannot do it well".

Re: Strong typing is like training wheels

[gweihir]

No, I assume it is code written by competent people. Sure, if the developers that wrote the code needed those training wheels, then removing them will have them fall over all the time. But leaving the wheels on is the wrong place to fix things.

Re:Strong typing is like training wheels

[Anonymous Coward]

Coding 25 years. Started in C moved to C++. I now do everything in Python now. I laugh at recruits asking if I'm interested in C++ jobs. Seriously. if it's a genuine performance problem I'll code it in C++ most likely. Otherwise python has so many wins it's ridicules to go back to a typed language for me.

But to be fair and dead blunt. An average coder (less than 5 years) will write more efficient Python code than an average C++ coder. Now an advanced 5+ years will kick ass in C++ when efficiency is desired.. but if he were me he'd code that computationally demanding parts in C/C++ and export that to python were he had access to nice inbuilt data structures and algorithms.

Someone higher up said it. But you can write good code in any language or you can write a heaping pile of rubish. Experience is almost alway's more important than language choice in my experience.

Re:Strong typing is like training wheels

[Jeremi]

It's cute that you need a language altogether. When you're ready to be a real programmer, you can learn how to write all your own op-codes in assembler, like a grown-up developer.

Assembly language is also a language. Toggle in the bits directly via the front panel switches, like a real man :)

Re:Strong typing is like training wheels

[swilver]

Yes, the language it was written in was broken.

Or are you suggesting that the people that actually write in these loose languages "because it saves me typing 5 characters" actually will write documentation saying that said function is called at new years eve? And will spend time on proper architecture? Perhaps in your fantasy world they also wrote unit tests with 90+% coverage?

No. You get the code dumped in your lap, and you will be praising the gods if there's an old completely outdated Confluence site that describes what some junior on the team thought that the software is supposed to do.

If that code is Javascript, then you might as well throw it away and rewrite it, it will be faster. If that code is Java, you can make modifications and refactorings to it and be reasonably sure that you didn't break anything totally unrelated.

Re:Strong typing is like training wheels

[swilver]

C/C++ suffers from a complexity problem, which it needs to do low level stuff. Often this the result of just too many types, too many #ifdefs, just too many edge cases. However its static typing and the amount of errors it catches at compile time is something to be praised.

Python has much less types and does away with compiler directives, and is generally a bit more expressive. This removes a lot of complexity, but it is not perfect. It could have been statically typed as well, without losing much in expressiveness. It also introduced indentation equals blocks, which was a huge mistake, and again, it would not have been any less of a language if it had simply adopted curly brace syntax.

So yes, Python is probably better than C/C++ when it comes to preventing bugs, even though it introduces new classes of bugs. There are however languages that offer the best of Python and C/C++. It may be worth your time to look into those.

Re:Strong typing is like training wheels

[Anonymous Coward]

Modding you down is a service to any novice programmers on here who might otherwise have mistaken what you said for some semblance of fact.

Re:Strong typing is like training wheels

[gweihir]

Hehehehehehehehehe ;-)====)

Re:Strong typing is like training wheels

[gweihir]

I found that C++ is not worth it for me. Far too complicated and most of its features are not needed. I use Python as glue and C for the heavy lifting these days. That works pretty well. Of course, this is not an approach a beginner can take, as you rightfully point out. And, of course, somebody experienced and competent can indeed write good code with almost anything.

Re:Strong typing is like training wheels

[Anonymous Coward]

Woah, front panel? What a pathetic N00b!

Real programmers use a paperclip and a logic probe.

Re:Strong typing is like training wheels

[Anonymous Coward]

I see the "incompetent coder" faction on Slashdot had mod-points today

Whereas you are one of those rockstar superhero coders that never makes a mistake, right? You must be totally awesome and not al all an insufferable ass.

Thank you, but I'll keep using the `training wheels' of strong typing, because I have only been writing software for 25 years now.

Re:Strong typing is like training wheels

[Kaenneth]

Oh la-dee-dah mr. fancy Hex editor.

copy con: program.com and keyboard alt codes are the way to go.

Re:Strong typing is like training wheels

[Anonymous Coward]

I found that C++ is not worth it for me. Far too complicated and most of its features are not needed. I use Python as glue and C for the heavy lifting these days. That works pretty well. Of course, this is not an approach a beginner can take, as you rightfully point out. And, of course, somebody experienced and competent can indeed write good code with almost anything.

In C++ you use only what you want. So just don't use "unneeded features". It's that simple.

Re:Strong typing is like training wheels

[Walter White]

Assembly language is also a language. Toggle in the bits directly via the front panel switches, like a real man :)

You are confusing machine code and assembly. An assembler is a program that reads a text file with instruction mnemonics, constants etc. and converts it to machine code. You can enter machine code via a front panel and (if done correctly) expect the results to execute. Not so with assembly. /pedantic

Re:Strong typing is like training wheels

[Anonymous Coward]

Have to agree. Mostly it's programmer can't program not the language itself that's the issue.

I think most would agree that assembler is inherently naster than C and C is nastier than Java - but the best code I've ever seen was asm, and the worst encountered day to day is Java.

All better languages do is allow poor programmers to produce code that runs more quickly - runs efficiently and does what it was supposed to do are not problems the language can fix. And larger volumes of code doesn't equal better code, usually the opposite.

Re: Strong typing is like training wheels

[liefer]

Oh do shut up already. Your entire argument is "I like dynamic typing, if you don't that means you suck and is a horrible person"

Re:Strong typing is like training wheels

[Anonymous Coward]

when you inherit code and projects it is pretty much the standard and there aint shit you can do about it. yes it is from poor practises but that is the practises 90%+ of developers use.

Re:Strong typing is like training wheels

[140Mandak262Jamuna]

Code documentation? The original design document that was never updated?

Why did you think Dijkstra said, "Always debug the code, not the comments".

Re:Strong typing is like training wheels

[jeremyp]

Obligatory XKCD

Re:Strong typing is like training wheels

[Anonymous Coward]

I see the "incompetent coder" faction on Slashdot had mod-points today. Mod me down all you like, does not make what I said any less true.

And Gweihir is here representing the Dunning-Kruger faction.

Re: Strong typing is like training wheels

[Anonymous Coward]

Christ, dude, nobody is impressed by how amazing a programmer you are. We all went through this phase where we thought we were the best programmer in the world. Then we got jobs, cracked open the legacy code, fired a supersonic blast of shit our pant legs, and finally truly understood what Dunning and Krueger were talking about.

Humility, sir. You're going to need it eventually, and it's easier if you start practicing now.

Re:Strong typing is like training wheels

[Anonymous Coward]

Let's play "spot the terrible developer."
gweihir for 1 point.

Re:Strong typing is like training wheels

[Afty0r]

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.

Absolutely agree. Code should be written more than anything to not fail (or to only fail gracefully), following this it should be written for readability. Using strong types provides a huge amount of semantic meaning - both to future you (or future other maintainer) and also to your compiler and IDE - this semantic meaning is invaluable.

Re:Strong typing is like training wheels

[Anonymous Coward]

My front panel has 8 switches and a step button.

Re:Strong typing is like training wheels

[ceCA]

Most programmers in commerce do not get to choose the language they want to program. Strongly typed languages are used by long time programmers simply because strogly typed languages were created first. So saying that long time programmers prefer strongly typed languages means nothing. C++ is overly complex and the only reason that it exists is that this very complexity insures job security and high pay. When you spend your time getting bogged down in useless minutia and trying to understand some purposely written esoteric code with strong typing when it could have been written in a dynamic language in 1/2 the time. I say that C++ makes a program more complex, harder to maintain, and take longer to code and even ultimately LESS reliable when the poor slob who takes over the program to maintain it misREADS the code. C++ is truly shit.

Re:Strong typing is like training wheels

[RoccamOccam]

It also introduced indentation equals blocks, which was a huge mistake, and again, it would not have been any less of a language if it had simply adopted curly brace syntax.

To the contrary, I've contended before that Python's use of whitespace to delimit blocks has been a key component in its *success*. Why? Simply, because it is one of the few languages that has that feature.

Some developers (myself included) really like this whitespace significance, but others hate it with a passion and talk shit about it every chance they get. Consequently, very few new languages adopt that behavior.

So, every time a hot new language comes around, it siphons excited developers and users from established languages (e.g., Perl -> Ruby). But (perhaps) that tends to not happen to Python, because for a lot of its developers and users, whitespace significance is really terrific and there are very few alternatives if you like that. It seems that Python keeps its developers for a long time and the language and the incredible diversity of libraries reflects that.

Re:Strong typing is like training wheels

[gweihir]

I am pretty much doing that. Calling what is left "C++" would not be accurate anymore though.

Re:Strong typing is like training wheels

[myowntrueself]

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.

Real programmers develop their own chipset.

Re:Strong typing is like training wheels

[Anonymous Coward]

"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."

Ah, we have a dreamer. Sail on, blithe spirit.

Re:Strong typing is like training wheels

[Anonymous Coward]

quit your whining. thats what you get paid for.

Re:Strong typing is like training wheels

[david_thornley]

Personally, I use butterflies.

Re:Strong typing is like training wheels

[david_thornley]

Or are you suggesting that the people that actually write in these loose languages "because it saves me typing 5 characters"

I think you're talking about the null set. A good dynamically typed language just works differently from a good statically typed language. They aren't the same thing, just with or without type declarations.

Re:Strong typing is like training wheels

[david_thornley]

You have just said that having code work is of secondary importance. I'm not convinced.

Re:Strong typing is like training wheels

[strombrg]

Python is pretty strongly typed, as is Java.

Tools like pylint and mypy can make Python practical for large projects.

Re:Strong typing is like training wheels

[strombrg]

Python is typed.

Re:Strong typing is like training wheels

[Z00L00K]

Except that it's dynamically typed, not statically typed so you need to go back to the assignment to find out what's assigned to the variable or do some analysis of the variable when it has been assigned to figure out what's up.

Follow-up study

[Anonymous Coward]

How does development time and/or effort differ between statically and dynamically typed languages?

Also, why does the title ask about strong typing while the body talks about static typing? Do the editors not know there's a difference? Or do they not care?

FORTRAN 77....

[MikeTheBike]

Python... smython...Still using FORTRAN 77 with the wonderful way of (not) declaring types of variables... or rather looking at the name of the variable to understand what kind of type it is...

Language matters

[doragasu]

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".

Re:Language matters

[gnupun]

* Ada has a lot of type safety and yet no one uses it.
* Pascal has decent type-safety and yet only a few people use it.
* C is very weakly typed and plenty of people use it.
* Python and JS are strongly typed, but with weak static checks, and again have plenty of users.

Can we infer that programmers are lazy and prefer languages that "don't check too much?" Languages with fewer compile-time error messages seem to do better.

Re:Language matters

[Anonymous Coward]

If you want to get unpredictable results, code it in Swift.

Re:Language matters

[Anonymous Coward]

JS is weak and dynamic typed. Python is strong and dynamic typed.

Re:Language matters

[maelkum]

Python is strongy typed. JavaScript is weakly typed. They are both dynamically typed. Consider the below code... ...in Python

>>> 42 + 'Answer'
Traceback (most recent call last):
    File "", line 1, in
TypeError: unsupported operand type(s) for +: 'int' and 'str'
...and in JS

js> 42 + 'Answer'
"42Answer"

One simple rule for determining if a language is weakly or strongly typed is: "Does the language lets me combine incompatible concepts (like add apples to oranges)?"
The rule itself is a bit weak, though - what are incompatible concepts, for example.

YES, ABSOLUTELY

[Anonymous Coward]

I have found the harder I mash my keyboard the more the bugs infesting it die. I think eating baklava while coding might have something to do with that. . .I go through a lot of keyboards. . .

Strong != Static

[Anonymous Coward]

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.

Re: Strong != Static

[Anonymous Coward]

Good point.

Unfortunately there are bad programmers who abuse flexibility in typing, just as there are good programmers who use it to advantage.

I have had to deal with code which nominally deals with a bool, but that could variously be NULL, or even a string treated as truthy.

When the bug is subtle, it is expensive to fix. And depending on the circumstances the bug could itself be very expensive.

15%? Even *if* true, at what cost?

[Anonymous Coward]

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.

You lost me at semantic whitespace

[Anonymous Coward]

But I guess a loose type system is another good reason to avoid it.

What a silly question

[asackett]

This observation doesn't make me wish to ditch a programming language, but it does make me glad I do test-driven development.

Re:What a silly question

[Anonymous Coward]

Do strongly/statically typed languages help reduce bugs.

Yes - yes they do. Next!

Seriously, this qualifies as a "DUH! question, but you stupid fucking Javascript monkeys never learn.

Even when your stream-of-consciousness caffeine fuelled 1 man band application falls over mysteriously at run time ... you will never learn.

Strongly/statically type languages make you think about what you are doing UP FRONT. They save masses of time and grief for both YOU and YOUR CUSTOMERS.

That multiplies up when you have to work with other people in a team - you know, on a big boy project.

If you want to write in Javascript... then use Typescript at least.

Oh, and if you crap on about how Javascript allows you to write quickly... remember, properly typed adult languages allow the IDE to intellisense and refactor FOR YOU. They help you write code faster.

Just sayin.

Re:What a silly question

[Anonymous Coward]

Seriously, this qualifies as a "DUH! question, but you stupid fucking Javascript monkeys never learn.

[....]

remember, properly typed adult languages allow the IDE to intellisense and refactor FOR YOU. They help you write code faster.

Just sayin.

And yet, the Javascript "monkeys" end up delivering working software which gets them money, customers and money and happiness for their customers whilst the IDE jockeys and their "scalable agile frameworks" end up delivering things like the 12 Billion pound NHS IT Disaster.

Just sayin.

Re:What a silly question

[Anonymous Coward]

So let me get this straight, you're comparing bullshit Javascript frameworks to a fucking gigantic IT system that was designed to manage the UK national health service.

Really?

I rest my case.

You're actually dangerous.

Re:What a silly question

[the_saint1138]

Yeah, I agree. Most of the discussions in this thread seems to forget that tests should cover any type errors potentially introduced by using a weakly typed language.

I would go further and say that if you're using a compiled, strongly-typed language instead of a comprehensive set of tests, you're doing it wrong.

Well duh

[DrXym]

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.

Re:Well duh

[Anonymous Coward]

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.

maybe you should try "testing your code before sending it to customers", seems like something that might help you

Re:Well duh

[doctorvo]

That "catching at compile time" doesn't come for free: you need to add type declarations to your code, and a lot of problems become much more complex to solve in a statically typed language. So it is, in fact, far from clear that this is "cheaper in terms of development effort".

As for bugs, static typing only finds a subset of them; you need good software testing. Once you have good software testing in place, it finds type errors just as easily as other errors, and the benefits of compile-time type checking, such as they are, are much reduced.

Re:Well duh

[DrXym]

I didn't say explicitly say type declarations. I'm referring to anything the compiler is remotely capable of catching that prevents a runtime error. Even the likes of Javascript, Ruby and Python have compilers that turn source code into some binary format and generate syntactical errors.

It's just that (for example) Javascript's compiler can't tell that the function / variable / field doesn't exist because those things can spring into existence at runtime. Therefore a whole raft of problems that simply don't exist in other languages can exist in Javascript.

Nor does JS care if that value is the right type, the wrong type, the right value in the wrong type (e.g. number inside a string), undefined, null or being coerced incorrectly because it has no information to go on. The reason that Typescript has caught on is because it adds a layer of additional checks and syntactic niceties that stop bad things happening to JS at runtime.

And yes some languages do have strong typing but some also have type inference. C++, Go, Swift, Rust et al. The compiler infers a type upon assignment and enforces it thereafter without cluttering the code with type declarations.

I'm also sure typing does get in the way sometimes and there is benefit to dynamic / ad hoc objects too. But not enough to argue that we should toss out strong compile time checks for the sake of those. If a language sees merit in supporting ad hoc objects it can declare an any or variant type and make allowances for it in the parser without compromising other checks.

Re:Well duh

[doctorvo]

And yes some languages do have strong typing but some also have type inference. C++, Go, Swift, Rust et al. The compiler infers a type upon assignment and enforces it thereafter without cluttering the code with type declarations.

And there is a price to pay for that, namely that those variables actually have a static type,

If a language sees merit in supporting ad hoc objects it can declare an any or variant type and make allowances for it in the parser without compromising other checks.

If only it were that simple.

But not enough to argue that we should toss out strong compile time checks for the sake of those.

You assume that there is a one-size-fits-all answer, "we" have something in common. People and organizations differ greatly in the kinds of projects they build, how they build them, how they test them, and what markets they sell to. There are apparently people who are so ignorant that they think that C++, Go, Swift, and Rust are good examples of languages with type inference. There are successful companies with no testing strategies. There are successful companies that let college CS majors loose on their corporate code base. Etc.

Type systems are tradeoffs between lots of factors, many of which you haven't even listed. You only list (and apparently only understand) only one side of those tradeoffs, a side that may work for your needs. Believe it or not, but other people have different needs. Personally, I use both statically and dynamically typed languages, as the problem domain requires.

Yes, and...

[Anonymous Coward]

Yes, and it also reduces the amount of code you write. Since it forces you to solve problems right away, it takes a lot longer to get to the point where the code is starting to work enough to provide you with an environment where progress starts to accelerate. Basically, you want to write code without it - but to have written code with it.

Python solves this with decorators

[heretic108]

Easy enough to add strong typing in Python by adding a type check decorator to each function and method.

Re:Python solves this with decorators

[gweihir]

I do that whenever it matters. In many places it does not, but sometimes it is really worthwhile.

Re:Python solves this with decorators

[zhiwenchong]

I don't mean to be pedantic, but Python is inherently strongly typed.
What it is not is "statically typed".
I think there is a general confusion in this thread between strong vs weak typing, and dynamic vs static typing.

Re: Python solves this with decorators

[liefer]

Well yeah, since strongly and weakly typed is not formally defined. It doesn't actually mean anything.

Re:Python solves this with decorators

[Anonymous Coward]

Yup.

Re:Python solves this with decorators

[Maxthod]

I don't mean to be pedantic, but Python is inherently strongly typed. What it is not is "statically typed". I think there is a general confusion in this thread between strong vs weak typing, and dynamic vs static typing.

Are trying to define something like "strong typing" finding your bug before run and "dynamic typing" annoyed you or your client doing something not is your uses cases at runtime are good solution because the word "typed" (before-codingtime-after)?

You can be as typed as you can but if value typed error occurs only at runtime how comes its more typed according to the discussion?

If you find the type at runtime, the language is not typed.

Re:Python solves this with decorators

[Anonymous Coward]

Luca Caderlli wrote an amazing paper just about this.

http://lucacardelli.name/Papers/TypeSystems.pdf

Re:Python solves this with decorators

[Anonymous Coward]

Yes, the story is confused. Python is obviously dynamically typed. The term 'strong typing' appears to be ambiguous.

Python has 'duck typing' which means that variables and method parameters do not have fixed types but can hold values of any type. Furthermore you can assign variables without declaring them first. The result is that every method needs to check the type of its arguments, which is often skipped.

Re:Python solves this with decorators

[Anonymous Coward]

It's butt ugly. Mypy (optional static typing for python) is better.

Ofcourse that static is better, for teams

[lucasnate1]

Python is very powerful when working alone. When working in teams, it becomes nightmare, because if one changes something, others are not automatically informed, and runtime errors (which may hide under conditionals) are introduced.

Also, javascript is shit and a typed language would be better, whether it is typescript or elm or whatever else.

All caps languages

[Anonymous Coward]

GNOME SAYIN?

Title of this thread is messed up.

[Jane Q. Public]

The title of this thread incorrectly conflates "strongly typed" with "statically typed".

They are two completely different things.

Re:Title of this thread is messed up.

[JustAnotherOldGuy]

Thank you, I wondered if I was the only one who noticed this.

Re:Title of this thread is messed up.

[Anonymous Coward]

Indeed. I got pretty annoyed during a course recently when the lecturer kept referring to strongly typed languages, when he meant statically typed. This got a lot of people confused when the language, Erlang, was referred to as "weakly typed" because "a variable can be assigned any value", and yet the supplementary notes called it "dynamic and strongly typed". Dynamic/static typing wasn't even mentioned (at least, not under the correct term).

Anyway, getting back on topic: I've used both statically typed and dynamically typed languages, strongly typed and weakly typed. I've found weakly typed languages (hi JavaScript and PHP!) to be abysmal for code quality out-of-the-box, but negligible difference between static and dynamic (with caveats). As someone who went from static to dynamic languages many years ago, I'll cast some love to the dynamic languages: they often require less code to achieve the same thing (and lines of code are a significant factor in bug counts), and dynamic language developers seem more likely to write pretty comprehensive test suites (we realise that most defects are independent of type checking).

Besides the strongly/statically typed confusion...

[Anonymous Coward]

... the benefit of statically typed languages is not only less bugs: it's maintenance.

Ask any programmer who has to inherit some code with more than a few source files what kind of language he'd chose (say: Java vs Python).

Makes sense to me

[blindseer]

As someone that has had to program in a number of languages I can say that strongly typed languages can catch a lot of trivial bugs quickly. One example is an if/then statement that allows non-Boolean arguments. If I mistype a comparison in an if/then statement then I should expect an error on compile. If I type an assignment "if (foo = bar)" instead of a comparison "if (foo == bar)" I expect this to get flagged, but some languages don't see this as a problem.

I prefer strongly typed languages as it can catch a lot of typographical errors and sloppy logic. It can also be frustrating at times since it can mean nesting type conversions to near absurdity. VHDL comes to mind in this. It can also be frustrating if trying to do something quickly and the compiler complains on what I would think is a pretty obvious implied type conversion.

It's interesting to see someone try to get an idea on how many errors strongly typed languages would catch. I'm not sure this makes an argument for one language over another. It might make an argument for testing, coding style, and such though.

Re:Makes sense to me

[93 Escort Wagon]

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.

Have you been looking at my perl scripts again?!

Re:Makes sense to me

[holophrastic]

"if (foo = bar)" isn't a bug in the code. It's only a bug in your brain.

bar = ;
if( foo = bar )
{
      foo += 2;
}

so foo is bar+2 if bar is true, otherwise foo is the same false as bar, be it undef, zero, null, or blank. And if you add some local scoping, being able to manipulate foo without manipulating bar often makes a lot of sense, especially with complex objects, and especially with functional logic like if(foo = dclone(bar)) -- or the much more routine if( record = dbgetrow(statement) ) which I'm absolutely certain you've done more than 100 times.

The bug in your brain is actually not a programming one. It's a visual one. Why are "=" and "==" so visually similar when they are functionally different? I might suggest using instead of == in perl, although the boolean would be reversed. At least cmp covers you for strings. .

Re:Makes sense to me

[Anonymous Coward]

> It's interesting to see someone try to get an idea on how many errors strongly typed languages would catch.

This is easy to test. Write code with normal text editor that doesn't show compiling errors. And count errors on that code.

But I don't understand what is the point. The question is would you rather have compiler errors visible or hidden. For example imagine writing a C program so that what ever you write, compiles fine, but it just crashes on runtime. Wouldn't it be fun to try to find syntax error in your code when only way to see it is to run the code?

Re:Makes sense to me

[Anonymous Coward]

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've always liked the fact Python made the former a syntax error. Coming from a C background, it was always a mare trying to debug someone's code when they were mixing side-effects and comparisons in conditionals. You were never sure if they meant something deliberately or had made a typo. The trouble is a lot of people were taught to do things like that for terseness. Seriously, would it kill you to write something that is quicker to grok, rather than trying to write a one-liner that might mask a bug?

Re:Makes sense to me

[Anonymous Coward]

Slashdot ate your special characters and your post makes not much sense.

Re:Makes sense to me

[holophrastic]

didn't eat a thing. all characters are there. you can't read neutered code.

Re:Makes sense to me

[Anonymous Coward]

My only issue with that code is that I would use additional parenthesise:

If ( ( foo = bar ) )

to (a) make it clear (to me) at a glance that this is an intentional assignment, not a typo; and (b) remove the inevitable superfluous warning that your compiler is going to throw out so the important warnings don't get drowned out by the noise.

Re:Makes sense to me

[holophrastic]

Well, making it clear to me would mean tightening much more:
if( (foo=bar) )

but that just screams for two lines:
baz = (foo=bar)
if( baz )

as for compiler noise, it's been twenty-two years since I've seen compiler output. Either I'm in an interpreted language, or I've rolled my own compiler. I don't do "noise"

but really, foo and bar is all crap when it comes to legibility. I can't make the following any more legible than it already is. I'm arguing that you can't either:
if( record = getNextRecord() )
if( line = )
if( frame = animation.nextFrame )
if( constituent = constituent.pop() )
if( names = fullname.split() )
if( div = div.nextSibling )

That last one is probably my favourite, because it's incredibly clear if you assume that it's intentional, and incredibly unclear if you think it's a mistake -- like most linked-list algorithms.

By the same token

[Waffle Iron]

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.

Re:By the same token

[hjf]

which can result in severe crashes and vulnerabilities

Learn to handle your exceptions, boy.

Re:By the same token

[Waffle Iron]

What exceptions? The most common behavior is a silently incorrect result.

Re:By the same token

[Anonymous Coward]

This is more due to the decision that the storage and performance characteristics shouldn't change without an explicit choice by the programmer. Also the reason that an array doesn't automatically expand like a list.

Re:By the same token

[Anonymous Coward]

Gracefully switching to big integer types might also be an error

Re:By the same token

[Anonymous Coward]

Lets say that you have a program that calculates a number and stores it into a database. Once a year those numbers are given as an input to another program that shoots a small laser into a human. The laser is harmless with small numbers.

Now, would you rather have your program crash when giving the numbers or would you rather have it collect wrong data for a full year and kill a human after that?

I'm just saying that you are not safe from "integer overflow"-bugs even if your program doesn't crash when encountering them.

Re:By the same token

[Waffle Iron]

That's an extremely contrived situation. Maybe the human target would start feeling the heat and eventually step out of your laser beam.

OTOH, if you used integers that overflow, at some point the laser could reverse polarity without warning. That could blow up your entire research station!

For fuck's sake, YES!

[Anonymous Coward]

First off, do you mean strongly typed or statically typed? They are not the same thing.

Second, if you do not already know that statically typed languages reduce bugs greatly, either you do not have a degree in computer science or else you should give it back because you did not learn anything.

My entire career I've been practically screaming that static typing reduces bugs. The entire purpose of static typing is to force the programmer to think through types carefully and only allow code that will work. My profession experience has been that people who prefer dynamic typing do it because they do not want to think carefully about their code, they just want to throw something together quickly and run it to see how it breaks, then fix a bug and try again. The people I've worked with who actually care about writing bug-free code universally prefer static typing.

Universally.

Re: For fuck's sake, YES!

[lucasnate1]

Mod parent up

Re: For fuck's sake, YES!

[K. S. Kyosuke]

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.

Re:For fuck's sake, YES!

[Anonymous Coward]

The idea that static typing reduces bugs is generally something that everyone knows but no one can actually prove with research. I haven't read the paper the article is about, so I can't comment on how it contributes to that research, but I have read past attempts that have not seemed terribly conclusive. If research can prove that static typing is better, it might also be able to then drill down into details about how type systems should be best designed.

Strong types

[Smallpond]

I've been using Janson and Bookman lately. Futura for san-serif. What was the question, again?

Re:Strong types

[JustAnotherOldGuy]

I've been using Janson and Bookman lately. Futura for san-serif. What was the question, again?

Nyuk Nyuk Nyuk!

type errors in scalars (int, etc)

[david.emery]

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.)

Re:type errors in scalars (int, etc)

[Carewolf]

Yeah, it is too bad strong typedefs haven't been introduced yet. I hear it is back on the table again for C++20.

Strong typedef would let you create a new int type that wouldn't implicitly convert to int or other strongly typed typedef of int. That way we could strongly typed units of measure and other cool things.

Re:type errors in scalars (int, etc)

[windwalkr]

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).

If the runtime performance is that important to you, you could consider invoking the preprocessor to select an 'int' in release builds and a custom strong type in debug mode (this is assuming your strong type is ONLY used for safety, and doesn't add special operators which understand multiple different strong types).

Re:type errors in scalars (int, etc)

[Anonymous Coward]

Maybe it's the style of software I write, or maybe I've become lazy because I know the compiler will keep me on track, but I get compiler errors from passing the wrong type of composite object as a function argument very frequently. I like compile errors and I wish C++ supported typed scalars natively.

Of course strongly typed reduces bugs

[goombah99]

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.

Re:Of course strongly typed reduces bugs

[Carewolf]

The answer is obvious that for identical code strong typing will reduce bugs. And yet does typing force people to write in ways that lead creating bugs?

More importantly why isn't there some gray scale on typing that I could slowly turn on as my program design matures?

-Wall
-Wall -Werror
-Wall -Werror -Wextra

Also when writing in C++ mark sloppy convenience functions and constructors as deprecated so the scale above will complain and force you to fix them when the program matures.

Re: Of course strongly typed reduces bugs

[Anonymous Coward]

Did a bot write that post

Re: Of course strongly typed reduces bugs

[Anonymous Coward]

use Boo then.

Re:Of course strongly typed reduces bugs

[djinn6]

More importantly why isn't there some gray scale on typing that I could slowly turn on as my program design matures?

You might be interested in type hints in Python.

Re:Of course strongly typed reduces bugs

[Z00L00K]

My first opinion is that C++ has the bad features from C and Java/C# without really providing benefits, but aside from that, when writing C I'd add
"-std=c11 -Wpedantic" (or whatever the latest C version may be, it has changed over the years since I started coding C in the late 80's K&R style).

Re:Of course strongly typed reduces bugs

[mindwhip]

C# and even *shudder* VB.Net allow you to do this with compiler options/directives and/or use of var type out of the box. Not that i would recommend it but you can effectively do the above by turning off the requirement to declare variables or declare everything as a var and setting the compiler options to allow all implicit type conversions. As you move towards completed code you move towards specific type declarations and disallow any implicit conversions...

Re: Of course strongly typed reduces bugs

[Anonymous Coward]

You have no clue what you're talking about. 'var' is a compile time shortcut, not implicit type conversion. The real type is well known with bad. Just mouse over it and the IDE tells you the type, no conversion at all.

Re:Of course strongly typed reduces bugs

[dkasak]

At least the part where you gradually specify the types in your program manually and optionally enforce the types statically can be done in Python today, see mypy.

Re:Of course strongly typed reduces bugs

[maelkum]

Type hints are cool and all, but there is no intention to actually enforce them and that makes them more akin to documentation than anything else.

For example, the code below is perfectly valid:

def frombulate(x : int) -> int:
    return { 'answer': 42, }

frombulate([ 'A', 'list', 'of', 'strings' ])

The frombulate() function supposedly expects an integer, and claims to return another integer, but is happy to get a list of strings, and return a dictionary.

Re:Of course strongly typed reduces bugs

[david_thornley]

You can optionally declare Common Lisp symbols (variables) to be a certain type. By setting safety and speed, you can typically either have your types checked at runtime or have the compiler assume you're right and use the information to produce better code.

Re:Of course strongly typed reduces bugs

[djinn6]

Type hints are not enforced at runtime. You need to use a static type checker like mypy.

If this doesn't make sense to you, remember that C++ doesn't check type at runtime either. Static type checking is most useful before you run the program.

Re:Of course strongly typed reduces bugs

[maelkum]

Type hints are not enforced at runtime. You need to use a static type checker like mypy.

I know that.

If this doesn't make sense to you, remember that C++ doesn't check type at runtime either. Static type checking is most useful before you run the program.

I know this too. And it makes sense to me. I am a big fan of static analysis tools of various kinds.

My point (poorly expressed, it seems) was that type hints are not required to be enforced (neither at runtime, nor at compile time) and therefore probably won't be (due to laziness, or other reasons). The fact that you can use some external tool is almost moot.
With C++ you have to work to avoid the type checking, with Python you have to work to enable it.

Re:Of course strongly typed reduces bugs

[strombrg]

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.

Python 3.x (and Python 2.x, sort of) has this now. It's called "gradual typing", and it's enforced by a 3rd party tool like mypy or pytype.

Only 15%??

[Anonymous Coward]

When coding in Python you ought to replace the compile time type checking with 100% code coverage... Even simple getter and setter methods have to be tested due to the risk of misspelling. In compiled, type checked these very simple errors are taken care of.

In C++ I usually go a lot further and make classes (not typedefs) for even simple types to make the code more readable and make the compilation fail if the wrong type is used. Could for instance be a class simply wrapping an int32_t to be used as an id another class for an id for something else. Never just an "int".

Always avoid Python

[Anonymous Coward]

There's already plenty of reasons to avoid Python. This is just another one.

You're looking @ one here... apk

[Anonymous Coward]

"Lots of Borland/Pascal programmers are saying we told you so though." - by Crashmarik ( 635988 ) on Saturday September 23, 2017 @05:33PM (#55251659)

See subject & far less buffer overflow possibles too (strings in pascal/delphi have length incorporated into 'em) unlike C/C++ deal with.

APK

P.S.=> Oddly though, I used Microsoft's C++ & VB alongside SQL for the bulk of my career the most (even over Delphi which I FAR preferred - especially when it kicked the crap out of both VB & MSVC++ (by 3-5x the performance of the latter even in math & strings no less which EVERY program does work in pretty much) in a competing trade rag "Visual Basic Programmer's Journal" Sept./Oct. 1997 issue "Inside the VB5 Compiler" where Delphi swept the floor w/ both in 4/6 tests total... apk

Re:You're looking @ one here... apk

[Walter White]

... 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.

Extremely wrong question, but today's Slashdot

[shanen]

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?

Re:Extremely wrong question, but today's Slashdot

[david_thornley]

In my experience, statically and dynamically typed languages have different strengths. I wouldn't say that I'm more productive in one or the other under all circumstances. Asking which is better is unproductive.

Obviously!

[Anonymous Coward]

To even question this displays a massive lack of insight and understanding of programming, how programs work.

ALL programs need a "design", even if a simple "Hello world". When it becomes more complex, static typing help you catch silly bugs at compile-time (read: early).

To even question this, and it getting onto the frontpage of /., tells me the world is going to hell in a handbasket, and morons driving it there.

compile-time or run-time?

[Anonymous Coward]

Depends on whether you are talking about finding more bugs at compile time or run time. I mean if you are measuring run-time bugs but your compiler catches all the stupid syntax, etc. bugs at compile time then you're going to have fewer bugs of that nature at run time. So it looks like you've got fewer bugs but that's not actually the case.

I find that dynamically typed languages require me to think less about what language I'm using and more about the problem I'm solving.

Great, more ignorance about type systems

[Anonymous Coward]

No, this red herring post does not make me want to suddenly reject Python.

Python is dynamically typed and strongly typed.

Strongly typed != manifestly typed and statically typed. This does appear, however, to be how this Slashdot post incorrectly uses the phrase "strongly typed".

Strongly typed == the availability of few to no implicit type conversions in a language.

Python is not 100% strongly typed, the chief exception being that you can use almost anything in a boolean context without getting an error. This typically tests for "nonemptiness", (AKA falsiness) EG a nonzero integer, or a nonempty list.

Java is also not 100% strongly typed, the chief exception I'm aware of being that you can add a number to a string without getting an error.
Please see http://stromberg.dnsalias.org/svn/Java-strong/trunk/JavaStrong.java for an example.

Python 2.x and Python 3.x can eliminate many runtime errors using tools like pylint, pychecker and/or pyflakes (I prefer pylint) - these look for variables that are set but not used, or used but not set, and can sometimes also use type inference to check for further errors before runtime.

Python 3.x (and to a lesser extent, 2.x) can also eliminate even more errors using what is called "gradual typing". This allows you to declare some of your variables' types and check them before runtime using a tool like mypy or pytype (I prefer mypy).

Also, unit tests can easily find many runtime errors before code hits production. Not unit testing your C++ and Java? You really should: "Compile and hope for the best" isn't terribly effective at yielding high quality code.

Haskell is worth thinking about here: It is statically, implicitly typed. You don't declare your variables' types - IOW it's not a manifestly typed language, even though it is a statically, strongly typed language.

HTH.

anecdotally

[buddyglass]

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.

Re:anecdotally

[djinn6]

The real question is whether the amount of time spent running lint and fixing those dumb bugs is more or less than having to create and maintain dozens of abstraction layers like "AbstractUserDataProtocolHandlerFactory”.

Badly designed study.

[gurps_npc]

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.

Re:Badly designed study.

[david_thornley]

Operators have been overloaded since the beginning of higher-level languages. "+" is almost always used to add both integers and floating-point numbers, even though those are different machine operations. (COBOL, of course, uses "ADD", but you can freely mix COMP, COMP-1, COMP-2, and (if available) COMP-3 types.)

Addendum: Defense of VB here though... apk

[Anonymous Coward]

See subject: You COULD use "Option Explicit" (or "Option Strict") to help offset some of the problems dynamic typing introduces (still a runtime interpreted language though, even MSVC++ is via MSVCRT.DLL for its forms) - yes, Delphi CAN be too (but I never used it that way, only statically compiled true .exe work).

APK

P.S.=> That's in addition to my original post favoring Pascal/Delphi over both VB & MSVC++ here https://developers.slashdot.org/comments.pl?sid=11155081&cid=55251983/ ... apk

Yes, but only with the right programmer

[Anonymous Coward]

There has never been, and never will be, a language in which it is impossible to write bad programs.

But if the programmer in question really appreciates the right way to use static types, then they reduce errors dramatically. If you hear static types and think "great, now I have to type int and string and struct everywhere, what a nuisance" then static types are not for you. If on the other hand you have experienced writing in ML and having your programs come out bug-free almost every time then you might be a good fit.

Personally I find that proper use of static types in a suitable language (Java at minimum, but hopefully something better) almost completely eliminates the need for unit testing. You still need testing of course, but your bugs are all going to be around interacting with libraries and arbitrary input, where unit testing doesn't help anyway.

If you're lucky enough to be able to use Scala, you can write code almost as bug-free as you can in ML, with the added value of being able to actually do real-world work with it.

Pascal fan

[rossz]

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.

Re:Pascal fan

[Anonymous Coward]

Try java!

Re:Pascal fan

[Tablizer]

where the idiot used "foo", "Foo", and "FOO" as different variables.

You mean "where the fool used 'fool', 'Fool', and 'FOOL'."

Re:Pascal fan

[david_thornley]

Capitalization can be used to separate namespaces. In C++, for example, FOO would be a preprocessor variable (or, according to some people, a constant), Foo would be a class, and foo would be a variable. For this to work, the coding standard has to be strictly enforced. Randomly using capitalization as a way to distinguish variables is a Bad Idea.

Re:Pascal fan

[Anonymous Coward]

I never quite understood why some languages (like C and C++) allow all types of identifiers to follow the same rules.

I was reminded of that when I was learning PHP, and the variables had to start with a '$'. It reminded me of my youth programming BASIC, where strings were marked with a '$' suffix.

Why not mark integers, floats, constants, pointers, addresses, and strings with a leading character? Make it a requirement on every use of an identifier. Simplify semantics for both the compiler and the programmer.

#foo : integer
%foo : float
*foo : pointer
$foo : value of what's at foo, dereference
@foo : string

etc. etc.

Re:Pascal fan

[david_thornley]

That's rare among languages. I believe PHP is something of a Perl descendant, and Perl uses sigils.

In any case, it wouldn't work for user-defined types, which are extremely common in C++ and not rare in C. There's a limited amount of punctuation characters. Also, # starts C and C++ preprocessor statements, % is an arithmetic operator in both, and * is the operator in both to indicate what a pointer points to. Neither C++ nor C has an actual string type, although they have ways to manipulate strings in their libraries.

Preference.

[Anonymous Coward]

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

Re:Preference.

[Anonymous Coward]

I don't think I've ever had someone try to come in my ice-cream. I can't say I would like that though.

yes, but they are a pain in the ass.

[Anonymous Coward]

Now shut the fuck up.

They're asking the wrong question

[xgerrit]

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.

Re:They're asking the wrong question

[Anonymous Coward]

I can tell from experience that strongly typed takes a lot less time. That is because writing code is fast. Reading (about 10 times slower) and trying to find errors from it (sometimes finding the error takes years, I have personally found 2 such errors that original authors never found) is slow.

It's the wrong question

[Anonymous Coward]

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".

Re:It's the wrong question

[haemish]

Absolutely! In my experience, statically typed languages are great when your goal is production; dynamically typed languages are great for quick demos.

Compiling

[ChrisMaple]

Strong typing seems like a good idea until you download a large legacy program and it won't compile because the language has been redefined to enforce stronger typing. Then you look at the particular error, and find that the type name has been aliased, and the alias has been aliased, and so on ten deep. Repeat for dozens of variables, and 2 days later than nice program that was going to save you a couple of hours still won't compile.

How many types of casts does C++ have to get around the strong typing problem? Can you figure out what each one actually does, and which one to use in a particular instance? Why does it seem that none of them claim to do what I need done?

No

[tylersoze]

Significate whitespace makes me avoid Python.

Re:No

[i.r.id10t]

This.

Of course, it does solve the argument of "tabs vs spaces" and "how many spaces to indent"

But at great cost.

Strength and bugs are relevative

[Anonymous Coward]

I don't think it makes much sense to put this question in a language specific context.

Simple example being anyone can define an integer in a strongly typed language when a type specific enum would have been more appropriate. The compiler lets them get away with it just the same regardless of language choice.

Some dynamic languages allow programmers to require more constraints than the default operating mode.

Extent to which strong typing really matters comes down to discipline of the programmer/development enterprise more than it does language. My personal perspective is while I tend to leverage pedantic type constraints as much as possible it was never much of an issue.. limited mostly to unmasking unintentional typos.

The best mechanisms for reducing bug rates is liberal use of assertions and always designing new code in a manner where systematic verification remains tractable.

No, of course!

[williamreview1]

I think I could say 'No' immediately https://williamreview.com/live...

strong typing != static typing

[doctorvo]

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.

Re:strong typing != static typing

[Anonymous Coward]

That is still not completely correct. You can have a strong-static, weak-static, strong-dynamic, or weak-dynamic language. It just that the vast, vast majority of static languages are strongly typed, but that doesn't mean that all of them have to be.

Re:strong typing != static typing

[Anonymous Coward]

That's what I said. You need to read more carefully.

Re: strong typing != static typing

[liefer]

How was this modded up? It's nonsense.

Re: strong typing != static typing

[Anonymous Coward]

Ah, a candidate for Dunning Kruger. The kind of riff raff that enters the computer industry these days.

Re: strong typing != static typing

[david_thornley]

Actually, doctorvo makes perfect sense. In Common Lisp, any symbol knows its type at all times, but can contain any possible data type, unless a special declaration is made. It's strongly dynamically typed. Try treating a string like an integer, and it'll fail, because they're different types. If you treat a string as an integer in Forth, it will flag no error, because Forth is as weakly typed as they come.

Seriously.

[rylyeh]

What kind of bugs are prevented? What about the bugs introduced in strongly typed languages, like the diamond inheritance case?

Re:Seriously.

[Psicopatico]

Honestly, I'm more worried about strongly mistyped languages.

Re:Seriously.

[Actually, I do RTFA]

No one who does diamond inheritance (in C++, because it's like the only language that allows it) doesn't know it's extremely dangerous. It is done rarely for that reason. Hence, templates/abstract classes were introduced. They solved the problem so well that subsequent languages removed it.

Besides, those exact same problems exist, and the same solutions to them exist, in prototype based languages. In fact, the analogs to diamond inheritance exist, but not necessarily the analogs to templates.

Nothing 2 pointers can't cure... apk

[Anonymous Coward]

See subject: For finding the length of the string (or char array as you put it, except I'd elect pointers over array indices for this, more direct & imo, better speed/less overhead (pointers & indirection & "all that" etc.)) - so merely keeping one double the size of the other as you move them thru it will yield midpoint on the smaller one once the larger errs out/no longer advances, essentially giving you the length (probably the sourcecode of strlen functions I'd even wager).

APK

P.S.=> That's how I'd do it & yes, I have before (for an interview with Microsoft "way, Way, WAY BACK" in 2003 where oddly, THEY approached ME, not the USUAL "other way around")... apk

avoid python?

[l3v1]

"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.

Type hints/checking in Python

[Fnkmaster]

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).

Time conservation also

[SuperKendall]

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.

Perl is strongly typed

[holophrastic]

The article shows javascript as buggy and untyped with 3 + "0" = "30" -- the classic stupid example.
Everyone likes to say that Perl is weekly typed, because "1.5" + 1 = 2.5.

Everyone is incorrect. Perl is very very very very strongly typed. Not the variables, the operators. Not the nouns, the verbs. Developer says "add these two variables", and perl adds them. Because the developer said so. If the developer said "concatenate these two variables" then perl will concatenate them. Every time.

That sounds strongly-typed to me. "3" + "1" = 4; 3 . 1 = "31". Every time.

I dare you to find out what perl does with 3 + "information". Go ahead. I dare you.

My point is this. Human beings don't care about type. An apple is an apple, and an orange is an orange, and I can eat them together, cook them into a sauce, bake a pie, cut them up, juice them, or put them into a basket. Whatever I tell you to do with them, you'll never respond with "but apples can't do that because they aren't oranges". Just bake the g.d. pie, because I told you to.

Now, if you can explain to me why any language would ever use the same symbol for "add" and "concatenate", then you're smarter than I am. For the life of me, I've spent 30 years trying to understand that one. What idiot makes one symbol do two things, and then builds the language to guess which one to do based on the values themselves, at the language-level no less? Idiotic.

Re:Perl is strongly typed

[Srin Tuar]

Thats still weakly typed, just a different kind of weak. Strongly types is when you fail; "a" . 1 would throw an exception and say "i dont know how I can possibly proceed" if it was strongly typed.

Strong typing vs weak is a minor detail anyway; the real meat is dynamic vs static.

Re:Perl is strongly typed

[Anonymous Coward]

I disagree, I care more about strong typing than static/dynamic.

Strong typing prevents the crazy from happening.

Static typing stops strange things from happening, but at the cost of creating additional types, and interfaces that do nothing but work around the strong typing.

Re:Perl is strongly typed

[Anonymous Coward]

It's true that human beings don't care about type. That is why most human beings are not programmers. Most human beings have difficulty handling logic too. Unfortunately, computers do what you tell them, not what you want.

Your point is wrong. Typing is there to save you from your own mistakes instead of powering through.
"Open the car door with this hammer"
Perl: smashes the window
Java: a hammer does not work in the door.

You almost never want the computer to second-guess your intention. Even people are pretty bad at it, and computers are notoriously so.

Re:Perl is strongly typed

[holophrastic]

Goddammit, if I tell my child to grab the hammer and open the car door, he'd better smash the window mighty quick!

In case of fire, break glass.

King's Quest says: "I'm sorry, you can't do that here, at least not now.".

I said open the door. I said use the hammer. I am the lord thy god. You do it. You don't refuse me.

As for perl, I've always said that a blank perl script doesn't do nothing, it does EVERYTHING. Programming in perl is all about reducing its freedom until it does only what you want. Java is certainly the opposite. It does nothing until you give it a tome of direction.

Less stable product more quickly (one-time use)

[raymorris]

> 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.

Re:Less stable product more quickly (one-time use)

[sfcat]

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.

You are why we have so many security issues as an industry.

Find work that allows you to...

[neoshroom]

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.

Strongly typed or statically typed?

[Anonymous Coward]

Strongly typed or statically typed?

Good programmers do

[aglider]

Not "good languages"

One anecdote..

[jcr]

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

That's easy: Yes.

[Qbertino]

I basically program exclusively in PLs with sloppy typing and no compiling and stuff. Python, PHP, JavaScript the works. The speed at which you get stuff done is notable, especially compared to classic "Type Nazi" languages. However, the trade-off is clear as can be: Write critical code beyond a certain scale in sloppy type PLs, and you're asking for trouble. Type Nazi languages force you to think before typing ... errrm ... hitting the keys ..., and that is a good and useful thing if the use case isn't a trivial scripting stuff that you can debug and modify on your Smartphone willst sitting on the bus.

Sloppy typed PLs have some stopgaps (code standards, frameworks, hacks, transpired dialects (such as JavaScripts TypeScript) but those are things intended to cover the gap and cater to specific needs.

Long story short: Nazi typing is more work to front but prevents lots of trouble downstream of large non-trivial projects, including a specific subset of bugs.

Re:That's easy: Yes.

[Anonymous Coward]

Me too: Perl, PHP, Ruby.

I just don't find myself having bugs that are type related.

bugfix

[Anonymous Coward]

python is strongly typed.

its not statically typed

Well, sorta...

[Chris Mattern]

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'll do even better (2 pointers cure it)

[Anonymous Coward]

See subject: For finding length of a string (or char array as you put it I'd use 2 pointers vectoring thru an array vs. indices for it - more direct & better speed/less overhead (pointers & indirection etc.)) - so merely keeping one double the size of the other as you move them thru it will yield midpoint on the smaller one once the larger errs out/no longer advances, essentially giving you the length (probably the sourcecode of strlen functions I'd even wager).

APK

P.S.=> That's how I'd do it & yes, I have before (for an interview with Microsoft "way, Way, WAY BACK" in 2003 where oddly, THEY approached ME, not the USUAL "other way around")... apk

python is trash for math majors who cant code

[Anonymous Coward]

fuck python

Re: Less stable product more quickly (one-time use

[oobayly]

Explain why.

Betteridge's law doesn't apply here

[Chewbacon]

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.

I don't get it

[Anonymous Coward]

Why does it matter how hard I press the keys when programming?

there is a middle ground

[Bent Spoke]

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 Removed.

[brian.stinar]

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...

Re:Makes no sense to me

[Anonymous Coward]

I hope to never have to deal with your code. :(

Re:Makes no sense to me

[holophrastic]

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.

Python is strongly typed.

[Anonymous Coward]

The argument at the beginning was for strongly typed languages. I do feel the lack of a strongly typed language is one of the shortfalls of Javascript. That stated Python is a strongly typed dynamically typed language. I think the original comment is confusing strong/weak vs. static/dynamic. They are fully orthogonal from each other. C++ is a statically typed language (ignoring the auto keyword) that is also fairly weakly typed. Ada is quite heavy handed in both static typing and strong typing. PHP is dynamically and weakly typed.

It's all about testing

[Anonymous Coward]

I've used JavaScript and Perl (and more recently Ruby) for about 17 years and I can't tell you how many times I've encountered runtime errors because of mismatched or unexpected types such as the elusive adding of a string to an integer, which is valid JS code, e.g. "12" + 3. But of course you would likely catch those bugs during development. If not, then you have unit testing. If such bugs are STILL not caught, you have SIT and UAT in most organizations. With the popularization of CI systems like Bamboo that can run unit tests automatically on checkin, it becomes even easier, not to mention peer reviews with tools like BitBucket and Github. If there are still these kinds of bugs after all of this, you (and your organization) are either too lazy or too incompetent and have no business writing software. The whole static vs dynamic argument suddenly becomes irrelevant if you have decent testing. In my experience I spend 3-4x more time and effort on unit tests than on the actual code it's testing, and the SLOC for test code could easily be 10x the target source, especially if you're aiming for 100% coverage. On the other hand, with a language like Java, I always FEEL like I have a better idea of what's going on in any given block of code, even if I've never seen it before. I personally like strong typing because it's comforting (to me) to have a full understanding of what methods or variables can and cannot contain, accept, or return. Languages like Ruby can feel highly ambiguous with absurdities like implied returns. In any case, either way it doesn't really do much to reduce bugs. In my opinion it's a non-argument.

Absolutely!

[Bitbeisser]

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...

small modular code is aways better

[Anonymous Coward]

Given the choice of a large project between:
  - project written in well defined modules, with some written poorly or in the "wrong" language
  - project written as a single program, using the "best" language, object oriented, using "state of the art" design patterns, strongly typed, of course.

I would always choose the poorly written code in well defined modules.

The over-engineered object oriented (but not modular), is almost always throw away by nature. The layers of abstraction intended to account for future changes usually have the opposite affect.

Strongly Typed = In-line unit tests

[Anonymous Coward]

I totally buy it because strongly typed is basically the developer writing some very basic âtestsâ(TM) in the code during development itself. Like âoeParam one is int16 and Param two is char* and oh, better expect a Boolean!â. The more such coverage you have the fewer bugs.

death accounting and other whopperage

[epine]

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.

Re:death accounting and other whopperage

[david_thornley]

Don't confuse C and C++ memory management. C++ is far superior, and provides bounds checking and pointer safety as desired.

ROTFLMAO!

[whitroth]

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.

Python has limited support for types

[Ottibus]

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 ]

JavaScript=bad specimen [Re:Bug Conservation]

[Tablizer]

Just look at all those Javascript frameworks that rise and fall and don't even try to maintain backwards compatibility

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.

Does this make you want to avoid Python?

[Anonymous Coward]

Not at all because I don't use Python for its ability to reduce my bugs, I use it for the ability to produce a functional program in the least amount of time.

I have been an SE for 13 years and I cannot recall anyone ever saying a dynamic typed language is going to be less error prone than a static typed language. It's really not necessary to do a "study" to figure that out. I mean, the whole point of a static typed language is to remove that vector of failure. The whole point of a dynamic typed language is that it is inevitably faster and easier to program and can therefore be used to create shitty programs more cheaply. If you want to program the flight controls of an airplane, you don't use dynamically typed languages, period.

The real study that needs to be done is one that determines how often Python is used for applications it should not be used in. The vector of failure here isn't the typing of the language, its the quality of the human component that should, ideally, know better than to use one language for all purposes. Knowing how prevalent the use of Python is, for things it should not be used for, might help to focus efforts on education and training of those individuals who just aren't very good at their job.

Imagine a world where AI...

[Anonymous Coward]

One can imagine this taken to the logical conclusion where the coder is jacked into the machine and is aided by an AI that not only can read his mind, but also has all the foresight and business knowledge necessary to produce the correct 'solution' which obviously is not only bug-free code, but also code that solves the business requirements (and hopefully nothing more) while retaining enough flexibility to hopefully handle most (90%?) possible future requests.

So yes, strongly type languages are I would argue better, specifically because you are eliminating the capability to produce a type of bug.