rmunn

I would argue that even if JPEG XL isn't the best choice for Web images, if browsers don't support it then that will widely hinder its adoption for its non-Web use cases. Would you agree?

The scenario I'm thinking of is sending a photograph by email. Let's say Sally has just had her second baby, and wants to send baby pictures to her mother, the baby's grandmother. Neither Sally nor her mother are computer professionals, and they don't want to care about image formats. Sally wants to upload a file from her camera, attach it to an email, and send it. Her mother wants to click on the email and see pictures of her new grandchild. Neither one of them wants to have to convert the image themselves.

Let's say it's a few years in the future and Sally's camera produces JPEG XL files by default. (Which I don't think would happen if browsers didn't support it, for exactly the reason I'm about to articulate). If Sally's mother's browser doesn't support displaying JPEG XL, then although Sally (who uses a different browser than her mother) sees the picture in the email when she sends it, her mother writes back an email saying "the picture didn't show up, can you resend it?" And they spend a few back-and-forth emails before finally getting tech support from a friend who helps Sally convert the picture to old-school JPEG so her mother can see it.

If that's the experience for end-users, cameras would hesitate to switch to JPEG XL as a default format. Because nobody wants a hostile review from a user saying "My mother couldn't load my baby pictures, what kind of lousy camera are you making?"

So even if it's not the best format for the Web, I'm still persuaded that having universal browser support for a format intended for photos is an important factor, and devices like cameras will not switch to it as a default format until manufacturers are certain that browser support (and OS support, and electronic photo frame support, and so on) is nearly universal.

None of that takes away from the argument "Other image formats are better for saving space on the Web", which is the main thrust of your post. But I do disagree with the last line, "I'm just not personally convinced we need it in browsers any time soon." I believe that if browser adoption is lacking, adoption of the format in places where it makes lots of sense (like cameras) will also be slow.

What are your thoughts on that argument?

Ah, didn't know that. Then the main reason to use DDG would be if their "we don't track your searches" claim is honest. (Which I think it probably is; certainly I've seen no evidence that DDG is lying about not tracking your searches).

Even if they're only a layer around Bing, having your Bing searches coming from DDG's IP addresses rather than from your own IP address almost certainly makes it harder for Bing to track you, since your searches are being pooled with everyone else who uses DDG. Naturally, Google will track you, your computer, your phone, and would even track your dog and your Roomba if they could figure out how.

Don't worry, I didn't spend much time digging through comment history. Thanks for the links; I'm about to have to leave my computer and do something else for several hours, so I can't look at them right now. But since you replied to one of my comments it'll be easy to find them again via the "threads" link, so I'll look at them later when I'm back at the computer. (And I did look at the first one; Logo Adventure is exactly the kind of thing I love to come across, so thanks for that!)

I'd also recommend `:degree <= 0` as the check, rather than `= 0`, just in case someone passes `5.01` to the function (which would cause an infinite loop as you'd never hit exactly 0). But yes, if that was just coded into the comment box then it looks pretty good.

Where the heck did the sudden vitriol come from? I went through the HN comments of the person you're replying to and found nothing like the kind of thing you're replying to in the first several pages. If he said something months ago that you're bringing up, you might want to link to it, because at it stands it feels like you just suddenly started ranting about politics in the middle of a conversation about teaching kids to code. Which is... kind of offputting, you know?

Could we please try to follow the guidelines and not have flamewars and partisan dispute? Especially ones that seem to spring up out of nowhere, reviving conversations that are months old? I'm here to learn about cool new projects; if I want to read about politics or personal drama I have pretty much the entire rest of the Internet to do so.

That's more true in some locations than in others. There are places where the reported quality of life is quite a bit higher than others. I see comments like yours a lot on HN, and I'm starting to suspect that the average HN commenter is more likely to be living in some of the poorly-run big cities than in the better-run small-to-medium-sized towns. (Specifics can, and will vary. But on average I've found I'm much happier living in a medium-sized town than in a megacity, and I've also found the city governments of medium-sized towns to be more likely to be competent. Perhaps I've just been lucky in the medium towns I've lived in, though; I'd need far more data before I was certain of the thesis).

Point is, if you're miserable in the place where you are, consider whether moving to a different town is feasible for you. It's not always an option for many people, for many varied reasons. But it's definitely something to consider. If it turns out you can do it, sometimes taking that risk can pay off in the long run.

DuckDuckGo is owned by Microsoft? Are you sure? You're not confusing them with Bing, by any chance?

Good example, which is why both you and the other commenter gave it. And if that's as far as it went it wouldn't have bothered me so much; it was when conservative people I know were getting different results from liberal people for the same search terms that I started to realize the potential for an echo chamber, and decided it was a bad idea.

It's good for your mental health to be exposed to arguments you disagree with. Many times they will be bad arguments and you can dismiss them, but it's good to know what the people who disagree with you actually believe. And sometimes, just sometimes, you might see something that makes you realize that it's your own worldview that was mistaken, and adjust your worldview to better fit reality. If your search results only show you echo-chamber results that already agree with yours, you'll rarely learn the areas where you were mistaken. (And nearly everyone is mistaken about some things; the person who is right about everything is a rare creature indeed, and you should never gamble that you're that person).

Glad to know the team is growing, it makes me slightly less worried about the project's bus factor.

There's a limit to how long the name can be, even in Snap! — not an enforced limit as far as I know, but a practical one. You don't want the block you're dragging around to be thousands of pixels wide, it's very inconvenient. So people are naturally going to rename "convert all the upper case letters in the input text ___ into lower case letters" (where ___ represents the input slot) into "convert ___ to lower case" at some point, because they get tired of that one block being so much wider than every other block around it. (Edit to add: especially if they're snapping it into the input of a `map` block, which itself is the list input of "keep items (predicate) from (list)" block. That would get unwieldly really fast).

But you know some wag is going to paste the Pevear and Volokhonsky translation of War and Peace into a block name, just to see if he can. :-) So perhaps there does need to be an artificial limit, at 4096 characters or so, on block names.

Oh yeah, forgot about those! (I didn't teach them to beginners for obvious reasons). Those make it a Scheme rather than a Lisp.

And thank you for all your work not just on Snap!, but on Logo before that. You have done a lot for coding education.

If you mean the tables in the https://eddie.codes/posts/pandas-should-go-extinct/#i-have-b... section, it looks like those came straight from the Amazon paper, in which case __eddie__ shouldn't fix them, on general "quote accurately even if the quoted document has mistakes in it" principles. (Though a [sic] might help).

The tables in the https://eddie.codes/posts/pandas-should-go-extinct/#i-have-b... section.

Cute title; I thought I was about to read a contrarian ecologist saying "a species that is so very specialized in its diet and finicky in its reproductive behavior doesn't deserve, evolutionarily speaking, to survive". (Seriously, it's seriously freakin' difficult to get pandas to reproduce in captivity). And while my knee-jerk reaction would be "maybe, but we should still preserve them because we can", I was prepared to see if the author had a serious argument to present.

Instead it's a cute bait-and-switch title, and the article tells you upfront that it's actually about the Python `pandas` library. Which I think I've encountered maybe once in my entire career (I'm not in the data-science field), so I don't have much meaningful to say about the article itself. I just want to commend the author on fooling me with the title. This is the kind of "clickbait" I can respect and actually wish there was a little bit more of sometimes. A nice chuckle, then a real article.

I wouldn't mind that one. That a man in the US and a woman in Japan would get different results for a search for "sushi restaurant" is perfectly reasonable (even if the woman in Japan was searching in English).

It's when two people in the same neighborhood got different results for the same search that I said "wait a minute, they're personalizing search results now for ad-targeting purposes" and ditched them. The potential for them to deliberately hide things from you was too great.

It means they're capable of burying news stories that would contradict your worldview and pushing news stories that support your pre-existing biases, leading to more engagement from you (a win from their point of view) but also burying you in an echo chamber. And unless you were in the habit of doing the occasional search in Incognito Mode, you wouldn't know. (And even then, they probably would be able to put together enough clues to figure out your identity even without your Google login cookie).

Yes, the fact that they could do it does not prove that they were doing it, not right away. I ditched them as soon as I found out that they could do it, because I was absolutely certain that eventually, they would end up doing it. And I wanted neutral search results, not biased ones, even ones biased towards my own point of view.

I've been using DuckDuckGo for years now, ever since it became noticeable that two different people searching for the same search term would get two different results back from Google. Meaning they were no longer completely reliable: they might show one person a result that they hide from the other person by burying it on page 3 where few people ever look.

DDG's search results have been poorer recently than they used to — I often see completely unrelated results (to the point of my saying "Why in the world did that come back as a search result??!?") starting from page 2. And yet, I still use them, simply because they aren't Google.

Not true in this case; the original intent for BYOB (Build Your Own Blocks) was as an extension to Scratch. When the Scratch team decided not to merge it, the BYOB folks decided to build it into Snap! instead of abandoning the perfectly-functional code they'd written.

In Snap! version 12 they have added the ability to create tutorials, which are projects that load up with a limited set of blocks (you choose what set is available when creating the tutorial). This fixes the intimidation problem: you can even create a set of tutorials that, if the student goes through them in the recommended order, teaches the basics with just four or five blocks available at first, then slowly introduces concepts over time.

> I think Snap! could take advantage of its equivalency with Scheme, and you could just parse Scheme into Snap! blocks, and the other way around. And ChatGPT knows scheme pretty well, though it's not as ubiquitous and standard as JavaScript.

There's already a right-click menu option called "Lisp code". Take the "turn left 15 degrees" block (the "15" is the default value but of course it's a parameter that can be set to anything), drag it out into the editor, and right-click the block. Choose "Lisp code" and `(left 15)` will be displayed in a results bubble; you can then right-click the results bubble and export it to a file or copy it to the clipboard. If you have two blocks put together then the resulting Lisp code looks like this:

    (
        (left 15) 
        (move 10)
    )

I haven't checked recently to see if they have finished the other half of that feature, the parse-Lisp-into-blocks half. But I know they want it to be in there; I forget what its status was last time I checked.

If you're thinking that LLMs will be doing all the coding, well, in my experience I get far better results from the model when I say "Write me a function that does X. It should take parameters Y and Z, and its validation step should check for conditions A, B, and C" than when I say "Write me a function that does X" without any further guidance. With no guidance, the LLM can run off in weird directions, and if you don't have any programming experience, you might not realize why those directions are bad ideas.

LLMs, at least the current crop, are skill multipliers. If your skill is positive and large, you'll get great results. If your skill is positive and small, you'll get small results. If your skill is negative, the LLM will harm you more than it helps you.

It did as of six months ago when I evaluated Scratch and chose Snap! instead for teaching the beginning-coding class I had signed up to teach. Scratch had lists, but they were only allowed to contain text or numbers, not other lists. To make a tree, you need to be able to nest lists inside other lists. Snap! allows lists to contain any kind of data, including other lists, or even blocks. And it allows blocks to take lists as input, which is another thing lacking from Scratch. Snap! also includes the standard basic list-manipulation functions like `filter` and `map`, which aren't in Scratch at all (naturally, since lists in Scratch can't be passed as input to blocks).

When I looked at Scratch six months ago, its lists were deliberately handicapped in function. They could only contain text or numbers; they could not contain other lists. Nor could they be passed as parameters to functions (!!), which really made me say "Nope, this is not what I'm going to use to teach programming to kids". I looked at Logo, and was drawing up lesson plans when I noticed Brian Harvey (the primary designer of Berkeley Logo which I was planning to use) had a lot of activity on this other repo. What in the world is https://github.com/jmoenig/Snap/ and why is Brian Harvey contributing to it so much? (Looks it up). Oh. OH.

And so I taught my class using Snap!, because it has:

- Lists that are proper first-class types, and can contain anything, including other lists, and also blocks

- Blocks (functions) that are also proper first-class types, and can take anything as parameters, including lists and blocks.

- Blocks that can create and return other blocks, thereby enabling functional programming

- All the standard list-handling primitives you would expect, like `filter` and `map`

All of which was missing from Scratch when I looked at it six months ago.

Scratch is a toy language, with a deliberate ceiling that you can't get past because of the language's design. Snap! is a real programming language with no ceiling, with the visual appearance of a toy. It takes longer to do anything in Snap! than in a professional language like Lisp or C# or Go or ... well, all of them, because dragging blocks together is a lot slower than typing. But you can do anything you need to in Snap!. There is no artificial limit that blocks you from going farther, the way Scratch has.

P.S. Saying that Scratch is artificially limited is not meant as a dig against the language. It's a deliberate design choice, and it's a fine choice if your intent is to teach people the very basics and then graduate them to another language. It's a choice I disagree with, because I prefer the way Snap! has implemented the same pedagogical choice (you can create tutorials with a limited set of blocks, to avoid presenting complete beginners with an overwhelming array of choices). But it's a defensible choice in many cases (many kids taking a programming class will not have the aptitude — and those who do turn out to have the knack for it can be graduated to Snap! really easily and not have to relearn everything).

Six months ago I was teaching a beginning-programming course to six kids, using Snap!, so I was reading the forums. And there was a group effort to add documentation to many of the blocks that were lacking it. I haven't been back in a few months, so I don't know how that effort is progressing, but there were definitely some undocumented blocks that were getting documentation completed as I watched, and eventually added to the Git repo to land in the next release.

So it's getting better.

The other thing to remember is that the core Snap! development team is just two guys, Brian Harvey and Jens Mönig. When they're focused on things like trying to figure out how to get macros into Snap!, so that Snap! can truly be a Lisp (right now it's only most of a Lisp), they tend to leave the documentation effort to the community. If they had a larger team I might fault them for that, but with just two guys, I can't really blame them for focusing their efforts on things the community is less able to do, and leaving things the community can do up to the community.

> It turns a fun 1-hour game into a much longer fun game.

First procgen game I ever played was Starflight 2. (Pre-Internet era, so I couldn't get hold of Starflight 1. SF 2 spoils you, hard, on the major spoiler in SF 1, so if you're playing them from GOG or other sources then you should definitely play 1 before 2).

My ten-year-old mind was boggled. Hundreds of star systems, each one with several planets (usually), and you could land on each one? And explore the whole planet (in a very limited top-down 2D view, because this was the 1980's), harvesting minerals, and the map was quite a bit larger than what would fit on one screen? And it all fit onto one 720K floppy disk?!??!?

Now, of course, I know how they did it. But there was an actual game there. There were half-a-dozen alien races you could interact with (talk or shoot, as required), and there was an actual story. With a twist at the end that 40-year-old me would see coming, but 10-year-old me was shocked and amazed by. (And the twist in SF 2 wasn't even as good as the one in SF 1). And you progressed that story by following the gameplay loop:

    - Fly around looking for planets with valuable minerals
    - Land, scoop up what you can carry, fly home to sell them
    - Gradually increase your ship's capabilities

Then eventually you would be able to make your way to planets with plot on them, at which the loop changes to:

    - Collect plot-important artifacts, fly home to get them researched
    - Research tells you "go talk to these aliens".
    - Do a fetch quest so they like you, then talk to them.
    - They tell you where to go to kick off the next plot point.

After only a few runs through that loop, it's on to:

    - Find out where the Big Bad's home base is
    - Find out where the MacGuffin is that lets you access that location
    - Take MacGuffin to right place, fight Big Bad, save the day.

Crucially, once you had gone to talk to those plot-important aliens, you probably had enough resources that you didn't need to do much mining anymore. You might land when you spotted a target of opportunity — "Oh look, scanners say big pile of platinum just sitting there on a nearby planet, let's make a small detour" — but that was just to keep the bank account topped off. You could afford enough fuel to fly all the way across the map and back, so you could focus on the story.

And they timed it well: the core harvest-resources-and-upgrade-the-ship loop didn't have time to get boring before you were off to collect plot coupons. And there weren't too many plot coupons before it was time to find the MacGuffin, use it to beat the Big Bad, and save the day.

Star Control 2 did it really, really well, with better graphics since it was released a few years later. BTW, if you haven't played SC 2, search for "The Ur-Quan Masters" to download and play a totally free, legitimate, open-source version of the game, with full original assets since the copyright reverted back to the original creators who released it into the public domain for the UQM project to port to modern machines. I wish that had happened to all the old classics, but Star Control 2 is truly a good game. Definitely seek out The Ur-Quan Masters.

But before you do that, I would strongly recommend to play Starflight 1 and Starflight 2, to get a feel for the origins of the procgen-with-good-story genre that Star Control 2 did so very well.

P.S. Edited the "core gameplay loop" paragraph to better make it clear there were two or three loops, and you progressed forward through them, rarely having to go backwards.

> Other than maritime navigation, I can't think of many tasks where Mercator would be more useful than an equal-area projection.

Precisely why, I suspect, the US voted against the change. (One of the reasons, at least) I mean, gee, I wonder why the country with the world's largest navy* would prefer maps where you can draw a line on the map between two points and it's the actual compass direction? (Give or take a bit of weirdness near the poles, where the difference between the Earth's rotational pole and its magnetic pole actually matters in a way it doesn't matter below the polar circles).

It's just a symbolic vote, of course, and nobody's navy is going to stop using the so-useful-for-maritime-navigation Mercator just because of this UN vote. But still, I would bet that factored into the reasoning. How much? Who knows, I certainly couldn't say. Except to suspect that it was a non-trivial factor.

* Largest by tonnage — China and Russia have more total ships, with the US in third place by ship count, but the US has nearly half the number of aircraft carriers in the entire world, 11 out of a total of 23, and aircraft carriers are some of the heaviest ships out there. Numbers are from https://worldpopulationreview.com/country-rankings/largest-n...

A reminder of the guidelines: "Eschew flamebait. [...] Please don't use Hacker News for political or ideological battle. It tramples curiosity."

It's good to have political opinions. But please don't use HN as a place to try to pick a fight with people who might disagree.

> ... most of the new testament has him [Jesus] as a fully separate person with his own separate agenda ...

Just want to correct a couple errors of fact here, by quoting from the sources that you're misunderstanding.

"And he withdrew from them about a stone’s throw, and knelt down and prayed, saying, 'Father, if you are willing, remove this cup from me. Nevertheless, not my will, but yours, be done.'" - Luke 22:41-42 (copied from https://biblehub.com/esv/luke/22.htm)

He doesn't want to suffer and die on the cross. Yet he chooses to serve the Father's agenda, not his own.

"I and the Father are one." - John 10:30 (copied from https://biblehub.com/esv/john/10.htm)

And note that, if you read just a few more sentences, you discover that this statement caused the Jews listening to him to pick up stones to stone him (for anyone who doesn't know, stoning was a method of execution: they intended to kill him). He asks (verse 32) why they want to stone him, and they reply (verse 33) that it's for blasphemy — "because you, being a man, make yourself God."

Finally, I want to address one other point in what you said:

> Christianity, if you ask anyone besides a christian, is polytheistic.

It's true that if you ask most people who are not Christians, most (not all, but most) will tell you that Christians worship three gods. But consider this: if you want to find out about Buddhist teaching, who would be a better source for explaining it to you correctly, a Buddhist, or a non-Buddhist? If you want to find out about Jewish teaching, who would be more informed about it, a religious Jew, or a non-Jew? (The word "Jew" is ambiguous, referring to both a religion and an ethnicity — so I use the term "religious Jew" to distinguish people who follow the religion from people who are ethnically Jewish but don't follow the Jewish religion). If you want to be well-informed about Islam, who would explain it to you better, a Muslim, or a non-Muslim? And if you want to understand what Christianity actually teaches, who's more likely to be correct about it, a Christian or a non-Christian?

P.S. To explain just a little further, the teaching of the Trinity is indeed one of the most complex teachings of Christianity to fully grasp, and there have been countless arguments and debates about it over the centuries. The council at Nicaea in AD 325, which formalized the Nicene Creed, did not completely settle that — some people continued to argue over the doctrine later — but it pretty well cemented the official church position. That the Father, the Son, and the Holy Spirit ("Holy Ghost" in older English texts, but "Holy Spirit" in modern English) are both three and one. The modern English translation of the Nicene Creed is probably worth quoting here (at least the relevant bits) so people can see what the actual teaching is:

"I believe in one God, the Father almighty ... I believe in one Lord Jesus Christ, the Only Begotten Son of God, born of the Father before all ages. God from God, Light from Light, true God from true God, begotten, not made, consubstantial [which means "of one being, of one nature"] with the Father ... I believe in the Holy Spirit, the Lord, the giver of life, who proceeds from the Father and the Son, who with the Father and the Son is adored and glorified ..." (Source: https://www.usccb.org/prayers/nicene-creed, though there are multiple translations, e.g. the translation I'm most familiar with says "of one being with the Father" rather than "consubstantial with the Father").

And before I quit writing this P.S., I want to mention one kind of awesome story about the council of Nicaea. Which is the story about what St. Nicholas allegedly did there. (Yes, the St. Nicholas whose life inspired the story of Santa Claus). Sadly, the story is probably not true, since Nicholas's name does not appear in any of the lists of attendees that have survived... but it's an awesome story anyway. The story goes that Arius was standing in front of the council arguing his position, which was that Jesus had not existed eternally, but was created by God the Father at one point. (The famous phrase is "There was a time when he was not".) That part is certainly historically true. What is likely not historical is the rest of the story: that Nicholas got so mad at Arius's denial of the divinity of Jesus that he got up and slapped (some sources say "punched") Arius in the face.

Which leads to this historical-humor variation on a famous American Christmas carol:

    He knows when you are sleeping,
    He knows when you're awake,
    He knows when you've denied the divinity of Christ,
    So if you're an Arian, DUCK!

P.P.S. One last note. My intention here is not to argue, but to explain. I am happy to argue/debate with anyone who wants to discuss further, but HN is not the right place for literal religious debate. If you want to argue or debate about Christian teaching, feel free to contact me at (my HN username) at pobox dot com. (And if you just write a note here that you've done so, that will avoid the possibility of my missing your email: my pobox address gets a lot of email).

I'm sure it was often used, but I spent a lot of my childhood and early adolescence in the non-English-speaking country where my father worked for many years. So "green-bar paper" is not the only apparently-commonly-used English term that I had to learn later in life, since when I was growing up, I heard English mostly from my parents and coworkers, and that's not a term that they happened to use a lot. So although it's my native tongue, I'm constantly finding holes in my vocabulary — usually 80's or 90's slang terms that my (extensive) reading habit couldn't teach me because most of the English-language books I had access to in the 80's or 90's were published in the 1970's or earlier.

In other words, don't take my not knowing a term as evidence that it wasn't commonly used; my childhood was unusual by the standards of most Americans. :-)

P.S. Another reason why Macbeth might have more injuries than either Hamlet or Romeo and Juliet is the setting. In both Romeo and Juliet and in Hamlet they're fencing with rapiers, appropriately to the setting. But in Macbeth they're in the Scottish highlands, and a rapier just wouldn't look right. I don't believe Shakespeare ever explicitly specified what kinds of swords the characters in Macbeth are fighting with, but traditionally they've used either longswords (two-handed) or arming swords (one-handed swords, which are what you might think "longsword" means if you came to your knowledge of weaponry through D&D or other RPGs). Both of which are heavier (especially the longswords) than a rapier, and easier to accidentally injure your opponent with (broken bones, concussions, etc) than a blunted stage rapier.

So that fact alone might help explain why injuries tend to be higher in stage productions of Macbeth. It's just inherently more dangerous to perform than the rest of Shakespeare's plays.