I disagree, but it doesn’t mean you’re wrong - we might just be looking for different things.
My view is that if you’re going to talk like a bored robot, then I need a transcript or a paper which is much shorter than a talk. I distinctly remember not going to classes at university because the teachers wouldn’t give me anything beyond reading a book aloud. I just read the book at home.
Now, if you’re able to indicate what’s important and not important, what’s interesting and what isn’t , and why you like it , I’ll be delighted to watch your talk.
I think it’s very difficult to be interested in something new if the presenter doesn’t seem to care about it. This is different from something written , where I expect something dry anyway.
The git documentation is one of the nastiest docs ever just like the whole git ui. It’s technically entirely correct, but won’t help you understand how it works in any way.
It’s exactly like folks in 1995 telling you to rtfm when you’re trying to install Linux from a floppy disk. It’s doable, but annoying, and it’s not that easy.
That's really unexpected.
To me, git documentation was one of the best cleanest official docs I've ever read.
Just in case, I'm talking about the Pro Git book [0]. I remember reading it on my kindle while commuting to office by train. It was so easy to understand, I didn't even need a computer to try things. And it covers everything from bare basics, to advanced topics that get you covered (or at least give you a good head start) if you decide to develop your own jujutsu or kurutu or whutuvur.
The book says that ‘ To really understand the way Git does branching, we need to take a step back and examine how Git stores its data’ then it starts talking about trees and blobs.
At that point you’ve lost almost everyone. If you have a strong interest in vcs implementation then fine, otherwise it’s typically the kind of details you don’t want to hear about. Most people won’t read an entire book just to use a vcs, when what they actually want to hear is ‘this is a commit graph with pointers’.
I agree with you : the information is there. However I don’t think you can in good faith tell most people to rtfm this, and that was my point.
> I don’t think you can in good faith tell most people to rtfm this
I can, and I do.
The explanation in that book creates a strong coherent and simple mental model of git branching. I honestly can't think of a better explanation. Shorter? Maybe. But "graph with pointers" wouldn't explain it.
So based on my experience teaching git ( I remember a cvs to git migration …) , reality tells me people find git difficult.
Now, once you teach them it’s a commit graph with names, some of them floating, some people get it.
The thing is, not everyone is comfortable with a commit graph, and most people are not - just like people get lists and arrays but graphs are different.
So I agree with you on principle ( it shouldn’t be difficult), but most people don’t have a graph as a mental model of anything, and I think that’s the biggest obstacle.
I don't use these tools that much ( I tried and rejected Cursor a while ago, and decided not to use it ) but having played with GPT5 Codex ( as a paying customer) yesterday in regular VSCode , and having had Composer1 do the exact same things just now, it's night and day.
Composer did everything better, didn't stumble where Codex failed, and most importantly, the speed makes a huge difference. It's extremely comfortable to use, congrats.
Edit: I will therefore reconsider my previous rejection
FWIW I come from a non working class background ( but am not American ). My friends and I routinely debate in such a manner, and don’t see any problem with this. If confronted with a stranger we might be a bit more cautious ( basically we’ll state the rules of the conversation) but that’s about it. If needed, we’ll sometimes be a bit more accurate.
I understand your statements as you mean them - I default to giving you the benefit of the doubt, and automatically assume that black and white statements are shortcuts. Only, and only if you seem to not understand nuance then I will adjust my stance, but I usually assume you do!
I think the problem can be described as assuming good faith in the argument - that is, that you're talking with someone who you are presuming is attempting to communicate, not just "win" the conversation.
The difference becomes clear very quickly - if there's a genuine misunderstanding, someone will clarify and move on; if someone is trying to rules lawyer the conversation, it won't.
Pascal is not a low level language - quite the opposite.
That being said, various implementations provide low level facilities, including turbo pascal back in the days , and free pascal which I did use in the early 2000s.
If I were you, if you like fpc, I’d actually look into Ada ( the OO part is a bit odd granted but works ). You’ll get extremely high control over low level stuff ( it’s used in the embedded world ) along with high expressivity and excellent performance.
The way you express it is different from most other languages I’ve come across.
It doesn’t make it bad in any way ( I’ve written Ada professionally), just unusual. Basically Ada already provides natively substantial capabilities relative to encapsulation, modularities, generics etc but in a procedural context. The designers bolted on OO facilities on top of said existing mechanisms.
While it may look reasonably clean in the link below, I’ve always found it integrates badly with an existing codebase, the primary problem being that the ‘boundaries’ of the objects are not clearly visible.
I had the same experience as you with Le Monde diplomatique. The language used in some of the articles felt a lot like propaganda ( hyperbolic language, us vs them, anger/emotional language, basic facts being ignored etc ). I was very surprised since the paper had a good reputation , and gave up. Maybe ( hopefully) this has changed.
Same here - I did consider buying a steam deck, then after experimenting with GeForce now on a small screen realized that pc game designers assumed larger screens. This is ok, but this makes many games unplayable on a small screen unless you have some kind of cyber vision. So no steam deck, even though every now and then I want to buy one.
My view is that if you’re going to talk like a bored robot, then I need a transcript or a paper which is much shorter than a talk. I distinctly remember not going to classes at university because the teachers wouldn’t give me anything beyond reading a book aloud. I just read the book at home.
Now, if you’re able to indicate what’s important and not important, what’s interesting and what isn’t , and why you like it , I’ll be delighted to watch your talk.
I think it’s very difficult to be interested in something new if the presenter doesn’t seem to care about it. This is different from something written , where I expect something dry anyway.
reply