Live data from Hacker News

I tried Gleam for Advent of Code

blog.tymscar.com

131–140 of 223 posts

Re: I tried Gleam for Advent of Code

#131
post #55

Earlier quoted context omitted.

> I fear LLMs have frozen programming language advancement and adoption for anything past 2021. Why would that be the case? Many models have knowledge cutoffs in this calendar year. Furthermore I’ve found that LLMs are generally pretty good at picking up new (or just obscure) languages as long as you have a few examples. As wide and varied as programming languages are, syntactically and ideologically they can only be…

There's a flywheel where programmers choose languages that LLMs already understand, but LLMs can only learn languages that programmers write a sufficient amount of code in. Because LLMs make it that much faster to develop software, any potential advantage you may get from adopting a very niche language is overshadowed by the fact that you can't use it with an LLM. This makes it that much harder for your new language…

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

Re: I tried Gleam for Advent of Code

#132
post #8

Gleam is a beautiful language, and what I wish Elixir would become (re:typing). For those that don't know its also built upon OTP, the erlang vm that makes concurrency and queues a trivial problem in my opinion. Absolutely wonderful ecosystem. I've been wanting to make Gleam my primary language, but I fear LLMs have frozen programming language advancement and adoption for anything past 2021. But I am hopeful that Gle…

I don’t mean to minimize the huge effort by the Gleam team; however, Elixir cannot become Gleam without breaking OTP/BEAM in the same ways Gleam does. As it stands now, Elixir is the superior language between the two, if using the full Erlang VM is your goal.

Re: I tried Gleam for Advent of Code

#133
post #41

Earlier quoted context omitted.

I recently used Gleam + Lustre for a small app that I normally would have built with Elm + PostgREST. It went very well, and I'm now planning to use it for a larger rewrite (of a rails app).

This Lustre? https://www.lustre.org/ Seems to be a filesystem, how would it replace a database?

This one is likely what they were referring to: https://github.com/lustre-labs/lustre

Re: I tried Gleam for Advent of Code

#134
post #41

Earlier quoted context omitted.

I recently used Gleam + Lustre for a small app that I normally would have built with Elm + PostgREST. It went very well, and I'm now planning to use it for a larger rewrite (of a rails app).

This Lustre? https://www.lustre.org/ Seems to be a filesystem, how would it replace a database?

No, this one https://hexdocs.pm/lustre/index.html

Re: I tried Gleam for Advent of Code

#135
post #120
post #101

Earlier quoted context omitted.

You can generate those conversions, most people do. But also, you shouldn’t think of it as writing the same type twice! If you couple your external API and your internal data model you are greatly restricting your domain modelling cability. Even in languages where JSON serialisation works with reflection I would recommend having a distinct definition for the internal and external structure so you can have the optimal…

>You can generate those conversions, most people do. Hi, what do people use to generate them, I found gserde (edit: and glerd-json)

The language server code action :)

Re: I tried Gleam for Advent of Code

#136

Earlier quoted context omitted.

There's a flywheel where programmers choose languages that LLMs already understand, but LLMs can only learn languages that programmers write a sufficient amount of code in. Because LLMs make it that much faster to develop software, any potential advantage you may get from adopting a very niche language is overshadowed by the fact that you can't use it with an LLM. This makes it that much harder for your new language…

> 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…

This last week:

* One developer tried to refactor a bunch of graph ql with an LLM and ended up checking in a bunch of completely broken code. Thankfully there were api tests.

* One developer has an LLM making his PRs. He slurped up my unfinished branch, PRed it, and merged (!) it. One can only guess that the approved was also using an LLM. When I asked him why he did it, he was completely baffled and assured me he would never. Source control tells a different story.

* And I forgot to turn off LLM auto complete after setting up my new machine. The LLM wouldn't stop hallucinating non-existent constructors for non-existent classes. Bog standard intellisense did in seconds what I needed after turning off LLM auto complete.

LLMs sometimes save me some time. But overall I'm sitting at a pretty big amount of time wasted by them that the savings have not yet offset.

Re: I tried Gleam for Advent of Code

#137

One thing im wondering with the LLM age we seem to be entering: is there value in picking up a language like this if theres not going to be a corpus of training data for an LLM to learn from? Id like to invest the time to learn Gleam, but I treat a language as a tool, or a means to an end. I feel like more and more I'm reaching for the tool to get the job done most easily, which are languages that LLMs seem to gel wi…

The Gleam language, yes all of it, fits in a context window (https://tour.gleam.run/everything/)

I have similar concerns to you - how well a language works with LLMs is indeed an issue we have to consider. But why do you assume that it's the volume of training data that drives this advantage? Another assumption, equally if not more valid IMO, is that languages which have fewer, well-defined, simpler constructs are easier for LLMs to generate.

Languages with sprawling complexity, where edge cases dominate dev time, all but require PBs of training data to be feasible.

Languages that are simple (objectively), with a solid unwavering mental model, can match LLMs strengths - and completely leap-frog the competition in accurate code gen.

Re: I tried Gleam for Advent of Code

#138
The `echo` part seemed interesting but it made me think, debuggers need this as a built in feature. If I have

    array
      .slice(0, 10)
      .filter(s => s[0].toLowerCase() l
      .map(s => s.toUpperCase());
It seems like it should be a common feature to be able to view between each array operation in a debugger without having to augment the code with `echo`

The out of bounds handling didn't seem all that good to me. Sure you can filter out undefined. You could also just make a function that returns an empty array if out of bounds, or array of 1 element if not.

     // JS
     function getElemFromGrid(grid, x, y) {
       return (x = grid.width ||
               y = grid.height)
         ? []
         : [grid.elems[y][x]]
     }
     
     ...
     
     neighbors = [
       ...getElemFromGrid(grid, x + 1, y + 0),
       ...getElemFromGrid(grid, x + 1, y + 1),
       ...getElemFromGrid(grid, x + 0, y + 1),
       ...getElemFromGrid(grid, x - 1, y + 1),
       ...getElemFromGrid(grid, x - 1, y + 0),
       ...getElemFromGrid(grid, x - 1, y - 1),
       ...getElemFromGrid(grid, x + 0, y - 1),
       ...getElemFromGrid(grid, x + 1, y - 1),
     ]

     
        
I also find grids made of 2 dimensional array to be code small. An array of arrays is NOT A GRID as there is nothing enforcing the inner arrays to be the same length as each other. Also, in efficienct code it would be better to provide a 1 dimensional array and bounds. Now, out of bounds checks based on accessing outside the array won't work. You need to check actual bounds. Again giving preference using a helper

Re: I tried Gleam for Advent of Code

#139
post #55

Earlier quoted context omitted.

> I fear LLMs have frozen programming language advancement and adoption for anything past 2021. Why would that be the case? Many models have knowledge cutoffs in this calendar year. Furthermore I’ve found that LLMs are generally pretty good at picking up new (or just obscure) languages as long as you have a few examples. As wide and varied as programming languages are, syntactically and ideologically they can only be…

There's a flywheel where programmers choose languages that LLMs already understand, but LLMs can only learn languages that programmers write a sufficient amount of code in. Because LLMs make it that much faster to develop software, any potential advantage you may get from adopting a very niche language is overshadowed by the fact that you can't use it with an LLM. This makes it that much harder for your new language…

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.

Re: I tried Gleam for Advent of Code

#140
post #72

I don’t know gleam, but surely list.map(fn(line) { line |> calculate_instruction }) Could be written list.map(calculate_instruction) ?

You're right, but loads of times I just left that there because I probably did something more involved in the map that I ended up deleting later without realising.

[deleted]
Post reply on HN