Hacker News Reader

Comment by ryanbrunner | Hacker News Reader

> These days if your chosen language doesn't have things like strong typing, interfaces, good debugging tools, a good compiler, etc, then you should definitely be asking yourself if it's the right tool for the job.

All of these things existed long before Ruby on Rails gained in popularity. Unless the popularity of Rails, Python, PHP, and Javascript was all just collective insanity, dynamic languages do offer benefits in some circumstances over languages with stronger type guarantees. Certainly not in every situation, but enough that it doesn't make sense to dismiss them out of hand.

View on HN

> Unless the popularity of Rails, Python, PHP, and Javascript was all just collective insanity, dynamic languages do offer benefits in some circumstances over languages with stronger type guarantees.

with strongly typed languages it's harder to perform exploratory coding. This drives a kind of backpressure on the design stage of development where it becomes more prudent to design your classes and interfaces before you start coding, because changing interfaces part way through development is a much larger undertaking than in, say, Javascript. On the other hand, strongly typed languages provide a lot of guarantees that have to be coded for in dynamic languages. This is why I prefer gradual typing - you get the best of both worlds.

This is not true in general. There is nothing intrinsic to static types that is incompatible with exploratory coding. If you want to turn all your type errors into runtime crashes, then some statically typed languages will even let you do this (e.g. deferred type errors in Haskell).

> with strongly typed languages [...] it becomes more prudent to design your classes and interfaces before you start coding, because changing interfaces part way through development is a much larger undertaking

Quite the opposite. With strongly typed languages, it becomes safer to make changes, because the compiler will catch mistakes. On top of that, with mature strongly typed languages, there is tooling which takes advantage of the types to help you avoid mistakes in the first place.

It's safer to make changes, but you can't rapidly mess around with different structures without having to perform housekeeping on your types. This primarily applies to OO code, which is primarily where I draw my experience from - I find FP code is easier to refactor even with strong types because it doesn't enforce as rigid a structure.

I love the idea that typed languages create backpressure. I have very little confidence in peoples' ability to create well-designed (in software architecture terms) projects.

Python is a strongly typed language and language dynamism has no relationship to strong typing. you're likely thinking of static typing. With Python's type annotation feature as well as the work being done with MyPy, Python is also beginning to grow some static typing behavior as well.

First of all, zzzeek, thanks for your great software. While working on SQLAlchemy, have you ever run into situations where you really missed static typing? Do you ever see yourself wanting to introduce Python's static typing behavior into that project, and why or why not?

I did nothing but Java from around 1998 to 2002 and then again around 2006-2008, and there is definitely a deep satisfaction when you have built your giant statically typed castle and compile it and then it runs the first time. In Java though, obviously the verbosity that implies, particularly when I was using it pre-generics, most certainly erased any productivity gains and made for code that was very difficult for new people to understand, tests were in particular extremely hard to write. So at least with Java's widely criticized model, it was sort of nice-ish but hard to say it was worth it.

What Python is doing with typing I think is going to be amazing though. Just not sure if I'll have time to embrace it fully within my own projects.

Unless the popularity of Rails, Python, PHP, and Javascript was all just collective insanity, dynamic languages do offer benefits in some circumstances over languages with stronger type guarantees.

The benefit they offer is fewer checks so you can deploy things faster.

It's the same benefit you can get if you take your car to a mechanic who doesn't bother to check the wheels are attached properly after they've changed the brake discs.

But one can add checks after the design/features settle; it's not all or nothing. Using the mechanic analogy, if you are requesting a custom car, the mechanic can shape the look and feel first, and then verify everything once you made up your mind.

Most CRUD (such as tracking applications) is just marshaling attributes around and about, not really doing much math on them. Forced type checks can be repetitive busy work and hogs screen real-estate.

Funny when it comes to semaphores in software industry, it's harder to understand than just trying to understand it as is.

Reply on news.ycombinator.com