Go to bed, you’re drunk.

I’ve never done it but apparently you can actually gradually transition to Typescript one file at a time by renaming them from .js to .ts. Might help a bit. Good luck anyway!

Yeah IntelliJ does amazingly without type annotations but even it can’t do everything. E.g. if you’re using libraries without type annotations, or if you don’t call functions with every possible type (is your testing that good? No.)

Static types have other benefits anyway so you should use them even if everyone in your team uses IntelliJ.

In common usage a linter detects code that is legal but likely a mistake, or code that doesn’t follow best practice.

Although static type checkers do fit in that definition, that definition is overly broad and they would not be called a “linter”.

Here is how static type checkers describe themselves:

Pyright is a full-featured, standards-based static type checker for Python.

Mypy is a static type checker for Python.

TypeScript is a strongly typed programming language that builds on JavaScript, giving you better tooling at any scale.

Sorbet is a fast, powerful type checker designed for Ruby.

Here is how linters describe themselves:

Pylint is a static code analyser for Python 2 or 3. … Pylint analyses your code without actually running it. It checks for errors, enforces a coding standard, looks for code smells, and can make suggestions about how the code could be refactored.

(Ok I guess it’s a bit redundant for Pylint to say it is a linter.)

Eslint: The pluggable linting utility for JavaScript and JSX

Clippy: A collection of lints to catch common mistakes and improve your Rust code.

Ruff: An extremely fast Python linter and code formatter, written in Rust.

You get the idea… Linters are heuristic and advisory. Quite different to static type checking.

Honestly I would take a look through a good standard library that provides a lot of algorithms (e.g. C++ or Rust). That has the basics, especially for data structures.

Also have a go at some hacker rank tests. Especially if you want to learn dynamic programming (abysmal name), they absolutely love that.

Linters 100% won’t. A static type checker is not a linter.

Yes because you used static type annotations. This thread was about code that doesn’t use static types (or static type annotations/hints).

It’s an example to demonstrate that linters cannot reliably detect variable name typos - you need static types. None of the stuff you mentioned is relevant.

The typo in your example is also undetectable by linters. I think you’re missing the point.

What’s awful about this example? The only thing I do is access an object member. Does your code not do that??

Yes you can use static type hinting and the static type checker (Mypy or Pyright) will catch that. Linters (Pylint) won’t.

If you use VSCode, open both files and then ctrl-shift-P “Compare active file with …”

You’re welcome.

def foo(x):
  return x.whatevr

No linter is going to catch that.

…for people who refuse to use static types.

Hilarious.

This is the sort of thing you have to learn by experience, like how you can’t really learn good coding taste from reading a list of rules (though some lists are helpful).

Anyway in my experience documentation is quite different in public (i.e. seen by customers) and private (inside your company). For internal stuff there’s a much smaller incentive to document things because:

1. documentation tends to be inconsistent (as you discovered), so people give up looking for it. Instead they just ask other people. This actually works fairly well inside a company because you can generally easily access whoever is responsible (as long as they haven’t left).
2. there aren’t customers to keep happy and away from support.

I think the best thing to do is to accept that people aren’t going to expect documentation internally. There’s zero point writing guides to tools on your company wiki or whatever, because nobody will even try to look for it - they’ll assume it doesn’t exist.

Instead you should try to keep your documentation as close to the user as possible. That means, don’t have a separate docs folder in your repo - put your docs as comments in the code.

Don’t put deployment instructions on your wiki - add a ./deploy.sh script. It can just echo the instructions initially.

Yeah, honestly you should stick to if/else until you’re really sure you want to do something more complex.

This is really terrible advice. Sometimes it’s better to do that, but definitely not in the example from this article.

If anyone says you should always prefer polymorphism to switches they are a bloody idiot.

There’s no value for the higher ups in fixing it

Well there is, it’s just long term value that they don’t even understand.

Really you should just make fixing technical debt part of your regular job. Don’t ask for permission, just do it. (Except for really big things obviously.)

For Python PyQt is the obvious choice. For Rust there isn’t really a mature option yet. Egui is decent, but it’s immediate mode which isn’t to everyone’s taste. Dioxus is pretty popular too but I haven’t used it.

No idea for Java. Is Swing still the standard?

What language are your apps written in? Generally the best options are:

1. Qt (C++) or PyQt (Python wrapper if you hate yourself). Old school desktop GUI. Works extremely well though.
2. Web based, then you can pick from a gazillion frameworks, most popular is React. You generally have a Typescript based frontend and a backend in whatever language you want. The downside is you have to deal with the frontend/backend communication which can be a pain.

There’s also Flutter which is pretty nice, but again you have to use Dart for the GUI so if the rest of your app is in another language you’ll have some friction.

But yeah, I would say the language you want to write your “business logic” in is the biggest factor to choosing. Also if you care about exposing your app over the web.