skydhash

> they can develop half-decent Electron apps with VS Code,

Only if you don't compare it with any native or quasi native editors like Notepad++ or Sublime text. And Emacs has been cross-platform for decades.

> it is in the product and organizational challenges of keeping those two products that need to be identical in sync.

They're two different platforms where the capabilities and UI patterns differs, so I don't see why they should be in sync. The web platform is not in sync with them. And using native features can give you a nice boost in maintenance and speed, unlike React Native where you always needs to align library semantics.

It's useful when starting a thread of research of research as new tabs will be opened to the right (Ctrl+Clicking a link). So after it's done, close to the right can be quite useful.

Not GP, but I can humbly share mine.

I think it's because a lot of analytics are data points oriented instead of being workflow oriented. So you can see that feature A is not being used a lot, but it's very important in a particular flow. Feature B may be used a lot, but it can be only important for a particular class of users while very detrimental mentally for another class.

People use software for a needs, but rarely I've seen a need being highlighted when interpreting analytics data.

> Breaking things is not fun.

I don't know. I broke a lot of things when I was a kid, mostly because I was excited to see how they work, but have no knowledge of their value or how to safely disassemble them. I don't do it as an adult because I now have that knowledge. So don't judge a kid as an adult.

>> > They also keep bringing up gigantic mono-repos and how Git can't handle the scale at which AI increases the amount of code bloat or commits.

I also doubt very much that the average monorepo is bigger than the linux kernel. While the latter is a single software as things go, it contains quasi independent subsystems. And those repos don't usually have a merge flow that is as smooth as the Linux kernel. If you have chaotic process, then the result won't be very good and it's not git's fault.

> to translate code into a different language someone would need to write a tokenizer, a parser, an AST and finally a translator. All significant engineering challenges, taking days to finish. Nowadays you can tell an LLM to do that in minutes.

Do people do that on a regular basis? The most recurring case of building the above is when someone wants to include a language into a project and they usually don't bother with a translator. The second case is when transpilling (ex. LESS to CSS) and that's more akin to macro and other preprocessing tricks than a full blown translation.

> we could easily argue that CSS wouldn't have existed if LLMs existed and could create table layouts from pasted images in a chat window.

All current UI and Document conceptual models include styles (either as direct properties or separate models) and some does include named styles. The novel aspect of CSS is the Cascading concept, not the styling part. And cascading is obvious when we consider that there was supposed to be user stylesheets for documents. I read epub and user stylesheets (created from UI) is crucial.

Isn’t it something like $10/yr or something?

> The surface area of stuff that an OS has to do today is absolutely massive, and the dependency graphs are poorly understood even by the engineers who work on those systems. Innocuous pieces of functionality have a way of becoming load-bearing over time

It’s not that huge. I use OpenBSD and the code is surprisingly approachable and readable. And even with no support for runtime modules, it’s pretty easy to customize and strip out whole features. Current complexity in something like linux is stretching the subsystems to support a huge array of use cases.

> You have to remember the Win (and MacOS) kernel is tuned to consumer desktop user use cases, while Linux kernel is tuned to server/DC use-cases.

I don’t mind the kernel doing kernel things. The issue is system services and other software that are either unnecessary or badly coded. You can’t disable them because of “reasons” and they’re just wasting your time and your electricity.

The thing with windows is that there is no idle state, something is always busy with the CPU/hogging ram. With Linux I can have like 98% idle and the system taking 2Gb out of my 8gb of ram, but with windows, the system is more like 30% cpu and more than 4GB of currently being used ram.

Running OpenBSD as a daily driver but with no DE.

It has a working X11 with DRM from linux as base so everything graphical will work mostly fine. The issue is more around the OS and some subsystems. OpenBSD is still using the Giant Lock model, so SMP can be an issue. Linux has more independent subsystems so heavy processing is unlikely to impact usb audio (which is an issue I have with my oldish laptop). Another issue is the input subsystem (wscons framework) which is not as sophisticated as Linux Input subsystem. In general, linux subsystems are more sophisticated/complex than their OpenBSD counterpart, but the latter work well enough.

There are some linuxisms in some applications (the recent moves to wayland/systemd,...) but they're mostly easy to port.

Have you tried using it in the case where React is actually a good help (very interactive apps)? And try to generate vanilla code for that as well?

I’ve been using magit lately, but I only do ‘git add .’ when it’s a very simple change. Especially in complex projects, I do some changes to isolate code or fix other issues in passing. So I stage by lines and hunks to isolate specific changes and commit them one by one. But magit is the vim of version control, so no speed issue there.

Does the architecture change or the weight change?

If you modify an engine to increase it’s output by adding sensors and an ECU, you don’t change the fact that is powered by gas.

If you use RL to increase the accuracy, it’s still a next token prediction, just more accurate.

> Most of us build a system to deliver a product to make money

Shouldn’t it be to deliver a system that is sold as a product? And even then that product is sold to consumers to solve their problems. Not knowing how it works means you don’t know what solution you’re selling.

You can see that in a lot of product announcement where the focus is on what they’re building, but not on how it solves some problem. The consumer is absent from the design process.

Pretty much this, they want to impose one method, but they don’t want to own the mistakes that it creates. Sometimes it felt like the bullies that are saying “why are you making me hurting you?”.

> That just sounds like a tower of abstraction to me;[...] I still don't see a division into two classes of abstraction.

It is a tower of abstraction as it's recursive. It's just that at every layer you will be dealing with two types, the primitive from the previous layer and the new system that you're building in this layer. Something like Character is a composition of symbols (bit) and encoding (ASCII, Unicode), in a specific form of Data.

DDD is kinda a meta on that where the emphasis is to simultaneously build a glossary (primitives) while also trying to define subdomains to restrict their semantic. But that's an approach for software architecture, not general system modeling.

> I guess I don't understand the argument here because those just sound like two different flavours of the same custard to me; the difference is just the balance of work you're doing on each side of the interface, and that decision depends on use cases specific to the project.

It is two different flavours. One is about interconnecting things, and the other is what you interconnect. What TFA called modelling abstraction seems to be the primitive ideas that goes in building more complex systems (which it calls Modularity Abstraction). Something like a String is not a primitive, but rather a combination of the idea of Character and List are. Just like you can go from a disk (a pure array of bytes) to a file system (in the unix world, a tree with nodes of metadata). The primitive here are Array (existing) and Tree (target) and with them you build a modular system (The file systems) that transform ones into another.

So yes, both are abstractions, one is about identifying primitives, and the other is about combining them.

> [ Note that his list is all about modularity abstraction: TCP (hide IP), string libraries (hide character arrays), file systems (hide spinning disks), virtual memory / flat address space (hide MMU and paging), SQL (hide query plans), NFS / SMB (hide the network), C++ string classes (hide char*). ] Modularity abstraction aspires to hide the interleavings and present operations as if they were atomic.

I wouldn't go with that. Most of the listed abstraction here is about building a new model on top of the old for new capabilities. They don't bother to hide them, merely use them for new purposes.

Like TCP using IP for interconnection, but adding transport stability on top. IP is still fairly visible, but in an axiomatic way. Same with string libraries which mostly add new operations but the nature of being a list of characters is still present.

A better example of abstraction for hiding are libraries where the public interface hide the nature of implementation (things like POSIX). This aligns more with the modeling abstraction, where you extract a minimalistic version of the system. Incomplete for implementation, but enough for interfacing.

Most AI use cases can be reduced to a deterministic listing/form/report format (on the web) or a cli tools.

Yep, people are typing comments with a computer that is powered by several layers of software that will be stored on another computer powered by several layers of software to be read on a computer also powered by layer of software. And then they hope to make the argument that humans cannot produce software.

Magit doesn’t anything that is not readily available in git. Most of magit usefulness comes from “active objects” (meaning you can act directly on the report of some commands like git-log) and quick command construction due to transient and autocompletion.

It requires the same mental model as git.

The goal is to produce music, and such music is generally constrained by music theory. Using git is to version control some software, and version control is dependent on the programmer/team workflow.

At the team level, it’s guided by the release process, configuration management, which version is canonical. At the programmer level, it’s usually guided by how to switch between task, how easy to explore an idea and save the resulting experiment, how to reset the code to a know state and how to replay a previous changes on top of new changes.

So you discern what you want to do (which is independent of the tool), the learn how to use git to do them. If you start from git, you’re going to be confused, just like someone opening autocad with no knowledge of engineering drawing.

What is version control to you? For me it’s basically being able to store and retrieve snapshots of code at different instances of time, where each instance has its own significance. Checkout have a very precise meaning in that regards, just like add and commit.

Maybe you can explain how is it leaky based on your understanding of version control?

I would say “align the worktree (or part of it) to a specific state previously saved in the repository.”

The repository is a store, you check out the previously saved instance of a file, a group of files, or a subtree. In that regards, switching branches and restoring files is actually the same thing. A commit stores whole files and branches are pointers to commits (which update themeselves).

We usually don’t. We look at the harm/benefits ratio and if way too big, we usually ban them. Guns, various chemicals, explosives,… is not allowed for any random cases. I’m not calling for regulation but you can understand why someone prefer not to associate themselves with it.

> Computers have produced untold exabytes of spam. Hit pieces, security vulnerabilities and data leaks[...] massive increase in water and electricity consumption. etc.

Then you must blame cars and airplanes as mass murdering tools as well.

> He says “a lot of developers have not learned git IN DEPTH” and you respond by saying that’s not true because you’ve gotten away with just using a small subset

You forgot the “because it's actually kind of terrible from a UX standpoint”. My stance is against that. I haven’t learned git in depth because I never knew any other workflow than code and check in the changes. There’s not a lot of guides on how version control can help in the software development process.

It wasn’t until I got involved into OSS that I learned more which in turns give me the motivation to use and learn about git in depth. I’m also using magit (after a tour in various GUI) but for me it is to git what vi is to ex. Direct interaction instead of a command prompt.

Not really. Learning the piano and learning music theory is two different things but tied together. One is skill and muscle memory, the other is theory and understanding. It’s the same with git and version control. One is a process and the other is a tool.