7 ms·
The whole point about abstractions is you shouldn't need to understand the internals to use them. If the best defense of git is "once you understand the inner w
by johnfn 9y ago
The whole point about abstractions is you shouldn't need to understand the internals to use them. If the best defense of git is "once you understand the inner workings, it's so clear" then it is by definition a poor abstraction.
- andrewflnr 9y agoWho said it's supposed to be an abstraction? The point, theoretically, of something like Git is that the actual unvarnished model is clear enough that you don't need an abstraction. The problem IMO is that the commands are kind of random and don't map cleanly to the model.
- AstralStorm 9y agoIndeed, the worst offenders are in my opinion checkout, reset and pull. They mix multiple only slightly related commands in one.
- simik 9y agoThere are couple projects that try to tackle this problem by providing an alternative CLI (on top of git's own plumbing), like gitless and g2. Haven't used any of them myself, but would be interested in experience of others.
- specialist 9y agoLeaky abstractions is how we get stuff like ORMs.
- pritambaral 9y agoTo be fair, most ORMs poorly implement the "leaky" principle. When implemented well, like with SQLAlchemy, the end result is a much nicer ORM. In fact, one of the things in common among the ORMs that have left a bad taste in my mouth is that they all tried to abstract away SQL without leaking enough of it.
- specialist 9y agoI have a different thesis: Picking the ideal interface to abstract is critically important (and very hard). In the case of ORMs, available solutions abstract the schema (tables, rows, fields), the objects, or use templates. My solution abstracted JDBC/ODBC. The only leak in my abstraction was missing metadata, which I was able to plug (with much effort!). My notions for interfaces, modularity, abstractions are mostly informed by the book "Design Rules: The Power of Modularity". http://a.co/hXOGJq1 http://a.co/hXOGJq1
- naasking 9y agoAny interface means you'll build an mental model of the system you're manipulating. How else could you possibly know what you want to do and what commands to issue? So given a mental model is inevitable, seems reasonable that that model should be the actual model.
- ethbro 9y ago> So given a mental model is inevitable, seems reasonable that that model should be the actual model. I think the longevity of SQL has proved there's value is non-leaky abstracted interfaces.
- flukus 9y ago> I think the longevity of SQL has proved there's value is non-leaky abstracted interfaces. How is sql non-leaky? To be proficient with sql you have to understand how results are stored on disk, how indexes work, how joins work, etc. To debug and improve them you need to look at the query plan which is the database exposing it's inner workings to you. You have to know about the abstractions an sql server sits on as well. Why is it faster if it's on an SSD instead of an HDD? Why does the data dissapear if it's an in memory DB?
- bch 9y ago> To be proficient with sql you have to understand how results are stored on disk, how indexes work, how joins work, etc No, you don’t. As far as I know, the data is stored in discrete little boxes and indexes are a separate stack of sorted little boxes connected to the main boxes by spaghetti. This is the abstraction, it works, and I don’t need to know about btrees, blocksizes, how locks are implemented, or anything else to grok a database.
- boudin 9y agoI disagree with that. The point of an abstraction is to not having to know the implementation. Understanding the principles used behind will always lead to a much better use of your abstraction
- AlexCoventry 9y agoI'd also say an abstraction could be carrying its weight even if it only reduces the amount you have to think about the implementation details when using it.