As per sibling comment, I think my "old school" wording is getting misconstrued here. I did mean 20th-century "old school", i.e. typewriters... Is the Late Middle Ages considered "old school"? :)
Agreed that in terms of precedent, typesetters had moveable type dashes for their presses.
> the fifteenth century, and "em" and "en" were standard printing widths in moveable type. People who write CSS still recognize em as a width.
Good point, but I think it's a little more complex than that.
To my knowledge (and what I meant by "old school"), it was common to type a "--" dash on typewriters[0] because most of them lacked en- and em-dashes, which are obviously not digital documentation devices.
But yes, typesetters of old (old, old school!) had myriad glyph blocks available to them for pressing!
I too find it a pity that the em-dash has been co-opted by AI. I use a double-hyphen ("--", the old school way of writing it), but fear that this will also become used by AI seeking a higher form of 'sophistication' as you put it.
We're experiencing broad scale changes in the sentiment of style in written English. I don't know what the best approach to take here is necessarily, but the more I see language evolving over time (especially over the past two decades) I think I'd prefer to shift my habits in line with whatever the "modern standard" is in order to avoid falling into pitfalls, i.e. being accused of being an AI writer.
I was only thinking about Flight Control[0] the other day and how I wish there were more modern takes on it! There was Mini Metro[1], but that was released over a decade ago.
I used to be a die-hard destructurer! I liked the readability aspect, but ultimately two core problems emerged that pushed me towards dot-accessors:
1. It's highly verbose, especially in a language like TypeScript where you're often defining properties in types and then destructuring the same properties, making the whole thing look quite duplicative.
2. If you're passing an object through different functions doing similar things, I would quite often have to rename a destructured property in TypeScript because I would want to reuse the same name in a function-scoped variable.
I think for exhaustive switches, destructuring can be fine, but in general as long as you've got a well-defined set of types backing everything up, dot-access is neater.
--
Also on the point about optional parameters:
> let's suppose some stations now have an anemometer and are able to record wind speed
I find that discriminated unions are so much better at dealing with these kinds of problems. Also tends to work better with dot-access because you're not then destructuring undefined properties.
That's actually the wikipedia article that inspired me to name a repo-convention checker I made called Pokayoke[0]. Do find it fascinating (as with Andon) how many cool Japanese loan-words there are for process refinement.
A daily puzzle game called Dozenal that I've been making with a friend. We've been increasing our user base over the past couple of months and are still trying to refine the learning curve.
If you like number puzzle games, I would be very keen for you to give it a go and to hear your feedback on it!
From the article, it's for "jobs in sectors like agriculture and construction". Would be interesting to learn about how this kind of work is managed in hotter climates.
For office work, a lot of European countries (especially the UK) haven't invested in AC as much as the rest of the world because they haven't needed to. This is especially apparent in housing, where working from home is becoming difficult in these higher temperatures.
It's hard, in my opinion, to lend credence to the author here when they decided to devote the first and largest section of their article to an incisive display of speculative ad hominem.
Would have been a great opportunity to outline the benefits of Zig! I've been keen to pick Zig up recently due to mitchellh's evangelism and inspiring writing on the subject.
481 upvotes on HN, and only $136 USD donated (out of $64k target) -- at the time of writing.
Given the amount of traffic this project has received by being at the top of the front page for half a day, one has to wonder if a different approach to soliciting donations would have yielded them more money.
Clearly, everyone here is at least interested in the idea of a .self domain, and I wager that most (even the naysayers) of the commenters would register theirs.
Imagine if instead of asking for a $15–125 donation behind a CTA, they asked for $2 to "pre-register" your domain (with higher tiers for more benefits). I have a feeling they would have raised a lot more money...
I disagree if your application is networked. Most SaaS is built on RESTful APIs that can be converted trivially into interfaces / contracts for tool use.
The author alludes to it but the defence to this is seemingly insurmountable at the moment because we’re ostensibly operating LLMs on a single channel — their inner, subconscious voice. Right?
Interacting with an LLM is a bit like seeing the output of an Inside Out (the Disney movie) scene. Or it’s a bit like a human brain that we’re providing tool call access and introspection with some kind of advanced neuralink.
But - like the author says - _we know_ our inside voice from the outside world, because we’re embodied.
Is there something we can do here by attempting to bifurcate internal and external systems? Like a conscious and subconscious stream of information on two separate bands?
If the model somehow knew its User was not it because it was clearly an external signal, then the attack documented here would be about as effective as a Jedi mind trick without the Force.
I think something that is a mix between localStorage or IndexedDB and access to the user's filesystem would be better.
I agree with the comments about how much of a security risk this poses. But, isn't that the case with any binary or executable files and apps we download from the internet anyway?
It would be cool if you could have a specially-demarcated directory (e.g. even inside the application like `~/Applications/Chrome/<website>/local_files`) which you can just open super easily with a button from Chrome, and just copy files over into that directory as needed. Would provide the benefits of a more secure enclave with the flexibility of being on the filesystem.
My friend and I have been working on a game: Dozenal. It’s a number puzzle game (with daily challenges) where you have to combine different mathematical operations to fill a grid with “12”s.
Today, my focus is on personalizing the internet at Kenobi.ai (YC W22)
Reach me at my name (Rory) and my company’s domain.