61–70 of 95 posts
Simple never means it is easy and it is always the biggest misconception in software.
Strong resonance with the famous essay "The Rise of Worse is Better" [1], which contrasted the (better) "MIT/Stanford style of design" with the (worse) "New Jersey approach". MIT/Stanford: > Simplicity -- the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation. New Jersey: > Simplicity -- the design must be simple, both in implementa…
I appreciate the New Jersey simplicity as a user (with development skills) too, though. It's usually just a matter of time before I have to dive into the program/library/whatever internals to fix a bug.
> The reason for this is that in Rust, a struct couples type-checking to a fixed data representation. You can't get one without the other. > Clojure decouples data representations from type checking. This is funny to me because seen from the other side, (this) Clojure couples runtime type information to data structures: you're no longer allowed to define a data structure that doesn't have some runtime type informatio…
Yeah that example was pretty flimsy and contrived.
Earlier quoted context omitted.
I appreciate the New Jersey simplicity as a user (with development skills) too, though. It's usually just a matter of time before I have to dive into the program/library/whatever internals to fix a bug.
It's why only nerds use Linux (simple for the developer) but everyone uses Office (simple for the user). Sorry, I meant Microsoft Copilot 365.
> There's no native Unix equivalent to frequencies, this sort | uniq -c is the closest we can get. Not only is it less performant (it has to collect the full input into memory before continuing), but it ties aggregation to ordering. One of the core features of the Unix command-line is that it is user-extensible. If there's no "native" command equivalent to frequencies, you can write your own, and it will be given the…
Honestly, so much of our conceptions of "what's wrong" is more to do with lack of familiarity with history than any actually unsolved problem.
Earlier quoted context omitted.
It's why only nerds use Linux (simple for the developer) but everyone uses Office (simple for the user). Sorry, I meant Microsoft Copilot 365.
I think Excel is a good example that everyone can build a clear mental model on how to use it, but implementing one is a daunting task.
Now consider Microsoft Word.
This is beside the point, and I'm being pedantic, but the unix pipeline and the clojure expression don't quite do the same thing. The clojure expression reads the entire file into memory first, and then operates on that memory representation. The pipeline processes the input in chunks. The two `sort`s might read the entire contents into memory, but an implementation like GNU sort will instead, for large inputs, creat…
> Now, let's say we want to make a small change: show the output in the original file order. In Clojure, this is fairly straightforward: store an ordered sequence of the words in word_seq, store a map from each word to its frequency in freq_map, iterate over the sequence, and look up each word in the map:
Emphasis on just "storing" something. The author seems to not understand that this change makes the solutions categorically different.
It's a little like critiquing the efficiency of moving a piano up a stairwell by saying why didn't they just use a crane via the window? Using a crane isn't a better way of getting a piano up the stairwell.
The word simple is used here a way I'm having trouble wrapping my head around. This specific usage appears to come from this linked talk, Simple Made Easy: https://www.youtube.com/watch?v=SxdOUGdseq4 My reaction to the Unix pipeline was that, the reason it exploded in complexity is because the pieces were too simple. They were insufficiently expressive. But the word is used in a different way here, and I'll have to w…
I don’t know. This reads more like a “Clojure is great” post, and Clojure is great. But the author takes a swing and a miss on the Rich Hickey magic. The UNIX example is contrived (the number of occurrences in the order they occur?), and trying to redefine simple in a way that excludes UNIX pipelines doesn’t work.
Honestly, having watched people argue about what simple is for about the last 10 years, I've pretty much settled on it not being a well-defined term. We know complex when we see it for sure, at least when it is present in quantity, but simplicity is not just the absense of complexity. There's at least three concepts we're all trying to stuff into the same word, and they are not only not "orthogonal" they are often in…
Could you try to define these three separate concept?
"Few tokens" - perhaps the most literal simplicity, literally, it doesn't use many tokens to do the job. But as the article points out, that doesn't necessarily fit with...
"Easy to reuse" - This is that simplicity that functional programming aspires to, where you craft some precise abstraction that somehow captures something like "monad". Haskell is full of this sort of simplicity, oozing out of every pore, but people generally think of it as a very complex and hard langauge, contrasting...
"Easy to understand" - As in, not cognitively complex. It is amazing how quickly things that I would otherwise describe as very simple still blow out our little minds. Consider the first time you saw quicksort... or even how it feels now. It's not a lot of tokens, but it's twisty and recursive and especially if you're not mathematically trained and in practice it's easy to call it more "complicated" than a CRUD form that takes in and validates 10 parameters in a straightforward way, even though in terms of what is actually happening the CRUD form may be doing vastly more than the little quicksort algorithm. It just isn't being twisty, recursive, and subtle in how it does it.
And I'm just filling out the first three that come to mind. Note these are not always in conflict by any means... but they certainly aren't always in harmony with each other either.
(One might argue "easy to reuse" is more about the complexity of the code doing the reusing, but I feel like this is definitely something people mean when they talk about the simplicity of code.)
> The reason for this is that in Rust, a struct couples type-checking to a fixed data representation. You can't get one without the other. > Clojure decouples data representations from type checking. This is funny to me because seen from the other side, (this) Clojure couples runtime type information to data structures: you're no longer allowed to define a data structure that doesn't have some runtime type informatio…