iron VS enso

Scala has quite good support for refined types across multiple libraries. A solution using the refined library might look something like

> The output you see is not generated by python.

Obviously, as running the code generates a very different output…

> It's generated by an external type checker.

I know.

But again, you didn't say that.

You said the above code "generates" this…

Maybe you've heard that by now somewhere: Words matter… ;-)

> The context is python. We're talking about python. I'm making a statement about python.

No, you made a statement about type checking. Here the full quote once again:

> The contents of a string can't be type checked and if all methods are defined this way on a class none of it can be checked.

Nothing in this statement is about Python.

All I did was just proving your words once again to be nonsense: You can statically dispatch (which involves static type checking!) just fine on strings. My (Scala) code is prove of this fact.

> There is literally nothing in my statement to indicate I'm making a general statement about type checking.

LOL. Do you actually know what you're writing? Once more:

> The contents of a string can't be type checked and if all methods are defined this way on a class none of it can be checked.

That's a general statement… It couldn't be even more general, actually.

> But I will say checking for the contents of a string is rare for a type checker to do. That is a general statement that is generally true.

Once again complete nonsense.

There are whole libraries doing more or less nothing else than handling singleton types.

Whole software layers utilize that! But I guess you never heard of static data validation…

https://github.com/Iltotore/iron

You have so little clue, but such a big mouth… That's so embarrassing.

A helpful tip: Stop spiting out maximally general claims (because these are almost always wrong!), and think about what you're actually writing.

What's in your fantasy, or what you "may have meant" is irrelevant!

> The guy made factually incorrect statements and so did you.

That's exactly what I'm talking about: You're a severe DK victim as it seems…

> It's just true that he's wrong.

No, actually you are wrong with almost every claim, like I've proven now several times. And this nonsense still didn't stop… Oh, boy!

> people shouldn't get worked up about someone else identifying a mistake.

Think about that once again. Especially in the context that it's you who is wrong here with almost everything you say.

And no, nobody is "pedantic". It only gets quite unrealistic that someone who doesn't even get banal prose straight would be able to write any code. Because the computer is actually very pedantic. And after production is on fire you can't just come to your boss and excuse yourself with "but I've meant this differently, just the stupid computer did again not understand what I've meant".

But to be honest this would actually explain:

> I've likely worked for more companies then you in the last 5 years or so due to my personality. I don't stay at one place for long.

I have some suspicions to why you don't stay anywhere for long… And yes, that would be indeed related to personality…

You might want to check out Iron.

And there is a beginner-friendly ticket: Add alias for True constraint and IronType[A, True]

Annotation is not the only way (and probably not the best IMHO) to do refined types. You might be interested in Iron in Scala 3 or Refined in Scala 2/3.

The second major version of Iron is out, featuring a complete rewrite on top of better foundations.

> At least I have yet to see one that is actually useful in the sense of a generic (or even a single-purpose-built) language

Yeah as said, https://github.com/enso-org/enso seems to be a general purpose functional programming language with visual editor, but otherwise I haven't really seen any no-code solutions worth their salt. I'm not particularly a fan of enso either, but it's the best I've seen.

Although it's not quite the same, I do like what Enso[0] is bringing to the table, especially the 1:1 visual node/language interop. Whether this is generalisable to a fully decoupled interface remains to be seen, but there's definitely potential.

[0]: https://enso.org/

I think Enso is already taken by a YC company [0]. Could get confusing.

[0] https://enso.org

COMPANY: Enso Inc. TYPE: Full time LOCATION: Europe and United States of America – fully distributed company REMOTE: Only remote VISA: No VISA required DESCRIPTION: Hi, we are Enso (enso.org, Y Combinator S21)! We are looking for an amazing Cloud engineer to join our core team. We are a remote first company, working in Europe and the USA.

Friends of mine are developing Enso (https://enso.org/), an interactive programming language with dual visual and textual representations.

Even well before Bret Victor's time, there were tools for visual programming. I have been using LabView to maintain data processing in an optical laboratory.

> I'm convinced this entire space should be visual.

At my last 2 jobs I spent entirely too much time debugging Matillion jobs, which are visual. I have my doubts that it’s the panacea that it appears to be.

That said, you may find Enso particularly interesting: https://github.com/enso-org/enso