Earlier quoted context omitted.
You can do that in static languages too by just parsing into a map
What's the type definition of the map out of interest?
Why static languages suffer from complexity
81–90 of 306 posts
Re: Why static languages suffer from complexity
#82Yeah, the current problem is that Idris code is far less efficient than Rust code, because Idris boxes everything and erases all types, and also Idris's support for borrowing seems less powerful than Rust (it lacks first-class mutable borrows as far as I can tell). It seems that fixing this is a research problem, which would lead to the holy grail of programming languages, i.e. an ultimate language that is as express…
> Idris's support for borrowing seems less powerful than Rust (it lacks first-class mutable borrows as far as I can tell).
Depends on what you mean. Idris's notion of multiplicities essentially subsumes Rust's borrowing (there's some differences with affine vs linear types), so I can't think off the top of my head of things that you can ensure with Rust that you can't with Idris, but Rust has a lot more quality of life improvements that make things less clunky (also having a GC, Idris can get away with a lot less need for borrowing in the first place).
Re: Why static languages suffer from complexity
#83Earlier quoted context omitted.
The types are there.. but you don't know which one it is that your program is dealing with. You could have dozens of implementations for any given abstract interface. One gets picked up at run time.
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.
Re: Why static languages suffer from complexity
#84I 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?
Re: Why static languages suffer from complexity
#85So whenever I have to study someone else's 'dynamic' python I encounter this sort of thing: def foo(bar, baz): bar(baz) ... What the heck is 'bar' and 'baz'? I deduce no more than 'bar' can be called with a single 'baz'. I can't use my editor/IDE to "go to definition" of bar/baz to figure out what is going on because everything is dynamically determined at runtime, and even grep -ri '\(foo\|bar\|baz\)' --include \*.p…
What the heck is 'bar' and 'baz'? So there's no docstring? And the actual variables are that random and indecipherable? Sounds like the problem is that you're tasked with looking at code written by someone who is either inexperienced or fundamentally careless. When dealing with reasonably maintained codebases, this kind of situation would seem pretty rare. In modern python we now have type hints of course, which have…
In other words, in Python you have to rely on your colleagues manually writing documentation, and if they don't you're out of luck and they're 'bad developers' and potentially the whole product is affected.
In static languages this simply isn't a problem. Types are checked for consistency at compile time and you don't have to rely on people toiling on this busy work.
Not to say documentation isn't necessary, or good, but isn't something you need to create working programs because otherwise no one knows wtf any variable is without running the program.
Re: Why static languages suffer from complexity
#86I wonder where TypeScript would fall on this language continuum?
My guess: It wouldn't because this is about static languages. Typescript is still a dynamic language with a very smart (probably best-in-class at this point in time) compile-time typechecker/static analysis tool.
Re: Why static languages suffer from complexity
#87So whenever I have to study someone else's 'dynamic' python I encounter this sort of thing: def foo(bar, baz): bar(baz) ... What the heck is 'bar' and 'baz'? I deduce no more than 'bar' can be called with a single 'baz'. I can't use my editor/IDE to "go to definition" of bar/baz to figure out what is going on because everything is dynamically determined at runtime, and even grep -ri '\(foo\|bar\|baz\)' --include \*.p…
That is why I like dynamic languages like Julia better because they use type annotations more frequently.
Re: Why static languages suffer from complexity
#88Earlier quoted context omitted.
> In modern python we now have type hints of course, which have helped quite a lot. I had to laugh, hard. If your Python program uses any library whatsoever, chances are that library won't have types, so you can't really use them. Even super widely used libraries like numpy don't have good support for types, much less any library that consumes numpy for obvious reasons.
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.
Re: Why static languages suffer from complexity
#89"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…
Absolutely agree.
All features are useful. That's table stakes. But usefulness is insufficient to warrant inclusion. How does a feature interact with all existing features? Are there ambiguities? Are there conflicts? A language is not a grab-bag of capabilities, it's a single cohesive thing that requires design and thought.
Re: Why static languages suffer from complexity
#90Earlier quoted context omitted.
In Clojure, I tend to put pre and post assertions on most of my functions, which is useful for checking errors in the schema of runtime data (very useful when dealing with 3rd party APIs) but it also offers the documentation that you are seeking: (defn advisories [config] {:pre [ (map? config) (:download-advisories-dir config) ] :post [ (map? %) ] } (let [ dir (:download-advisories-dir config) ] ;; more code here
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?