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

161–170 of 306 posts

Re: Why static languages suffer from complexity

#161

Post by pas »

tus666 wrote: post #39
pas wrote: post #28

Earlier quoted context omitted.

In TS JSON is usually Record .

Well unknown is not a type (by definition), so you have just stepped outside of a type system, which is very common in TS if I understand.

Unknown is a top type in the TS type system. It serves the very important role of "here you need to apply some pattern matching and validation" and then you can make sure that you can continue working in a type safe environment. TS has a lot of facilities that help you with this (from the usual narrowing things, typeof and instanceof guards, control flow analysis, and at the end of the list there are the big guns like this thing called type predicates which basically allows you to wrap these checks and "casts" in nice reusable functions).

There are also recursive types that help you model JSON, but knowing that it's an arbitrary deep nested map/list of maps/lists and number and bool and string mixed like a Bloody Mary cocktail doesn't really help :)

With NestJS it's very easy to add decorators/annotations to fields of a class, and the framework handles validation (throws HTTP 422 with nice descriptions of what failed) and then in your controller you can again work in a type safe environment.

https://www.typescriptlang.org/docs/handbook/release-notes/t...

https://www.typescriptlang.org/docs/handbook/2/narrowing.htm...

Re: Why static languages suffer from complexity

#162

Post by convolvatron »

preseinger wrote: post #151
pdpi wrote: post #40

Earlier quoted context omitted.

Structure is a tool. Like any tool, it can be misused or overused. For anything even remotely production-y I'll always prefer explicitly parsing JSON into a known structure, but there's a lot of value in in being able to do some exploratory scripting without those constraints.

Yes! Exploratory scripting is a categorically different thing than programming, though, I think.

not necessarily. there is a bottom up school of thought that encourages people to noodle around and construct primitives by playing in the domain, and then interactively composing those primitives into larger and larger systems.

Re: Why static languages suffer from complexity

#163

Post by raphlinus »

erichocean wrote: post #56

FWIW, I've been developing code directly in MLIR recently, and in MLIR "Comparing types is cool" is indeed true. It's amazing what you can do when you have compiler transformations and targets always available. Suddenly, "little DSLs" (MLIR dialects) don't seem so bad, since they are defined the same way and map in semantically-sound ways to lower-level dialects. You can have dedicated dialects, like Halide, for doin…

Can I pick your brain on MLIR? It sounds awesome from what you describe, but I want to know more about whether it's specialized to machine learning types of workloads or whether it's good for more general things.

Re: Why static languages suffer from complexity

#164

Post by dmitriid »

agentultra wrote: post #145
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. And yet type theory is an excellent way to express all kinds of invariants. The more rich the type system the more you can express. If you get to dependent types you essentially have all of mathematics at your disposal. This is the basis of some of the most advance proof automation available. What is super cool is that proofs are program…

> The more rich the type system the more you can express. If you get to

Ah yes. And then you end up writing entire prgrams in types. So the next logical setep would be to start unit- and integration tests for these types, and then invent types for those types to more easily check them...

> you essentially have all of mathematics at your disposal.

Most of the stuff we do has nothing to do with mathematics.

Re: Why static languages suffer from complexity

#165

Post by preseinger »

convolvatron wrote: post #162
preseinger wrote: post #151

Earlier quoted context omitted.

Yes! Exploratory scripting is a categorically different thing than programming, though, I think.

not necessarily. there is a bottom up school of thought that encourages people to noodle around and construct primitives by playing in the domain, and then interactively composing those primitives into larger and larger systems.

Yeah, that's true. It's a judgment call for sure, but I've always found that angle on things to be self-subversive. The best programmers I know are all bottom-up learners, not top-down.

Re: Why static languages suffer from complexity

#166

Post by bqmjjx0kac »

zmmmmm wrote: post #149

The problem I find with static typing is that it so easily leads you over-specifying the requirements / constraints. In fact, it makes such a virtue out of that over-specification that many people would consider it a best practice to do so. For example, perhaps my `calculate_price` function only depends on 2 attributes of the order which has 65 attributes. Am I creating a 2-element data type for that function to proc…

> As soon as things get ambiguous or flexible, go right ahead and specify that your function takes a Map.

Dear god, please don't. Some of the worst spaghetti code I have disentangled used this pattern. Typos in the string literals used as keys, object type mismatches, etc.

If you only want some of the fields from another struct, you have a few options

* Define another struct `FooArgs`. This is easy, and I (respectfully) reject the claim that nobody does it.

* Just define your function to take those two fields directly.

Re: Why static languages suffer from complexity

#167

Post by mountainriver »

preseinger wrote: post #152
DonaldPShimoda wrote: post #109

Earlier quoted context omitted.

> 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…

Type systems are useful, but not nearly as useful as many people believe they are.

Try working in a big system without them =P I think they are invaluable

Re: Why static languages suffer from complexity

#168

Post by raphlinus »

BalinKing wrote: post #159
spc476 wrote: post #158

Earlier quoted context omitted.

> You can write your programs and use the same language to prove theorems about them. Didn't Kurt Gödel and Alan Turing do some work on proving statements within a system?

AFAIK languages like Idris, Agda, and Coq are not Turing-complete (specifically, they disallow general recursion) for just this reason.

If my understanding is correct, Agda and Coq disallow general recursion, so all programs terminate by construction, but Idris relaxes this, in a desire to be more pragmatic at the cost of not as clean mathematically (functions have to be modeled as partial in general, to account for the fact they might not terminate).

Re: Why static languages suffer from complexity

#169

Post by mountainriver »

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…

Type systems also allow people to understand your code, this is very important

Re: Why static languages suffer from complexity

#170

Post by yen223 »

brundolf wrote: post #160
zmmmmm wrote: post #149

The problem I find with static typing is that it so easily leads you over-specifying the requirements / constraints. In fact, it makes such a virtue out of that over-specification that many people would consider it a best practice to do so. For example, perhaps my `calculate_price` function only depends on 2 attributes of the order which has 65 attributes. Am I creating a 2-element data type for that function to proc…

You’re putting structural types in the same boat as dynamic types, which I don’t think is fair. Some of the most popular static type systems out there have structural typing, including Go (as you mentioned) and TypeScript. And that’s not even getting into languages that do extensive type-inference, including TypeScript Haskell and ReScript (which also saves you from locking into over-broad contracts).

One works with the type system they have, not the one they want. Out of the top 20 most popular languages according to Stack Overflow [0], TypeScript and Go are the only statically-typed languages that also have structural types support.

[0] https://insights.stackoverflow.com/survey/2021#technology-mo...

Post reply on HN