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

Why static languages suffer from complexity

hirrolot.github.io

Post reply on HN
Print view View original

121–130 of 306 posts

Re: Why static languages suffer from complexity

#121

Post by Verdex »

DonaldPShimoda wrote: post #109
Animats wrote: post #100

Fascination with type systems does not seem to be all that useful in practice. Go has a minimal type system, and is able to do much of Google's internal server side work. Most of the problems that cause non-trivial bugs come from invariant violations. At point A, there's some assumption, and way over there at point B, that assumption is violated. That's an invariant violation. Type systems prevent some invariant viol…

> Fascination with type systems does not seem to be all that useful in practice. > ... > The Rust borrow checker is an invariant enforcer. [...] This is real progress in programming language design, and is Rust's main contribution. I'm so confused by your stance here. You essentially say "type systems are not useful" and then "oh but this most recent advance in type systems — that one is useful." Do you find type sys…

I think the key is the following:

> It explicitly does automatic global analysis

They appear to think that the borrow checker isn't achieved with type theory, but with some other technique ("global analysis").

Although, to be fair, my understanding of making a practical affine type checker is that things get kind of wonky if you do it purely logically. So practically you do some data flow analysis. Which is, I believe, what rust is doing. This also explains why MIR was such a big deal for certain issues with borrow checking. They ended up with a format that was easier to run a data flow analysis on, and that allowed the borrow checker to handle things like non-lexical lifetimes, etc.

[I've only read about such things. So I might have mis-remembered some of the details. However, this is my take on why someone might not call rust's advances purely type theoretic (even if they can be handwaved as type theory at a high level).]

Re: Why static languages suffer from complexity

#122

Post by throw10920 »

armchairhacker wrote: post #54

"Why not add X feature? If people don't want to use X, they just don't, and there are basically 0 downsides." In theory this is true. If the compiler is decent, compile times and analysis shouldn't really be affected. Maybe libraries will use X but otherwise they would use a manual implementation of X anyways. But in practice developers misuse features, so adding a feature actually leads to worse code. It also create…

> But in practice developers misuse features, so adding a feature actually leads to worse code.

Is that really a problem on the language's side, though? Devs are capable of mis-using any feature, even extremely basic ones that almost every language has (variable names, for instance (although I'm laughing in FORTH)). Code standards and code reviews are necessary tools in the first place because it doesn't matter what language you give a programmer - they're perfectly capable of constructing a monstrosity in it.

I argue that preventing programmers from doing dumb things with well-designed language features (so, hygenic Scheme macros, and not raw C pointers) is a social and/or organizational problem, and it's better to solve that at that level than to try to solve it (inadequately) at a technical level.

("I keep dereferencing null pointers", on the other hand, is an example of a technical problem that can be solved on the technical level with better language design)

Re: Why static languages suffer from complexity

#123

Post by goldsteinq »

chriswarbo wrote: post #77

I think the comparison between printf in Idris and Zig is a little off, since the Idris version defines an intermediate datastructure, and hence requires extra parsing and interpreting functions for it. That's a nice approach, but the Zig version is operating directly on characters, so it's a bit apples-to-oranges. We can get a more direct Idris implementation by inlining the parser (toFmt) into the interpreter (Prin…

Except this version doesn’t compile. I’m not sure that it’s possible to get it to compile: type-level Idris is actually a _subset_ of Idris and pattern-matching non-ADTs is half-broken on the type level. You can also observe this problem in this simplified example:

    f : Char -> Type
    f '0' = Int
    f _ = Char

    g : (c : Char) -> (f c)
    g '0' = 0
    g c = c

Re: Why static languages suffer from complexity

#124

Post by yakshaving_jgt »

Jtsummers wrote: post #118
yakshaving_jgt wrote: post #108

Earlier quoted context omitted.

The Haskell-y way to do this is to use a smart constructor[0]. [0]: https://wiki.haskell.org/Smart_constructors

The first part of that page demonstrates what amounts to pre/post conditions, but placed in the constructor. The range is checked dynamically, not statically. The second part is using Peano numbers to enforce the constraint. I guess you could try and force that into some mainstream languages, probably C++. With its template programming you could get something going in this vein, though I'm not sure how well it would…

The way that the value floats through the system is checked statically, and the program can (and should) be designed so that the value with the appropriate type cannot be constructed unsafely.

If you need to statically check the construction of values in Haskell, there are things like refinement types[0].

[0]: http://nikita-volkov.github.io/refined/

Re: Why static languages suffer from complexity

#125

Post by Hirrolot »

tempodox wrote: post #95

This article spends many words to say, “there is no silver bullet”. But dynamically typed languages produce at least the same amount of accidental complexity, just in different ways.

> This article spends many words to say, “there is no silver bullet”.

Rather "I believe there is a silver bullet, but I don't know where yet". Probably I am too naive!

Re: Why static languages suffer from complexity

#126

Post by yakshaving_jgt »

vanusa wrote: post #117
yakshaving_jgt wrote: post #112

Earlier quoted context omitted.

> I just don't buy the suggestion that static typing magically solves a huge set of problems // compiles and runs, but does bad things function foo(x, y) { someDangerousEffect(); return x + y; } -- does not compile; huge sets of problems magically solved foo :: Int -> Int -> Int foo x y = someDangerousEffect >> pure $ x + y

A problem but not a huge one in practice. And you're neglecting the part of my statement you conveniently truncated.

> not a huge one in practice.

Our experiences have been wildly different :)

Re: Why static languages suffer from complexity

#127

Post by lowbloodsugar »

"We might want to zip our car with their car..."

We do or we don't. There is no "might". Spending money on "might" has been the death of many projects.

If we didn't, and now we do, we could write a fn to map the car to parts, or we could define the car struct in terms of its parts, or we could just do away with the car altogether.

But far more valuable would be an analysis of what changed about the requirements that the model no longer works.

Now, don't get me wrong: I'd love a better language, and by better I mean "as fast as assembly but 'dynamic'". The problem is that, at the end of the day, all compilers are just "premature optimizations" or perhaps "willing premature optimizations". We could all be happily programming in smalltalk or build a runtime using predicate logic, but a) the number of people who could program in it is vanishingly small and b) it would be fucking slow. These languages don't solve a problem that I have, or rather they don't solve a problem that I don't already have a far better solution for. They solve a problem that academics have.

Re: Why static languages suffer from complexity

#128

Post by acchow »

Zababa wrote: post #113
Animats wrote: post #100

Fascination with type systems does not seem to be all that useful in practice. Go has a minimal type system, and is able to do much of Google's internal server side work. Most of the problems that cause non-trivial bugs come from invariant violations. At point A, there's some assumption, and way over there at point B, that assumption is violated. That's an invariant violation. Type systems prevent some invariant viol…

> Go has a minimal type system, and is able to do much of Google's internal server side work. Isn't it stil mostly Java and C++? That's what I hear all the time here. Also, I'm not sure what point you're trying to make. You start by saying that fascination with types systems is not useful in practice, and end with an example where it is useful (Rust). While Go can stick a GC to avoid most of the issues that Rust is t…

> Isn't it stil mostly Java and C++? That's what I hear all the time here.

Go's type system is much weaker and less expressive than either Java's or C++'s. C++ in particular has parametric polymorphism, type constructors, and dependent types. Go has none of those.

Re: Why static languages suffer from complexity

#129

Post by Hirrolot »

gumby wrote: post #12
preseinger wrote: post #9

> I cannot imagine a single language without the if operator, but only a few PLs accommodate full-fledged trait bounds, not to mention pattern matching. This is inconsistency . . . How? > Sometimes, software engineers find their languages too primitive to express their ideas even in dynamic code. But they do not give up . . . Is this a failure of the language, or a failure of the engineer? > If we make our languages…

> > I cannot imagine a single language without the if operator… Production languages (like prolog or make) don’t need an if statement or operator as selection is implicit when a production matches.

Nice point, didn't know about that. My fail.

Re: Why static languages suffer from complexity

#130

Post by skybrian »

Zababa wrote: post #113
Animats wrote: post #100

Fascination with type systems does not seem to be all that useful in practice. Go has a minimal type system, and is able to do much of Google's internal server side work. Most of the problems that cause non-trivial bugs come from invariant violations. At point A, there's some assumption, and way over there at point B, that assumption is violated. That's an invariant violation. Type systems prevent some invariant viol…

> Go has a minimal type system, and is able to do much of Google's internal server side work. Isn't it stil mostly Java and C++? That's what I hear all the time here. Also, I'm not sure what point you're trying to make. You start by saying that fascination with types systems is not useful in practice, and end with an example where it is useful (Rust). While Go can stick a GC to avoid most of the issues that Rust is t…

It's been a while since I worked there, but the trend at Google at the time was that the amount of code written in each popular language was rapidly growing, and the number of popular languages was also slowly growing. (Despite a lot of resistance to introducing new languages.)

I'm out of touch, but I would expect that there is a lot more Go code by now, and it also didn't catch up with C++ or Java.

Post reply on HN