Comment by kerkeslager | Hacker News Reader

Comment by kerkeslager | Hacker News Reader

> Now let’s address level 4. Big players sit at this level, perhaps the most popular languages by headcount of their programmers. The problem with a lack of static typing is that it’s hard to work on such code in groups and at scale. Every successful business started with those languages eventually rewrites their codebase to use one of the “lower level” languages because big codebases written by many people are hard to maintain and modify without the support of a static type-checker. They are still great languages for solo, small projects, especially if the code can be easily automatically tested.

This is total made up nonsense. I've worked in Python for over a decade, and at multiple successful companies that have been running quarter-million plus line Python codebases for 8+ years.

Proponents of static typing like to sound alarms that it's impossible to scale dynamic codebases when they lack the experience in those languages to know people solve scaling problems in those languages.

I'm not hating on static languages, but I think they involve more tradeoffs than proponents of static typing admit. Time spent compiling is pretty costly, and a lot of codebases go to great lengths to somewhat bypass the type system with dependency injection, which results in much more confusing codebases than dynamic types ever did.

Meanwhile, many of the worlds largest and longest-maintained codebases are written in C, which is only half-assed type checked at any point, and is much harder to maintain than dynamic languages. The idea that projects reach some point of unweildiness where every one of them gets rewritten is just not correct.

I might have gone a bit easier on this if the author hadn't said "Every successful business..."--the word "every" really is just way too far.

EDIT: I'll also note that just because a language isn't statically typed, doesn't mean it gains no benefit from type checking. JavaScript and Python are not created equal here: JavaScript will happily let you add NaN and undefined, only to cause an error in a completely unrelated-seeming area of the codebase, whereas Python generally will type check you and catch errors pretty close to where the bug is.

i completely agree. i have lead a team of 3 (three, incl. me) which has made and run completely "untyped" 90KLoc python + 90KLoc javascript for years (well, about 25% was generated, from another 1%. Meta programming, yes). And a few other similar codebase magnitudes and team-counts, before.

IMO rewriting happens mostly because going to lower-level of the needed proficiency/understanding - once the product why-what-how is more-or-less discovered, its code can be commoditized and hardened, kind-a. Dynamic stuff is very powerful == becomes too powerful (and "magic").

There is quite some wishful thinking around what so-called static-typing (which is actually static type-hinting) in dynamic languages, hoping and believing that declaring something Float, guarantees it being Float at runtime.. which is nonsense. In Ada, and few other runtime type-and-range-etc-checking languages - yes. But in plain ones.. nope. C++, Java, whatever - noone checks things at runtime. Most of those do not have a way to know what some n-bytes represent, hoping it matches the expected layout (i.e. type). While, say, python very well knows what each and every object is. If asked.

Of course, one can build such real-runtime checkers, and apply them where/when it is needed and makes sense - instead of blanket policy everywhere, but noone bothers. (Funny thing is, when i made one such library 15y ago, i was spit at and told to go code in java. And, even i haven't since then stumbled on pressing need to use it myself. Having 10 asserts (or constraint checks) in some 10kLoc does not justify whole library)

That said, i think something like language-verticals might be useful. And/Or gradual hardening, on piece-meal basis. At least a standartized way for going up/down or stricter/relaxed, from wherever one is.

> But in plain ones.. nope. C++, Java, whatever - noone checks things at runtime. Most of those do not have a way to know what some n-bytes represent

But then my question is, what are you doing that you need to manually check for types ? I mean i get it at some point, usually at the time of user input usually you need to run checks to actually convert some input into a valid type. But once it is inside your program you don't need to check anymore because well... static typing and all that, you should know what you have in every step just at a glance

> once it is inside your program

Well, if it is in my program - or codebase of (design+code but mostly) lining-and-discipline by me - i don't need them type-checks. They give somewhat fake sense of correctness, kind of over-confidence. Maybe useful here or there, but like 1% (Given any inputs from outside are gated with checks/validations/conversions). One rarely sends by mistake a single float where a Point3D is needed. But move(x,y) and move(y,x) are wildly different things and no typing would catch that (except excessive&brittle stuff like Xcoord/Ycoord as types). Needs explicit naming (not typing), like move(x=a, y=b) or smth.moveX(a).moveY(b) or whatever.

Reply on news.ycombinator.com