Hacker News Reader

Comment by tambourine_man | Hacker News Reader

> But that's a pretty out-of-date take

Gradual/optional static typing are not new ideias. It’s just that they are fashionable now.

It used to be that not having to deal with types at all was the cool place to be in. Our computers were getting so much faster every year, why would performance be a concern? Programmers are more productive in dynamic languages and computer time is cheap, etc, etc.

The “correctness” pitch, the required for larger projects, compiletime vs runtime errors are all discussable, even though they are often thrown in the conversation as irrefutable advantages of static typing.

The performance angle, not so much. Static will almost always be faster then dynamic typing, even with all the crazy tricks we’ve developed over the decades.

View on HN

It’s not that they’re fashionable, it’s that their ergonomics have improved significantly over the past decade. I saw dynamic types as a response to cumbersome static type systems, but increasingly type systems are becoming more expressive and less cumbersome.

Yeah, this is how I see it, too. Sort of a gradual convergence.

On the static side, Java and especially C# are simply _better_ than they used to be. Type inference is great - I can just write var x = new List<Thing>() rather than having to stupidly repeat the type e.g. List<Thing> x = new List<Thing>(). Add in generics, and lambdas, and about a dozen other things that have now become widespread, and it's really a different game than 10 years ago.

Coming the other way, I never expected to see Intellisense-like autocompletion for languages like Ruby or Python. It honestly feels magical. Refactoring has gotten much better to where I can pull methods up and down inheritance chains using PyCharm or other mainstream IDEs.

I actually think it's mobile that's pushed people back toward static. Swift, ObjC, Java, and Kotlin are all static and there's less emphasis on this "one language" idea that drove a lot of people toward trying to use the same language (JS/TS) for their React front-ends and node backends.

But C# has had everything you've listed for over 10 years. Along with a great IDE that has provided very useful intellisense since pretty much the beginning.

You couldn't (easily) use C# to write the frontend for a web application that you wanted to use as either a developer or a user, though (which is to say sit down, ASP.NET Web Pages, nobody ever liked you).

That's the lock that TypeScript turns, IMO.

There aren't that many languages that do this even today, much less 10 years ago. You've basically turned what was a discussion about static typing in general into Javascript vs Typescript.

Not only C# and Java, but C++ has auto, Typescript has let, Rust has let and I think many other languages have type inference.

When it comes to code, I'm fairly certain "correctness" is in fact an irrefutable advantage.

The argument has always been whether or not the price of that correctness is too high.

But at this point if you're using a modern IDE / code editor (e.g. VSCode), it's actually easier to write statically typed code because the inference / auto-completion / etc is so much better when you do.

At least with TypeScript in VSCode.

> The argument has always been whether or not the price of that correctness is too high.

No. I mean, that's been part of the argument, but so has whether static typing actually gave you useful correctness. Many static languages have had type systems that are more designed around convenience of compilation (and performance of compiled code) than correctness; the type systems of the optional typecheckers of modern dynamic languages are leaps and bounds better than static type systems of most popular static languages a couple decades ago, and have been for some time.

> But at this point if you're using a modern IDE / code editor (e.g. VSCode), it's actually easier to write statically typed code because the inference / auto-completion / etc is so much better when you do.

If you have good inference, statically typed and dynamically typed code is virtually indistinguishable TypeProf-IDE for Ruby, discussed in TFA, generates type signatures by inference from plain Ruby code.

Strong disagree with the idea that dynamic inference steps to static declarations, particularly for Ruby and especially if you're using anything that expects you to write code inside of its DSL. The inference tends to fall off and because it isn't expected of you, nobody's doing anything to help there.

Maybe Rails is special-cased enough to get away with it, but I still maintain a project in Grape and none of the autocomplete solutions I have found for Ruby help significantly at all. Meanwhile over in TypeScript, I literally can't remember the last time I used `any` or `unknown` except at a module's edge during validation of untrusted input, and autocomplete is awesome.

> it's actually easier to write statically typed code because the inference / auto-completion / etc is so much better when you do.

Ruby has a pretty nice language server, nice linter, REPL (Pry), many other tools.

The best development experience IMO is still stuff like SLIME or Smalltalk environments.

"Intellisence" just makes using statically typed languages bearable. It's not a unique feature.

Intellisense will allow you to do explorative programming, finding what method is callable on a given object. It’s much easier to look up n methods than to try to guess what is the whole state of the program where it may accept this and that, where even in the best case you might get a fraction of what a statically typed language’s autocompletion allows for.

Like just seriously try intellij with java and pycharm for a php code.

Ruby has (always had) a REPL and .methods gives you all possible methods you can call on an object. Editors with completion have been around forever too.

"Intellisence" is just what MS calls it. It's not unique to statically typed languages. Completion has existed for dynamic languages probably longer than I've been alive. In fact, the reason tooling for Java/C# is so good is because the VM can feed it info as it's running, since even though the language is static the runtime is dynamic.

I have used that REPL extensively. I've written plugins for Pry for my personal usage. There are absolutely cases I've run into where it is nice to break into code, write it inline, and save the buffer. This is true. But I've run into more cases where having to do that to know what I'm working with in the first place is a tiresome slog.

Please try one out, the difference in quality is staggering. Also, .methods is a runtime thing, that’s hardly useful. Of course at runtime you must know the available methods.

I do write code in statically typed languages (C++, Haskell, have done Java before, etc...).

> Also, .methods is a runtime thing, that’s hardly useful

I think you missed the whole point of a REPL and dynamic languages... Developing while program is running = runtime things are definitely useful, they provide instant feedback (including completions, linting, that sort of thing).

Or try RubyMine for Ruby.

The challenge of providing a list of available methods in a dynamic environment is real, for sure, but there are great tools out there doing it right now.

That’s why I used correctness in quotes, because it’s no guarantee.

It's not a guarantee, but an environment/language that yells at you when you try to pass a boolean to a function that should only ever accept a string is going to result in a more correct program than one that just... doesn't say anything and lets you happily do things that make zero sense.

With Visual Studio also. Intellisense works wonders.

> Gradual/optional static typing are not new ideias. It’s just that they are fashionable now.

I'd add that Common Lisp has had optional type hints (as both documentation and performance improvement) for getting close to 40 years now.

You might not care about types but the computer you are running your code on, cares very much.

Are they releasing processors with typed registers now?

AFAIK registers and assembly is untyped.

That's true, however I think you're misunderstanding how languages work. The Ruby interpreter knows the "type" of everything. How could it not? It was there when you defined a variable, and it was there when you added data to it. It's there when you define interfaces and other things that might affect the type of something. It's perfectly capable of holding all of that information. And there's no meaningful difference between parsing "int x = 3;" and "var x = 3;" in a program.

Reply on news.ycombinator.com