grumpyprole

Don't forget Ada/Spark and ATS.

This is where tooling can help. An IDE could display the type next to all auto symbols if you want. Or allow you to query it with a keyboard shortcut. This gives the best of both worlds, rather than forcing everyone to write out the types all the time. Sometimes we simply don't care what the exact type is, e.g. if it's an object created and consumed by an API. We still want it type-checked, but we don't want to be forced to write out the type.

You are confusing dynamic types with type inference.

> What types of issues do you experience?

In GHC Haskell, it can be difficult to predict the lifetime of heap objects and control when objects are not shared (optimisations may or not lift terms out of a local context).

It's an entire fork of the Python ecosystem. So not really that much different to what we have here. Maintaining an ecosystem of libraries and tools is the hard part, not a compiler or interpreter.

Sounds like you just need more practice. Haskell is more expressive than most other languages and offers much more consistent and powerful abstractions. This does result in more productivity once the learning curve is overcome.

> I do wonder if one might get those same benefits in another language without the problems which seem to crop up with Haskell

Not until other languages raise their game. Nothing compares to Haskell for productivity and I've tried many different languages professionally over the years (including Haskell). But yes, reasoning about what happens operationally is the big problem.

Why is it any different to "bank python" used by e.g. JPMorgan or BAML? Or Google writing Dart?

You won't need a Haskell PhD to work at a bank, even one that uses Haskell.

He probably means that GHC will parse and type check faster. Switching the front-end doesn't sound like it will circumvent the whole program nature of their compilation. But I'm just guessing.

I agree but the context was interpreters. GraalVM is a compiler, it JIT compiles bytecode into machine code.

Well implementing all the OOP semantics and such could complicate and dilute the essentials. A simpler language would also make it easier to cover more ground, such as type checking. So I don't think it sounds ideal from a pedagogical perspective either, but again, I haven't read the book.

Note that Lisp in Lisp (SICP) works well because Lisp itself is very simple and just the essentials. It's just one chapter in SICP.

Not the parent and I've never read that particular book, but the premise seems rather bizarre to me, where is the excitement in implementing a slow version of Java in Java? If anyone is going to want to implement a custom interpreted language, it will likely be very different to Java, e.g. Lisp, the core of a DSL or configuration language. But it's still going to probably have functions and data types. Writing Lisp in C is exciting, one is moving up the abstraction hierarchy, building a more expressive and powerful language.

If one wants to learn specifically how Java works, then maybe a book on compilers would be better?

They get the all love because they were not only technically excellent for their time but also affordable, they are we what we had. The Apple Mac was something I only read about.

Yes the AppleII priced itself out of the 8-bit home computer market. I never saw one in the UK in the 80's. One could get the same tech (6502) with an equally good BASIC and OS for less than half (e.g. Acorn BBC Micro was my choice).

Wow that's pretty misleading

VMs still probably a better fit for dynamic languages. But modern Java doesn't really need a VM.

> The quality standard has already been met

I acknowledged in my first post that a particular quality standard had already been met by AI. I also concede that this quality standard could be sufficient for many businesses. God help us all if it's 90% of businesses.

Is that where your 90% estimate comes from? Browsing Reddit? You are the one with the extraordinary claim (and it therefore requires extraordinary evidence).

I think your 90% number is significantly over-estimating. Most creative people are actually quite creative and not just recycling.

You will have to proof read anything it writes and you should also fact check it, otherwise you are taking a risk. However, this is very difficult to do if GPT4 is unable to provide references or citations, or any provenance at all.

The human with the art history background at least has some credentials, whereby the output can be trusted, to some degree and explained if necessary.

If there is a job that requires generating bullsh*t, then definitely it is at risk. Otherwise, no.

If you buy a laptop with good Linux support, e.g. a ThinkPad. It should be fine for well over a decade in my experience. That is better value than Apple offer.

Ubuntu offer an LTS distro though. In theory this should be more stable than Fedora. Perhaps it matters less for the desktop.

> Programming languages have settled on '=' for assignment and '==' for equality comparison.

Certainly not all. "=" is a poor choice for assignment as it has a totally different meaning in maths. Algol and Pascal got this right with ":=". Fortran got it wrong here.

> plus '=' is used for assignment in math just as often too

No it's a relational operator in math, so "x = x + 1" does not have the same meaning as assignment to a mutable variable.

Why does it have to be either extreme? It certainly looks much easier than Agda or Coq. As someone without a CS degree, I applaud them for not racing to the bottom and creating an ad-hoc dynamically-typed soup, which still needs an instruction manual, if only to figure out how the equality operator works.

> Do you have any good resources on OCaml5 effect handlers I can follow?

I encourage you to have a look at the published paper, it's an easy read and covers the motivation and examples:

https://arxiv.org/abs/2104.00250

Here's an excellent talk that walks through modifying a non-trivial code base for concurrency using effect handlers:

https://youtu.be/k3oQwpyXmpo

> It does feel to me like error's and async's both should remain orthogonal

They aren't completely orthogonal though, as both are effects. Haskell and Rust model both with Monads. OCaml 5 can model both with effect handlers. It is desirable to track the difference in types, this is something I hope the OCaml folks will add in the future.

> Long story short, this library solves the function colouring problem

For a great example of this, see OCaml 5 support for effect handlers. It's basically a generalisation of exceptions, very lightweight and elegant. I can't help but think this approach would have been a much better fit for Rust than the current async effort. Monads like Async and Result are a slippery slope into the world of FP, something Rust will never excel at. Effect handlers are an alternative which arguably better align with systems programming.

> It's usually used for logging and exceptions.

That's why I was querying it's suitability for profiling. The time to get a lock for a global "safepoint" and then release it must be significant no?

This of course relies on Java's reflection ability, in this case, an API to retrieve stack traces for all threads dynamically. An interesting question is how this is implemented and how regular invocation might affect the runtime (e.g. global locks).