Comment by bnchrch

> Because LLMs make it that much faster to develop software

I feel as though "facts" such as this are presented to me all the time on HN, but in my every day job I encounter devs creating piles of slop that even the most die-hard AI enthusiasts in my office can't stand and have started to push against.

I know, I know "they just don't know how to use LLMs the right way!!!", but all of the better engineers I know, the ones capable of quickly assessing the output of an LLM, tend to use LLMs much more sparingly in their code. Meanwhile the ones that never really understood software that well in the first place are the ones building agent-based Rube Goldberg machines that ultimately slow everyone down

If we can continue living in the this AI hallucination for 5 more years, I think the only people capable of producing anything of use or value will be devs that continued to devote some of their free time to coding in languages like Gleam, and continued to maintain and sharpen their ability to understand and reason about code.

> but LLMs can only learn languages that programmers write a sufficient amount of code in

i wrote my own language, LLMs have been able to work with it at a good level for over a year. I don't do anything special to enable that - just front load some key examples of the syntax before giving the task. I don't need to explain concepts like iteration.

Also llm's can work with languages with unconventional paradigms - kdb comes up fairly often in my world (array language but also written right to left).

I bet LLMs create their version of Jevons paradox.

More trial and error because trial is cheap, in the end less typing but hardly faster end results

I don't think this is actually true. LLMs have an impressive amount of ability to do knowledge-transfer between domains, it only makes sense that that would also apply to programming languages, since the basic underlying concepts (functions, data structures, etc.) exist nearly everywhere.

If this does appear to become a problem, is it not hard to apply the same RLHF infrastructure that's used to get LLMs effective at writing syntactically-correct code that accomplishes sets of goals in existing programming languages to new ones.

You raise such an interesting point!

But consider: as LLMs get better and approach AGI you won't need a corpus: only a specification.

In this way, AI may enable more languages, not less.

I would argue it's more important than ever to make new languages with new ideas as we move towards new programming paradigms. I think the existence of modern LLMs encourages designing a language with all of the following attributes:

- Simple semantics (e.g. easy to understand for developers + LLMs, code is "obviously" correct)

- Very strongly typed, so you can model even very complex domains in a way the compiler can verify

- Really good error messages, to make agent loops more productive

- [Maybe] Easily integrates with existing languages, or at least makes it easy to port from existing languages

We may get to a point where humans don't need to look at the code at all, but we aren't there yet, so making the code easy to vet is important. Plus, there's also a few bajillion lines of legacy code that we need to deal with, wouldn't it be cool if you could port (or at least extend it) it into some standardized, performant, LLM-friendly language for future development?

> It’d be like inventing a new assembly language when everyone is writing code in higher level languages that compile to assembly.

Isn't that what WASM is? Or more or less what is going on when people devise a new intermediate representation for a new virtual machine? Creating new assembly languages is a useful thing that people continue to do!

We may end up using AI to create simplified bespoke subset languages that fit our preferences. Like a DSL of sorts but with better performance characteristics than a traditional DSL and a small enough surface area.

I believe prompting an AI is more like delegation than abstraction especially considering the non-deterministic nature of the results.

(I know Erlang well, but haven't used Gleam)

The library the parent links to says this:

> Not all Erlang/OTP functionality is included in this library. Some is not possible to represent in a type safe way, so it is not included.

Does this mean in practice that you can use all parts of OTP, but you might lose type checking for the parts the library doesn't cover?

> Hi, I’m the creator of Gleam!

What's the state of Gleam's JSON parsing / serialization capabilities right now?

I find it to be a lovely little language, but having to essentially write every type three times (once for the type definition, once for the serializer, once for the deserializer) isn't something I'm looking forward to.

A functional language that can run both on the backend (Beam) and frontend (JS) lets one do a lot of cool stuff, like optimistic updates, server reconciliation, easy rollback on failure etc, but that requires making actions (and likely also states) easily serializable and deserializable.

Fair enough, but to be fair to my statements, the quotes I chose were largely from gleam-lang.org or the Gleam OTP library.

Take for example this section of the Gleam website FAQ section:

https://gleam.run/frequently-asked-questions/#how-does-gleam...

"Elixir has better support for the OTP actor framework. Gleam has its own version of OTP which is type safe, but has a smaller feature set."

At least on the surface, "but has a smaller feature set" suggests that there are features left of the table: which I think it would be fair to read as a subset of support.

If I look at this statement from the Gleam OTP Library `readme.md`:

"Not all Erlang/OTP functionality is included in this library. Some is not possible to represent in a type safe way, so it is not included. Other features are still in development, such as further process supervision strategies."

That quote leaves the impression that OTP is not fully supported and therefore only a subset is. It doesn't expound further to say unsupported OTP functionality is alternatively available by accessing the Erlang modules/functions directly or through other mechanisms.

In all of this I'll take your word for it over the website and readme files; these things are often not written directly by the principals and are often not kept as up-to-date as you'd probably like. Still even taking that at face value, I think it leaves some questions open. What is meant by supporting all of OTP? Where the documentation and library readme equivocates to full OTP support, are there trade-offs? Is "usable as normal" usable as normal for Erlang or as normal for Gleam? For example, are the parts left out of the library available via directly accessing the Erlang modules/functions, but only at the cost of abandoning the Gleam type safety guarantees for those of Erlang? How does this hold for Gleam's JavaScript compilation target?

As you know, Elixir also provides for much OTP functionality via direct access to the Erlang libraries. However, there I expect the distinction between Elixir support and the Erlang functionality to be substantially more seamless than with Gleam: Elixir integrates the Erlang concepts of typing (etc.) much more directly than does Gleam. If, however, we're really talking about full OTP support in Gleam while not losing the reasons you might choose Gleam over Elixir or Erlang, which I think is mostly going to be about the static typing... then yes, I'm very wrong. If not... I could see how strictly speaking I'm wrong, but perhaps not completely wrong in spirit.

I wonder why so many have got this wrong across this thread? Was it true once upon a time or something, or have people just misunderstood your docs or similar?

hey, thanks for the clarification. I was under the impression that Gleam had a few shortcomings re: OTP, like missing APIs or the need to fall back to Erlang. Many people I know who work regularly with Elixir hold similar opinions - do you have any idea what happened there? Is there a lack of publicity for this support? Is it a documentation problem?

"Big Elixir" must be paying people to misunderstand Gleam today eh ;-)

who cares, just dont shove political opinions into a software project that developers. we are devs not jobless sjw's running around the road with some useless sign board

They are working towards "the real thing", whatever your definition of real is.

BTW in the 90s people tried to come up with a type system for Erlang, and failed:

--- start quote ---

Phil Wadler[1] and Simon Marlow [2] worked on a type system for over a year and the results were published in [3]. The results of the project were somewhat disappointing. To start with, only a subset of the language was type-checkable, the major omission being the lack of process types and of type checking inter-process mes-sages. Although their type system was never put into production, it did result in a notation for types which is still in use today for informally annotating types.

Several other projects to type check Erlang also failed to produce results that could be put into production. It was not until the advent of the Dialyzer [4] that realistic type analysis of Erlang programs became possible.

https://lfe.io/papers/%5B2007%5D%20Armstrong%20-%20HOPL%20II...

--- end quote ---

[1] Yes, that Philip Wadler, https://en.wikipedia.org/wiki/Philip_Wadler

[2] Yes, that Simon Marlow, https://en.wikipedia.org/wiki/Simon_Marlow

[3] A practical subtyping system for Erlang https://dl.acm.org/doi/10.1145/258948.258962

[4] https://www.erlang.org/doc/apps/dialyzer/dialyzer.html

I hate how people talk about type systems as if there were no trade-offs to be considered. A Hindley–Milner style type system would effectively kill half the features that make Elixir amazing, and worse, would break pretty much all existing code.

- No state machine behaviours. Gleam cannot do gen_statem.

- Limited OTP system messages. Gleam doesn't yet support all OTP system messages, so some OTP debugging messages are discarded by Gleam.

- Gleam doesn't have an equivalent of gen_event to handle event handlers.

- Gleam doesn't support DynamicSupervisor or the :simple_one_for_one for dynamically starting children at runtime.

homepage