Zompist Bboard Again

jcb wrote: ↑Tue Mar 21, 2023 12:27 am

I’m working on this! There’s a couple of languages with some support for units (Frink, F#), but nothing which is both good and statically typed. I haven’t quite figured it out yet, but there’s enough literature on how such a language would work that I’m sure I’ll manage it eventually.

Good ! The 1998 Mars climate orbiter crash inspired this, and again, the fact that this kind of problem still exists 25 years later should make the whole field of computer science ashamed.

Oh, this isn’t a CS problem. This can be done already, like I said. It’s just that industry hasn’t adopted languages with rich enough type systems yet — though given the success of TypeScript, that may be changing.

It’s just that industry hasn’t adopted languages with rich enough type systems yet

That's what I mean by CS here.

though given the success of TypeScript, that may be changing.

TypeScript can do this ?

jcb wrote: ↑Tue Mar 21, 2023 12:52 am

though given the success of TypeScript, that may be changing.

TypeScript can do this ?

No, but it has a richer type system than many other languages which have become popular in industry. Rust too, come to think about it. Maybe a language with dimension types will get popular soon…

jcb wrote: ↑Tue Mar 21, 2023 12:12 am What I would like to see is a system that lets one add units/measurements to types. So,

Code: Select all

3 feet + 5 meters

gives a compiler error (or auto converts units appropriately), but still lets me use any ft and m type with any function with an integer parameter, thus relieving me of having to duplicate function definitions for different types. ( (+) for both ft and m). Of course, the types would combine appropriately when multiplied and divided. Thus, a function for velocity would have a return type of m/s, and acceleration m/s^2, and would raise a compiler error if the value returned didn't match the signature.

Can't Ada be bludgeoned into doing this? I think you need a lot of renaming to hide the multiplication and division that come from the scalar types, which is why I say 'bludgeoned'.

comconlang idea: a language in which no integer or float can be passed to anything if it's not explicitly stated in what unit it is. units are imported as python libraries, and the language is open source, so generic "times", "blobs", and "things" are competing alternatives that allow the programmer to just play around with unitless numbers. the compiler crashes if it is even possible to divide "times" unless you add a method to the "times" class specifying what half a time.

Torco wrote: ↑Fri Mar 24, 2023 3:08 pm comconlang idea: a language in which no integer or float can be passed to anything if it's not explicitly stated in what unit it is. units are imported as python libraries, and the language is open source, so generic "times", "blobs", and "things" are competing alternatives that allow the programmer to just play around with unitless numbers. the compiler crashes if it is even possible to divide "times" unless you add a method to the "times" class specifying what half a time.

If you write an EBNF grammar, it's usually, if not easy, fairly systematic, to write a recursive descent parser.

This post reflects my personal opinion. It's not an objective assessment about CS.

jcb wrote: ↑Mon Mar 20, 2023 3:11 pm Imo, the OOP craze (Java, C++, etc) has stunted programming language evolution for a whole generation.

Personally, syntactic differences don't register with me anymore. My mind works in categories like "arrows" (functions; thanks, category theory) and "boxes" (variables), over which I layer programming language skins. I guess my "favorite" language is C++. It's relatively fast, it supports lambdas, and it's what I was taught. People say that languages have "better" or "worse" syntax, but syntax just looks like a bunch of absurd symbols that leave me cold. I do use prototyping languages like Python, Matlab and sometimes even Logo. I don't know if the syntax for these is "better". It can be shorter, but brevity cuts both ways. I often want functions to stand out flamboyantly.

I don't understand why functional programmers think their paradigm representss such an advance in general programming. How does making things more static provide an advantage? How can programmers be expected to write large and complex code without seeing incorrect outputs?

jcb wrote: ↑Mon Mar 20, 2023 3:11 pm Why does he hate it ? ... There are things I dislike about Haskell, but Elm fixed most of them.

I don't know much about Elm.

jcb wrote: ↑Mon Mar 20, 2023 3:11 pm Such as ? I find most of Haskell's deeper features useless and needlessly complex (elm wisely never implemented them for this reason), but then again, I'm not an academic doing academic things with Haskell, which is why most of those features exist in the first place.

I was talking about the coding style bradrn mentioned.

rotting bones wrote: ↑Sun Mar 26, 2023 12:20 pm Personally, syntactic differences don't register with me anymore.

Same with me. I think most experienced programmers think like this.

"arrows" (functions; thanks, category theory)

Pedantic note: the arrows of most categories aren’t functions! The whole point is that category theory abstracts over a huge range of different structures. (Not that it matters for programming, of course.)

I guess my "favorite" language is C++. It's relatively fast, it supports lambdas, and it's what I was taught.

I think this is the first time I’ve ever heard someone call C++ their favorite. It inherits all the bad parts of C, plus adds a huge number of footguns of its own, set to fire at any moment. There is such a thing as a language being ‘too complex’, and this is the case with C++. (At least in my opinion.)

I don't understand why functional programmers think their paradigm representss such an advance in general programming. How does making things more static provide an advantage? How can programmers be expected to write large and complex code without seeing incorrect outputs?

Firstly: you say you like C++ in part because it supports lambdas. That’s an innovation from FP, ultimately. Quite a lot of the things which used to be ‘uniquely FP’ have now diffused into most mainstream languages, so obviously people did think it represented an advance.

As for Haskell: I don’t think anyone’s ever seriously claimed that it eliminates incorrect outputs (i.e. bugs) altogether. Just that it prevents a bunch of common bugs. And this agrees with my experience: when I write a program in Haskell+JavaScript or Haskell+C++ or whatnot, the non-Haskell portion always has more bugs than the Haskell portion. And Haskell is the only functional language for which people regularly make such claims.

Also, I think you’ll find the Haskell community is quite open to doing things in a non-static way. As long as it can be represented in the type system, people are generally happy with it. And I get the impression people really like features such as macros and extensible records/variants, which are features more usually associated with dynamic languages. (I like this post on the topic: http://blog.ezyang.com/2012/08/is-haske ... servative/. Make sure to read the linked Yegge article too!)

jcb wrote: ↑Mon Mar 20, 2023 3:11 pm Such as ? I find most of Haskell's deeper features useless and needlessly complex (elm wisely never implemented them for this reason), but then again, I'm not an academic doing academic things with Haskell, which is why most of those features exist in the first place.

I was talking about the coding style bradrn mentioned.

Wait, which one? This conversation has gone on for so long I’ve forgotten what you’re talking about.

How does making things more static provide an advantage?

Would you rather your compiler tell you that something's wrong before it compiles ? (and then immediately force you to account for the case), or would you rather your program crash and burn at some unknowable time in the future? Furthermore, if your program compiles in a non-static language, how do you know whether it's truly free of bugs !? It's like playing a game of russian roulette, but you don't know how many bullets are in the chamber. Maybe there's 0, or maybe there's 6 ! Maybe you think there's 0, but you find out that there is 1 (again, maybe more, after all, we can't tell in this system !!) at 3:00 AM when you'd really rather be sleeping than coming into work to fix the program/app that just broke. Or maybe it's not even possible to "go in" and fix the program, because the program is on a space probe that's millions of miles away from earth, so now the space probe has just become very expensive space debris.

How can programmers be expected to write large and complex code without seeing incorrect outputs?

That's exactly the problem ! Weakly and dynamically typed languages hide that info until it's too late (at **run-time**), which crashes the program. Strongly and staticly typed languages will show you the error at **compile-time**. This allows you to fix it before the program compiles, and **prevent it from ever happening**. As a corollary, if your code compiles in such a language, your can be sure that it has no bugs, and will (almost) never crash. (And if it does crash, it'll be for reasons that have nothing to do with the type system, like recursing too deeply.)

I guess my "favorite" language is C++. It's relatively fast, it supports lambdas, and it's what I was taught.

Firstly: you say you like C++ in part because it supports lambdas. That’s an innovation from FP, ultimately. Quite a lot of the things which used to be ‘uniquely FP’ have now diffused into most mainstream languages, so obviously people did think it represented an advance.

brdrn already said it. C++ didn't have lambdas when I was learning it 15 years ago. Many FP things have leeched into mainstream OO languages nowdays, precisely because people have found them useful.

I don't know much about Elm.

It's like Haskell, but less complex/bloated, and is designed for making webapps. https://elm-lang.org

Note its tagline: """A delightful language for **reliable** web applications.""" (emphasis mine)

I think I am in this a... centrist? I'm a python peasant, and a hobbyist at that, don't get me wrong, but I've written in kotlin and I can understand the use for explicitly, exhaustively just saying what you mean, right? this isn't a list I'm going to be passing you, function, this is going to be a list of integers: get anything else and you need to unalive yourself and give me this string as an error message (or whatever the compilation error equivalent is). And document in comments that yes, this object SQLMaker is, you know, the thing writing the SQL for when you consult the database. But at some point, its got to get tedious enough that the faff isn't worth the sturdyness. and that point is, I think, different for different applications.

In a way, static vs dynamic is kind of like vernacular vs academic language. I sometimes wish human languages would be statically typed

But at some point, its got to get tedious enough that the faff isn't worth the sturdyness. and that point is, I think, different for different applications.

My experience has taught me the opposite of what you're implying. That is, doing a short script in Python or some other dynamic, weakly typed language is fine, but trying to do a large project with many interacting parts in such a language is a nightmare. The sturdiness gained is totally worth the minor faff and tedium.

I think that you're misunderstanding the situation. If you write a program in Python and it runs fine at first, **that doesn't mean that you're program is free of bugs**. It just means that it might have bugs, and if it does have them, **you won't find out about it until the program tries to do it at runtime, when it crashes**. You're just pushing the inevitable bug-fixing session to some random and inconvenient time into the future (while possibly putting people's data and lives at risk, depending on the program), instead of detecting and fixing it before compilation.

My mind works in categories like "arrows" (functions; thanks, category theory) and "boxes" (variables), over which I layer programming language skins.

Then why do you say that your favorite language is C++ ? You don't still think about manually managing the heap or the stack, do you ? Those were things that imperative languages have long let the programmer forget about. Then why not take it a step further and stop thinking about manually managing union types, or pointers, or the bytecode implementation of utf8, etc ?

It is a truth universally acknowledged that:

- If you use strong typing, you will sooner or later encounter situations where weaker typing would be much more convenient and useful.
- If you use weak typing, you will sooner or later encounter situations where stronger typing would be much more convenient and useful.

I have done both, frequently.

the centrist solution would be optional typing, but I can't help but thinking that switch typing would be more fun!

require <stuff>
!strongtype = True
<code>

though one might as well just mix langs at that point, i suppose.