Hacker News Reader

Comment by rkwz | Hacker News Reader

I curious how using Typescript makes the project more "structured" compared to using plain JS.

Typescript just gives you static types and classes. I can understand "classes" make the code more modular and thereby more structured, but can't you already do that using ES5 "class"? Types help in catching errors early and can help in documenting the interface of the methods etc.

Also, if the other problem was isolating the scope of modules and dependency injection, it could be easily done using Requirejs and all the modules could be concatenated during build time. Webpack is a cool tool, but given the nature of its documentation, the maintenance would be really costly in the long run. Requirejs is just more established and satisfies all the author's requirements.

It would've been really helpful if the author had included additional reasoning behind the choices made.

View on HN

The basic idea here is that complex data structures are usually easy to understand, while complex code isn't. This is one of the few fundamental insights about programming that withstood the test of time.

Note that while this all is not necessarily about types, this is about documenting the data structures - and good type systems enable you to do so in an unambiguous and even machine-checkable way.

1975: There's a famous quote in "The Mythical Man-Month" by Frederick Brooks:

    Show me your flowcharts and conceal your tables,
    and I shall continue to be mystified.
    Show me your tables,
    and I won’t usually need your flowcharts;
    they’ll be obvious.

Note that this is old language from the 1970s, where "tables" roughly means "types definitions" (or comments describing the structure of input and output values, think of database table definitions) and flowcharts roughly means "function definitions" (think of hand-written flowcharts written next to low-level code to make all its GOTOs understandable).

1989: You can find a similar statement in "Notes on Programming in C" by Rob Pike:

    Data dominates.
    If you've chosen the right data structures and organized things well,
    the algorithms will almost always be selfevident.
    Data structures, not algorithms, are central to programming.

Note that Rob Pike refers directly to Frederick Brooks.

1995: Frederick Brooks reiterates this statement in the second edition of "The Mythical Man-Month" (20 years later).

2003: The same idea is also stated as one of the basic design rules in "The Art of Unix Programming" by Eric Raymond:

    Rule of Representation:
    Fold knowledge into data, so program logic can be stupid and robust.

Note that Eric Raymond refers directly to Rob Pike.

2006: Another quite famous quote from the Git mailing list by Linus Torvalds:

    Bad programmers worry about the code.
    Good programmers worry about data structures and their relationships.

And so on.

(BTW, does anyone know about a similar quote before 1975? Or a popular reformulation after 2006?)

> BTW, does anyone know about a similar quote before 1975?

Just take a look at the data division of COBOL. This has been very clear for a long time.

In a related note. Databases schemas usually outlast applications. I highly recommend taking a look at database refactoring.

Thank you for the history lesson.

I have found a lot of bang for the buck in software development comes from "the schema". I can use them to automatically enforce the runtime contracts between my code and my consumers'. As a communication mechanism between myself and other developers, the well-annotated schema builds an unambiguous picture for everyone of the entities, relationships w/ restrictions, and cardinalities in our systems.

At the boundaries of our microservices, we JSON Schema validate messages before they are sent on the service and upon receipt by the client (at least in the non-production environments.) We use the schema to guarantee the services and clients are always "speaking the same language" even when teams are releasing versions of their code at different times.

Structure means walls. There are tons of crazy things you can do 'outside' the walls with javascript. There are no checks if anything you reference exists or that your assignments are compatible. The browser's compiler will figure it all out and/or blow up at run-time.

Type and reference checking creates the walls your code must stay inside of otherwise there are compile errors. The compiler enforces a certain structure on your code that you must adhere to in order for the compilation to succeed.

Think of it like a coloring book where TypeScript keeps you inside the lines. Ever see a three year old's coloring book? :p

As much as I love programming with no self imposed 'walls', I fear maintaining anything larger than 10,000 lines created that way. When you step into an existing enormous code base with no testing implemented, static typing and the associated tooling are fantastic.

ES6 class lets you define classes, but it doesn't let you annotate variables or parameters as being a certain type.

Adding Requirejs is a dependency just as typescript. Typescript has modules out of the box.

The types are what give it structure. Types are the structure. When you create a type, you are saying in concrete terms "this is exactly how things happen and nothing else".

This is very useful information for a large project. Think of it like a map. You don't need one for your house, but you need one to walk cross country. Or like NASA procedural manuals for something normal people don't need a guide for...like an astronaut taking a shower or something.

I don't understand.

> Types are the structure. When you create a type, you are saying in concrete terms "this is exactly how things happen and nothing else".

Types make the interface concrete - which is better for compiler/interpreter (catch bugs) and better for developers (easy to understand instead of guesswork)

But when I think about "structure", It is usually about how the codebase is organized. How different modules interact with each other and is the flow of the code easily understandable. This could be easily achieved without Types.

Maybe it's just my interpretation of the term "structure".

It is pretty much impossible to have any sort of inferred structure from plain javascript. The reason you can use super powerful tools to refactor, rename, and find all references across files in typescript is because the IDE can build a 100% accurate data model of your code base when it's written in typescript.

You can do that kind of stuff in dynamic languages like JavaScript, Python and Ruby. Check out JetBrains' editors.

Yeah, but at the end of the day it's a guess. Nothing more. The IDE cannot prove that it's change all instances of the "thing" being passed into a function, for it's just using names and heuristics to correlate them and derive meaning, not an actual mapping.

I use IntelliJ when writing Ruby, and the navigation and refactoring tools are much less reliable than those for Java. Finding symbol references can return a lot of false positives since it cannot use the type of the receiver, and a lot of the refactoring operations are not available.

Jetbrains' editors for e.g. Python help me significantly less than their editors for e.g. java.

Not that it's a bad thing, but basically Pycharm is an editor with some nice-to-have Python env integration, linter, etc. IntelliJ has significantly better refactoring tools.

To do things like that in a dynamic language, you need to either infer types somehow, or rely on metadata like JSDoc, beyond the language itself, and that sucks – if another developer works on the project with a dumber IDE, their code will probably lack such metadata or it will not be entirely correct.

I have been using IntelliJ daily for the last five years for PHP, JS and TS development. For PHP, I write typehints and PHPDoc wherever possible to help the IDE make sense of things. For JS, I tried doing the same with jsdoc but it didn't work out, and I have decided to avoid any automated refactoring or even autocomplete, it's far too fragile. For TS, using the types in my code makes the IDE smart and reliable, although IntelliJ's support for type inference in TS is still far behind VSCode.

Special mention here goes to Magento developers, whose PHPDoc, 98% of the time, is either lacking or outright incorrect (referencing classes that don't exist – incredibly frustrating).

I use Webstorm. When we switched to Typescript, it made navigating and error checking dramatically faster.

I agree with everyone else, I don't find Webstorm's js refactoring to be anywhere near Jetbrain's static offerings. And the js auto-completion is about the same as Atom's autocomplete-plus applied to generic text (which is really great, but nothing like static type tooling).

When you use TypeScript, you don't have to organize your program any differently than you would in JavaScript.

If "structure" means how the directories and files are organized, then TypeScript makes no difference. I personally use the outDir setting in my tsconfig.json file to separate my JS from my TS, but not everyone does that.

If "structure" means "paradigm" (such as OOP), TypeScript might make a difference. You might find, for example, that functional programming makes more sense than object orientation to you once you have types. It really depends on you. Again, there's no real reason you'd change your preferred paradigm.

If "structure" means the types themselves (the structure of your data), then TypeScript isn't changing anything. It's just documenting your intentions in a way that other people and the compiler can understand.

It doesn't add structure, it just makes the existing structure obvious/explicit.

http://www.spaceref.com/iss/ops/sm.life.support.book1.pdf

A guide to the ISS personal hygiene facilities and operations.

I couldn't help myself...

Reply on news.ycombinator.com