If that code is in your main() function and program execution stops as soon as you boot because you messed up, then that's fine, but what if you make an obvious error buried super deep in some code that rarely runs (but blows up 100% of the time) and it's not caught for awhile? I'm not sure if that's how Python works but that's how JS does.

And that's not to say it crosses some kind of line, or that it's wrong or anything - you can write dumb bugs that will always blow up in C++ too. It's just further down the continuum of tradeoffs between safety and iteration speed, and having spent most of my life working closer on the "safety" side, where the fact that your code even compiles guarantees a base level of "correctness" in what it's doing, it feels odd and new to me to be doing things differently.

It would be helpful to learn at least one language from the broader ML family (including Haskell, Scala, F#, etc) to place this debate in proper context.

What's wrong with

average(x: number, y: number):number

where int/double/float/numerics/etc are subtypes of number

average[t/number](x:t, y:t):t

where average is a generic function over type t where t is a subtype of number?

How is user_id constrained to be an integer? What's an integer here anyway - is it a 32-bit or 64-bit or system defined? If I later change it to use some kind of GUID string, does it break? What does it break?

The main reason that we have popular dynamically typed languages is that they are a couple of orders of magnitude easier to design and implement, which allows for more of them to exist in the first place.

The other reason is that if most of your code is about talking to the outside world, which is not strictly typed by default (the outside world is not constrained by the language's type system), most of the benefits of a strict type system go away while most of the drawbacks remain.

The program with that error won't run at all in Python no matter where it is, and it would be pretty difficult to get to the point where this is deep in code unless you are just writing reams of code without ever compiling.. I think there is some continuum here, but if JS does that, I have to agree that's kind of yucky.

Python absolutely allows you to run a program that will 100% blow up due to a type error. That's kind of the point.

I'm not sure if you mean "that is a good thing" (in which case, wat) or "that is a worthy tradeoff to get the good parts of weakly typed languages" (subjective but valid).

I've never understood these arguments mostly because it just makes sense to me the way JS does it. Hey my function is expecting a string? OK, send it a string. Oh it didn't give a string and blew up when I ran it and it told me what line it blew up on? OK fix that?

I guess compile-time checking would be nice to catch those but with babel/eslint/jshint catching any bad CODE on save ('unexpected token', gulp outputs an error to the notify window instantly) I'm fine with my toolkit and the language.

Other than 0 being falsey that **** sucks.

Goofy Im 100% with you and thats generally my gripe when using python, but Im guessing its just because I also started off with static typing. Luckily there is scala so I can at least pretend Im a dynamic, functional programmer

Sounds like its just what youre used to.

It's like how guns killing people is a feature.

But if we could make your gun be like "oh hey, I detected that you're pointing this at a human and you haven't activated the 'this is an emergency' switch, so I'm gonna do the world a solid and not fire a bullet right now", that would be pretty cool!

Is everyone here familiar with the worse is better essay?

http://dreamsongs.com/RiseOfWorseIsBetter.html

https://en.wikipedia.org/wiki/Worse_is_better

Dynamically typed languages (ironic given the origin of the essay) are a classic case of worse is better - it's just so much easier to design and implement an acceptable dynamically typed language that it's what you end up with by default unless you have a massive budget and/or some kind of programming language + type theory experts. They are also much easier to learn and use, which means it follows worse is better on the adoption side as well. The fact that statically typed languages are as popular as they are, given the enormous evolutionary disadvantage they carry, says a lot about the importance of compile-time type checks. I will add that dynamically typed languages tend to evolve towards static types as well.

I will do whatever I can to avoid creating another non-trivial Python production application.

Thoughts on TypeScript? We're starting to play around with it now. Will Sublime do all the possible compile time checking or do we need something like WebStorm?

Do you mind elaborating on this?

This is a tough one because some of the advantages are offset by the risk of ending up with an obsolete codebase (due to TypeScript falling out of favor much like CoffeeScript) but given how poorly JavaScript code bases age anyhow, the likely popularity of TypeScript going forward and generally readable JS output that the TypeScript compiler generates, I would be okay using it for production apps.

No idea about the IDE support for it though.

Posting from my phone so I apologize for the format.

Regarding signals, I agree with you in theory. Many people don't see it that way and maybe even associate a negative stigma with boot camps. Until pretty recently app academy encouraged students not to mention that they went to a boot camp on resumes or in cover letters.

I'm not sure if it's actively encouraged now but when mentioned they try to make sure students couch it with something like "Graduated from App Academy, a 3 month, 1000+ hour boot camp with an acceptance rate of under 5%"

Certainly the boot camps know that their students need an easily understood, visual portfolio. Students are encouraged to clone a relatively pretty, well known site and polish up some of the games and mini site clones that are done through the course of the program.

Regarding CS grads from mid tier schools asking for less money, I think there are a few factors. Boot camp grads are going to be productive from day one assuming they land somewhere with a stack they're familiar with. They're going to be junior, but they know the frameworks pretty well. This isn't necessarily the case with a lot of recent grads.

And it's not just framework and language familiarity too. They know how to use git and have some practice breaking down and scoping projects. My understanding is that many CS programs still don't tech any of these skills.

Lastly, these boot camps keep track of where their students go and how much they make for marketing purposes (or tuition calculation in the case of App Academy). As a result they are able to speak with confidence about what is available and how much the skill set is worth on the market.

I think there are valid reasons to prefer hiring from the set of boot camp grads or cs grads, but ultimately I think the choice is close and should be dictated by the needs of your company. Both groups have gaps, they're just in different places.

Timely article from HN http://games.greggman.com/game/dynam...static-typing/ cliffs: the safety you get from static typing is not worth the development/debugging time spent vs dynamic languages.

I just set up typescript to work with vim about a week ago. The auto completion boost it gives is pretty amazing and would be very helpful when working with some large unfamiliar codebase. I don't have it doing syntax highlighting with errors in real time, the typescript compiler just outputs the errors in another terminal.

Writing out type annotations doesn't seem like a huge time sink or annoyance to me tbh. But it feels like people abuse it and start making everything implement an extension of an extension of an interface and soon the code looks like java.

Good read, thanks.

In all fairness, statically typed languages tend to be much more verbose. Java and C# aren't exactly compact languages.

If you can get the brevity and speed development of Lisp / JS / Python / Ruby and tack on types, I'd like to see a one-to-one comparison there.

http://danluu.com/empirical-pl/

i believe haskell fits that bill

There's this comment though which I agree with:

The right answer really is that if you're working on an app where correctness and error rate are big concerns, the code should be unit tested whether you're working in a statically typed language or not. Adding tests which ensure type safety where needed in a dynamic language is trivial compared to all the boilerplate you have to write in static typing.

What? Boilerplate is easy to write in any modern IDE. I have no idea how you think it can be so much more work than writing tests.

I'm going to avoid getting into something as complex as type arguments. My earlier comment about Python applications is based around my belief that large python applications are much harder to maintain long term than equivalent applications written in many statically typed languages.

Unit tests don't ensure type safety - writing unit tests for type safety is actually very difficult and virtually never done systematically. Typically unit tests are of the form where when function f is called with arguments x, y and z, it should return value v. Unless you've somehow made it the function's responsibility to handle type errors, in which case your code would be even more verbose than boilerplate in static typing because every function would have a preamble that declares and checks arguments types, you need to make sure that f is never called with wrong argument types. This means the responsibility for ensuring that f is called a type-safe manner is scattered around in unit tests for various other functions that happen to call f and if f is part of a dependency that's injected/mocked, it's extremely easy to make a wrong assumption and/or test against wrong types. Remember, in the absence of a type checker, your brain has to know exactly what the valid argument types are when you're writing tests.

And that's still assuming you're using dynamically typed languages as statically typed languages without compiler errors. If you fully take advantage of the fact that the variables are not typed and can contain differently typed values at runtime with no constraint, you're in a much worse shape because it's very easy to have 100% test coverage and still have show-stopping type errors. And with dynamically typed languages is that you don't know which situation you're in - it's not like it tells you if you're using the same variable/parameter for differently typed values at different times.

I think part of the reason that a lot of people don't think that it's a big deal is because even most mainstream statically typed languages are dynamically typed with respect to some key aspects. C++/C#/Java all have nulls which make all object types dynamically typed with respect to null and have historically encouraged the use of unsafe casting instead of proper union types or generics, often to get around historical limitations, some of which don't exist anymore. But the benefits of static typing apply even here - the less you rely on these "dynamic" features, the better type checking works for you. For example, Scala retains Java's null semantics but because I never really used null in Scala code, I don't think I've ever seen a NPE while coding in Scala except when relying on Java libraries because in idiomatic Scala code, you don't use "dynamic" nulls - you use static "Option[T]" which is a type-safe way to handling optional values.