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

511–520 of 632 posts

Re: Diminishing returns of static typing

#511

Post by klibertp »

catnaroek wrote: post #487
hwayne wrote: post #96

Earlier quoted context omitted.

> The developer is encouraged to think of the invariants before trying to prove that their implementation satisfies them. This approach to software development asks the programmer to consider side-effects, error cases, and data transformations before committing to writing an implementation. Writing the implementation proves the invariant if the program type checks. I really wish more languages took this to the logica…

Contracts are useless. They merely describe what you want your code to be, not what your code actually is. Just grab a pen and a piece of paper, and start proving things about your programs.

> Contracts are useless.

No, they are not.

1. If the code doesn't conform to the contract, it will fail on the contract boundary, with a well-defined error. If this is useless, then `assert` is also useless, which it is, of course, not.

2. With a sufficiently well-designed language and sufficiently smart compiler, you can move some contract checks to compile-time. See Racket.

3. If your language supports both static and dynamic typing, the contracts are a dual of static types, which lets you interface the static and dynamic parts of the code seamlessly and automatically (in both directions). Again, see Racket.

Meta: I wonder, why it's mostly static-typing proponents who aggressively evangelize, insult the other side, are 110% sure they're right even though there is no scientific evidence and so on. Could it be the bondage&discipline approach of static typing just appeals to people with a certain mindset, who are statistically more probable to engage in such behaviors, no matter the subject?

Re: Diminishing returns of static typing

#512

Post by blub »

flavio81 wrote: post #346
Tade0 wrote: post #305

Earlier quoted context omitted.

Do you believe that this is plausible?

I think this has happened for a long time. First (70s), features from Algol-68, like structured programming or better flexibility for data types, were ported to other languages. Then (80s-present), the features from Smalltalk and Lisp started slowly to be ported to other languages, many times in an incomplete or unelegant way. We're still doing this, for example the last production spec of the Java language finally i…

You managed to pick the two things where Rust is actually not improving on C++, because it's both more annoying and less usable compared to C++.

There's a reason the expression "fighting the borrow checker" was coined.

You're confusing your own biases and preferences for facts.

Re: Diminishing returns of static typing

#513

Post by willtim »

mpartel wrote: post #417
willtim wrote: post #363

Earlier quoted context omitted.

As a counterexample, C# needed expensive language extensions to accommodate both LINQ and Async/await. Both can be implemented in Haskell purely as a library, thanks to HKTs. Both Java and C# tend to rely heavily on frameworks such as Spring to workaround issues with the expressivity of the languages. This causes problems when one needs two frameworks (they don't in general compose). In Haskell, HKTs allow one to wri…

Not sure about LINQ, I thought that was "just" syntactic sugar for a bunch of collection methods. Are you refering to extension methods as an unfortunate prerequisite? But I think I get your general point: things like 'Control.Concurrent.Async' ('async'/'await') and 'Control.Monad.Coroutine' ('yield') are libraries that implement some and very generic type classes: 'Functor', 'Applicative', 'Monad'. This then lets yo…

Just like async/await, LINQ (and even enumerators) are tied to special syntax in the C# language. HKTs allow Haskell to provide very general resuable syntax, such as do notation.

What I meant by "polymorphic programs" as an alternate to DI, is something like this:

doStuff :: HasLogger m => Input -> m Output

The effectful function "doStuff" above is polymorphic with respect to which logging implementation is used, it could even be one that uses IO. All made possible with HKTs.

Re: Diminishing returns of static typing

#514

Post by z3t4 »

While the made up graphs might help understanding his reasoning, I think it's way too abstract/philosophical. It's like walking into a dark room making assumptions and arguments based on your belief of what color the walls are.

Re: Diminishing returns of static typing

#515

Post by miclill »

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…

I would add fun.

I know "fun" is highly subjective but still important none the less.

Re: Diminishing returns of static typing

#516

Post by willtim »

hota_mazi wrote: post #475
mpartel wrote: post #427

Earlier quoted context omitted.

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…

Mainstream developers forget just how much time they invest in learning the latest fad frameworks with new ad-hoc concepts and terminology. I guess "Hardcore FP developers" are fed up with this state of affairs and are looking towards mathematics to provide guidance and common patterns/names. At least any knowledge of mathematics will not become outdated!

Re: Diminishing returns of static typing

#517

Post by willtim »

AndrewBissell wrote: post #408
willtim wrote: post #363

Earlier quoted context omitted.

As a counterexample, C# needed expensive language extensions to accommodate both LINQ and Async/await. Both can be implemented in Haskell purely as a library, thanks to HKTs. Both Java and C# tend to rely heavily on frameworks such as Spring to workaround issues with the expressivity of the languages. This causes problems when one needs two frameworks (they don't in general compose). In Haskell, HKTs allow one to wri…

I'm not sure what Java expressivity problem Spring is meant to solve. XML configs are basically just a duplication of what would be done in a static initializer, except you lose type-checking and get to find your wiring mistakes at startup time instead of compile time. Autowiring annotations can be nice when you first use them, but become inscrutable magic once some other poor sap has to come along and make changes t…

I guess passing parameters down manually through all the constructors gets too painful. The language is not expressive enough for a Reader monad! :)

Java's static initialiser blocks are too dangerous whenever one has threads.

Re: Diminishing returns of static typing

#518

Post by aoloe »

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…

Wordpress is 14 years old.

It's probably a good reference project, when talking about maintenance (nightmares).

Re: Diminishing returns of static typing

#519

Post by wiz21c »

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…

I wonder how older you are than the average javascript crowd :-)

Another little thing is (from my own point of view) is that many application don't live in a vacuum : they use json schema, or WSDL; and database with types and constraints. So what the language does not "type", the context does.

Re: Diminishing returns of static typing

#520

Post by z3t4 »

flavio81 wrote: post #323
Tade0 wrote: post #302

Earlier quoted context omitted.

>Not to mention the paradigm of meta-programming and DSLs, something that is usually new to programmers foreign to Lisp. Is it really? What about templates(as in C++ templates), macros, CSS and HTML? These are two examples of metaprogramming and two DSLs respectively. > However, languages like Clojure and Smalltalk can be rather easy to learn, and they are fairly powerful. It's not like I don't believe you, but if th…

>Is it really? What about templates(as in C++ templates), macros, CSS and HTML? "Lisp macros" go far, far beyond "C macros" ("preprocessor macros", and indeed go far beyond what you can do with C++ templates. You should take a look, but basically, explained in a few words: In Lisp, code is data. Code is a first-class citizen. The functions and constructs that are there to manipulate data, also manipulate source code…

JavaScript was very nice before ES6. All ES6 did was to add syntax sugar/meta. var in JavaScript belongs to the function it is declared in. ES6 made the language way more complicated, and divided the community up into more dialects. The plan was to unite compile-to-JavaScript communities like CoffeeScript, but that didn't work because there's more compile-to-JavaScript languages now then it ever has been.
Post reply on HN