Recent submissions

Comment · 1 month ago
Comment · 1 month ago
The code makes me smile, because it's nasty. This isn't like C4, a tiny but complete C compiler which does error checking on its subset. Instead, this is worse than Sector C, which takes every shortcut and just plain assumes everything in the source is right.

This "Python" just plain assumes for keywords: Any "f" is a "for [x] in range[y]" (exactly that, no other for's). Any "w" is a "while". Any "i" is an "if". Any "d" is a "def". Any "p" is a "print("

Nasty, nasty.

(Also nasty is that the code snippets in the article has more comments than the github copy of the "readable" version. You need the article to understand what's going on.)

This is a just a bit too simple for a "Tiny Python". If somebody is willing to allow a few more K's of bytes, I'd love to see at least lists & dicts here--Lisp can do them!

Comment · 1 month ago
Yes, but compiling or modifying Snek from source is very challenging. I wish it was one single C file for an example base like Posix, instead of many files for many platforms plus a custom parser in Python (Lola).
Comment · 2 months ago
Is it down? Every attempt to click the link in both Firefox and Chrome is forbidden by both browsers: "SSL received a record that exceeded the maximum permissible length."
Comment · 4 months ago
Chinese apparently was originally always written vertically top-to-bottom. (And then columns would be right-to-left.) Modern Chinese just rotates everything except the characters themselves 90 degrees to the Latin order.

I also read that a few Chinese texts only make sense in vertical order: one had a pun where the characters read one way as separated characters, but as stacked was also a single character pun for something like a "crumbly cookie".

Comment · 4 months ago
Comment · 5 months ago
A forgotten point is that modern pixel fonts all assume pixels have a 1:1 ratio: height the same as width, so an 8x8 character box is perfectly square.

That's NOT true for many of the old computer displays. Most had finer resolution in the horizontal compared to vertical lines, so more pixels across than in the same distance down. 1:1 "square pixels" was an innovation of the Macintosh, and very unusual for the time. So the fonts on this page displayed on other 80's machines would not look "right". And fonts from those machines brought to modern displays also look off.

Comment · 5 months ago
Interesting. In the 70's & 80's, 8-bit microcomputers had a the same problem as old teletypes: you couldn't type in some ASCII characters even when the computer could display them. (And many couldn't.) At least some home-grown tiny-C compilers allowed a Pascal-like "BEGIN" and "END" substitute, which I'm sure would be an abomination to Kernighan. Even Pascal itself could have a problem: the very popular TRS-80 Tiny Pascal used ( and ) instead of [ ] for arrays because neither brackets nor braces could be typed.

To summarize from the article for { and }:

Modern digraphs:

   <%  ,  %>. This is only one that looks symmetric
Less-modern trigraphs:

  ??<  ,  ??>
Unix v4 (in the teletype driver):

   \(  ,  \)
PDP-11 B:

   *(  ,  *)
PDP-7 B:

   $(  ,  $)
In other micro software (Advanced MuMath for the TRS-80), I have seen:

   <<  ,  >>    for [ , ]

   (<  ,  >)    for { , }
Back in the 80's, the joke among new learners of C and Unix is that the designers must have had a very bad keyboard where typing each character was painful, because every keyword or command was so short and cryptic. This article suggests a different reason: on their 36-bit Honeywell 6070, "four characters fit into a word", so there was incentive to fit in 1 machine word.

It also explains why they used the obscure characters {,},|, and ~ while never using the FAR more common # and @. In the Teletype driver, "#" is clear previous char, and "@" is clear current line. So unavailable for C. I will still curse the C designers to my dying day for picking * as the prefix operator for dereference pointer, when the more logical @ character was SITTING RIGHT THERE! On every keyboard! So now every newbie to C has to stop thinking "multiplication" when they see *.

Comment · 6 months ago
Huh. Works on Android phone. Doesn't work on desktop, Adblock or no Adblock.
Comment · 6 months ago
I'm confused. Should I be seeing something on this site?

From the comments, there are apparently supposed to be amazing photos. But I see text, I see black backgrounds, but no photos--none at all. Neither on Firefox, nor on Chrome. Just empty boxes where say "Amber Ducky" should be.

Comment · 7 months ago
The CBS field-sequential color system did have one application after the 1950's: it was the system used for color transmissions from the Apollo moon landings.

https://en.wikipedia.org/wiki/Apollo_TV_camera#Westinghouse_...

If you watch footage of the Apollo 17 LEM liftoff from the moon, you can see color artifacts in the burst of fragments off the platform. Their motion is too fast to stay in the same color band.

Comment · 10 months ago
It runs, but it would be very slow on actual hardware.

I tried on a cycle-accurate emulator of a TRS-80 Model I with Omikron CP/M mapper. Most Z-80 machines of the time were 4MHz, but the TRS-80 was only 1.77 MHz.

1. Type "GUESS", get question prompt.

2. User types: "Are you an animal?", ENTER key

3. Wait 25 seconds

4. Program prints "N"

5. Wait 20 seconds

6. Program prints "O"

7. Wait 23 seconds

8. Program prints linefeed, returns to question prompt

Total time to return 2-char answer to user's question: 1 min 9 sec or so. I bet a longer answer would take proportionally longer.

"The wonder isn't that it does it well, it's a wonder it does it at all."

Comment · 1 year ago
Thanks for the 8088 version on Github. Any chance you still have the 8080 CP/M version?

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton