Comment by andjd | Hacker News Reader

Comment by andjd | Hacker News Reader

Parent Full thread

This is kinda the point of smalltalk. It's a radically different programming model _and_ paradigm than most C-derived languages. If you're looking for a language that feels comfortable to developers with a background in [insert widely-deployed language here], there are better options for you.

Smalltalk has been around for over 40 years, which makes it a contemporary to C. Just like FORTRAN or COBOL, there's a corpus of deployed code, and institutions that are invested in a maintained runtime, but that dosen't mean that you would necessarily want to use it for a new project today.

A lot of the great things about smalltalk, such as block syntax for anonymous functions, have been copied into many modern programming languages, and we probably wouldn't have them without smalltalk taking it's unconventional approach.

> The paradigm they're going for is TDD for everything. Personally, I feel this is a big step backwards from most mainstream scripting languages adding on type annotations.

So, the push to add types to JS, Python, Ruby and other dynamic languages is largely from developers accustomed to Java, C-Sharp, and other enterprisy languages who would probably rather not work in a dynamic language at all. Put another way, it's a concession of these languages to try and be everything for everyone. But statically typed complied languages do not provide an inherently better programming paradigm than dynamic programming. Smalltalk commits further and deeper to a live, dynamic programming experience. It's different, and I don't feel like saying that it fails to conform to expectations brought in from other, very different programming paradigms is a meaningful criticism of the language.

> So, the push to add types to JS, Python, Ruby and other dynamic languages is largely from developers accustomed to Java, C-Sharp, and other enterprisy languages ...

Nope, this is not true. I am personally pushing to add types to our Python codebase, and I have no love for "Java, C-Sharp and other enterprisy languages".

It's just that as the codebase grows, and especially as number of contributors grows, people start to make more mistakes. A rarely used code path, like an error handler, might fail in production because of wrong type or missing argument. We can require unit tests with 100% coverage, but this is very hard -- and typing linter finds you many more bugs per effort spent.

That does not mean that we should always specify every type in program explicitly, like Java does. Unspecified types are great for interactive exploration, or a quick hack. But as you move to production, don't understimate typecheckers -- they can help a lot.

This is pretty much my feeling. I'm not adding types because I have some kind of brain rot that makes me need AbstractFactoryBeanContainerAnnotationFactory. I like adding type annotation because it means you can do static analysis on your code base. Without it, you need exhaustive coverage tests to demonstrate what exactly can be returned.

> That does not mean that we should always specify every type in program explicitly, like Java does. Unspecified types are great for interactive exploration, or a quick hack.

It's also helpful to consider whether they constitute unnecessary requirements[1]. Most mainstream JS code is rife with problems like this—including rampant mis-/over-use of triple equals. (I call this "going out of your way to do the wrong thing".)

1. https://www.teamten.com/lawrence/programming/dont-invent-unn...

In what situation do you want the whole spectrum of `==` behavior in JS, other than possibly the `undefined == null` case? I’d argue exercising any of the other type conversion cases like `1 == true` or implicit `valueOf/toString` makes the code much harder to understand.

To ask the question is to fundamentally misunderstand the context. Please do check out the link. It's not a matter of wanting "the whole spectrum" of double equals (and then justifying that). You need to justify the requirements you're imposing. The article I linked gives an excellent example of why unnecessary requirements should be avoided.

Aside from that, overuse of triple equals is almost always a code smell that indicates the contributor is coming from a place of following cargo cult advice instead of solid understanding. (And in the case of the cargo cult advice about triple equals, it's not even very logical advice. I.e. it's not just the people following the advice who aren't thinking it through—the people dispensing it tend to be engaged in shallow thinking, too.) For example, anyone who asks you in a code review to replace `typeof(x) == y` with 'typeof(x) === y` has no solid reason whatsoever for that change (and will never have any; there is no argument that will hold up under scrutiny).

Adding types to an overly complicated and unreadable javascript codebase helped me to make sure I understand it before I refactor it.

> But statically typed complied languages do not provide an inherently better programming paradigm than dynamic programming.

For any large long lived project with multiple contributors, statically type analysis definitely adds value by eliminating an entire class of errors at compile time.

> the push to add types to JS, Python, Ruby and other dynamic languages is largely from developers accustomed to Java, C-Sharp, and other enterprisy languages who would probably rather not work in a dynamic language at all

I recall Guido van Rossum stating once, that he got convinced of the necessity for type annotations by JetBrains explaining to him how hard it was to provide good code completion. Not sure its the full answer, but back then I found it interesting as an example how lobbying can work.

(I feel rather indifferent on the type annotations for Python actually, I can see their usefulness, but also the shortcomings of retroactively introducing such a system into a dynamically typed language).

Typically in Ruby (which is heavily Smalltalk-influenced) we do ad-hoc type annotations anyway and call it documentation.

So you've got the camp that favors type annotations for various reasons and the camp that is opposed. There is also a third camp: the DBC (design by contract) camp. Their argument is that type annotations don't go far enough and that's what you really need is to enforce preconditions and postconditions. While I see their point, I think DBC lacks a "killer app" -- which as you pointed out, for type annotations, is static analysis (which leads to tools like code completion, refactoring browsers, performance improvements, and more).

One „killer app“ for these is interactive programming with instrumentation and generative tests:

https://clojure.org/guides/spec

> I think DBC lacks a "killer app"

If Ariane 5 carried astronauts, it'd certainly be a killer app:

https://ieeexplore.ieee.org/document/562936

> I recall Guido van Rossum stating once, that he got convinced of the necessity for type annotations by JetBrains explaining to him how hard it was to provide good code completion.

What a weird reason to decide type annotations are useful, but I suppose I am not surprised. And is that really even true? Code completion works fine with Elixir and ElixirLS in VS Code and is seemingly independent of whether typespecs are present or not.

Type annotations are there to help the user in figuring out what the parameters have to behave like, and, perhaps more importantly, for linters to help finding issues caused by mismatching the types.

Invoking the .detonate() method on a pyrotechnic bolt is, usually, far more benign than invoking it on an instance of Warhead. You really want to make sure you don't pass a Warhead to the function you wanted to get only bolts. A linter will warn you about such possible mishaps.

I understand how type annotations are useful for users and also for static analysis tools (called Dialyzer in Elixir/Erlang), which is exactly why I didn't see why code completion would be one's primary reason for wanting them. However, in Python's case with heavy use of OOP and dot notation, I suppose I could see it being beneficial if the tools pickup up type annotations for code completion (still not the primary reason though) as opposed to something like Elixir. In Elixir, types and modules are tightly coupled, which means user's being implicitly being aware of types and also code completion generally working without type annotations (which can be inferred by Dialyzer anyway).

So your comment actually backs mine up. I don't know why code completion would be the tipping point for type annotations when their usefulness to users and static analysis tools are already enough. Documentation for users is in fact enough to have them.

It could have been that code completion was the feature Guido saw would seal the deal with users. Good code completion is a great tool for exploratory coding. I frequently found about new APIs through the IDE before reading the documentation. This has been extremely valuable since Visual Basic 3, IIRC.

I like it - sometimes I want something to really take an integer (or an explosive bolt) and not any number (or a warhead). If I can say that the argument is supposed to be something, then it's harder to the IDE user to misuse it with unpredictable results.

Or, if my library or function can do something I never expected it could, I welcome the patch to make it obvious.

> I recall Guido van Rossum stating once

There are so many ... interesting ... Python design choices that I'm not sure whether "Guido said" helps an argument or hurts it.

One line lambdas comes to mind.

Types exist for a reason. It's not a fad, it's a solution to various problems.

Reply on news.ycombinator.com