undefined | Better HN

0 pointshnfong4y ago0 comments

Which camp is plain wrong?

The side that insists on using strongly typed languages for a weekend throwaway project?

Or the side that insists on using dynamic languages for 2000 file projects?

I always see "rifts" as a lack of perspective. One solution is obviously the only best way because they only see their narrow sets of use cases.

0 comments

rafale4y ago

"in any project that's meant to grow and last"

I specified what I am talking about. Weekend projects are not even a contention point. People code them in Brainfuck and we all have a laugh about it. It's the stuff that end up at the job that frustrate us where you end up assigned to a 100k (or even just 10k) lines of javascript inferno hell. Because some dev thought he can develop "faster" in Javascript.

Tade04y ago

Adequate testing goes a long way in dealing with that.

If you don't have tests you're screwed either way.

RussianCow4y ago

This is wrong; tests and type systems have different purposes. One helps prevent logical bugs and regressions in your code, while the other enforces the correct use of code and data structures. They overlap a bit, but all the unit tests in the world can’t give you the guarantees that a type system does. And that’s without even mentioning the benefits to discoverability and documentation that a static type system gives you.

1 more reply

axiosgunnar4y ago

> The side that insists on using strongly typed languages for a weekend throwaway project?

yes? it's gonna take me 30min in a dynamic language because i keep running into "undefined" errors, or 20min in a strongly typed language because if the IDE is happy, i know it will work.

the advantage of strongly typed languages is linear, from something that takes 10 minutes to something that takes 10 years, coding in a strongly typed language is always X% faster.

put the other way: why would I want to code in a language that allows me to write impossible code? what is the point?

the only selling point of python is the large corpus of third party packages (numpy etc), and that the syntax "looks simple" and is thus beginner-friendly.

there is literally no other reason to use it apart from the above two reasons.

zo14y ago

And don't forget the 15mins you spent choosing how to handle multiple types and future proofing by adding IOC and a DI framework that works like magic. Oh and the myriad activations and config that library devs added to their frameworks using a Fluent syntax because it looks better. No thanks.

monocasa4y ago

That's orthogonal to strong types. Java isn't the pinnacle of what strong type systems can look like.

kevinmgranger4y ago

Indeed. Every single technical choice has tradeoffs. It's just that some tradeoffs are non-issues for narrow use cases.

j / k navigate · click thread line to collapse