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

Diminishing returns of static typing

blog.merovius.de

Post reply on HN
Print view View original

471–480 of 632 posts

Re: Diminishing returns of static typing

#471

Post by naasking »

napsterbr wrote: post #463
dnautics wrote: post #449

Earlier quoted context omitted.

This is basically why erlang's hot code reloading would be impossible as a general solution in a statically typed language

As long as we are here, with experienced programmers of both "sides", here's a question I've been wondering for some time: is it possible to create a haskell-like type system on an erlang-like language? Erlang has dialyzer, which is great but it's based on optimistic typing. Hot-reloading aside, what would be the issue to creating such language? Maybe some issue with the process pids, which are quite dynamic?

There is no issue. Plenty of typed process calculi exist, and concurrent ML existed back in the late 90s and features channels and processes.

Re: Diminishing returns of static typing

#472

Post by xfer »

mpartel wrote: post #423
xfer wrote: post #365

Earlier quoted context omitted.

Rust doesn't have anyway to manage side-effects in types ..

Don't mutable and immutable references with lifetimes count? Sure, one could argue whether the borrow checker is really part of the type system, but it's a compile-time check either way. Yes, in the standard library, an immutable object can hide mutable state in e.g. a 'Mutex', and effects to the external system aren't wired through anything like monads or unique objects. I see those as compromises Rust makes in the…

Right, but you are addressing only part of the story to side-effects. IO is another story, which rust doesn't address.

Re: Diminishing returns of static typing

#473

Post by yawaramin »

19873287234 wrote: post #39
cm2187 wrote: post #3

The benefit of static typing isn't just reliability. Tooling is another major argument. Won't appeal to certain hardcore programmers who think that even notepad has too many features. But it is great for refactoring, finding all references to a function or a property or navigating through the code at design time. Basically all the features visual studio excels at for .net languages. And I disagree with the barrier to…

>Tooling is another major argument. vscode seems to figure out the types in javascript without any static typing. >But it is great for refactoring Searching for strings isn't that much worse. Also, when it comes to web development, you cross into the client-side and suddenly you can't refactor. So you can only refactor the server-side and end up with a mismatch. >finding all references to a function or a property or…

> There are a ridiculous amount of tech companies that have used dynamic languages to go from nothing to the biggest companies in the world and only switched to static languages well and truly after that occurred.

This is a biased sample though. You're saying 'ridiculous number', but the truth is most startups (using static or dynamic languages) fail and we don't actually know if their language choice had much impact on their success or failure.

Re: Diminishing returns of static typing

#474

Post by Cerium »

irrational wrote: post #468
alkonaut wrote: post #265

There are 3 main areas of interest in the discussion of benefits of static vs dynamic typing. - Quality (How many bugs) - Dev time (How fast to develop) - Maintainability (how easy to maintain and adapt for years, by others than the authors) The argument is often that there is no formal evidence for static typing one way or the other. Proponents of dynamic typing often argue that Quality is not demonstrably worse, wh…

10-20 years?! Holy Cow! Other than huge software projects (like Word or Mac OS - and even then...) is there really software that still has that kind of maintenance window? I've worked for a Fortune 150 company for nearly 2 decades. There is not a single piece of software at the company that has not been rewritten from scratch (usually due to business changes) at least once every 10 years. I can't even imagine somethi…

I work in medical robotics and I can tell you that a lot of our code is quite old, and we have a culture that code you write will stay around. Some things don't change for example optimal control algorithms, while others things are very difficult to change such as network routing. So, while the applications get re-written on the 4-10 year time frame parts of the OS are 15+ years old.

Re: Diminishing returns of static typing

#475

Post by hota_mazi »

mpartel wrote: post #427
runT1ME wrote: post #418

Earlier quoted context omitted.

>They seem to have huge potential for hard to follow code as you need to mentally unpack and remember more layers of abstraction That's the beauty of abstraction without side effects, you don't need to unpack anything. If you know what the inputs are and the outputs are, you don't need to know how it works or what type classes are even used to transform certain things. People use sequence all the time in Scala, not r…

Fair point about 'sequence'. There are probably a bunch of these I use regularly in Scala without realizing it. Though as a counterpoint, 'Future.sequence' wouldn't really lose _that_ much if it didn't return a collection of the same type. And I haven't yet felt the need for a generic `sequence`, which I'm sure scalaz has. I don't buy your point about not needing to unpack side-effectless code, however. There are _al…

It's a pretty typical symptom I've seen a lot of hardcore FP developers exhibit: they forget how much time it took them to reach their level of mastery.

It's like spending ten years learning to speak Russian and then criticizing anyone who says that learning Russian is difficult.

Puzzling out scalaz code is difficult and requires an enormous investment in hours and practice, investment that a lot of people prefer to put into different learnings.

Re: Diminishing returns of static typing

#476

Post by yawaramin »

comex wrote: post #459
dozzie wrote: post #422

Earlier quoted context omitted.

> The C compiler picks up on that, too. Except when it's not. Just five days ago I was debugging an error in my Erlang port driver that was caused by me passing receiver (ErlDrvTerm, an int in disguise) in the place where I wanted number of iterations. The funnier thing was that the declaration of the function had the arguments in correct order (and that's what guided me), but definition had them swapped. The compile…

That’s why people should use one-element structs instead of typedefs for that kind of use case. A struct is a distinct type that can’t be accidentally mixed up with random integers, but its memory representation and efficiency will generally be identical; and you can add one-liner conversion functions to minimize syntactic overhead when you do need to convert to/from raw integers. Same idea as ‘newtype’ in Haskell; i…

In fact, make the structs opaque so that you retain full control over the data and its invariants.

Re: Diminishing returns of static typing

#477

Post by cpitman »

irrational wrote: post #468
alkonaut wrote: post #265

There are 3 main areas of interest in the discussion of benefits of static vs dynamic typing. - Quality (How many bugs) - Dev time (How fast to develop) - Maintainability (how easy to maintain and adapt for years, by others than the authors) The argument is often that there is no formal evidence for static typing one way or the other. Proponents of dynamic typing often argue that Quality is not demonstrably worse, wh…

10-20 years?! Holy Cow! Other than huge software projects (like Word or Mac OS - and even then...) is there really software that still has that kind of maintenance window? I've worked for a Fortune 150 company for nearly 2 decades. There is not a single piece of software at the company that has not been rewritten from scratch (usually due to business changes) at least once every 10 years. I can't even imagine somethi…

I also consult for Fortune 500 companies on a regular basis, and most of them still have core business processes running on mainframe code bases well older than 10 years. No one is doing major greenfield development on mainframes, but they still exist all over the place.

Re: Diminishing returns of static typing

#478

Post by naasking »

tom_mellior wrote: post #329
naasking wrote: post #181

Earlier quoted context omitted.

Assembly is typed. The types are machine words and usually floating point types are also available. Basically, the machine types are the types of data that the register files can hold.

That's not a useful notion of type. If I cannot tell statically by inspecting a register name nor dynamically by inspecting a bit pattern whether a given register holds a pointer or an integer or a floating-point value, that's pretty much the definition of "untyped".

Dynamic type testing or introspection is not an essential feature of type systems. The fact is, your computing machine is typed. You can not deference a floating point register as an address, for instance.

Re: Diminishing returns of static typing

#479

Post by solidsnack9000 »

s17n wrote: post #409
zbobet2012 wrote: post #281

Earlier quoted context omitted.

It depends on your type system. In new languages like Idris or F* you can encode in the type the correctness of an algorithm and it will not compile if the compiler can not prove that correctness. For example I can prove my my string reverse works in Idris ( https://www.stackbuilders.com/news/reverse-reverse-theorem-p... ). Or I could prove that my function squares all elements in a list. Etc. Now a big part of the p…

There's no such thing as "proving correctness". You can have bugs in the type definitions. You can have bugs in the english (or whatever your native language is) description of what you think the algorithm should be doing. You can prove a program does what the types say it should do but that is not what "correctness" means. >Now a big part of the problem is expressing with sufficient accuracy what the properties of t…

> There's no such thing as "proving correctness".

Given the caveats you mention, is there such thing as proving anything?

Re: Diminishing returns of static typing

#480

Post by naasking »

s17n wrote: post #409
zbobet2012 wrote: post #281

Earlier quoted context omitted.

It depends on your type system. In new languages like Idris or F* you can encode in the type the correctness of an algorithm and it will not compile if the compiler can not prove that correctness. For example I can prove my my string reverse works in Idris ( https://www.stackbuilders.com/news/reverse-reverse-theorem-p... ). Or I could prove that my function squares all elements in a list. Etc. Now a big part of the p…

There's no such thing as "proving correctness". You can have bugs in the type definitions. You can have bugs in the english (or whatever your native language is) description of what you think the algorithm should be doing. You can prove a program does what the types say it should do but that is not what "correctness" means. >Now a big part of the problem is expressing with sufficient accuracy what the properties of t…

> This is no different from writing tests in a dynamic language.

Types and tests are not equivalent. This is a prevalent myth among dynamic typing enthusiasts. There is no unit test that can ensure, eg. race and deadlock freedom, but there are type systems that can do so. There are many such properties, and tests can't help you there.

Types verify stronger properties than tests will ever be able to, full stop. You don't always need the stronger properties of types, except when you do.

Post reply on HN