When I complained about how ill-defined "simple" was, a lot of people pointed me to Hickey's "simple made easy". Here's a challenge about that: Provide code that is simple but not easy. Then provide code in the same language, doing the same thing, that is easy but not simple.
-
Show this thread
-
Replying to @hillelogram
Took me a while to get to it, but I re-watched this talk as a result of your tweet and the most striking thing to me is how it's a series of reasonable sounding but totally unsupported and often ill-defined and/or unfalsifiable claims.
1 reply 3 retweets 12 likes -
Replying to @danluu @hillelogram
Like, "we can only hope to make reliable those things we can understand". Sounds reasonable, how can you argue with that? But, in fact, this is quite common in engineering. A lot of engineering is making reliable things we don't understand!pic.twitter.com/lGzSb0m1bq
2 replies 0 retweets 8 likes -
Replying to @danluu @hillelogram
When I worked on flash mem (2001), I read the literature on how it worked. At the time, the exact physical mechanism by which some things happened wasn't understood. There were theories, but multiple theories were consistent with what was observed. But we can make flash reliable!
2 replies 1 retweet 4 likes -
Replying to @danluu @hillelogram
And to the extent that it's not reliable, we can describe when we expect it to be unreliable and what the odds are. Someone might argue that this is equivalent to "understanding", but that's your point, I think -- the talk is so vague it can mean whatever you want.
1 reply 0 retweets 1 like -
Replying to @danluu @hillelogram
He has this idea that composing simple components is the way to make robust systems and that abstractions over complexity are worthless.Sounds reasonable, but we manage to build reliable chips even though the underlying physical mechanics we abstract over are tremendously complexpic.twitter.com/ESbBbYQKgB
2 replies 4 retweets 3 likes -
Replying to @danluu @hillelogram
The big productivity boosts have been abstractions that hide but don't eliminate underlying complexity. Gate-level design instead of transistor-level design, RTL instead of schematic capture, synthesis instead of doing raw circuit design, etc.
3 replies 2 retweets 7 likes -
Replying to @danluu @hillelogram
Later, he says you should just use data structures because they're "simple". Imagining the same idea in EE: no gates, only do layout because it's simpler. Metal, poly, and n/p-wells are "simple", why complicate things with gates? We're EEs, it's all physical layout in the end.pic.twitter.com/uEiZ1CY7Zk
3 replies 0 retweets 5 likes
As for software, why have data structures? Memory is actually very simple. There are not a tremendous number of variations in the essential nature of memory. There are locations that contain addresses. There are locations that contain values. There are not a lot of other concep
-
-
-
Replying to @Kensan42
Hallo please find the unroll here: Thread by
@danluu: "@hillelogram Took me a while to get to it, but I re-watched this talk as a result of your tweet and the most striking th […]" https://threadreaderapp.com/thread/1128855310867677184.html … Share this if you think it's interesting.
0 replies 0 retweets 0 likes
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.