3 ms·
Preface: I've worked on code ranging between FORTRAN 77 to a rather nuts react, typescript, webpack,... combination. From my experiences, what I have observere
by samhuk 6y ago
Preface: I've worked on code ranging between FORTRAN 77 to a rather nuts react, typescript, webpack,... combination.
From my experiences, what I have observered first and foremost is that the problems that software is solving are getting more complex as time progresses, causing software complexity. That is often proportional to the number of bugs.
Many popular FORTRAN packages out there solve a particular (or set of) well(ish)-documented mathematical or physical problems. Matrix manipulation, eigenvalues, weather simulation, etc. What i've observed is that these problems are, although sometimes complex, require minimal dependencies. The primary dependency is some journal paper somewhere, which you don't have to install as a software dependency!
Constrast that to a couple recent codebases i've worked on, easily >300MB of npm dependencies for a mix of react, typescript, webpack, sass (gyp!! >:(), jest, cypress, etc.
Having said all of that, for both of the above eras of software, i've encountered annoying bugs. It's just that nowadays i see most bugs are package compatibility issues (looking at you, steaming pile of webpack 5), whereas with FORTRAN it has instead been a mathematical error.
My point is that software is solving very complex problems right now. Back then, a web application was 3 types of files, because web applications were simpler. But now entire businesses use them, all their processes can rely on a single web app. Important processes sometimes with regulatory involvement. This necessitated typescript (scalable js), testing (jest and cypress), better performance (webpack), etc....
- cryptica 6y agoI see TypeScript more as a bandaid patch which solves small problems but causes bigger future problems than it solves. TypeScript and its many dependencies add to the kinds of compatibility problems you allude to. I'm a strong believer that the language's type system doesn't matter that much. Statically typed or dynamically typed. It's possible to write equally good quality code in both paradigms. The key to good code is logical separation of concerns (high cohesion) and simple interfaces which have simple parameters and return values (loose coupling). Also, having well defined concurrent event loops is important if your system requires a lot of async logic. The obsession with TypeScript now is mostly the result of the fact that people have a tendency to blame tools (dynamically typed languages in this case) for their own incompetence.
- jamil7 6y agoI feel very productive in statically typed languages like Rust and Swift but hard agree on Typescript and I’ve said it here before. It feels like the worst of both worlds, extra code and dependencies for limited type safety. The amount of times it causes some issues with compatibility or a library has missing or incorrect typings has left a bad taste in my mouth. Granted I always work on small teams or alone though.
- samhuk 6y agoI agree with the library compatibility issues for typescript, I've felt that pain before, but it is getting better by the day with more adoption. I've always held the belief that the major flaw of Typescript was that it is preceded by Javascript. This caused fragmentation. If the web was Typescript first, I believe it would have been quite the "nirvana". But then again, Rome wasn't built in a day...