Hacker News Reader

Naming is incredibly hard, though. And refactoring is hard.

It's a pain in the neck when something starts out as bla_list or whatever and you discover that after half a decade of changes bla_list isn't actually a list anymore, it's a dictionary, and that it doesn't only hold Bla these days, it can also contain Foo or Bar. This type of stuff is immediately obvious with modern static typing.

I agree, naming can be incredibly hard. I periodically spend a long time trying to decide the best name for variables, and at times whatever I come up with isn't satisfactory to me even then (and I usually try to explain it better in a comment at its declaration).

I don't always change the names if their use drifts a bit either because I know the other developers might be used to the code where it's named something else and it might confuse them, and/or I have to rename it in a bunch of places that might make a merge particularly messy, especially if I'm working in the same place that I think another dev might be working on at the same time (it's happened more often than you'd expect actually, I've had to do some particularly gnarly merges at times).

This feels more like developers learning that any variation on Hungarian notation is a bad idea.

You have to account for developers learning, for any code base, though. Let alone for third party dependencies :-)

This feels less like a case of Hungarian Notation being a bad idea and more like a case where developers are making irresponsible updates to their code. If a variable/function/class/whatever is being updated, the naming should be updated as well, if appropriate.

Blaming the original author for the actions of the maintainer is not fair.

I'd still blame the individual developer for poor naming. Naming a variable something like int_list is terrible in that it's both very specific and semantically meaningless. Either choose a semantic name like grades or part_numbers, or take a hint from ML convention and use semantically void names like "xs".

Sure, but is there anything stopping the person updating from revising the name? The original quality of the name is not relevant to my point, which is that anyone changing the code but leaving poor names behind is complicit in the debt.

I guess static first is a chore because at that point you have no idea what invariant or structure is required for the task. After prototyping you know where to tighten the bolts.

There are some languages that give you a bit of both worlds, like F#.

This! My favourite thing about working with F# is the tiny delta between prototype script and production MVP.

hey, the ml family is only 40+ years old, maybe in 50 years they'll be mainstream

Sort of but at the same time being forced to think about those things also helps get a handle on exactly those parts of the program. Remember you still need to think about them in a dynamically typed language but it's obfuscated because they're implicit.

> you have no idea what invariant or structure is required for the task

I often write the program in TypeScript types/interfaces first because it forces me to think about the data flow both in and out. In my opinion, data, not code, is the most important thing about a program.

that way of working was my only pleasurable experience in eclipse/java

start with interfaces and let the live type checker tell you where your incoherences are. Very very smooth way to work.

> you have no idea what invariant or structure is required for the task

In my experience, in general, if you don't already have an idea, you should probably be spending the up-front time thinking about it. If we're talking React/Redux, then carefully thinking through both data representation and what goes into components' properties/states helps a lot for designing a clean and understandable structure.

Designing my types first is precisely how I want to begin prototyping.

There is why TypeScript IS so great.

In the early days of a new app or feature, you have no idea what the correct data/type shapes are.

In TypeScript you can define the types and then easily do major refactors even if you have 1000's of lines already written.

It becomes so tedious to do the same refactoring in JavaScript.

TypeScript makes it trivial to change an object or function signature when developing new code (or old code).

Refactors that take 3 minutes in TypeScript take 3 days in JavaScript and you better hope you catch all the uses.

The refactor ability that TypeScript gives you makes it so much easier to change data types and function signatures dozens of times until you get things right.

> I also think static typing has the benefit of enforced self-documentation a bit, so other developers know just by checking the type what sort of data they should expect to see in there, and not trying to give it garbage to begin with. Granted good variable naming and proper documentation would alleviate that, but that's never been fully consistent at any organization I've ever worked for.

I don’t think naming is fully alleviated by static typing; however, on the other hand, static typing allows IDEs to offer better refactoring capabilities, since they can presumably build such functionality on top of the compiler’s structured syntax tree representations.

As an example, lately I fairly frequently find myself using VS Code capabilities to rename TS identifiers as my code evolves. It always handles correctly the scope and everything, I’m sure it’d be more error-prone with plain JS.

Agreed about statically typed code being more self-documenting in general. It’s a bit of a double-edged sword in that it may give an illusion that your project is easier to understand than it actually is, but it usefully shifts the focus of documentation from minute details of code itself to subject domain specifics and how you represent them in your architecture.

Seems like an easy cutoff is when you add a build step as opposed to just including your script on the page. If you need to use Webpack for a project, you might as well add TypeScript as well.

SQL is not typed, it is just text sent over a network or whatever and then parsed...

The schema and functions are typed.

I use type annotations in Python no matter what. It really helps skim the code faster and mentally understand what values I am expecting. Its very useful to know which var is a List[dict] and so on.

I don't like TS because javascript is just a silly language to do anything serious with (besides front end), and its so stringent it takes forever to write quickly.