Peaker

And this is why they need human brains in The Matrix

A type-class or just a callback type, vs pattern-matching, yeah.

There's a huge advantage to not everything being async/await. Knowing exactly when you yield control can give you atomicity and more determinism for free.

Then what you have is not "anything". You have an expression problem:

Either each element has some "handler" that does the right thing for that data type.

Or you have a set of cases that each data can be, and you handle them all.

Neither is just "any type". And static types are very suitable to describe either.

Everything is of course possible, but at what cost?

In my experience, with large projects, you get to pick 2:

Dynamic typing Development velocity Reliability

I've seen multiple large projects grind to a near halt in their development speed, and I've seen some retain development speed, but unreliably crash after various changes.

UT coverage is expensive. System tests don't catch everything. Either you fear changes, and the system rots, or you work very slowly with coverage for everything.

When do you have lists of lists of elements of any type?

What can you even do given such a value?

That's great for functions you just wrote. It's not as great for functions you change in a large code base.

Rust is a great systems language.

When I write applications, I don't need a systems language, and Haskell is easier to use.

Also, Rust is a great imperative language, it's not as great as a functional language, and you can't reap the benefits of pure functional programming.

An average US citizen contributes far more to pollution than the average African or Asian.

There are various library-level implementations. Here's the first one that turned up on Google:

https://raw.githubusercontent.com/target/row-types/master/ex...

Haskell has reasonable implementations of row types as well.

Life on Earth started within a few hundred million years, not 2 billion years.

I suspect the problem is mentoring. It took me months to get basic Haskell.

The people I mentored, though, could clarify any misunderstanding and get explanations from multiple viewpoints from me -- after years of experience with these abstractions. With such mentoring, you don't have to go through all the confusion phases.

Haskell record syntax with lenses is workable:

  import Control.Lens

  data MyRecord = MyRecord { _a :: Int, _b :: MyRecord }
  makeLenses ''MyRecord

Then you can use it nested like:

  over (b . b . a) (+5) myRecord

I've mentored programmers in Haskell and they were also productive within a few weeks.

I'm pretty sure I could get a student to write useful Haskell code in that time span with just mentoring and existing documentation material.

That's the Maybe type. The Maybe monad is this:

  instance Monad Maybe where
    return = Just
    Nothing >>= _ = Nothing
    Just x >>= f = f x

(And is not really related to the discussion)

Destroying a language's safety for a single use case is a terrible trade-off.

There are various possible solutions for circular structures that do not require destroying all static safety with nulls everywhere.

Isn't the bottleneck in any sequential access case the memory bandwidth?

IOW: Are the scalar instructions slower than memory bandwidth?

Of course that's true. But Lisp is shitty at controlling memory use, indirections, and manual MM.

They're not really "inheritance". They can do what inheritance can do, and much much more.

I agree about constexpr, templates and exceptions.

But C function pointers are not really emulating virtual functions. They're better and more powerful than virtual functions.

I can vet the guys who published this.

This is legit, and they haven't published anything that can be used maliciously.

You don't have to write it - you just have to avoid -Wall :-)

Why do they reduce the amount of code?

They add the ability for constructors to carry constraints, which aids expressivity in some cases.

But the majority of GADT uses purely add safety. Can use ordinary ADT without a type-variable that is correlated with the data constructor, and crash at runtime if the constructors don't match.

But you can do this without S-expressions.

DLang, for example, has free-form macros that they weirdly call "mixin" (as in, mixing in some text or declarations into the AST, syntax-wise).

Each mixin must be a valid AST subtree on its own, which gives the same guarantee that paren matching prior to macro expansion gives you.

Then, the compiler can interleave:

     parsing

  -> evaluating mixin strings
  -> resuming parsing of the mixin subtrees
  -> evaluating the deeper mixin strings
  -> ...

You get the power of Lisp macros, but without the Lisp syntax that is unattractive to many.

You can't use -Weverything on a real project.

It's full of noise.

You can enable many others though, but -Weverything is virtually useless.

Have you looked at https://github.com/Peaker/git-mediate ?

Everyone I talked into using it had always initially thought "meh" but later thanked me - claiming it's a huge life-saver :)

It makes solving conflicts into a fun mechanical game while reducing erroneous merges by a lot.

Allocate for the worst case use in the bss. The program's static size indicates explicit memory requirements.

Programs could be explicit about those constraints, encode more of them statically and check them statically.

True, but we don't have much trouble with it though. We don't directly call syscalls but use our own wrappers that take care of this for us.