HackerTrans
TopNewTrendsCommentsPastAskShowJobs

syklemil

no profile record

comments

syklemil
·há 7 meses·discuss
> 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
·há 7 meses·discuss
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
·há 7 meses·discuss
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
·há 10 meses·discuss
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
·ano passado·discuss
>> 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
·ano passado·discuss
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
·ano passado·discuss
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
·ano passado·discuss
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
·ano passado·discuss
> 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.
syklemil
·ano passado·discuss
There's no discussing taste, especially with syntax. Personally I find the Rust syntax unoffensive, while the Go syntax comes off kind of … weird, with type signatures especially looking kind of like run-on sentences by someone who hates punctuation. C's type signatures come off as a turgid mess to me; stuff like this https://www.ericgiguere.com/articles/reading-c-declarations.... is just a design mistake as far as I'm concerned. And Python … kind of goes into the "ah, I give up, slap an `Any` signature on it" territory.

And some people love that! It just ain't for everyone.
syklemil
·ano passado·discuss
Python is growing type annotations at a brisk pace though, and Typescript is cannibalizing Javascript at an incredible speed. Between that and even Java getting ADTs, I suspect the people who whine about "type nerds" are in for some rough years as dynamic languages lose popularity.

And I suspect the people who are familiar with seeing something like `dict[str, int]` can map that onto something like `HashMap<String, i32>` without actually straining their brains, and grow from there.
syklemil
·ano passado·discuss
You've already had some replies for the C FFI side of things, you might also be interested in maturin & PyO3 for python bindings. I haven't looked if they've exposed some python interface (guessing not), but Rust/Python interop is often pretty easy: https://www.maturin.rs/
syklemil
·ano passado·discuss
> It absolutely does not matter what language this tool is written in. That goes for any tool.

Eh, there are a lot of tools where it actually does kind of matter. I suspect for a lot of invocations of tools like `fd` and `rg`, they'll be done before an equivalent written in java has even had its JVM spin fully up.

There's _tons_ of Java software, but it somehow never managed to make a dent in the CLI space.

> To me, there is no reason to ever use “find”. If I’m on a new system, I just install fd and carry on.

I guess I should finally have a look at how to replace my `find $path -name "*.$ext" -exec nvim {} +` habit … turns out it's `fd -e $ext -X "nvim" "" $path`
syklemil
·ano passado·discuss
> Generally speaking, non-religious people understand church to be a building. Whereas religious people understand that the people are the church, the building is just a building.

The word "church" itself is used to refer to the building in several languages; some of the buildings get some fancier word like "cathedral" or "dom church" or just "dom", like the Kölnerdom or Nidarosdomen. It's a type of building the same way that you expect certain things of a Rathaus or office building or detached house.

Of course, it is also used to refer to what in secular contexts would be called a club or organization, like "the church of $country". E.g. if you want Norwegian waffles abroad, Sjømannskirken (literally "The seamen's church") is very likely to have them. Norwegian churches-as-organizations run partially on coffee & waffles.

The only other group I can think of off the top of my head that get called the same as a building is parliament? While with churches it's kind of as if we used just one word to describe a football field, the football team, and that football team's supporters. Homonyms can trip people up.

So for people who aren't in the organization, but know that people associated with that kind of organization take umbrage at a lot of things that they can't easily predict, it's no wonder that churches-the-buildings have mental priority because that's what they actually experience in their daily lives: Buildings that exist in their vicinity, that often represent a sizable investment, and that they might even get invited to for some rituals like marriages and funerals. The … Jesus club is about as visible to them as a local role-playing club, or indoor sports club.
syklemil
·ano passado·discuss
You would likely approach it in any style with some helper functions once whatever's in the parentheses or ifs starts feeling big. E.g. in the dot style you could

  fn bookFilter(book: Book) -> bool {
   return book.pageCount > 100 and 
     book.language == "Chinese" and 
     book.subject == "History" and
     book.author.mentions > 10_000
  }
  
  var favoriteFoodsOfFurryPetsOfFamousAuthorsOfLongChineseBooksAboutHistory = books
    .filter(bookFilter)
    .flatMap(book => book.author.pets)
    .filter(pet => pet.is_furry)
    .map(pet => pet.favoriteFood)
    .distinct()
syklemil
·ano passado·discuss
> But in functional code, the entire chain is a single statement. There are no natural breakpoints where the reader could expect to find justifications for the code.

How are we deciding what's "functional code", here? Because functional languages also provide means like `let` and `where` bindings to break up statements. The example might in pseudo-Haskell be broken up like

    distinctAuthors = distinct authors
      where
        authors = map (\book -> book.author) longBooks
        longBooks = filter (\book -> book.pageCount > 1000) books

IMO the code here is also simple enough that I don't see it needing much in the way of comments, but it is also possible and common to intersperse comments in the dot style, e.g.

    distinctAuthors = books // TODO: Where does this collection come from anyway?
        // books are officially considered long if they're over 1000 pages, c.f. the Council of Chalcedon (451)
        .filter(book => book.pageCount > 1000)
        // All books have exactly one author for some reason. Why? Shouldn't this be a flatmap or something?
        .map(book => book.author)
        // We obviously actually want a set[author] here, rather than a pruned list[author],
        // but in this imaginary DinkyLang we'd have to implement that as map[author, null]
        // and that's just too annoying to deal with
        .distinct()
syklemil
·ano passado·discuss
Right you are. I wish I had an excuse for my mistake, but I don't.
syklemil
·ano passado·discuss
> Nope, pure functions are referentially transparent. The key idea is that you can replace the function invocation with a value and it shouldn’t change the program.

[Edit: This is wrong: And idempotent.] Generally you can expect that you can call them as many times as you like and get the exact same result. It _feels_ very safe.

> This isn't just a Haskell thing though. I'll write code this way in C# (and have built a large pure-FP framework for C# to facilitate this approach [1]).

I think that habit from Haskell is also what allowed me to pick up Rust pretty easily. You don't run afoul of the borrowchecker much if you don't expect to mutate a lot of stuff, and especially at a distance.
syklemil
·ano passado·discuss
I consider syntax highlighting to be a part of the _visual_ structure. Visibility is more than just whitespace and placement!
syklemil
·ano passado·discuss
I'm more partial to the first one because it keeps a linear flow downwards, and a uniform structure. The second one kind of drifts off, and reshuffling parts of it is going to be … annoying. IME the dot style lends itself much better to restructuring.

Depending on language you might also have some `.flat_map` option available to drop the `.reduce`.