3 ms·

Nothing you've said really invalidates his argument - we are still typing mostly imperative code into text files, it is still very easy to introduce bugs into s

Nothing you've said really invalidates his argument - we are still typing mostly imperative code into text files, it is still very easy to introduce bugs into software, and software development is on the whole unnecessarily complex and unintuitive. It's heartening to see a renewed interest in functional, declarative and logic based programming today, but also saddening that the poisonous legacy of C has prevented us from getting there sooner.

zxcdw 13y ago
> It's heartening to see a renewed interest in functional, declarative and logic based programming today, but also saddening that the poisonous legacy of C has prevented us from getting there sooner. From the point of view of programming a computer, this doesn't make much sense to me personally. But perhaps the problem is that I first and foremost see that I program a computer, a deterministic machine with limited resources and functionality, rather than "designing an user experience and letting computer take care of making it run as I describe". Guess I dwell in the depths of hardware/machine centric programming rather than fly high in user centric programming.
- derefr 13y ago
  Unless you're writing IA64 microcode, you don't really program a computer. You explain your desires to a compiler using a vocabulary as expressive as is possible for it to comprehend, and then it uses whatever intelligence is at its disposal to program the computer.† The more intelligent the compiler (e.g. GHC with its stream-fusion), and the more expressive the vocabulary it knows (e.g. Erlang/OTP with its built-in understanding of servers, finite-state machines, and event-handlers) the higher-level the conversation you can have with it is. Your conversation with the compiler is actually the same conversation a client would have with you, as a software contractor. From the client's perspective, you play the role of the compiler, interrogating and formalizing their own murky desires for them, and then coughing up a build-artifact for them to evaluate. This conversation just occurs on an even higher level, because a human compiler is smarter, and has a much more expressive vocabulary, than a software compiler. ...but the "goal" of compiler and language design should be to make that distinction, between the "software compiler" and the "human compiler", less obvious, shouldn't it? The more intelligence we add to the compiler, and the more expressivity we add to the language, the more directly the programmer can translate the client's desires into code. Until, finally, one day--maybe only after we've got strong AI, but one day--the client themselves will be the one speaking to the compiler. Not because the client will be any better at knowing how to formalize what they want than they ever were (that's the dream that gave us the abominations of FORTRAN, SQL, and AppleScript) but because the compiler will be able to infer and clarify their murky thoughts into a real, useful design--just as we do now. Wouldn't that be nice? --- † If you use a language-platform that includes garbage-collection, for example, then you're not targeting a machine with "limited resources" at all; garbage-collection is intended to simulate an Abstract Machine with unlimited memory. (http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047586.aspx http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047...)
  - zxcdw 13y ago
    Sometimes the awesomeness of "the future" outright depresses me. :(
artagnon 13y ago
Don't talk rubbish. Nobody enjoys spending 10 hours to accomplish something that can be accomplished in an hour. Ofcourse we're trying to build compilers for nicer languages. Programming isn't going to become any less complex or unintuitive by sitting around wishing for better solutions: it's going to happen by studying existing technology, and using it to build better solutions. What has "prevented" us from getting there sooner is purely our incompetence. It's becoming painfully clear to me that people have absolutely no idea about how a compiler works.

zxcdw 13y ago

> It's heartening to see a renewed interest in functional, declarative and logic based programming today, but also saddening that the poisonous legacy of C has prevented us from getting there sooner. From the point of view of programming a computer, this doesn't make much sense to me personally. But perhaps the problem is that I first and foremost see that I program a computer, a deterministic machine with limited resources and functionality, rather than "designing an user experience and letting computer take care of making it run as I describe". Guess I dwell in the depths of hardware/machine centric programming rather than fly high in user centric programming.

derefr 13y ago
Unless you're writing IA64 microcode, you don't really program a computer. You explain your desires to a compiler using a vocabulary as expressive as is possible for it to comprehend, and then it uses whatever intelligence is at its disposal to program the computer.† The more intelligent the compiler (e.g. GHC with its stream-fusion), and the more expressive the vocabulary it knows (e.g. Erlang/OTP with its built-in understanding of servers, finite-state machines, and event-handlers) the higher-level the conversation you can have with it is. Your conversation with the compiler is actually the same conversation a client would have with you, as a software contractor. From the client's perspective, you play the role of the compiler, interrogating and formalizing their own murky desires for them, and then coughing up a build-artifact for them to evaluate. This conversation just occurs on an even higher level, because a human compiler is smarter, and has a much more expressive vocabulary, than a software compiler. ...but the "goal" of compiler and language design should be to make that distinction, between the "software compiler" and the "human compiler", less obvious, shouldn't it? The more intelligence we add to the compiler, and the more expressivity we add to the language, the more directly the programmer can translate the client's desires into code. Until, finally, one day--maybe only after we've got strong AI, but one day--the client themselves will be the one speaking to the compiler. Not because the client will be any better at knowing how to formalize what they want than they ever were (that's the dream that gave us the abominations of FORTRAN, SQL, and AppleScript) but because the compiler will be able to infer and clarify their murky thoughts into a real, useful design--just as we do now. Wouldn't that be nice? --- † If you use a language-platform that includes garbage-collection, for example, then you're not targeting a machine with "limited resources" at all; garbage-collection is intended to simulate an Abstract Machine with unlimited memory. (http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047586.aspx http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047...)
- zxcdw 13y ago
  Sometimes the awesomeness of "the future" outright depresses me. :(

artagnon 13y ago

Don't talk rubbish. Nobody enjoys spending 10 hours to accomplish something that can be accomplished in an hour. Ofcourse we're trying to build compilers for nicer languages. Programming isn't going to become any less complex or unintuitive by sitting around wishing for better solutions: it's going to happen by studying existing technology, and using it to build better solutions. What has "prevented" us from getting there sooner is purely our incompetence. It's becoming painfully clear to me that people have absolutely no idea about how a compiler works.