Testing something is the best way to prove that it behaves correctly in all the cases you can think of. Relying on your own (fallible) understanding is dangerous.
Of course, there may be cases you didn't think of where it behaves incorrectly. But if that's true, you're just as likely to forget those cases when studying the expression to see "what it actually says". If you have tests, fixing a broken case (once you discover it) is easy to do without breaking the existing cases you care about.
So for me, getting an AI to write a regex, and writing some tests for it (possibly with AI help) is a reasonable way to work.
I don’t believe this is true. That’s why we do mathematical proofs, instead of only testing all the cases one can think of. It’s important to sanity-check one’s understanding with tests, but mere black-box testing is no substitute for the understanding.
in theory theory and practice are the same, in practice not really
in the context of regex, you have to know which dialect and programming language version of regex you’re targeting for example. its not really universal how all libs/languages works
> It's fun to nerd out about memory allocators, but that's not contributing to overall improvements of software engineering as a craft which is still too much ad hoc hacking and hoping for the best.
I'm sorry, but it is. Understanding memory layout and (sometimes) using custom allocators can improve performance in ways that no compiler cannot do automatically. And when used correctly they contribute to code correctness too. This is the reason they are used in projects like Chromium.
Regarding your car analogy, you have to remember that developers here are not driving the car: they're building the car. Understanding the differences between and ICE engine and an electric motor are very salient to designing a good car.
> But what do those functions return? Oh look, it's DOM nodes, which are described by and implemented with inheritance.
Well of course. React builds on what the browser provides. And the DOM has been defined as a class hierarchy since forever. But react components don’t inherit from one another. If the react devs could reinvent the DOM, I think it would look very different than it looks today.
> theoretically it can react to crowds better than any human could
That's one area I'd expect AI to do poorly. Performance is a two-way dialog between performers and the crowd, with facial expressions and body movements from both the stage and the audience in communication. I'd expect any AI that's not attached to a humanoid robot to be less exciting to a crowd.
However, I am very excited about AI in some of the other contexts you mentioned, like as a music-writing or editing partner.
Imagine a club where the people dancing are wearing, for example, heart rate monitors amongst other things. In that scenario they already weren't looking at the DJ and the AI would have a steady stream of information to work with.
There are some things that rubbed me wrong way about it. Like typing but still giving way to runtime errors in specific scenarios or lack of macros (which is what makes Rust great to work with because otherwise it’s just sea of boilerplate eventually).
IMO the more sensible decision would be moving „down”. One still has to use some Erlang in Elixir (for example for tracing) and there are small benefits I appreciate lately - like visual differentiation between variable and an atom.
Runtime errors? As far as I know Gleam will never present runtime errors unless you manually add `todo`, `panic` or `let assert` statements. [1]
I feel you on the macros, I have wanted them too, but I respect the language creator's commitment to minimalism, and I don't feel that e.g. JSON decoders are too much effort. It seems the language is headed down the route of code generators rather than macros, which seems like a reasonable tradeoff to me. [2]
Yes, that’s let assert on pattern matches. We’ve briefly evaluated Gleam (but I only very shortly) and result was that we cannot port existing code any way and integration would be very difficult (especially given missing macros).
I do, however agree with you on macros and code generations. My hand in Rust is macro heavy (I dislike boilerplate) but in Go I learned to appreciate codegen utilities and it might be the way to go.
The topic itself is interesting, because I’ve been doing „business logic in types” and it’s impossible to pull of without invoking so much magic that keyboard starts to emit indigo and that puts Gleam in akward place because when we are at that place maybe it’s easier to write code generation with Prolog/Cue but instead of putting another layer just settle with Erlang/BEAM assembly.
But my problems are more in domain of „what happens when during daylight saving shift I receive an out of order message that should be included in generated raport of order fashion and one of node died at that point”.
Gleam has a subset of OTP functionality already [1]. It also compiles extremely quickly. I haven't made any huge projects yet, but I've used some fairly chunky libraries and everything compiles super quick.
Yes, I agree, insertion not moving things is a very useful feature of deques. It allows you to keep items with deleted copy and move constructors in a container that has good cache locality.
The word makes perfect sense, somebody just used it wrong. Don't let's go down the post-modernist "nothing means anything" route just because some people are too partisan to use words properly.
What the person should have said is "a Nazi made that car".
The C++ testing framework Catch2 enables this kind of testing. The first time I saw it I couldn't figure out how some of the tests would even pass.
It turns out that using some evil macro magic, each test re-runs from the start for each inner section [1]. It also makes deduplicating setup code completely painless and natural.
You just have to get over the completely non-standard control flow. It's a good standard bearer for why metaprogramming is great, even if you're forced to do it in C/C++'s awful macro system.
Can you explain why you don't like `use` but you would like an `await` keyword?
As far as I can see, `use` is a superset of the `await` transformation that just happens to work in a lot more situations. It circumvents callback hell when you're working on the Javascript target [1] but also de-indents lots of other code like handling results [2].
Of course, there may be cases you didn't think of where it behaves incorrectly. But if that's true, you're just as likely to forget those cases when studying the expression to see "what it actually says". If you have tests, fixing a broken case (once you discover it) is easy to do without breaking the existing cases you care about.
So for me, getting an AI to write a regex, and writing some tests for it (possibly with AI help) is a reasonable way to work.
reply