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

451–460 of 632 posts

Re: Diminishing returns of static typing

#451

Post by fineline »

coding123 wrote: post #276

I'm converting a codebase of Javascript of about 200+ js files to Typescript today. I am about 5% complete... already found two places where the argument list was wrong and was being sent into a void. I also see the code that was making up for the fact that the third argument was being ignored (basically patching downstream because they thought the feature was broken). Now this codebase was written with a high degree…

Promises (representing the result of a single asynchronous operation) and Observables (representing an ongoing stream of emitted values) aren't really equivalent. I know you can create an Observable from a Promise, which will emit a single value when that promise is fulfilled and then be marked as completed or closed - but this is more for integration - such as being able to combine inputs from single-shot async calls into broader observable operations. If your Promises are discrete async calls, I'm curious why you would want to convert them?

Re: Diminishing returns of static typing

#452

Post by zzbzq »

oldandtired wrote: post #429

It has been interesting to see the to and froing of arguments for and against static typing in the discussions here. Though I am not a type theorist (I only dabble in compilers and language design), I have noted that many people conflate static typing and dynamic typing with other additional ideas. Static typing has certain benefits but also has certain disadvantages, dynamic typing has certain benefits but also has…

Maybe part of the problem is I can't picture what you're actually talking about with soft typing. I can tell you C#/.NET has the DLR which allows you to do dynamic types whenever you want. Outside of a few gimmicks, you rarely see these used. I've rarely even seen them for quick prototyping, because generally you mess around with using them for prototying, then the first time they go bad, it's really obnoxious, and you realize you're compiling the code and writing function signatures anyway, might as well save the time later and do it right the first time.

Then there's the whole tooling aspect of trying to mix type systems. It's different lifestyles. Dynamic programmers aren't going to start compiling their code to run it, static programmers aren't going to switch to a language with weaker tooling around the IDE-ish features, which are mostly built on the type system.

My conclusion is this: New languages should all be statically typed, because we shouldn't need new languages at all. We should be fine. The reason we need new languages at all, is because the trifecta of C++/Java/C# basically encompassed the entire statically typed world, but they're all infected with this fully overblown OOP obsession, and the null pointer bug--which newer languages have fixed, through more static typing. Basically we need to replace those languages with similar ones and then just stop making languages for a few decades, until whatever we're doing now looks as dumb as OOP and null pointers. In the long run, Go/Swift/Kotlin/Rust will take over the statically typed world and it's going to be great.

Re: Diminishing returns of static typing

#453

Post by comex »

flukus wrote: post #426
mikeash wrote: post #405

Earlier quoted context omitted.

It's not just that void * exists, but that it's basically mandatory. C's built-in arrays are super weak, so you need some library to do proper resizable arrays. Since C doesn't have generics, such a library will use void * as the type for putting values into the array and getting them back out again. You'll be casting at every point of use, and nothing will check to make sure you got the cast right, other than runnin…

> C's built-in arrays are super weak, so you need some library to do proper resizable arrays. Since C doesn't have generics, such a library will use void * as the type for putting values into the array and getting them back out again. You'll be casting at every point of use, and nothing will check to make sure you got the cast right, other than running the code and crashing. There are other options though like macros…

I don't know why macro-based containers aren't more popular. You can have a quite usable interface, and even the implementation isn't that ugly. Example:

http://attractivechaos.github.io/klib/#Khash%3A%20generic%20...

This approach isn't just more strongly typed than using void * for everything, it's also typically more efficient. For an array, you can put larger structs directly in the array rather than being forced to use a pointer. For a hash table, the same applies, plus you can avoid expensive indirect calls to compute hashes. (There are alternative non-macro approaches that trade off that overhead for other types of overhead, but you can't do as well as with a specialized container.)

I guess you could ask, at that point why not just use C++? And a lot of people do, and the people left writing new C programs are often traditionalists who don't want to switch to new approaches. And to be fair, there are disadvantages to macro-based containers, like increasing build time. But I still think there's room for them to see more adoption.

Re: Diminishing returns of static typing

#454

Post by eloff »

dnautics wrote: post #450
eloff wrote: post #448

Earlier quoted context omitted.

Seriously with the downvotes? Dynamic languages are obviously slower than static languages in general. Some special cases aside. Performance is a concern for some projects - you wouldn't write an OS, database kernel, or mainstream game engine in a dynamic language. How is that not a valid concern in the dynamic vs static typing argument? The parent comment has a legitimate point.

Technically, this is a strong/weak type distinction. Dynamic but strongly typed languages like Julia and erlang can be quite performant when given strong fences around the types their functions are passed.

No. Not at all. It has more to do with implementations.

Python is strongly typed, but dynamic. But slow. JavaScript and PHP are weakly typed and dynamic as they will coerce types in strange ways during operations and comparisons.

Lua is dynamically and strongly typed like Python, but LuaJIT can sometimes produce code on par with or even slightly faster than native code - because it's really JIT compiling the hot path to native code with some guards and offramps to interpreted code for special/unexpected cases.

But there are limits to those techniques and it's doubtful that dynamic languages will ever perform at the same level as static languages because the compiler simply has more information and doesn't have to be as pessimistic or insert as many runtime guards.

Re: Diminishing returns of static typing

#455

Post by sampo »

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…

> you can't make good experiments with those time frames

Multi-decadal longitudinal studies are not too uncommon in medicine, epidemiology and psychology. Why there is no will to conduct, or fund, this kind of research in computer science, I am not sure.

https://en.wikipedia.org/wiki/Longitudinal_study

Re: Diminishing returns of static typing

#456

Post by zzbzq »

ruskimalooski wrote: post #14

These graphs really mean nothing. There is no data behind them. I might as well make a graph that conveys a non-descript correlation between how much an article bashes static typing & assertion and how high it is on HN.

Think again--since when do graphs depict only cold, dry data? Graphs have always been useful for depicting relationships--real or proposed. Line graphs in particular are often found depicting proposed relationships rather than real data (though often inferred from data,) since for all cases where the real data is discrete, this would result in a scatter plot rather than a line.

Re: Diminishing returns of static typing

#457

Post by nhumrich »

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.

Re: Diminishing returns of static typing

#458

Post by dnautics »

eloff wrote: post #454
dnautics wrote: post #450

Earlier quoted context omitted.

Technically, this is a strong/weak type distinction. Dynamic but strongly typed languages like Julia and erlang can be quite performant when given strong fences around the types their functions are passed.

No. Not at all. It has more to do with implementations. Python is strongly typed, but dynamic. But slow. JavaScript and PHP are weakly typed and dynamic as they will coerce types in strange ways during operations and comparisons. Lua is dynamically and strongly typed like Python, but LuaJIT can sometimes produce code on par with or even slightly faster than native code - because it's really JIT compiling the hot path…

> it's doubtful that dynamic languages will ever perform at the same level as static language

I think these timing benchmarks come after the jit warmup procedure, so the presumption is that the compilation cost is amortized over lots of runs in an HPC-type setting:

https://julialang.org/#high-performance-jit-compiler

Re: Diminishing returns of static typing

#459

Post by comex »

dozzie wrote: post #422
Sir_Cmpwn wrote: post #268

Earlier quoted context omitted.

I don't really the lumping of C in with Python and Ruby here. The C compiler picks up on that, too. All over this comment section people are calling C weakly typed, I don't get it. Is it because void* exists? Every language has something like that.

> 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; it works pretty much just as well in C, at least for ‘ID number’ sorts of types where you’re usually just shuttling values from place to place rather than doing any arithmetic. (For types where you do need arithmetic, it gets pretty ugly in languages without operator overloading. Except Go, which doesn’t have operator overloading but does have builtin support for defining distinct versions of integer types.)

Re: Diminishing returns of static typing

#460

Post by kobeya »

dnautics wrote: post #449
gitgud wrote: post #415

Earlier quoted context omitted.

These are good points, but what about considering replaceability as an alternative to maintainability? I personally find dynamic languages allow for easy replacability, as there's less explicit references of types. However this is highly dependent on the system being somewhat modular I suppose.

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

You mean like this:

http://hackage.haskell.org/package/hotswap

Or this:

http://hackage.haskell.org/package/dyre

Post reply on HN