Hacker News Search

gavmor 3y ago

"Correctness" isn't even the draw of static typing; speed and flexibility are. When I make a single business-relevant change, the compiler's error messages guide me to modify what must else accommodate. This is faster (and less error-prone) so I can get onto my next feature sooner.

gls2ro 3y ago
What kind of business-relevant change are you referring to here? I don't think the compiler with the error messages makes a difference when the business is pivoting between features, when they ask to add a new field to various forms, to generate new reports or add new emails in various points of the work flow. Or change the emails from one point to another point. Or add password less. Or just switch the external provider of an API from an important flow because there is a better deal elsewhere. I am not saying static typing does not provide speed or flexibility, but I just wanted to say that business-relevant change has more to do with features than code.
- gavmor 3y ago
  > business-relevant change has more to do with features than code I cannot comprehend this. It's like saying "Health has more to do with organs than cells." Organs comprise features. Features comprise code. To change the feature, one must change the code. If the code is not business-relevant, delete it. It's a liability. We are not artists. If the code is well-written, the compiler errors will echo the business' failings.
ActorNightly 3y ago
Thats the "academic" advantage of static typing. In practice, it essentially leads to one of 2 things 1. Any time you have to make a change for a prototype, you have to go change a whole bunch of dependencies on your library, even if the change is not used in those explicitly, all because of the prototype. 2. You start introducing dependency hell or duplicate code, to either abstract stuff away so you don't have to do the prototype changes, or you start writing duplicate classes/functions to handle different parameters. Neither of which is either fast or flexible. Anyone who has worked at Amazon dealing with Java services can attest to this. Dynamic typing on the other hand is actually flexible and fast. For example in Python when building out something that is changing quite often, its very easy to pass around dict objects. And yes, dynamic typing, it can lead to more errors, but in practice, most all of these are caught during testing, and are just as straightforward to fix as compiler errors. If you try to access a dict field that is not in the passed dict, its pretty much equivalent to a compiler error.
- gavmor 3y ago
  I don't have an "academic" background, I just enjoy the subjective ergonomic advantages. At the very least, strict types obviate a class of tests that I'd previously considered indispensable. > dynamic typing, it can lead to more errors, but in practice, most all of these are caught during testing I think we're practicing such different styles of software design that one another's tools are a hindrance. For example, I don't think that "bugs are caught during testing" because I am testing first. Unless you mean user acceptance testing, which is uncomfortably late in the cycle.
  - ActorNightly 3y ago
    When you compile the code with static types, there is a process of parsing the syntax and executing a state machine that checks all the validity of types. When running a dynamic type language, these errors are going to be caught at runtime. What Im saying is that from the perspective of code execution, there is no difference between the two as long as those checks are performed somewhere before you ship your code, whether in tests or in the act of compilation.
    - gavmor 3y ago
      > as long as those checks are performed somewhere before you ship your code Preferably, they're performed before I push to a remote repository. Hopefully they're performed before I alt-tab away from the editor for a single second. Hopefully they're performed before I fuzzy-find a collaborator module to edit. > When running a dynamic type language, these errors are going to be caught at runtime. Only if those code paths are exercised in a test suite, or am I doing it the hard way?