I mean, "cool". You have ideas, but everybody has one, I have mine and I guess there will be someone with even multiple ideas on the matter. So we will not ever be able to agree, point.
So why bother?
81–90 of 123 posts
I mean, "cool". You have ideas, but everybody has one, I have mine and I guess there will be someone with even multiple ideas on the matter. So we will not ever be able to agree, point.
So why bother?
Rich Hickey and Bret Victor here are squashed into overly simple (and/or wrong) categories whose descriptions go like "the best programs [...] formally prove correctness" and "beautiful code is more important than beautiful UI". Both have been very vocal against these points.
Jon Blow is definitely not (just) in category 2. "But one of the reasons his last game (The Witness) took so long to write was that he wrote his own engine instead of using something off the shelf [...]. I understand". He'll probably have a heart attack reading this deep, deep assumption that creating his own thing slowed down his unique game rather than enhanced it.
As someone who does OCaml (and who maintains ReasonReact), shoving it into the category of "poetry is more important than execution speed" and "code over UI" is exactly what we're going _against_. It sucks to emphasize pragmatism, compile & runtime and UI, only to be shoved back into the "poetry" category.
I get a weird feeling criticizing a blog post that mostly gets the right idea across but then goes e.g. "don't worry, we get that you're a poet and care more about that than real-world execution and we empathize with your different perspective" or "we get that you don't prioritize writing simple beautiful code". Like, I _do_ care and these folks _don't_ abide by what you're describing. There's gotta be a name for this.
Good article, though Ada is misplaced there. It is more of a maker’s language. It just has a formal proving add on (SPARK) available to test correctness because of its use in mission critical software where correctness really really matters. People who love Haskell, lisp, etc. despise Ada.
> People who love Haskell, lisp, etc. despise Ada. Why?
I think the author probably thinks Ada's type system is more powerful than it actually is (or is just thinking of SPARK). Ada is basically just verbose C with a slightly nicer type system and better aliasing rules.
This post is nice, but... Rich Hickey and Bret Victor here are squashed into overly simple (and/or wrong) categories whose descriptions go like "the best programs [...] formally prove correctness" and "beautiful code is more important than beautiful UI". Both have been very vocal against these points. Jon Blow is definitely not (just) in category 2. "But one of the reasons his last game (The Witness) took so long to…
But extremes are useful to define a scale. In your work on ReasonReact, how much time do you spend thinking about the ergonomics of the users? It sounds like a fair bit of your time and mental cycles go into that. So it sounds like you sit somewhere between the extremes of those camps. I don't think I would have been able to say that sentence without defining overly steriotyped, extreme positions.
And there's lots of interesting thoughts that follow from that - like, what happens when those motivations come into conflict? Eg, users care about feature X, which is going to be really ugly to implement, but desired. What do you do?
In modern app development our computers are fast enough that this kind of thinking isn't really important any more.
Thinking it doesn't matter is how we end up with things like instant messaging clients using billions of bytes of memory and billions of CPU cycles to receive a dozen bytes of text and display it on the screen, and when every application on the system wants to consume like that, none of them can, and the result is unhappy users.
That said, from my experience it often turns out that the simplest code is also the most efficient and elegant as well as being likely to be correct, so from that perspective I'm essentially valuing all 3 tribes.
Makers are a dime a dozen. In the end everyone is "making" something so everyone is a "maker" in a sense. It's just the "makers" described in the article don't know how to hack or write a poem so they just concentrate on delivery time.
Earlier quoted context omitted.
At the risk of just jumping on a single point: > I build things for people to use and maintain. Maintenance. Maintenance. Maintenance. That's the key. It is the lack of that mindset which is killing our home world. Ultimately, it's just expression of not having to pay for your externalities. It also kills software dev. If software devs were actually held to account for their legacy (software, hah), then we'd have a l…
In context of this, I've always been thinking that software engineers should be held way more liable -- like those of the physical engineering disciplines. In order to enforce good software engineering practice, there must be either incentives or disincentives (carrot or stick) that have clear consequences on the engineer himself/herself. Otherwise there is nothing stopping them from producing bad work. It may be uni…
This is the kind of piece I am happy to forget about as soon I stop reading it in the middle of the page, because its basically strong opinions on how pretty much everybody should see everything in CS and the whole industry in general. I mean, "cool". You have ideas, but everybody has one, I have mine and I guess there will be someone with even multiple ideas on the matter. So we will not ever be able to agree, point…
I know what you're talking about though... Lots of blog posts talk about their own ideas about the industry that are largely irrelevant. But if you touched all the technologies he has listed in his write up you'll see he's completely correct. He's not speculating about something. This is reality.
I think this is a good article, but ironically I think all three tribes would actually describe themselves the same way many times (whereas this article implies they'd describe themselves, or what matters to them, differently). To use an example from the article, I think Jonathan Blow would absolutely argue that he wrote his own game engine because it was best for his user . Whether you agree with him or not, he is w…
Re: Jonathan Blow, I don't think it's a stretch to say different/better tools can have a profound effect on the industry and resulting games as a whole. As someone in games, quite a lot of software has had far-reaching impact that influenced games on a noteworthy level. Speedtree, Zbrush, and the substance package have basically defined modern AAA art assets. And while the major public engines have had a profound imp…
I'd consider myself almost entirely between the 2nd and 3rd "tribe", and I very much disagree with this: In modern app development our computers are fast enough that this kind of thinking isn't really important any more. Thinking it doesn't matter is how we end up with things like instant messaging clients using billions of bytes of memory and billions of CPU cycles to receive a dozen bytes of text and display it on…