3 ms·
Okay, I'll bite. Analogies are not really helpful for software development. Comparing software development with building a house doesn't work and this compariso
by keithb- 10y ago
Okay, I'll bite. Analogies are not really helpful for software development. Comparing software development with building a house doesn't work and this comparison with foods doesn't work either. The problem is not in your mocks or your layers. Software development is about translating prose into code. Given that, it doesn't really matter if your shell is imperative or reactive because your job is translation not creation.
I had a feeling something was going astray when the examples were primarily about data access and I/O. Reactive is (at best) a framework for handling streams and events. CRUD events aren't a great place to start because you're only showing the happy path. What about sequencing? What about retry? What about conflict? I'm not questioning your concept; it's the application.
Reactive isn't a translation technique which is ultimately why these analogies fail. Sometimes I wish software engineers could have a Roy Fielding/REST moment where someone comes along and clarifies the purpose of software engineering by pointing out the fact that everything you need already exists. In lieu of that, I'm sure that people smarter than me will eventually abstract away the reactive boilerplate behind some language keywords because the alternative (i.e. more data access and service endpoint examples) is really tiresome.
- sesm 10y agoI think those slides try to convey the same idea, as the famous paper "Out Of the Tar Pit" (although, I'm not sure author read the paper) Reactive and functional approach don't help you to deal with the essential complexity of your problem, but they do minimize incidental complexity, the primary source of which is the mutable state.
- kod 10y ago> Software development is about translating prose into code...your job is translation not creation. This is so fundamentally at odds with my experience of software development I have to wonder where you're coming from. Most of the projects I've worked on didn't have prose descriptions of requirements. In the cases that did, the prose was quite out of sync with the actual business problem that needed solving. Paid software development is about solving business problems by writing as little code as possible. It's rare enough for people to fully understand what the problem is, much less know the full solution in advance. This makes software development an inherently creative endeavor - you need to discover what the actual problem is, and create a solution for it.
- Sharlin 10y agoIndeed. I guess the old car mechanics' joke [1] applies in software development too. [1] Eg. https://s-media-cache-ak0.pinimg.com/736x/ee/8e/f6/ee8ef6c2a73e89f6aae8a6366538a8f0.jpg https://s-media-cache-ak0.pinimg.com/736x/ee/8e/f6/ee8ef6c2a...