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

621–630 of 632 posts

Re: Diminishing returns of static typing

#621

Post by cpitman »

huhlig wrote: post #610
cpitman wrote: post #477

Earlier quoted context omitted.

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.

I think IBM and their Z division would disagree. IBM Z Users: The 10 top insurers, 44 of the top 50 banks, 18 of the top 25 retailers, 90% of the largest airlines

That seems to agree with me? Mainframes are still in use everywhere. However, that statistic doesn't imply that those customers build their brand new greenfield capabilities on those mainframes.

Re: Diminishing returns of static typing

#622

Post by jamaicahest »

zmmmmm wrote: post #419
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…

> For any code base that isn't a throwaway like a one-off script or similar, say 10 or 20 years maintenance I think one of our problems is that people have downgraded the importance of this. Much code nowadays (rightly or wrongly) is considered "disposable" - people think that the likelihood of any given piece of code they are writing as surviving more than a few years is negligible. It is a natural assumption when y…

>I think one of our problems is that people have downgraded the importance of this. Much code nowadays (rightly or wrongly) is considered "disposable" - people think that the likelihood of any given piece of code they are writing as surviving more than a few years is negligible.

I think younger devs think this. Once you get a decade or more experience, you grow wiser and realise that code never dies, and especially the code you wish would die is particularly tenacious. And this is pure speculation, but I would wager that the number of lines of legacy code that is kept alive with maintenance is much greater than the number of lines of code that gets abandoned/rewritten/obsoleted.

Re: Diminishing returns of static typing

#623

Post by vorg »

zmmmmm wrote: post #618
vorg wrote: post #587

Earlier quoted context omitted.

Static typing was grafted onto Apache Groovy in 2012, but no-one really uses it. I'm not sure about its reliability -- its use never took off on the Android platform, and none of the Groovy codebase itself has ever been rewritten in static Groovy. Groovy's still great for scripting on the JVM though, for stuff like those 10-liner build scripts for Gradle, glue code, and mock testing. Just don't use Groovy for buildin…

> Static typing ... no-one really uses it. I'm not sure about its reliability -- its use never took off on the Android platform, and none of the Groovy codebase itself has ever been rewritten in static Groovy You keep saying this repeatedly but it just isn't true: https://github.com/grails/grails-core/blob/master/grails-cor... https://github.com/groovy/groovy-core/blob/master/src/main/g...

Both your examples use very simple logic. The Apache Groovy codebase example is of some peripheral functionality, i.e. a builder. All the methods in your Grails codebase example are, at most, 1 line long. I can't be bothered re-investigating what proportion of the core Groovy codebase really uses static compilation -- it certainly wasn't much only 2 years ago. As for Grails, virtually no-one has upgraded from v.2 to Grails 3 since it was released 2.5 yrs ago, or started many new projects with it.

Re: Diminishing returns of static typing

#624

Post by pkd »

kazinator wrote: post #589
pkd wrote: post #296

Earlier quoted context omitted.

There is a programming language property called Restrictability - it means that you only need to know a subset of the features the language provides to become productive. The best languages have high restrictability without compromising on the high level features like powerful macros. The point of having macros is that they allow you to solve problems that cannot be solved elegantly in any other way. But 95% of progr…

> it means that you only need to know a subset of the features the language provides to become productive. That only works when you work by yourself (or in a small team to whom you can dictate the language subset), and without any third party code. > But 95% of programmers don't need to solve such problems and can do very well without using macros. Languages that have great macro systems use them to bootstrap themsel…

Sure, you can use them as a consumer all the time, but that doesn't mean that you need to write your own to program in Lisps, for instance. For the few that do need it, it's a worthy tool to have.

Re: Diminishing returns of static typing

#625

Post by lisper »

seanwilson wrote: post #594
lisper wrote: post #578

Earlier quoted context omitted.

> Languages like Coq require you to prove a function halts before it will compile. Well, that's incredibly stupid. That means you can't write, for example, a web server in Coq unless you intentionally introduce undesirable behavior to satisfy the compiler. > because you can't prove all functions halt it's a waste of time proving any functions halt No. That's obviously a straw man. Can you please consider the possibil…

> Well, that's incredibly stupid. That means you can't write, for example, a web server in Coq unless you intentionally introduce undesirable behavior to satisfy the compiler. There's ways around it (e.g. proving progress is always going to be made instead of termination) and there's a web server in Coq: http://coq-blog.clarus.me/pluto-a-first-concurrent-web-serve... > 2. There are properties of interest that cannot…

> Why do you think it would be common properties of interest wouldn't be provable?

Because proving all common properties of interest is tantamount to proving all interesting mathematical theorems.

> Do you think mathematicians have this issue

Yes, obviously. If they didn't they wouldn't have jobs.

> it can be very challenging currently

Yes indeed, and that is exactly my point. Humans just keep finding new and more complicated things to care about. Math doesn't converge.

Re: Diminishing returns of static typing

#626

Post by tormeh »

nhumrich wrote: post #457
willtim wrote: post #101

Our industry has not yet even scratched the surface of what types can offer: Types for enforcing architectures and controlling effects, types for checking correct use/free of scarce resources, types for verifying protocol implementations etc etc. Currently, half the industry is using schema-less json and dynamic languages; so really it is far too early to generally talk about any diminishing returns.

Its so funny how people argue for types everywhere, then use nosql databases and lack type checking on data validation.

I used to agree, but after seeing how easily versioning of schemas, procedures etc in conventional databases can turn into a clusterfuck I have changed my mind. I have begun to like the idea of putting all the schema info into compiled applications that can't easily be changed on the server. MySQL et al is the worst of all worlds.

Re: Diminishing returns of static typing

#627

Post by naasking »

tom_mellior wrote: post #611
naasking wrote: post #607

Earlier quoted context omitted.

I'm not sure who you're quoting, but I never even used the word "architecture". I don't even know what that's supposed to mean.

You try to explain CPU architecture to me, then claim you don't know what CPU architecture is? OK, maybe you don't win, in any case I'll stop here.

"Architectural reasons" is nonsense. "Architecture" isn't a set of reasons justifying anything, rather it's the other way around: we design architecture for specific reasons. Your claims that we do things for "architectural reasons" don't have any clear meaning. I said the actual reasons are performance. I don't think I'm the one being unclear.

Re: Diminishing returns of static typing

#628

Post by crdoconnor »

macspoofing wrote: post #617
crdoconnor wrote: post #547

Earlier quoted context omitted.

>No. I mean when the codebase is of a certain size, new features require some thought and planning. Features may span multiple-modules. They may require partial or full rewrites or the refactoring of any number of sub-components to support the new behaviour. This means that you proceed carefully because you may not want to introduce regression bugs. This costs time. Yes. And all equally true for statically typed lang…

>Yes. And all equally true for statically typed languages. >Refactoring without tests is easier in a statically typed language, but still stupid. If you assume a decent body of tests, the benefit dissipates quickly. We're not arguing whether dynamic language+extensive integration/unit test is better than static typing and no tests. >And, if your design is solid ... Yes, if you have a very solid architecture, strict c…

>We're not arguing whether dynamic language+extensive integration/unit test is better than static typing and no tests.

I am, because that's the way I'd work in any language, because I'm not a hack.

>Yes, if you have a very solid architecture, strict coding guidelines, extensive integration and unit test coverage, experienced developers (etc. etc. etc.) you will mitigate a lot of problems with dynamic typing.

Eliminate.

>A similar argument is made to me when I assert JavaScript is a terrible language.

No, javascript is different. The weird and fucked up implicit type conversions render even a high level of testing insufficient to achieve a high level of confidence in the code. There's way too many edge case behaviors where it should be throwing exceptions and it does something weird instead. C suffers from this problem too despite being statically typed.

Re: Diminishing returns of static typing

#629

Post by jon49 »

Languages like F# give a nice sweet spot between static typing and dynamic typing. It has Type Providers that "generate" code on the fly as you are typing. You don't need to specify all the types, it will infer many types for you. So, you almost feel like you are writing in a dynamic language but you it tells you if you are writing something incorrectly.

I would not consider a language to be modern unless it has Type Providers I consider this to be such an essential feature. I believe Idris and F# are the only languages that have it. People are trying to push TypeScript to add it - who knows if it will happen.

Many are saying that if you have a dynamic language you just need to be disciplined and write many tests. With good static typed languages like F# you can't even write tests on certain business logic since the way you write your code you make "impossible states impossible", see https://www.youtube.com/watch?v=IcgmSRJHu_8

Re: Diminishing returns of static typing

#630

Post by lomnakkus »

kazinator wrote: post #609
lomnakkus wrote: post #595

Earlier quoted context omitted.

This really sounds like "semantics" to me (not PL semantics! :). For example, these days it's quite possible to ask GHC to defer type errors to runtime. Does that mean that the GHC dialect of Haskell is dynamically typed? This is basically a command line switch away, btw. Retention of type information does not "dynamic typing" make. As a trivial example, consider C++ RTTI. You really have just reinvented static (type…

C++ RTTI is only for class objects, and only useful when they are manipulated by pointer or reference. I believe I covered that sort of thing with my statement, "Some static languages support OOP, and so stuff some minimal type info into objects for dispatch." . It's a gadget which provides an alternative to the structure of doing everything via virtual functions on a base class reference.

Ok, fair enough, but what about e.g. "-defer-type-errors" for GHC?

I still think you're just arguing semantics.

EDIT: Incidentally, the statically typed crowd can even go the "other way", namely from runtime -> compile time. For example, it's quite possible to derive a static proof/type from a runtime value in e.g. Idris by pattern matching as long as you're meticulous about building up the proof.

Post reply on HN