3 ms·

[also, reducing tedium]

by 6ren 15y ago

gruseom 15y ago
Yes, beer reduces tedium :) I meant critical for building great software systems sustainably over time. That's also my purpose, if you expand "system" to include the team that's building it. I agree with Alan Kay that the software industry has become a reductio of wildly inflated complexity and that it's possible to do orders of magnitude better. Presumably, anyone who figures out how to do that will be able to do things other companies can't. That is how the world gets changed. Not by persuading others to do it but by just doing it. For a long time, smart people thought it was a matter of writing in more powerful languages, but it seems clear that it isn't that alone. It's not just the medium, but how we're using it. The 64 billion dollar question is: how can we use it better? And how will we know? My hypothesis (not that I invented it, but I subscribe to it) is that we will know when we are able to build valuable systems with drastically less code. Obviously that requires knowing how much code there actually is. I'm fine with LOC as a metric (some HNers convinced me of that) but you still have to know what code you're measuring and what (e.g. libraries, language implementations, OS) you're not. Interestingly, Kay's VPRI project doesn't have this conundrum because they're building everything up from hardware.
- 6ren 15y ago
  Striking some chords, I've thought on these issues too. software systems sustainably over time Aside: the related idea of business sustainability is a business issue, not a technical issue (to do with customer needs and competitors both changing over time). Clayton Christensen sees high-tech as going through phases favouring performance, reliability, convenience then price over time - what wins one phase won't necessarily win the next. Warren Buffet sticks with low-tech (like a brick maker) because slow change enables advantages to be more sustainable over time. reductio of wildly inflated complexity and that it's possible to do orders of magnitude better Yes, their performance sucks, and also distorts the right way to do things (like the MS framework example). But does it depend on which "better" we mean? If better means "time to market", then the present stack is better... I respect much of what Alan Kay has said and done but note he's never had business success. Not by persuading others to do it but by just doing it. Yes, I think so too. :-) It's not just the medium, but how we're using it. I think it's specific abstractions, that suit the problems people are facing - and I think we're making steady progress. From arithmetic, function invocation, namespacing, way up to standard libraries (consider in sequence those of: C, C++, Java, Python) and now web-based APIs. Like scientific progress, it's not one single theory, but a great many specific facts and theories. Each a mysterious journey and heroic victory in itself. BTW: There's that idea of using the analogue behaviour of transistors directly, instead of going through circuits, microcode, compilers and programs to simulate them... amazing performance, but hard to manage. build valuable systems with drastically less code I think libraries. e.g. we can make a valuable website very little code with sinatra (or PHP). That means we're there already :-). I know you're concerned with how to measure the length, and should it include libraries, but I think that if the abstraction suits your problem, it does not introduce unnecessary complexity into your code - and so I'm happy to consider it as part of the platform and ignore its actual cost. I'm not sure how to justify that, but it seems intuitively right to me (like not worrying how long code is in the implementation of arithmetic - I understand the IEEE fp spec is huge). Perhaps because that's the kind of library I'd write if I did the whole thing from scratch. I think this is the nub of our impasse: I'm fixated on clean abstractions, and you're concerned about measuring program length. I think clean abstractions don't contaminate your code with complexity from another level - so you can pretend to start fresh in a new world. Ray Kurzweil suggests this happens with technological innovation, and even in biology e.g. tweaking DNA, cells, multicellular body plans, behaviour etc rather than inventing alternatives from scratch. Similar to SOTSOG. A source of facts: ARM is a new stack compared to x86; and iOS is a new stack compared with desktop OS. Is there progress? They seem better (more efficient, smaller), but using the same fundamentals. Those Forth chips are totally different though. BTW: do you have a link for the ideas about complexity from Kay at VPRI? I looked at their website, but couldn't see anything directly on it - and didn't want to download a bunch of pdfs to search for it. :-)

[also, reducing tedium]

by 6ren 15y ago

[also, reducing tedium]

Yes, beer reduces tedium :) I meant critical for building great software systems sustainably over time. That's also my purpose, if you expand "system" to include the team that's building it. I agree with Alan Kay that the software industry has become a reductio of wildly inflated complexity and that it's possible to do orders of magnitude better. Presumably, anyone who figures out how to do that will be able to do things other companies can't. That is how the world gets changed. Not by persuading others to do it but by just doing it. For a long time, smart people thought it was a matter of writing in more powerful languages, but it seems clear that it isn't that alone. It's not just the medium, but how we're using it. The 64 billion dollar question is: how can we use it better? And how will we know? My hypothesis (not that I invented it, but I subscribe to it) is that we will know when we are able to build valuable systems with drastically less code. Obviously that requires knowing how much code there actually is. I'm fine with LOC as a metric (some HNers convinced me of that) but you still have to know what code you're measuring and what (e.g. libraries, language implementations, OS) you're not. Interestingly, Kay's VPRI project doesn't have this conundrum because they're building everything up from hardware.

6ren 15y ago
Striking some chords, I've thought on these issues too. software systems sustainably over time Aside: the related idea of business sustainability is a business issue, not a technical issue (to do with customer needs and competitors both changing over time). Clayton Christensen sees high-tech as going through phases favouring performance, reliability, convenience then price over time - what wins one phase won't necessarily win the next. Warren Buffet sticks with low-tech (like a brick maker) because slow change enables advantages to be more sustainable over time. reductio of wildly inflated complexity and that it's possible to do orders of magnitude better Yes, their performance sucks, and also distorts the right way to do things (like the MS framework example). But does it depend on which "better" we mean? If better means "time to market", then the present stack is better... I respect much of what Alan Kay has said and done but note he's never had business success. Not by persuading others to do it but by just doing it. Yes, I think so too. :-) It's not just the medium, but how we're using it. I think it's specific abstractions, that suit the problems people are facing - and I think we're making steady progress. From arithmetic, function invocation, namespacing, way up to standard libraries (consider in sequence those of: C, C++, Java, Python) and now web-based APIs. Like scientific progress, it's not one single theory, but a great many specific facts and theories. Each a mysterious journey and heroic victory in itself. BTW: There's that idea of using the analogue behaviour of transistors directly, instead of going through circuits, microcode, compilers and programs to simulate them... amazing performance, but hard to manage. build valuable systems with drastically less code I think libraries. e.g. we can make a valuable website very little code with sinatra (or PHP). That means we're there already :-). I know you're concerned with how to measure the length, and should it include libraries, but I think that if the abstraction suits your problem, it does not introduce unnecessary complexity into your code - and so I'm happy to consider it as part of the platform and ignore its actual cost. I'm not sure how to justify that, but it seems intuitively right to me (like not worrying how long code is in the implementation of arithmetic - I understand the IEEE fp spec is huge). Perhaps because that's the kind of library I'd write if I did the whole thing from scratch. I think this is the nub of our impasse: I'm fixated on clean abstractions, and you're concerned about measuring program length. I think clean abstractions don't contaminate your code with complexity from another level - so you can pretend to start fresh in a new world. Ray Kurzweil suggests this happens with technological innovation, and even in biology e.g. tweaking DNA, cells, multicellular body plans, behaviour etc rather than inventing alternatives from scratch. Similar to SOTSOG. A source of facts: ARM is a new stack compared to x86; and iOS is a new stack compared with desktop OS. Is there progress? They seem better (more efficient, smaller), but using the same fundamentals. Those Forth chips are totally different though. BTW: do you have a link for the ideas about complexity from Kay at VPRI? I looked at their website, but couldn't see anything directly on it - and didn't want to download a bunch of pdfs to search for it. :-)