Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cold Showers

github.com

Post reply on HN
Print view View original

181–190 of 363 posts

Re: Cold Showers

#181

Post by yCombLinks »

throwaway675309 wrote: post #135
OJFord wrote: post #79

Earlier quoted context omitted.

Allegedly? Have you ever written code in a dynamically typed language? I'm forever fixing TypeErrors and AttributeErrors and the like. I suppose it's not even necessary to argue about experience fixing them or not, just the fact that those are runtime errors rather than compile-time (and so we presume not shipped) shows it reduces bugs doesn't it?

I always notate my functions with JSDocs and my DTOs as jsdoc types which in any modern IDE gives you the same advantages that you would get out of the explicit typescript interface/type. And Unlike typescript my code doesn't need to be transpiled at all since it is already vanilla JS.

Discipline doesn't scale. https://www.sicpers.info/2020/10/discipline-doesnt-scale/ Add 10 people to your project and start forgetting some docs or failing to update them.

Re: Cold Showers

#182

Post by semiquaver »

HL33tibCe7 wrote: post #71
glouwbug wrote: post #21

Earlier quoted context omitted.

Until the types don't match the execution model... see: python type hints

That isn’t static typing That’s a dynamic typed language with comments

Most statically typed languages compile down to object code which runs in one of the most dynamic runtime environments imaginable. What are the types in the source code but “comments”?

Re: Cold Showers

#183

Post by ReactiveJelly »

moffkalast wrote: post #143
forrestthewoods wrote: post #122

Earlier quoted context omitted.

Hard disagree. Dynamic typing only increases development speed for the first few thousands lines of a solo programmer project. After that it is, in my personal experience, a significant drag on development speed. Furthermore, dynamic typing makes modifications and new features significantly harder to write. Turning compile-time bugs into runtime bugs is a catastrophic decrease in development speed. That’s my personal…

taps temple That's why you keep code encapsulated as much as possible in separate files/classes up to like a thousand lines. Any more will be unreadable anyway. > dynamic typing makes modifications and new features significantly harder to write Depends on what you're doing I suppose. Adding a parameter to an object? With dynamic typing you just add it to the object in literally any location, no issues. With static ty…

"serialization code"?

Maybe it's an issue with Java. In Rust if I add a new field, I just wrap it in an Option.

When de-serialized, old objects have a None, new objects with the field have a Some. When serializing it's just `Some (5)` instead of `5`, if it's an int.

No runtime crashes from nulls, either.

Re: Cold Showers

#184

Post by ReactiveJelly »

hsn915 wrote: post #166

IMO a lot of truths in programming are not amenable to "scientific studies". Static typing is objectively better than dynamic typing for the vast majority of cases, but you can't capture this in a scientific experiment or study. The only thing you can do is find people who are similarly experienced, break them up into groups (n=1 is also ok) and ask them to complete a specific project, and see how much time it takes.…

I present "The emotional argument for static typing".

Static typing is good because dynamic typing measurably makes me sad. Therefore I want the company to use static typing.

Re: Cold Showers

#185

Post by ReactiveJelly »

strager wrote: post #89
agildehaus wrote: post #16

Earlier quoted context omitted.

Static typing makes refactoring easier. Your compiler can instantly tell you what you've broken. Bugs are reduced by monitoring, testing, and reducing how much code there is so there's less surface area (which also makes monitoring and testing easier). You reduce code by refactoring.

> Your compiler can instantly tell you what you've broken. For some definition of "instant". I can often run my Python or JavaScript test suite faster than Haskell/GHC or Rust/rustc can type-check a module. And it can take a while to understand Haskell, Rust, or C++ error reports. (Of course, Python and JavaScript startup time and execution speed can hurt refactoring too. And AttributeError-s and random undefined-s a…

How many hours do you, the human, have to spend maintaining the type-checking of that test suite?

Re: Cold Showers

#186

Post by ReactiveJelly »

BlargMcLarg wrote: post #58
slaymaker1907 wrote: post #46

Earlier quoted context omitted.

Considering how many null pointer bugs I've seen, I think that this is a case where absence of evidence is not evidence of absence (at least for null safety).

Almost all of the null pointer errors I've seen came from not fully thinking things through. I can see the same mistakes happening with non-nullable types because someone got lazy and passed a default value or something. You get the benefit of the compiler shouting at you for not initializing a variable, but that won't necessarily protect you from not thinking every situation through / lazily passing default values /…

But the languages that are null-safe all have Option, Optional or Maybe.

So if I do need a null value, I can make the field optional and the type checker will help me figure it all out.

Re: Cold Showers

#187

Post by lmz »

lostmsu wrote: post #176
makeset wrote: post #94

Earlier quoted context omitted.

With larger data it really depends on the algorithm. If you must iterate over more than a few GB at a time, GPU memory capacity and bus speeds become prohibitive, while a dead-simple implementation on a single CPU with 100+ cores and TBs of RAM goes brrr.

CPU RAM is generally much slower. 8 channels of DDR4-3200 only provide 200GB/s bandwidth. RTX 3090 has 936GB/s. So even 4 socket Xeon won't catch up.

That would only be an advantage if you had to do multiple passes over the data, otherwise the data would still go through the CPU RAM before getting loaded onto the GPU, no?

Re: Cold Showers

#189

Post by MarquesMa »

> Static Typing reduces bugs.

This matches my experience. People say otherwise might need to put more effort on writing better tests.

That said static typing usually catch minor problems like typo faster. But for dynamic typing it's going to catch by tests a bit later. But usually tests run faster with dynamic languages, so it's a tradeoff.

My favorite approach is the mixed approach like TypeScript:

1. Faster feedback loops: Usually statically typed languages compiles slower thus slower feedback loops. But languages like TypeScript can skip type check and emit only to the runtime, making test watcher very fast - as soon as I hitting Cmd-S I can see the result.

2. Optional typing: Sometimes a function signature is going to be 10x larger than the body, which is really a hassle. Sometimes I just skip them, or skip typing module private functions as long as it's properly tested.

Re: Cold Showers

#190

Post by maleldil »

falcolas wrote: post #168
randtrain34 wrote: post #129

Earlier quoted context omitted.

But suppose you were unfamiliar with the code, the 2nd tells you what fields/methods are available for "item", and furthermore most IDEs will use that info to populate autocomplete suggestions and such.

Language engines exist for Python and Ruby (and Lisp, etc.)as well, and they handle autocomplete and refactoring quite handily.

How would a "language engine" know what you can do with `item` if it has no type information?

You can do that with Python (sometimes) because many libraries have type hints today, so even if you don't use types yourself, the type checker can infer them in your code and help you out.

Post reply on HN