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

101–110 of 306 posts

Re: Why static languages suffer from complexity

#101

Post by msla »

dvh wrote: post #84
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…

Would printf even exist if C had sane strings?

Some kind of formatting function would because sometimes, you really do need to print an integer with enough leading zeroes to fit in a five-digit field.

Re: Why static languages suffer from complexity

#102

Post by Zababa »

In the SML/OCaml world there's something like that: there is a difference between types and modules, and functions (from types to types) and functors (from module to module). Work was done on 1ML to unify everything: https://people.mpi-sws.org/~rossberg/1ml/. An extract:

> In this "1ML", functions, functors, and even type constructors are one and the same construct; likewise, no distinction is made between structures, records, or tuples. Or viewed the other way round, everything is just ("a mode of use of") modules. Yet, 1ML does not require dependent types, and its type structure is expressible in terms of plain System Fω, in a minor variation of our F-ing modules approach.

> An alternative view is that 1ML is a user-friendly surface syntax for System Fω that allows combining term and type abstraction in a more compositional manner than the bare calculus.

On the other hand, from the "engineer" point of view, all abstractions melting into one may not be desirable. It's nice to be able to use weak abstractions for simple stuff and powerful abstractions for more powerful stuff. Being exposed to the full complexity of your language all the time sounds like a recipe for disaster.

Re: Why static languages suffer from complexity

#103

Post by Diggsey »

foxfluff wrote: post #83
Diggsey wrote: post #79

Earlier quoted context omitted.

You don't need to know which one, because the abstract interface tells you how to use it...

That's the theory. Works great when there are no bugs and everything's been designed just right. In that world you could wipe implementations from memory because you won't ever need to dive in.. Very often I'm looking at code and "how to use the interface" is not a question I'm looking to find answers for.

Some information is a lot better than none. In some cases you might want to know what implements the interface: that information is also statically available. In Rust, you can look at a trait and see what types implement that trait.

If you need to know exactly which implementation is being used in a particular context then maybe you shouldn't be using an interface, but should be using the concrete type?

Re: Why static languages suffer from complexity

#104

Post by foxfluff »

arc619 wrote: post #73

This entire article can be summarised as "compile time stuff should use the same language as run time". I guess the author just hasn't encountered Nim before, where anything becomes compile time by just assigning to a const, and macros have access to the real AST without substitution. Macros also allow compile time type inspection, as they are a first class citizen rather than tacked on. The compile time print, AFAIC…

> This entire article can be summarised as "compile time stuff should use the same language as run time".

I think the message is more nuanced than that (otherwise wouldn't lisp with its homoiconicity and compile time macros fit the bill perfectly?). Idris uses the same language, but is still too complex. And Zig not general purpose enough. I don't want to put words in the author's mouth but I think the implication is that this is a large space to explore and we don't have a solution yet; there's nothing like "just make your language like this and it'll be good." They're just pointing out the problem they see, and some (non-)solutions to it.

Re: Why static languages suffer from complexity

#105

Post by preordained »

Having used Clojure for a while now, I will say having 90% of things be a primitive, map, or vector goes a long way in and of itself. A lot of types concocted in a more conventional language just don't need to exist, IMO, and they create so much baggage around themselves.

Re: Why static languages suffer from complexity

#106

Post by dandotway »

naasking wrote: post #71
nicoburns wrote: post #14

Earlier quoted context omitted.

The real power of dynamic languages is being able to do: const foo = JSON.parse(arbitraryJsonString); and not having to worry about the structure up front.

> The real power of dynamic languages is being able to do: const foo = JSON.parse(arbitraryJsonString); and not having to worry about the structure up front. That's not power, that's a shotgun aimed at your crotch whose trigger is connected to a cosmic ray detector.

+NaN For comments that make me laugh out loud for duration T>2.0 seconds, I wish HN provided a way to transmute/sacrifice one's past karma points into additional +1 mod points.

Re: Why static languages suffer from complexity

#107

Post by vanusa »

arc619 wrote: post #88
vanusa wrote: post #72

Earlier quoted context omitted.

I had to laugh, hard. It's fine if you want to insulate yourself. But I don't see that you're making much of a point here.

They're probably laughing because a) you're suggesting manually doing the work static typing does in a dynamic language because its untenable not to for large projects, and b) you can't easily add type hints to other people's libraries.

No - (a) is not what I'm suggesting. And (b) while disappointing, just doesn't slow one's work down very frequently in daily practice.

Look, I just don't buy the suggestion that static typing magically solves a huge set of problems (or that it does so without imposing negative tradeoffs of its own -- the very topic of the original article). Or that dynamic languages are plainly crippled, and that one has to be a kind of a simpleton not to see this obvious fact.

Re: Why static languages suffer from complexity

#108

Post by yakshaving_jgt »

Jtsummers wrote: post #90
maleldil wrote: post #49

Earlier quoted context omitted.

How is this any better than static types?

Pre/post conditions are complementary to a type system. They can ensure logical properties that may not be encodable in your underlying type system (that is, essentially every mainstream statically typed language). Such as the relationship between two values in a collection. Trivial example, if you have a range such as [x,y] where x < y must hold, how would you convey that in any mainstream type system?

The Haskell-y way to do this is to use a smart constructor[0].

[0]: https://wiki.haskell.org/Smart_constructors

Re: Why static languages suffer from complexity

#109

Post by DonaldPShimoda »

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 systems useful or not?

There are a lot of properties we can analyze statically, and practically all of them essentially amount to extensions of type systems. Any of them increases our ability to rule out undesirable programs from every beginning execution. Some of them have unintuitive syntax, but many of them are no more syntactically burdensome than most other type systems. This is especially true if you consider how far we've come with type inference, so we no longer have to write code with the verbosity of Java just to get some meager guarantees. It's still a very active area of research, but we're clearly making progress in useful ways (which you even highlight), so I don't really know what point it is you've set out to make.

Re: Why static languages suffer from complexity

#110

Post by vanusa »

duped wrote: post #93
vanusa wrote: post #65

Earlier quoted context omitted.

Not argument and return types. When conventions are followed they do exactly that, actually. And unless the code is a complete trainwreck, it's pretty easy to tell what the return type is, even without explicit annotation in the docstring.

What conventions are those, besides Hungarian notation (which I don't think I've ever seen in Python)?

PEP 257, and local conventions in certain projects.

What all comes down to is: if you really have people on your project writing code like the foo/bar/baz example way up above - then you have problems way bigger than static type checks can possibly help you with.

Post reply on HN