4 ms·

As I answered elsewhere in this thread, I did not say a word about design. I was talking about programming solely. Design is not only a complex problem, it is

by sklogic 11y ago

As I answered elsewhere in this thread, I did not say a word about design. I was talking about programming solely. Design is not only a complex problem, it is an unsolved problem. Is there any passable design out there? I have not seen it yet. It is either disgusting, incomprehensibly disgusting, or, in the best case, barely tolerable. And the same thing is going on in any kind of an industrial design, it is not limited to web. As for the type class hierarchy, yes, I did not notice this bit, thanks. I'll take a closer look now.

lmm 11y ago
Programming is nothing but design - a full spec of what needs to happen is a program. Like any other kind of programming, if parts are trivial you automate them, until you're at a state where what you have to do to accomplish a given task is precisely the amount of thought/uniqueness that that task involves; if you're a programmer then you never need be doing mindless drudge work (you've got a computer for that). When you've automated most of what used to be your job, reaching up or down the stack is a good way to find more things to automate (or you can simply increase throughput, but often that just means other parts of the business become the bottleneck). IME it's if anything easier to get closer to the "full brain all the time" state with web programming, because there's so little external latency, whereas in hardware there's only so much you can do before you're spending most of your time waiting for slow test cycles or actual manufacturing (even if you try to reduce the importance of those by introducing things like formal methods, others will often want to see a few test cycles to prove the effectiveness of those).
- sklogic 11y ago
  > Programming is nothing but design No, it's a different kind of a "design". It's an engineering. You've got a set of constraints and need to optimise a solution until all the constraints are met. Purely mechanical. Designing something for a human interaction is different. It involves extorting information from a not necessarily cooperative and not very sane human, reducing it to a reasonably sane subset and then finding out the workflows that would make sense for a living human being. Unsolvable. Impossible. Got nothing in common with something as simple as "here's a high level formal description of an algorithm, turn in into a code". > whereas in hardware there's only so much you can do before you're spending most of your time waiting for slow test cycles or actual manufacturing In my book, it's a blessing. Time to slow down and reflect on what a mess you've just created.

by sklogic 11y ago

lmm 11y ago

Programming is nothing but design - a full spec of what needs to happen is a program. Like any other kind of programming, if parts are trivial you automate them, until you're at a state where what you have to do to accomplish a given task is precisely the amount of thought/uniqueness that that task involves; if you're a programmer then you never need be doing mindless drudge work (you've got a computer for that). When you've automated most of what used to be your job, reaching up or down the stack is a good way to find more things to automate (or you can simply increase throughput, but often that just means other parts of the business become the bottleneck). IME it's if anything easier to get closer to the "full brain all the time" state with web programming, because there's so little external latency, whereas in hardware there's only so much you can do before you're spending most of your time waiting for slow test cycles or actual manufacturing (even if you try to reduce the importance of those by introducing things like formal methods, others will often want to see a few test cycles to prove the effectiveness of those).

sklogic 11y ago
> Programming is nothing but design No, it's a different kind of a "design". It's an engineering. You've got a set of constraints and need to optimise a solution until all the constraints are met. Purely mechanical. Designing something for a human interaction is different. It involves extorting information from a not necessarily cooperative and not very sane human, reducing it to a reasonably sane subset and then finding out the workflows that would make sense for a living human being. Unsolvable. Impossible. Got nothing in common with something as simple as "here's a high level formal description of an algorithm, turn in into a code". > whereas in hardware there's only so much you can do before you're spending most of your time waiting for slow test cycles or actual manufacturing In my book, it's a blessing. Time to slow down and reflect on what a mess you've just created.