Convenient way of saying "you're holding it wrong".
6,487 karma · joined April 24, 2019
Convenient way of saying "you're holding it wrong".
A lot of people are bashing old practices, but from y standpoint, it always seems like a lack of proper (usage of) tooling to streamline the coding phase of building software.
We have something that is statistical in nature so there should never been any expectation of error-free results/actions. The value has always been about discerning trends or the cost of errors being way lower than any good result.
They don't care, but they care about their computer being slow because of swapping. While they can't identify the cause and link it to the various Electron apps they're using (Teams, Slack,...) it's obvious for the tech-aware person they complain to.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
It requires the same mental model as git.
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.
Maybe you can explain how is it leaky based on your understanding of version control?