jonnycat

This should be required reading for every software engineering team (and the business & product teams they interact with).

Good point - definitely some rough edges around the search, I'll make sure that gets addressed. Thank you for the feedback!

Thanks for spotting that - I'll make sure the disclosures get added!

There are a couple of options to simplify and emulate a ternary operator:

if x, do: y, else: z

Or, though it's not very idiomatic Elixir, this also works:

x && y || z

Their mathematical analysis is for sure beyond my understanding, but on some level, I'm surprised this is surprising. While baby steps may be the norm in gradient descent, there are plenty of there optimization techniques that embrace larger step sizes. Some, like simulated annealing, explicitly model changes in step size over time. Others, like genetic algorithms with crossover let the balance between exploration (big steps) vs exploitation (small steps) emerge more organically.

In fact, applying the idea of "no free lunch in search and optimization" (https://en.wikipedia.org/wiki/No_free_lunch_in_search_and_op...), you'd kind of expect this result: sometimes big steps good, sometimes big steps bad.

I agree with the overall assessment, but there's a catch: even "highly skilled" workers are not skilled in "all the things". I've felt that ChatGPT hasn't increased my productivity in my core languages and frameworks, but it has helped immensely in areas where I'm not an expert.

To be concrete about it, I recently ported a project from SwiftUI on iOS (an ecosystem I am very comfortable with) to an Android app written in Kotlin (an ecosystem I mostly dread). I don't find ChatGPT very helpful with my day-to-day Swift stuff, but it was incredibly helpful with the Android work, from language syntax to idioms to outright translation of code.

I largely agree with this. I've been coding professionally a pretty long time and have worked with a wide variety of languages (including quite a lot of Objective C back in the day), and I've just never met a language with a larger surface area than Swift.

I can work with Swift and be productive with it, but at the same time, I feel like I still encounter new patterns, gotchas, property wrappers, language quirks, language changes, type-system oddities, etc, almost every day, and I have a hard time keeping track of it all.

Oh hey, I worked on Push with Lee at Hampshire and am one of the authors on that page. I never expected to see this on HN in 2023!

I haven't been involved with actual GP research for a long time, but writing a Push interpreter and GP system remains one of my "Hello, World" projects when learning a new language.

The "blue checkmark" of beers. This bottle certifies that the person holding it has $30.

I was a bit involved in more old-school AI research in grad school around ~2000, with an interest in the sadly neglected field of Artificial Life. A lot of Alife is focused on the simulation of life-like behavior and at least part of the field leans towards more philosophical questions: "Can an artificial agent truly be alive? Can it truly think?".

I thought these were fascinating and very difficult to answer questions.

When I would tell people about the field and these questions 20 years ago, people thought the questions were laughable, and some thought I was a fringy werido. But now, it seems like the pendulum has swung completely to the opposite side: of course machines can think and be alive.

But for me, my position hasn't really changed: I still think these are fascinating and very difficult to answer questions, and the deep learning revolution of the past several years hasn't actually done much to answer them. What LLMs are doing right now is amazing - but hasn't really moved the needle on the deeper questions, and a lot of the people who think it has are Fooled by Non-Randomness (apologies to Taleb).

I don't know what it will look like, but remember that the job of a "coder" is not to "write code" but to solve business problems.

The programming profession has always demanded that developers operate at higher and higher levels of abstraction and produce more/bigger/faster. I expect LLMs to continue that trend - a tool to get more done at a bigger scale.

Forgive the plug, but I just wrote up a post[1] on simulating Hypercycles, which are a model showing how self-replication behaviors can emerge through the interactions of simple molecules. Not to say that they are the mechanism, but are an interesting model for exploring emergent behaviors and the conditions under which self-replicating systems can arise.

[1] https://blog.devgenius.io/origins-of-life-building-a-hypercy...

The thing that a lot of the AI cheerleaders miss is that the mechanism through which these models "lie" is exactly the same mechanism through which they "look smart".

A tangent from the point of the post, but Komar & Melamid did a similar "experiment" with music to produce both the most wanted and most unwanted songs, and the results are amazing/hilarious.

The most unwanted song, for example, features all the thing people dislike in music (according to their surveys): opera singers rapping about cowboys, bagpipes, uncomfortably slow tempos, and choirs of children singing ad jingles among other things.

https://www.youtube.com/watch?v=-gPuH1yeZ08

A lot of the discussion here is about inferring the model's chess capabilities from the lack (or occasional presence) of illegal moves. But we can test it more directly by making an illegal move ourselves - what does the model say if we take its queen on the second move of the game?

Me: You are a chess grandmaster playing as black and your goal is to win in as few moves as possible. I will give you the move sequence, and you will return your next move. No explanation needed. '1. e4'

1... e5

Me: 1. e4 e5 2. Ngxd8+

2... Ke7

This is highly repeatable - I can make illegal non-sensical moves and not once does it tell me the move is illegal. It simply provides a (plausible looking?) continuation.

This is exactly right. Actually writing the kind of code that ChatGPT produces is a vanishingly small part of my job. And there's a ton more specialized scenarios to deal with, like next week when the third-party company is breaking the contract in <contract_json>.

If you want to hire a developer to implement qsort or whatever, ChatGPT has them beat hands-down. If you want to build a product and solve business problems, there's way more involved.

Of course, this often works the other way as well: a project is failing or stalled by the "wrong" theory being saturated through the team, and it can only be fixed by replacing individuals and developing new mental models of the problem.

Same here, I only learned about it as an adult.

If you need any kind of interactivity on the frontend, but are more comfortable with the backend, I would suggest looking at Phoenix LiveView [0] or a similar server-rendered HTML technology for your language of your choice [1].

In short, these solutions take JavaScript out of the mix entirely and basically let you deal with a single logical "app", rather than a separate frontend & backend.

[0] https://github.com/phoenixframework/phoenix_live_view [1] https://github.com/dbohdan/liveviews

Nobody bothers to write about the languages and technologies that are actually dead.

I've seen so many posts like this talking about programming language demand as a number of positions available - but I don't think I've ever seen one talking about programming language supply. JavaScript is certainly in high demand, but the market is also brimming with JavaScript developers.

Some other languages on the other hand, are far less common, but because they occupy a specific niche, might actually be more "in demand" (ie, less competition for an applicant, higher salary).

I can understand the value prop to the consumer - but I have a harder time understanding why it's an actual business, and why existing credit card companies or other lenders can't eat their lunch with the flip of a switch.

The a-ha moment for me was that functional programming - in most real world applications - is less about "no state" and "no side effects", and more about "properly managed state" and "properly managed side effects". This is one of the things I really like about Elixir/Erlang/OTP - of course your application needs to manage state, but it's well contained and well managed, avoiding a lot of common pitfalls.

The end result is superficially different. That's the point - we like the flow of the end result! But the implementation is completely different, as it's pure functional compared to object oriented.

"string".do_stuff() - do_stuff() is a method on the "string" class, with all of the potential gotchas that might come with an OO implementation. Does the method mutate the internal state of the object? Does the particular class override the default implementation? Is it a monkey-patched implementation (the issue raised by this article)?

"string" |> do_stuff() - do_stuff() is a standalone pure function. The data is immutable and does exactly what it says.

Elixir (and some other languages as well) solves this with the pipe operator:

some_array |> do_thing() |> do_another_thing() |> do_something_else()

Even though Elixir is functional and aggressively not object oriented, if you squint at this pattern you get the readability of an OO-style method chaining API.

You'd be forgiven for thinking that all SWE positions are high-paying soulless FAANG jobs - those jobs get a lot of attention and are very appealing to a lot of people.

But there are tons of other kinds of SWE jobs out there that aren't about squeezing another fraction of a percent of profit out of some process - positions with non-profits, development jobs in medical research of all kinds, or even early stage startups where you get to play a bigger role in the product development. You probably won't make FAANG money, but you can do just fine for yourself in a position where you feel like you're doing something more meaningful.

"Man on bicycle moves so fast he's banned from running competitions"

It only needs to be "data-driven and backed by science" if it's making scientific claims. It's totally okay to write a book of advice about workplace interactions based on anecdotes or your own experience (there are many such books) - but it's an entirely different thing to make scientific-sounding claims about how people are categorized.

I think there's a certain trap that many software engineer & technical types fall into with crypto. Crypto & blockchain are often portrayed as technically superior solutions to many problems, especially by non-technical people. Many of these problems, upon technical scrutiny, are actually not better with crypto: for most crypto use-cases, one could build a more efficient, simpler & "technically superior" solution using centralized services like, I don't know - a Postgres database and a REST API. In this way, a lot of technical people see crypto as a solution in search of a problem.

But the interesting thing about crypto is - in my opinion - not technical: it's social, and economical. Due to the decentralization, it changes the kinds of systems & solutions that are socially and economically viable. When I say "economical", I don't mean that the solutions are necessarily cheaper in the dollar sense, but in the sense that it changes which parties can participate in and profit from those systems. DeFi, for example, lets individuals participate in, and benefit from, transactions that used to only be provided by traditional banks.

So while there are many technical types that do see this side of crypto, there are many for whom their deeper technical understanding is a bit of a liability on the topic.

The people here saying the label is "correct" are both wrong, and missing the point. The objective of the model is not "taxonomic classification", the objective is "video recommendation". The label, in the context of the purpose of the model, is completely wrong.