originally i had them both in one article but it was getting to be really quite long and i am still thinking through what i want to say in the follow-up
This little change was mind-blowing for me so I always try to share when I can :)
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
—Zawinski's Law of Software Envelopment
Data and data collections should have app-tributes, apps shouldn't have data.
The problem with most operating systems is that they need to model space time and minds as first class but they don't.
I've been using my own personal OS for years now that I call imtropy, once your abstraction maps to reality everything becomes easier to reason about.
The simple fact is most people and programmers are stuck in logic and rationality when they should think a layer deeper, coherence is all that matters.
i prefer this type of writing for comedy generally
I guess time will tell if this is a new ‘thing’ people do ¯\_(ツ)_/¯
[1] http://www.alt-usage-english.org/excerpts/fxwhyisi.html [2] https://www.thesaurus.com/e/grammar/whycapitali/ [3] https://greatbigstory.com/why-do-we-capitalize-the-word-i/
*##body:style(text-transform: lowercase !important;)
trust me.
also, it's worth noting that proper capitalization does not automatically yield text worth reading. from that perspective, i like lower case text as a form of rebellion against the artifice of rules; any rebellion against particular aesthetics is fair game in my book. more generally, i'm skeptical of process advocacy in cases where the process seems to be done for its own sake.
on the flip side, good grammar helps me parse sentences, so i do sympathize with arguments in its favor.
Interestingly your semi-colons stand out much stronger than the periods for me.
https://archive.org/details/livestimesofarch0000marq/page/20...
I strongly recommend rethinking that approach. You ascribed intentions to the author and then spent more time getting upset about them than you did interacting with the content.
There are actually interesting points in that text, yet here we are getting fussy about the author's supposed lack of decorum. That's really disappointing to me.
A quick search shows that others have made this connection between Altman and lowercase and non-AI authenticity: https://ted-merz.com/2023/12/18/writing-in-lowercase/
It looks like this particular blog previously used conventional capitalization from 2017 to late 2023. The first post in this style appears to hint at a kind of shift in identity of the author, so perhaps, in this instance it is more a signal of personal expression or tribalism than non-AI-ness. Then again, we may see the line between the two continue to blur.
Seems to be a trend though now to do it everywhere in public. I've seen the htmx author do that and the guy who wrote the second forked version of opencode.
Not sure what it has to do with Sam Altman though.
But the topic is long-form, published content. Writing styles communicate tone, which may change culturally with generations.
https://news.ycombinator.com/newsguidelines.html
(Of course annoyances are annoying, but they're also distracting, and they tend to get stuck at the top of threads, choking out more interesting conversation.)
Everything is a file is a good example of a fundamental and major standard that lasts till today and even though IPC kind of didn't make it all the way, I think about the core UNIX philosophy and Alan Kay's thoughts around as very, very accurate in terms of where we've ended up and what the likely ways out look like to me.
The real problem is Plan9 never really had a lot of attention put on the things that make having a sane security policy good. Factotum seems, at best, to be bolted on after the fact.
What gives you this impression?
That is a myth that keeps getting propagated. https://plan9.io/sys/doc/auth.html
Which describes that yes, there was security in Plan 9 prior to Factotum, just that it wasn't good enough.
> Regardless, I'm more talking about the fact that transport encryption still isn't used ubiquitously to my knowledge.
It certainly is. You get SSL/TLS for free on Plan 9 as its a service. You dont mess with security code and instead use tlssrv(8). See https://man.9front.org/8/tlssrv
I stand corrected on tlssrv
One likely place to stop is at "processes". But this must be motivated since ultimately processes are as synthetic a convention as a language thread - it's just that the runtime is called a "kernel" instead of a "runtime".
Ultimately I think what the author is getting at is a data problem, not a code problem. Or rather, it's yearning toward a world where data and code are strongly decoupled, conventions around data are standardized, so that processes written in disparate tooling can successfully interoperate locally. However I doubt there is much appetite for a "model of everything" registry (such things have been tried, and failed, in the past). That said we might take another stab at this, since LLMs make likely that software will become more dynamic in terms of translating data structures at runtime such that one program can examine a peer program and its data structures, and how to map them to local data structures, thus achieving interoperability without a centralized agreement on representation.
The problem I have seen at most organizations is they simply want their APIs to reflect their database schema, even if its not a good or useful idea. They throw junk over the wall.
They carry this practice over from REST to GraphQL and of course its horrible, its not a good way to use the technology.
Now organizations that understand GraphQL allows you to create a data schema unbound by its sources, they leverage GraphQL quite well, and its very pleasant to use. Unfortunately not enough organizations do this, or do this well.
SOAP was and is still simply a bad protocol and had tons of issues ranging from security to payload size to parsing issues between different clients
Not if it is open source, and you're willing to put some effort into it. When I write code I like to think of it more as using a computer effectively instead of programming.
FWIW I wrote a post about this design issue:
Oils Is Exterior-First (Code, Text, and Structured Data) - https://www.oilshell.org/blog/2023/06/ysh-design.html#survey...
That is
- Powershell and nushell have an "interior" design (within a process/VM)
- while POSIX shell, bash, OSH, and YSH have an "exterior" design (between processes)
And I'll claim that the exterior design is the glue you need in large, heterogeneous systems. Making the shell "interior" and "easy to use" is at odds with the role as essential glue -- it creates pressure for something else to be used instead.
---
Maybe the more pithy statement is here:
A Sketch of the Biggest Idea in Software Architecture - https://www.oilshell.org/blog/2022/03/backlog-arch.html
The lowest common denominator between a PowerShell, Elvish, Rash, and nushell script is a Bourne shell script (and eventually a YSH script)
I also claim this isn't theoretical -- there are probably a non-trivial number of bash scripts gluing together PowerShell and other shells. IMO it's better to have 1 type of glue, than 2 or more types, which I call "Unix sludge / Cloud sludge".
---
And I disagree with this part, which references protocol buffers:
> how do you get a schema? well, you establish in-band communication. RPC is ...
Protocol buffers transmit schemas OUT of band, usually via a monorepo. The data sent over the wire can't be interpreted without the schema information compiled into the binary.
The monorepo works well enough within Google, but even there it failed to scale (probably around the time of "Alphabet", e.g. Waymo and other companies)
Also, protobufs are biased toward C++; users of other languages feel this friction to varying degrees. In general, they'd rather use .gob for Go, pickle for Python, JSON for JS, Java serialization, etc.
Unix shells (local), I'll add in HTTP (remote), and Email (remote and asynchronous) are the only forms that are ubiquitous, precisely because they enforce no structure for the payload. The structured alternatives are only popular in specific domains because they create their own ecosystem. As long as input can clearly be parsed, which goes hand in hand with being human-readable as long as you're not trying to be too efficient, you get schema implicitly transmitted out of band (by having output that you can visually inspect) and interoperability for anything that can read and write text.
I'd be interested in other directions this might go, but I remain skeptical of anything that will introduce and enforce a new paradigm that requires adding complexity to programs to accommodate it.
Sharing data is just totally undefined for the overwhelming majority of all data in the world, because there just isn't any standard for the format the data should be in.
Data models are even harder, because whereas data is produced by the world, and data formats are produced to intentionally be somewhat generalized, data models are generally produced in the context of a piece of software.
POST /api/users
|> validate: `
name: string(3..50)
email: email
age?: number(18..120)
team_id?: number
`
|> jq: `{ sqlParams: [.body.name, .body.email, .body.age] }`
|> pg: `INSERT INTO users (name, email, age) VALUES ($1, $2, $3) RETURNING *`
|> result
ok(201):
|> jq: `{ success: true, user: .data.rows[0] }`
validationError(400):
|> jq: `{
error: "Validation failed",
field: .errors[0].field,
rule: .errors[0].rule,
message: .errors[0].message
}`
https://www.rfc-editor.org/rfc/rfc1855
Communication has not been merely a matter of personal habit — it follows commonly accepted standards for exchanging information within a group. Ignoring these conventions risks your message being unread, unheard, or misunderstood.
That said, it seems possible the author is intentionally addressing a specific subgroup that has agreed upon a different set of communication rules.
let host;
if (document.referrer) { host = (new URL(document.referrer)).host; }
if (host === "news.ycombinator.com" || host === "lobste.rs") {
let style = document.createElement('style');
// let transform = host === "lobste.rs" ?
style.textContent = `
body { text-transform: uppercase; }
pre, code { text-transform: none; }
`;
document.head.appendChild(style);
console.log("HN readers clearly can't handle the typing habits of the average trans girl.");
return;
}
PaulHoule•5h ago
nikolayasdf123•5h ago
PaulHoule•4h ago
That is, I'm not afraid of being branded subversive because I like to eat strange foreign foods, I'm afraid that I'm going to get the worst pizza in town instead of the best pizza in town because somebody paid off Apple or because Google or Facebook can put up a tollbooth in front of new entrants or that they might not be interested in working with or being fair with independent restaurants because private equity has bought most of them up.
idle_zealot•5h ago
jynelson•5h ago
mapcars•5h ago
Yes its editable in runtime, but not the whole thing and not reliably so: I remember changing some low level array methods that broke the whole image.
Even in pharo your data has to be organised in some way and if you add new code to existing image you have to know how to reach the data you need.
And the biggest downside to productivity and stability is it doesn't have a type system and every action can fail because the receiver doesn't support a particular message.
igouy•1h ago
> data has to be organised in some way
Yes it does.
igouy•1h ago
https://www.cincom.com/blog/smalltalk/smalltalk-programming-...
PaulHoule•5h ago
coldpie•5h ago
https://learn.microsoft.com/en-us/windows/win32/com/com-tech...
pjc50•5h ago
All the apps are carefully sandboxed, because left unattended they will steal your data. The new category of AI largely works by sending your data to a server in the US where it can be surveilled. It would be great to have interoperability but first the user has to have confidence that it's not going to be weaponized against them.
jdauriemma•2h ago