syklemil (u/syklemil)

syklemil commented on The programmers who live in Flatland blog.redplanetlabs.com/20... · Posted by u/winkywooster

johnfn · 3 months ago

Is it really that uncharitable? Yes, it's slightly hyperbolic, but I argue only slightly. Whether intended or not, the tone of the article is patronizing. Here are some examples.

> The programmers who live in Flatland

> Likewise, you cannot comprehend a new programming dimension because you don’t know how to think in that dimension

> the sphere is unable to get the square to comprehend what “up” and “down” mean.

All of this is patronizing. It implies that I am incapable of understanding the benefits of Lisp. If only I were able to lift myself out of the dull swamp I find myself in! But I am capable, and I do understand them, and I still don't like it! And I think most Lisp detractors do as well! I would argue that it is the Lisp proponents that live in Flatland - they need to understand that there's another dimension to criticisms of Lisp that aren't just "I don't like parentheses" and that there is substantive feedback to be gleaned.

syklemil · 3 months ago

> they need to understand that there's another dimension to criticisms of Lisp that aren't just "I don't like parentheses" and that there is substantive feedback to be gleaned.

I'm also somewhat reminded of the decline of Perl and how some people who love and still frequently use Perl don't really seem to even acknowledge the complaints people have about it, which seems to prove the claim about the decline being cultural. According to that kind of attitude, the lack of popularity is inexplicable, and we might actually be lucky that they're not resorting to conspiracy theories to "explain" the mismatch between their preferences and observable reality.

The Haskell motto of "avoid success at all costs" seems a lot healthier, as in, they know they might need to choose between going mainstream and getting to keep a language that suits them personally.

Lots of the Lisp advocacy also comes off as either entirely too vague, like this blog post, or stuck in the age of the `worse-is-better` talk (1989, so predates WWW and nearly all the programming languages in widespread general use). I don't care about comparisons to C, because the only places C is seriously considered for new projects these days are in places where a GC is unacceptable (and purposes Rust isn't certified for or whatever).

syklemil commented on The programmers who live in Flatland blog.redplanetlabs.com/20... · Posted by u/winkywooster

GMoromisato · 3 months ago

I'm curious here, because I don't know Rust. What's the difference between a macro and a function call from the caller's perspective? Do I (as the caller) need to know I'm calling a macro? Why?

Why is println! a macro when it's a function in almost all other languages?

syklemil · 3 months ago

I think another macro, `json!()` works better as an example for that: inside the `json!()` you write something very similar to actual JSON. So when you see a `!` you know that there might be something out-of-the-ordinary following: https://docs.rs/serde_json/latest/serde_json/macro.json.html

Incidentally it also means that formatters like `rustfmt` won't apply the usual rules. For the macros that don't really deviate from ordinary Rust syntax, that can be a bit annoying.

syklemil commented on Perl's decline was cultural beatworm.co.uk/blog/compu... · Posted by u/todsacerdoti

twoodfin · 3 months ago

Perl did have `use strict`, so there was at least some plausible path to making non-breaking changes under a new pragma.

The OP’s theory that Perl 6’s radicalism allowed Perl 5 to be conservative sounds right to me.

syklemil · 3 months ago

Though at the same time the bit where `use strict` was optional wound up being off-putting to a lot of us, at least in part because we'd always wind up with _something_ that wasn't designed for `use strict` and had, uh, interesting failure modes.

It's the same drive that we see from JS to TS these days, or adding type hints to Python, and even to some extent why people pick up Rust: because you get a refusal to act and an explanation rather than wonky results when you goof.

IME there's been a wider shift away from worse-is-better, and Perl was kind of one of the early casualties of that. Part of that is also how science has marched on: When Python and Perl were new, the most popular typed languages were kind of tedious but not what people would consider _good_ at types these days. Perl was the first language I learned, and if I was transported back to the 1990s, I'd probably still pick it, even if I don't use it in 2025.

(OK, maybe I'd go all in on OCaml. Any way the camel wins.)

syklemil commented on Jujutsu for everyone jj-for-everyone.github.io... · Posted by u/Bogdanp

paradox460 · 6 months ago

I've been enjoying JJ recently, after giving it another try. I'd tried it when it was new, and the sharp corners were still a bit too sharp for my liking.

JJ seems to be part of a new "era" of tooling that's just really good. I mused about this a bit in a blog post:

https://pdx.su/blog/2025-08-13-the-quiet-software-tooling-re...

syklemil · 6 months ago

re: `fd` I also find it a lot better to do something like `fd -e py -X ruff format` than `find -name '*.py' -exec ruff format {} +`.

Part of it is that `find` seems to come from before we standardized on `--foo --bar` having an equivalent in `-fb`, and the nagging about some flags being positional, but also just the general syntax of their `-exec`, which _requires_ the `{}` to be present, but it can only ever be in one position for the `+` variant.

My one nag about `fd` is that it has two optional positional arguments, so the way I use it I sometimes wind up with `fd -e $ext "" /path/to/search`. (`fd -e $ext --search-path /path/to/search` might be a clearer alternative I should habituate myself to.)

IME positional arguments are always less ergonomic than flags/options, _especially_ if there are more than one of them and they're not mandatory.

But they're still better than the `find` syntax.

syklemil commented on Generic interfaces go.dev/blog/generic-inter... · Posted by u/Merovius

gabrielgio · 8 months ago

Generic is not about reducing how many keys you press but how you abstract your logic from the type. In go, it reduces a lot code making it safer and faster. Handling interface{} was just painful.

This is an extreme example and I hardly think anyone writing go code on a daily bases will need anything close to this. I haven't and I have not seen any lib that does anything remotely similar to that. To be honest, hardly anything beyond the stdlib will need to handle generics. They aren't widely used but quite useful when needed, which I think it is sweet-spot for generics.

I don't share the same animosity against generics. I like the recent language addition to the stdlib and am also waiting for them to add some sugar to reduce the boilerplate in error handling.

> Especially in the era of AI assistants, the downside of writing out explicit types and repetition matters very little

Yeah, let's design languages based on the capabilities of code assistance /s

syklemil · 8 months ago

>> Especially in the era of AI assistants, the downside of writing out explicit types and repetition matters very little

> Yeah, let's design languages based on the capabilities of code assistance /s

I mean, that _is_ essentially the Go team's take these days, c.f. their previous blog post about error handling: https://go.dev/blog/error-syntax

> Writing repeated error checks can be tedious, but today’s IDEs provide powerful, even LLM-assisted code completion. Writing basic error checks is straightforward for these tools. The verbosity is most obvious when reading code, but tools might help here as well; for instance an IDE with a Go language setting could provide a toggle switch to hide error handling code.

Personally I expect that getting an LLM to write error handling and then have the IDE hide it sounds like a recipe for surprises, but I guess things work out differently if the goal is to have hordes of the cheapest possible juniors kitted out with tools that let them produce the most amount of code per dollar.

syklemil commented on Generic interfaces go.dev/blog/generic-inter... · Posted by u/Merovius

ntstr · 8 months ago

It makes more sense if you know about Rob Pike:

https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3B...

>Syntax highlighting is juvenile. When I was a child, I was taught arithmetic using colored rods (http://en.wikipedia.org/wiki/Cuisenaire_rods). I grew up and today I use monochromatic numerals.

The language creator really hates it (and most modern editor tooling).

syklemil · 8 months ago

Which also makes more sense if you take into consideration that he has a form of colour blindness: https://commandcenter.blogspot.com/2020/09/color-blindness-i...

Ultimately he's fine with _some_ syntax highlighting, especially the kind that uses whitespace to highlight parts of the syntax, as evidenced by the existence of `go fmt`. He just hasn't taken into consideration that colour is just one typographical tool among many, including the use of whitespace, as well as italics, bold, size, typeface, etc. Switching inks has been somewhat tedious in printing, but these days most publications seem to support it just fine, and obsessive note-takers also use various pens and highlighters in different colours. For the rest of us it's mostly about the toil of switching pens that's holding us back I think, rather than some real preference for monochromatic notes. We generally have eyes that can discern colours and brains that can process that signal in parallel to other stuff, which along with our innate selective attention means we can filter out the background or have our attention drawn to stuff like red lights. Intentionally not using that built-in hardware feature is ultimately just making stuff harder on oneself with no particular benefit.

There's also some google groups quote from him about iterators which is also pretty funny given how modern Go uses them, but I don't have the link at hand. Several google groups quotes from the original language creators (not just Pike) tell an unfortunate story about how the language came to be the way it is.

syklemil commented on Learn Makefiles makefiletutorial.com/... · Posted by u/dsego

llukas · 9 months ago

This is excellent modern replacement for part where Makefiles get messy: https://github.com/casey/just

syklemil · 9 months ago

I also use just as a command runner, but I gotta agree with the others here that it should be described accurately as a command runner, while make is a build system.

There are some uses of make, especially by people who have never used it to build C/C++ projects, which makes more sense to replace with just. It doesn't have the baggage that make does, and they're not using it to actually make files. They also quite likely don't know the conventions (e.g. what a lot of us expect "make install" to do), and I support them in not learning the conventions of make—as long as they use something else. :)

Other uses of make will need other modern replacements, e.g. Cmake or Bazel.

It is possible that Kids These Days can say "no thanks" when someone tries to teach them make, and that the future of make is more along the lines of something us greybeards complain about. Back in _my_ day, etc.

syklemil commented on Learn Makefiles makefiletutorial.com/... · Posted by u/dsego

arccy · 9 months ago

It may be gnu make, but it's 20 years old: https://lists.gnu.org/archive/html/info-gnu/2006-04/msg00000...

so for all intents and purposes, it's a different make than what most people think about when they say gnu make.

    $ gmake --version
    GNU Make 4.4.1
    Built for aarch64-apple-darwin24.0.0
    Copyright (C) 1988-2023 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.

syklemil · 9 months ago

This seems similar to how macos has bash, but it has ancient bash. Allegedly the reason is that Apple is fine with GPL2 but not GPL3.

Though at that point I kinda wonder why they bother shipping bash at all, when their default shell is zsh, and it's entirely possible to have system shell scripts run by the BSD-licensed dash, rather than bash.

There's probably also something to be said about the choice of running ancient GNU make rather than BSD make, but I don't know enough about the differences to say it.

syklemil commented on If an AI agent can't figure out how your API works, neither can your users stytch.com/blog/if-an-ai-... · Posted by u/mattmarcus

lesser23 · 10 months ago

“AI” can’t use X so we have to dumb it down to the point a next token predictor can figure it out. Every day it seems like we are using spicy autocomplete as a measure of understandability which seems entirely silly to me. My own employer has ascribed some sort of spiritual status to prompts. The difference between prompting an LLM and a seance with psychedelics is getting smaller and smaller.

The next AI winter is going to be brutal and highly profitable for actual skilled devs.

syklemil · 10 months ago

> My own employer has ascribed some sort of spiritual status to prompts.

You may want to get them away from the prompts asap. They might be headed down the route to heavy spiritual delusions: https://www.rollingstone.com/culture/culture-features/ai-spi...

It seems that just like how some people predisposed to psychosis should stay away from certain recreational drugs, some people should stay away from LLMs.