Why static languages suffer from complexity

https://hirrolot.github.io/posts/why-static-languages-suffer-from-complexity#

by Lapz • 5 years ago

213 290 5 years ago

hirrolot.github.io

dleslie• 5 years ago

I'm unfamiliar with one of the language logos in the meme graph at the bottom: what's the red swooshy thing beside zig?

andrenth• 5 years ago

It's the Idris logo https://www.idris-lang.org/

guidorice• 5 years ago

Best.Programmer.Art.Ever

dnautics2• 5 years ago

I didn't see the article touch on the "why" explicitly, but: zig really has the chance to square this circle for low level languages, since there is duck-typed type-inferenced-coercion in places where it makes sense. Completely correct about zig not necessarily being good for higher level stuff, but I think (dynamic) HLLs have been converging on dealing with this using static typechecking, with varying levels of success

peterashford4• 5 years ago

I spent a couple of days with Zig. Thought the language was great but the tooling (on Windows) just killed it for me. I hope that gets better 'cos I'd like to give it another go

preseinger11• 5 years ago

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 fully dynamic, we will win biformity and inconsistency,[^] but will imminently lose the pleasure of compile-time validation and will end up debugging our programs at mid-nights . . . One possible solution I have seen is dependent types. With dependent types, we can parameterise types not only with other types but with values, too.

Types are a productive abstraction/model in programming languages. One of many. Each has its strengths and weaknesses; each is appropriate in some circumstances and not in others. Types are not the solution to all problems, any more than currying or OOP or whatever else is.

gumby2• 5 years ago

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

jayd162• 5 years ago

Shader languages are also hellbent on avoiding branches too so if is frowned upon and often not used. I could easily imagine not having it in a shader language.

Hirrolot3• 5 years ago

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

oldsecondhand• 5 years ago

In Prolog :- is the if operator.

preseinger11• 4 years ago

I'm not sure I buy your premise -- `make` is a DSL for a very narrow set of problems, and I've never encountered Prolog in production use?

ModernMech• 5 years ago

Ugh, I know I'm getting old when I don't understand the memes.

seanw444• 5 years ago

I really want to know where I can find quality programming memes like these. Not just the generic "haha language ___ is bad, nerd" memes.

dandotway2• 5 years ago

So 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 \*.py

Won't tell me much about foo/bar/baz, it will only start a hound dog on a long and windy scent trail.

nicoburns• 5 years ago

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.

valcron1000• 5 years ago

What's 'foo' and what you can do with it?

preseinger11• 5 years ago

Structure is a virtue, not a vice. By doing this you're subverting your own interests.

mountainriver5• 5 years ago

You can do that in static languages too by just parsing into a map

HideousKojima• 5 years ago

In C# I can just parse it to a Dictionary<string, object>, and I can do that without destroying the usability of the rest of the language.

commandlinefan2• 5 years ago

I thought the real power of dynamic languages was being able to do things like:

   eval('alert("hello, ' + userInput.name + '!")')

sandofsky• 5 years ago

When that JSON payload changes (intentionally or not), you will run into a mysterious problem in some unrelated area of your code. It will be significantly more expensive to fix than failing fast at the point of parsing.

ironman1478• 5 years ago

But the thing is, don't you have to worry about structure? You have to unpack the elements from the JSON, so you will need to encode its structure explicitly, which includes type information. The only reason this would be useful is if you're just shuttling data to another API that expects a dict structure (that will then validate everything) and not JSON and you aren't really doing any real work yourself.

cheriot• 5 years ago

There's something to this. I love featurefull type systems, but I've seen engineers try to parse JSON the "right" way in Scala, get frustrated, and blame the entire concept of statically typed languages. Elm manages to make this user friendly so perhaps it's "only" a matter of compiler messages and API design?

woodruffw• 5 years ago

Every static language that I know of also supports this -- you can parse into a sum type of `JsonAny` (or whatever), where `JsonAny` is one of `Null | Number | String | List[Any] | Dict[String, JsonAny]`.

The API then becomes a runtime fallible one, which is perfectly sound.

laumars2• 5 years ago

That’s not a capability unique to dynamic languages

naasking• 5 years ago

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.

yakshaving_jgt10• 5 years ago

You can trivially do exactly the same thing in Haskell, so I think you’re suggesting that dynamic languages have no “real power”.

adwn• 5 years ago

Rust:

    let foo: serde_json::Value = serde_json::from_str(arbitraryJsonString)?;

There, just as powerful [1]. But you know what's even more powerful? After you've done your dynamic checks, you can do this on the entire JSON tree, or on a subtree:

    let bar: MyStaticType = serde_json::from_value(foo)?;

and you get a fully parsed instance of a static type, with all the guarantees and performance benefits that entails.

[1] Value represents a JSON tree: https://docs.serde.rs/serde_json/enum.Value.html

arc7768• 5 years ago

In Nim you can even convert JSON to static types! https://nim-lang.org/docs/json.html#to%2CJsonNode%2Ctypedesc...

Now you get type checking on JSON at compile time :)

earth_walker• 5 years ago

How powerful is this, really?

As soon as you try to do anything useful to foo it's not arbitrary anymore. You have to make some kind of an assumption on the underlying type, check for keys, nulls, maybe it's a number (the right number?), maybe it's a list. So now you have to scatter some boilerplate checks everywhere you touch a part of foo.

If you could parse it into a typed structure up front, you'd only have to deal with this in one spot, and have guarantees for everything else that follows.

Bonus: if your typed language has good support for records, you can even do this in a way that only provides structure to the parts you care about, and is robust to changes to any other parts of the json.

solox3• 5 years ago

I can't use my editor/IDE to "go to definition" of bar/baz

I use "Find Usages" on foo to see where it is used. Once you see where it is used, you know what the types can be. It's not great, but it's also something that can be progressively remedied.

In the event that the function is not as trivial as your example suggests, the author should have written a docstring to help you understand what it is trying to do, in addition to type annotations that will make it more readable.

In this example, bar can either be a function, a class, or any object with __call__(), so the type information is less important in this case, than actual docstrings that express intent.

lkrubner• 5 years ago

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

anyfoo3• 5 years ago

And now imagine the compiler would actually enforce that practice, and you have static typing, with less boilerplate.

maleldil• 5 years ago

How is this any better than static types?

mountainriver5• 5 years ago

Yup, I find this completely insane behavior to think that you somehow benefit from types not being there.

You just make it way harder for people to understand your code and contribute to it.

commandlinefan2• 5 years ago

It doesn't just make the code harder to read, it makes it run slower, too. Static typing provides some compile-time guarantees about what's going to go where, so the compiler can make a lot of simplifying assumptions that speed things up.

tus6664• 5 years ago

Oh yeah the easiest code in the world to read is some contorted type system and function signatures that look like hieroglyphics that you need a PHd in CS to comprehend.

Python is easy to grok, and if you have programmers writing code like bar(foo,baz) then the problem is not Python. You can write crap in any language.

Unit tests do much of what typing checks anyway ... and here's the thing ... you NEED unit tests no matter what. No typing system can tell you that you wrote > when you should have written <.

jan_g• 5 years ago

To be fair, in recent years I've worked on a number of Typescript projects and it was common for developers to use `any`, `Object`, `() -> Promise<void>`, etc. Not super helpful.

Though in my experience, sane code structure and informative comments trump everything else when it comes to understanding big and unknown codebase. I still shudder when I think about working years ago on various Java codebases (mostly business IT systems). What a convoluted mess of n-levels deep interface hierarchies. Types? Yeah, but good luck unraveling what exactly is happening in the runtime.

dgb23• 5 years ago

The example is entirely ridiculous. Types are names too. Does foo(bar: baz) solve the issue? Languages are there to convey meaning.

vanusa14• 5 years ago

Insane, no - it's just a tradeoff.

I agree that on balance type signatures are better -- and that's why modern Python has evolved to incorporate them. But they aren't a magic cure-all, and do they impose a significant tax of their own.

foxfluff6• 5 years ago

Static languages unfortunately don't save you from that. You find automatically inferred types, or types that refer to some abstract interface or template-class-mess but you have no idea where the actual implementation lives until you compile with RTTI and run it under a debugger... and as tfa posits, people working with the limitations of static languages often end up reinventing a dynamic structure.

Is this somehow supposed to relevant to the posted article or did you just want to start a tangentially related dynamic-vs-static flame war here in the comments section?

hota_mazi2• 5 years ago

Static languages unfortunately don't save you from that. You find automatically inferred types,

Oh yes, they do. Even inferred, the types are there and pretty easy to locate, even if you're not using an IDE.

dmitriid3• 5 years ago

to some abstract interface or template-class-mess

And traits! "Oh look, this functionality is implemented in a trait implemented by a trait implemented by a trait implemented by what you're looking at. Maybe"

Diggsey3• 5 years ago

Static languages unfortunately don't save you from that.

While you still can make a static language that is confusing, it's a lot harder... I challenge you to write a function signature in Rust that is both:

1) Useful

2) As opaque as the python signature above.

You find automatically inferred types

A minority of static languages do type inference in function signatures. I think it's a bad idea for exactly the same reason the python code is bad. On the other hand, every dynamic language allows you to omit any information about a type signature.

jacobn• 5 years ago

They usually save you from that particular pitfall, but not always of course.

Static vs dynamic makes for such difference in the detailed workflow, both in terms of changing existing code & in terms of writing new/(more) from scratch code, yet they can both be quite fruitful, and can both be abused in absurdum.

It seems like people naturally fall into one of the two camps (either by personality or by training), and the other side just seems kind of insane: "how can you even work that way!?". Then culture and idioms emerge over time and strengthen the tribalism.

I've gone back and forth between the two over the course of my career, and it's quite a mind-shift when switching, with a fair bit of pain involved ("but it would be so easy to do this in [old language]", or "what the hell is this garbage anyway!?") and then eventually it settles in and it's not all painful, all the time ;)

(Going back and forth between Scala and Python right now, so this hit a bit of a nerve)

vanusa14• 5 years ago

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 helped quite a lot.

maxwell862• 5 years ago

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.

duped4• 5 years ago

Coming from any statically typed language to Python or JavaScript codebases this plagues me. Virtually every project I have seen suffers from this.

Function names and doc comments describe behavior, not argument and return types.

arc6193• 5 years ago

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.

timeon• 5 years ago

I do not want to argument against Python. This is more like off topic / side note.

What I like about Rust is that it even checks code in your 'docstring'. So it is easier to keep it maintained.

aidos• 5 years ago

Well, you could put the types on these days.

But also, there’s nothing stopping the code from being much clearer about its intention than this weirdly contrived example (I have a lot of code and most the function names are pretty unique). And surely you want to search for ‘foo(‘ to find invocations.

lkuty• 5 years ago

Indeed. An interesting reading is https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ...

yakshaving_jgt10• 5 years ago

This is one of my favourite blog posts on the Internet and I implore every programmer to read it.

The claim is simple: in a static type system, you must declare the shape of data ahead of time, but in a dynamic type system, the type can be, well, dynamic! It sounds self-evident, so much so that Rich Hickey has practically built a speaking career upon its emotional appeal. The only problem is it isn’t true.

socialdemocrat• 5 years ago

That is why I like dynamic languages like Julia better because they use type annotations more frequently.

rightbyte• 5 years ago

My worst developer experience ever was trying to make changes to a custom build system with functions exactly like that. Injector or decorator pattern, or what ever it is called.

I just gave up and introduced globals and used as flags for some places in the code.

To make things even more fun, big parts of the system was written in 2.7 called from runtime generated bat files from 3.4 as remnants of a rewrite and the consultant that had his funding cut.

batrachos• 5 years ago

I dislike the phrase 'dynamic language' and especially dislike the phrase 'static language'. We should say 'dynamically typed' or 'statically typed', because 'static' languages are the site of major dynamism.

chriswarbo2• 5 years ago

I think 'dynamic language' is appropriate here, since it's not only talking about types; it's largely talking about macros, pre-processors, reflection, etc. too.

Also, the main argument is that separating features into those used at compile-time (AKA static) and run-time (AKA dynamic) is necessarily creating separate languages (i.e. a "static language", which may involve types, macros, preprocessors, etc.; and a "dynamic language", which may involve memory allocation, branching, I/O, etc.)

honkycat• 5 years ago

Great article, made me think! However, I think it needs to be trimmed down. Making your argument in the final paragraph of the article is not great.

Hoist the "Final Words" section to the top and make it a "tldr" introduction, that way your reader can begin with a high level understanding of your argument, which you can hone and refine as you progress.

devit• 5 years ago

Yeah, 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 expressive as Idris and as efficient as Rust, and is thus essentially perfect.

siknad• 5 years ago

an ultimate language that is as expressive as Idris and as efficient as Rust, and is thus essentially perfect.

Are both Idris's expressiveness and Rust's efficiency (given stronger guarantees) perfect? Aren't theese languages really complex both to learn and to write? There are poblems without a solution, perfect and unique to all of them.

dwohnitmok• 5 years ago

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).

preseinger11• 5 years ago

Expressiveness is not an unambiguous net good -- more expressiveness is not a priori better. Expressiveness carries costs of comprehension and coherence that need to be appropriately weighed in the contexts where the language will be applied.

Programming languages are not theoretical things. They're concrete, practical tools that _enable_ other stuff. Engineering, not science.

ImprobableTruth6• 5 years ago

How would you define expressiveness (as its commonly used, so a definition where Turing complete languages can have different expressiveness) if not as how much something can be simplified and thus aiding comprehension, rather than detracting from it?

Programming languages are not theoretical things. They're concrete, practical tools that _enable_ other stuff. Engineering, not science.

You can't escape theory, engineering is applied science.

zozbot234• 5 years ago

The Prusti effort to endow Rust with proof-carrying code is also worth mentioning. There are some reasons to expect this approach to be more fruitful than an actual extension of dependently-typed languages, since the type system features of Rust itself are hard to integrate with dependent types. (At best, it might be somewhat feasible to use the latter in the `const`, compile-time evaluated subset of the language.)

adamddev1• 5 years ago

I wonder where TypeScript would fall on this language continuum?

dnautics2• 5 years ago

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.

AtNightWeCode• 5 years ago

This is some kind of joke, right?

armchairhacker• 5 years ago

"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 creates a higher learning curve, since you have to decide whether to use a new feature or just re-implement it via old features. See: C++ and over-engineered Haskell. So each feature has a "learnability cost", and only add features which are useful enough to outweigh the cost.

But most features actually are useful, at least for particular types of programs. It's much harder to write an asynchronous program without some form of async; it's much harder to write a program like a video game without objects. This may be controversial, but I really don't like Go and Elm (very simple languages) because I feel like have to write so much boilerplate vs. other languages where I could just use an advanced feature. And this boilerplate isn't just hard to create, it's hard to maintain because small changes require rewriting a lot of code.

So ultimately language designers need to balance number of features with expressiveness: the goal is to use as few simple but powerful features to make your language simple but really expressive. And different languages for different people. Personally I like working with Java and Kotlin and Swift (the middle languages in the author's meme) because I can establish coding conventions and stick to them, C++ and Haskell are too complicated and it's harder to figure out and stick to the "ideal" conventions.

preseinger11• 5 years ago

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.

throw109202• 5 years ago

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)

Jensson• 5 years ago

Is that really a problem on the language's side, though?

Yes, for a language to be good in practice you need to look at what developers actually do and not how a perfectly rational developer would use the language.

acchow3• 5 years ago

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

I have found the opposite to be true. Missing features often leads to what one would call "design patterns". When the language adds official support to solve the problem you're trying to solve with that pattern, the code becomes clearer.

erichocean2• 5 years ago

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 doing something as concrete as image processing kernels.

Oh, and you can output those kernels to both the CPU and GPU, including automatically introducing async functions, host-side sync barriers, etc. Good luck doing that automatically with a general purpose programming language and a combination of macros, AST manipulations, and derived types! You really need a compiler to stay sane.

"Programming languages ought to be rethought."

Indeed.

raphlinus3• 5 years ago

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.

erichocean2• 5 years ago

Well, we're using it for business automation. We have automated agents that are selectively override-able by humans on an as-needed basis (e.g. a case we don't currently handle, or because of a runtime error).

Also, most of our code needs to support suspend/resume on another machine, either in the middle of an action or more often between actions. So, a "behavior" might begin on machine A and then migrate to machine B to do more work, then on to machine C. While doing work, its execution state might be serialized to Postgres while some dependency is waited on—say, a human task that doesn't get done until the following Monday. It's then resumed in the same execution state, potentially on an entirely different worker/machine, and continues executing.

The suspend/resume stuff completely destroys the code if you're writing it by hand, as does moving from machine to machine.

So we write the core logic in our own internal MLIR dialect and then output code that has the suspend/resume semantics automatically (i.e. literal compiler transformations, plus our own "interpreter" (which is just JavaScript/v8 with all of the extra suspend/resume cruft added in).

We don't translate out of SSA form at all, our codegen can execute it directly. We also insert debug hooks so when there's an error, you can map the execution state to the original code.

Most of the cool machine learning stuff MLIR can do, we're not even doing yet outside of some internal prototypes. So far, just the methodology of MLIR has made a huge impact—it gives really nice structure (read: tooling) for the kinds of code transforms we've needed to do.

HTH

arc6193• 5 years ago

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, AFAICT, already exists in Nim as the `&` macro in strformat. That lets you interpolate what you like at compile time, and supports run time values too.

foxfluff6• 5 years ago

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.

Hirrolot3• 5 years ago

arc7768• 5 years ago

I think the message is more nuanced

I thought it was more nuanced too as they were explaining how integer types can be derived, until I finished the article, and they really did just seem to be complaining that there's a mismatch between compile time and run time.

Dynamic types don't really solve the problems they mention as far as I can tell either (perhaps I am misunderstanding), they just don't provide any guarantees at all and so "work" in the loosest sense.

otherwise wouldn't lisp with its homoiconicity and compile time macros fit the bill perfectly?

That's a good point, I do wonder why they didn't mention Lisp at all.

we don't have a solution yet

What they want to do with print can, as far as I can see, be implemented in Nim easily in a standard, imperative form, without any declarative shenanigans. Indeed, it is implemented as part of the stdlib here: https://github.com/nim-lang/Nim/blob/ce44cf03cc4a78741c423b2...

Of course, that implementation is more complex than the one in the article because it handles a lot more (e.g., formatting and so on).

At the end of the day, it's really a capability mismatch at the language level and the author even states this:

Programming languages ought to be rethought.

I'd argue that Nim has been 'rethought' specifically to address the issues they mention. The language was built with extension in mind, and whilst the author states that macros are a bad thing, I get the impression this is because most languages implement them as tacked on substitution mechanisms (C/C++/Rust/D), and/or are declarative rather than "simple" imperative processes. IMHO, most people want to write general code for compile time work (like Zig), not learn a new sub-language. The author states this as well.

Nim has a VM for running the language at compile time so you can do whatever you want, including the recursive type decomposition (this lib isn't implementing Peano arithmetic but multiprecision stack based bignums): https://github.com/status-im/nim-stint and specifically here: https://github.com/status-im/nim-stint/blob/ddfa6c608a6c2a84...

    func zero*[bits: static[int]](T: typedesc[Stuint[bits] or Stint[bits]]): T {.inline.} =
      ## Returns the zero of the input type
      discard

    func one*[bits: static[int]](T: typedesc[Stuint[bits]]): T {.inline.} =
      ## Returns the one of the input type
      result.data = one(type result.data)

It also has 'real' macros that aren't substitutions but work on the core AST directly, can inspect types at compile time, and is a system language but also high level. It seems to solve their problems, but of course, they simply might not have used or even heard of it.

chriswarbo2• 5 years ago

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 (PrintfType). That lets us throw away `Fmt`, `toFmt`, etc. to just get:

    PrintfType : (fmt : List Char) -> Type
    PrintfType ('*' :: xs) = ({ty : Type} -> Show ty => (obj : ty) -> PrintfType xs)
    PrintfType (  x :: xs) = PrintfType xs
    PrintfType [] = String

    printf : (fmt : String) -> PrintfType (unpack fmt)
    printf fmt = printfAux (unpack fmt) [] where
      printfAux : (fmt : List Char) -> List Char -> PrintfType fmt
      printfAux ('*' :: fmt) acc = \obj => printfAux fmt (acc ++ unpack (show obj))
      printfAux (  c :: fmt) acc = printfAux fmt (acc ++ [c])
      printfAux []           acc = pack acc

dvh• 5 years ago

Would printf even exist if C had sane strings?

foxfluff6• 5 years ago

How is formatted printing related in any way to the internal representation of strings?

printf is what you call when you want to print X in hexadecimal with at least two digits, left justified on an eight-character wide field. I don't see how the sanity of whatever string representation the programming language uses is relevant here.

msla• 5 years ago

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.

peterashford4• 5 years ago

printf exists in Java. Because its so bloody useful.

goldsteinq• 5 years ago

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

tempodox• 5 years ago

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.

lambdasquirrel• 5 years ago

Indeed, the article has it backwards. The types are always there. Your program will fail at runtime if it's not correct. The type system merely surfaced that.

Complexity in the types happens when the type system isn't expressive enough. Or when you're trying to do something that would make the compiler try to solve the halting problem.

To that last point, this is why the PLT community has pushed in the direction that Agda / Idris has. Kind of like how we realized years (decades?) ago that we didn't need pointer arithmetic, there's been a realization that "total" isn't actually that helpful, and it's okay if we didn't have languages that could express the halting problem.

skybrian2• 5 years ago

That's the hope, but saying there's something wrong is insufficient. The compile-time errors need to be understandable, or it's just going to be frustrating.

Maybe we should judge compile-time constraint systems by how easy it is for the library author to add good error messages for misuse?

adamrezich• 5 years ago

Kind of like how we realized years (decades?) ago that we didn't need pointer arithmetic

who's "we" here? pointer arithmetic is useful for all kinds of things.

Hirrolot3• 5 years ago

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!

Animats• 5 years ago

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 violations. Because that works, there are ongoing attempts to extend type systems to prevent still more invariant violations. That creates another layer of confusing abstraction. Some invariants are not well represented as types, and trying makes for a bad fit. What you're really trying to do is to substitute manual specification of attributes for global analysis.

The Rust borrow checker is an invariant enforcer. It explicitly does automatic global analysis, and reports explicitly that what's going on at point B is inconsistent with what point A needs. This is real progress in programming language design, and is Rust's main contribution.

That's the direction to go. Other things might be dealt with by global analysis, Deadlock detection is a good example. If P is locked before Q on one path, P must be locked before Q on all paths. There must be no path that leads to P being locked twice. That sort of thing. Rust has a related problem with borrows of reference counted items, which are checked at run time and work a lot like locks. Those potentially have a double-borrow problem related to program flow. I've heard that someone is working on that for Rust.

DonaldPShimoda• 5 years ago

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.

Verdex3• 5 years ago

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).]

joe_the_user• 5 years ago

Not the original author but it seems like they're saying that type-systems are non-specific invariant enforcers and so have costs without necessarily having benefits whereas a user-specifiable invariant enforcer is more guaranteed to have the benefits.

preseinger11• 5 years ago

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

halpert2• 5 years ago

Rust's borrow checker isn't a type system. It's a static analyzer that tries to determine if it can figure out when to free your allocation.

fho3• 5 years ago

It is probably pretty presumptuous to assume, but I think that a lot of programmers that have only every been exposed to C/C++/C#, Java and Python have basically no concept of what a good type system can do for them.

Two examples from the top of my head:

1. Encoding matrix sizes into the data- and function-types, so that you can safely have a function `mat[c,b] mat_mult(mat[a,b] a, mat[c,d] b)` or even `mat[w-2,h-2] convolve(mat[w,h] input, mat[3,3] kernel)` and have the compiler check that you never use a matrix of the wrong size.

2. Actually checking the correctness of your implementation.

There is a very nice online demo of Liquid Haskell [1], where they defined the properties of ordered lists (each element has to be smaller or equal to the one before, line 119). Then they define a function that takes an (unordered) list and spits out a ordered one by applying a simple quicksort.

Now, if you break the algorithm (e.g. flip the < in line 193) and run Check, the compiler will tell you that you messed up your sorting algorithm.

Pretty neat.

edit: I just realized that LiquidHaskell is almost 10 years old. Sad to see that basically nothing made it into "production".

[1] http://goto.ucsd.edu:8090/index.html#?demo=Order.hs

Zababa3• 5 years ago

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 trying to solve, it stil has to ship with a defer mechanism (no linear/affine types/RAII) and a data race detector.

acchow3• 5 years ago

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.

skybrian2• 5 years ago

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.

sanderjd6• 5 years ago

Go has definitely gained more mindshare more quickly outside Google than inside, in my experience.

acchow3• 5 years ago

Go has a minimal type system, and is able to do much of Google's internal server side work.

And yet Go is adding generics in 1.8. And I'm sure its type system in another 5 years will be much more expressive than 1.8's. The community has long been saying that the minimal type system isn't enough.

benhoyt2• 5 years ago

Nit: they're adding Generics in 1.18 (not 1.8). Regarding "another 5 years": I'm not so sure. Go is very conservative about language changes. The type system didn't change at all from version 1.0 through version 1.17 (a 12-year period).

Chyzwar• 5 years ago

Rust contribution affect less than 1% of programmers. Most code written today do not require manual memory management or even explicit multithreading.

I think typescript with gradual and structural typing and similar like mypy or sorbet are making real difference.

Type systems provide multiple benefits, performance, self-documentation, better tooling and more explicit data model.

pkolaczk• 5 years ago

Most code written today do not require manual memory management

Rust has automatic memory management.

or even explicit multithreading.

You don't need explicit multithreading to run into data races. Languages that allow any kind of unchecked mutable state sharing and allow any form of concurrency (explicit or hidden) are prone to that problem.

Even single-threaded programs with aliasing of mutable variables are hard to reason about and Rust improves on that considerably by not allowing accidental aliasing.

agentultra2• 5 years ago

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 programs. You can write your programs and use the same language to prove theorems about them.

This is still fairly advanced stuff for most programming activities but the languages have been steadily getting better and the automation faster and I think the worlds will eventually collide in some area of industrial programming. We're already seeing it happen in security, privacy, and networking.

I don't think type systems suffer from complexity. They merely reveal the inherent complexity. You can use languages that hide it from you but you pay a price: errors only become obvious at run time when the program fails. For small programs that's easy enough to tolerate but for large ones? Ones where certain properties cannot fail? Not so much in my experience.

update: clarified wording of "proofs are programs"

spc476• 5 years ago

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?

dmitriid3• 5 years ago

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.

YorkshireSeason5• 5 years ago

The more rich the type system the more you can express

Why is this interesting? You pay an extremely heavy price in terms of language complexity. In practise, you almost never have the invarants at all or correct when you begin programming, and your programs evolve very rapidly. Since with dependent types you loose type-inference, you now what to evolve two programs rather than one. Moreover proofs are non-compositional: you make a tiny change somewhere and you might have to change all proofs. In addition we don't have full dependent types for any advanced programming language features, we have them only for pure functions that terminate.

the same language to prove theorems about them

That sounds like a disadvantage. Ultimately verification is about comparing two 'implementations' against each other (in a very general sense of implementations where logical specs and tests also count as implementations). And the more similar the two implementations, the more likely you are to make the same mistake in both. After all, your specification is just as likely to be buggy as your implementation code.

type systems suffer from complexity.

This is clearly false for just about any reasonable notion of complexity. For a start pretty much as soon as you go beyond let-polymorphism in terms of typing system expressivity, you looks type-inference. Even type-checking can easily become undecidable when the ambient typing system is too expressive.

There is no free lunch.

quickthrower2• 5 years ago

This advanced types stuff sounds really useful but it needs to be made very easy to use for the mainstream Java of C# programmer to use.

A success story in this regard is the async keyword. Very quickly you can get used to it and it feels like any other imperative programming.

In C# if I can add assertions and have C# compile time check the source that the assertion will not be violated. This would be great. I know they do this for null checking.

sigmaml• 5 years ago

Highly expressive type systems can lead people to as much design hell as does deep OOP. I have seen and experienced this in at least a couple of projects.

The only difference is: instead of brittle hierarchies, we get ossified compositions (depending on how much nominal vs structural typing happens).

We, of course, agree that we are quite some distance from having advanced type systems brought to day-to-day industrial programming.

mountainriver5• 5 years ago

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

marcosdumay• 5 years ago

and is able to do much of Google's internal server side work.

You mean, one of the companies with the largest number of developers on the world, paying one of the highest average salaries for them is able to use the language?

That means absolutely nothing.

darthrupert3• 5 years ago

Go has been used by way more successful startups than Rust, Haskell and others of their kind combined.

At least so far. Rust might change that in the future.

lmm4• 5 years ago

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.

Which is exactly what a type error is!

The Rust borrow checker is an invariant enforcer. It explicitly does automatic global analysis, and reports explicitly that what's going on at point B is inconsistent with what point A needs. This is real progress in programming language design, and is Rust's main contribution.
That's the direction to go.

The borrow checker is an ad-hoc informally specified implementation of half of an affine type system. Having to switch programming languages every time you want to add a new invariant is a poor paradigm. What we need is a generic framework that allows you to express invariants that are relevant to your program - but again, that's exactly what a type system is.

Rust has done a great thing in showing that this is possible, but linear Haskell or Idris - where borrow checking is not an ad-hoc language feature that works by gnarly compiler internals, but just a normal part of the everyday type system that you can use and customize like any other library feature - are the approach that represents a viable future for software engineering.

comex• 5 years ago

Rust has affine types, and uses them extensively: types that own memory, as opposed to borrowing it, are generally affine.

In principle you could implement a form of borrow check with linear types (I don’t think affine is good enough), but the ergonomics would be horrible.

sanderjd6• 5 years ago

It's not a fascination, it's just easier and better to have good static analysis when programming. That doesn't have to be a type system, but I think there is a lot of reason to think that a type system is the lowest hanging fruit for useful static analyses.

earleybird2• 5 years ago

I think this sums up the pragmatics well. Brian Cantrell discusses in one of his talks what they did at Sun to ensure they were writing safe C. This was a substantial amount of tooling they had to build up. Type systems bring you this tooling in a well founded, logical way. And as you say, it's a good place to start, even if it's just to know how the puzzle pieces of your code fit together.

Zababa3• 5 years ago

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.

preordained• 5 years ago

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.

Zababa3• 5 years ago

You know what they say about people with hammers.

zmmmmm2• 5 years ago

Hmm, how well does this scale though? you are passing around these giant maps of vectors of tuples and then you pass it to someone unfamiliar with the code, how the hell do they know what's in there? Is the order price the first element of the tuple or the second? What happens when I refactor things and now all the tuple elements shift over one? Surely you'll end up writing just as much in documentation as you would have to specify the types?

Currently working my way through some complex Python code written in that style and it's completely impossible to understand it. In fact, the only way I can actually do it is transforming all these ad hoc data structures into proper types so I can make sense of it.

spinningarrow• 5 years ago

If your data is not position-dependent a tuple doesn’t sound like the correct choice. In the price example you provided, a map would be much better.

As for how you know what’s in there - you should only know whether what’s relevant to your function is in there and not care about the rest of the world. For the former, tools like clojure.spec are helpful but ultimately good design helps the most (something that typed languages can often obscure).

sanderjd6• 5 years ago

I have the exact opposite experience. I can't think of anything I got more sick of than every freaking method in every rails project having `params = {}` where you have no idea what keys are required or expected or ignored. Easily 90% of these should have been named structures instead of these arbitrary data grab bags.

bcrosby952• 5 years ago

If you had a generic params map, you would likely destructure it and the keys would be obvious. Destructuring in Clojure also gives you a way to specify defaults for each key right there.

MrBuddyCasino2• 5 years ago

Agree that "map oriented" code bases are pretty bad. Always an unmaintainable mess, usually developed by single dev, painful to refactor. Seen this with Groovy back when some people thought this language had any merit.

lowbloodsugar• 5 years ago

"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.

zmmmmm2• 5 years ago

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 process? no! I'm specifying that it processes an Order data type, with all its 65 elements. But implicitly then I'm saying the function has 65 input parameters of all these specific types and nobody can call it now without providing them all. What a pain! Huge amount of extra code, refactoring, unit testing, because of this.

So either you end up with a cambrian explosion of micro-types or you have these way overspecified interfaces everywhere.

Compare with dynamic languages (or structural typing, Go etc) that only care that things "quack like a duck". The calculate_price function doesn't care what object you give it, as long as it has the two attributes it needs. Now I can unit test `calculate_price` with a 2-element object rather than needlessly creating the 23 irrelevant required elements of a valid Order.

I think a lot could be solved with culture shift. Where data types are really known and locked in, use the crap out of them. As soon as things get ambiguous or flexible, go right ahead and specify that your function takes a Map<String,Object>. If a useful concrete interface emerges at some point factor it out then. The problem is that this is really frowned upon in a lot of places.

mdoms• 5 years ago

Or you could just take the two parameters you're actually using on your function. No new type, no need to pass your mega-object, just take two nice strongly typed arguments.

brundolf• 5 years ago

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).

yen223• 5 years ago

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

bqmjjx0kac• 5 years ago

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

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.

mountainriver5• 5 years ago

The calculate_price function doesn't care what object you give it, as long as it has the two attributes it needs

The issue with this is it makes it difficult to understand code. If anything works potentially anywhere then the flip side is you have no idea what works anywhere without running the code.

Running code is slower iteration cycles than a type checker. Also you don’t actually know what it returned. So it was able to produce an output, was it what you expected? Or was it subtly different in ways that will break your code downstream.

I work at a company with a large untyped code base and the product is constantly breaking in these ways.

arc7768• 5 years ago

Compare with dynamic languages (or structural typing, Go etc) that only care that things "quack like a duck".

Go is a statically typed language. Unless you're referring to interfaces at run time?

I'm saying the function has 65 input parameters of all these specific types and nobody can call it now without providing them all. What a pain! Huge amount of extra code, refactoring, unit testing, because of this.

I've seen this "cambrian explosion of micro-types" argument before on HN but I think it comes from a misunderstanding about what you actually do in a static language. No one's creating types for every combination of parameters.

Either you'd pass the two arguments directly (`a, b: int` or whatnot), or you'd pass the Order type and just use the bits you need.

If you have multiple Order types, you'd use generics or something like it to get duck typing. If you used a field that wasn't there, you'd get a compile error.

The reality is the code would look pretty much the same in both static or dynamic languages.

jim-jim-jim2• 5 years ago

In addition to what others have said about just passing two parameters, there also row types, where the signature of `calculate_price` can be specified to accept any record that has the two required fields.

mratsim3• 5 years ago

Isn't that duck type?

Too2• 5 years ago

Typescript can do exactly what you ask for, “static duck typing”. Just define the input argument to be a interface with the 2 relevant attributes, any struct having at least these 2 attributes are now allowed, even if there is no explicit inheritance to it. This can be done inline in the function signature so doesn’t contribute to bloat.

Python can do the same using what they call Protocol. Here protocols need to be defined upfront.

This is usually called Structural typing, as opposed to nominal typing where classes inherit from a base.

AndyKelley• 5 years ago

This article incorrectly states that Zig has "colored" `async` functions. In reality, [Zig async functions do not suffer from function coloring](https://kristoff.it/blog/zig-colorblind-async-await/).

Yes, you can write virtually any software in Zig, but should you? My experience in maintaining high-level code in Rust and C99 says NO.

Maybe gain some experience with Zig in order to draw this conclusion about Zig?

chrisaycock• 5 years ago

Debating language design with people who don't actually know the language (or understand the features) is extremely frustrating.

But anyway, thanks for your work on Zig. Your metaprogramming concepts were heavily influential for some of the ideas in my own language, Empirical.

MrBuddyCasino2• 5 years ago

incorrectly states that Zig has "colored" async functions

This was indeed weird to read, given that only Zig (and soon the JVM) solves this problem, and is well known for the fact. Especially when language design and type theory are an area of interest.

But hey, silver lining: Zig still kind of came out on top.

pyrale• 5 years ago

I must admit I was very surprised so see what started as a static-types rant ending up extolling the merits of Idris.

mbrodersen3• 5 years ago

Almost all software running the world is written in statically typed languages. This is not by accident or because developers don’t know better. Every few months on HN somebody will make some new claim about why dynamically typed languages are somehow better. But the truth is that statically typed languages have won in the market place for real world software. And I don’t see anything changing that.

bcrosby952• 5 years ago

The article is about attempting to escape this static vs dynamic dichotomy, not about declaring dynamic languages superior to static ones.

mbrodersen3• 5 years ago

Yes you are right. And I do agree with the author regarding Dependently Typed languages.

darthrupert3• 5 years ago

Today I learned that python, javascript and php are statically typed languages.

Too2• 5 years ago

Any hygienic team using those today, are using analyzers on top, like mypy, hhvm or typescript.

mbrodersen3• 5 years ago

Python, JavaScript and PHP run on runtimes written in statically typed languages. And those runtimes run on operating systems written in statically typed languages, using hardware drivers written in statically typed languages. So yes the world does indeed run on statically typed languages. The code you write in Python/JavaScript/PHP is a thin layer on top of C/C++.

chubot• 5 years ago

Nice article! Highly related discussions:

https://github.com/fsharp/fslang-suggestions/issues/243#issu...

https://old.reddit.com/r/ProgrammingLanguages/comments/placo...

F# designer Don Syme is making the "biformity" argument, e.g. needing a debugger for compile time as well as runtime.

and

Syme & Matsakis: F# in the Static v. Dynamic divide https://old.reddit.com/r/ProgrammingLanguages/comments/rpcm6...

I still think something an application language with something like Zig's comptime would fill a big niche. (As opposed to a systems language.)

aabbcc1241• 5 years ago

One way to do dynamic macro in static type language is to generate the source code using the host language as separate build process before the compilation of hand-written and generated source code.

For example in Typescript, I use tsc-macro to run "*.macro.ts", they can import any functions and modules just like normal source code. And their evaluated result are saved as "*.ts"

The generated ts are then compiled alone with other hand-written typical source files into js for deployment and execution.

Why static languages suffer from complexity

Related Stories