4 ms·

The bigger question is, why are we still programming the way we did 20yrs ago? Higher level languages were a great improvement over machine language. But what c

by WWKong 11y ago

The bigger question is, why are we still programming the way we did 20yrs ago? Higher level languages were a great improvement over machine language. But what comes next? Why don't we have it yet? A decade ago I was setting up database, writing queries, designing forms, writing the code to wire it all up. I still have to do all these steps with more amount of effort today.

merlinsbrain 11y ago
I think Backend-as-a-Service providers are a good step towards a place we want to be, although I still think we're not super close to using such services to deploy complex business logic on. Services like parse cloud code and AWS lambda are another step closer. Context: We (me + couple of collaborators) are writing a similar platform for ourselves, although the purpose is dogfood more than $.
- xyzzy4 11y ago
  Parse is shutting down though.
  - merlinsbrain 11y ago
    While I view them as pioneers in the space, the fact that executed their cloud code functionality, and did it well is enough for the rest of us to take it from here :) Perhaps it's even a part of the (now) open source parse-server? I am not sure, but as I am building a similar thing I will definitely be having a closer look at their source code in the coming weeks.
- davidjnelson 11y ago
  Aws lambda does look like a particularly large innovation regarding complexity management. Anyone have stories on using it to share?
  - room271 11y ago
    Nothing amazingly innovative, but I've used it a lot at work. For simple jobs/event processing it is amazing as it removes a load of complexity (logging, monitoring, scaling, deploying). Lambdas tend to be < 100 lines of Javascript which means maintenance and rewriting is trivial. And because the jobs are so simple people don't need to be Javascript experts or aware of the JS ecosystem to write them. Lambda is also very cheap if you have bursty or just very low-volume workloads.
douche 11y ago
But, but, but... The cloud! Social! Containers! Synergy! ScrummBanFall! Seventeen JS dependency managers, and a new one every week! We have all that stuff now! /s
sklogic 11y ago
We have not seen any theoretical breakthroughs in over 20 years anyway. Unlikely programming is going to change fundamentally. But there is a lot of game changing practical advances which totally overturned the way we design systems. Microcontrollers are powerful and dirt cheap now. Low end FPGAs are more accessible than ever. GPGPU is a dramatic game changer, and it is dead easy to use it these days. RAM is nearly infinite. SSDs are cheap and fast. 1gbps networks are everywhere. CPUs have dozens of cores. So, yes, on a practical side everything changed.
- mbrock 11y ago
  Yeah, practical and cultural shifts determine how the theoretical foundations come into play. Ten years ago, if you said you were into functional programming, most people wondered if you were crazy and why you didn't just program in a real, normal language. Fifteen years ago, garbage collection was considered slow and mostly only suitable for "scripting." Twenty-five years ago, there was Haskell, Erlang, Common Lisp, Smalltalk, and so much cool technology and visionary ideas. For most of the time since, it's all been considered weird, fringe, academic stuff. The past decades of industrial talk about best practices and methodology doesn't seem to have been wildly successful, and now we're looking at other ideas in a diverse way. So it's an interesting time.
  - Roboprog 11y ago
    Slight nitpick: I would have said "20 years ago" about garbage collection. As soon as Java came out, full GC (vs ref count) somehow became OK. Disclaimer: Java programmers get jobs, so I am one. My feeling about it is "The elegance of C++ at the speed of a Lisp". Fortunately, we are starting to get better language front ends which can reuse the old JVM binaries, as well as having a GC-ing VM that has had decades and $millions thrown at it.
  - Roboprog 11y ago
    I hear you on the FP part, though. Forget "higher order functions" and such, just the idea of "pure function" was hard to get across to some coworkers 10 years ago. "Why would you want to trace the dataflow through the routines, as a pipeline, rather than just whacking on the DATA DIVISION, er, beans / instance variables, as needed???"
rpgmaker 11y ago
I think you are asking for the utility-zation of programming (which is coming) and since that development will make a lot of developers obsolete, I for one don't want that to happen before I'm "retired".
gozur88 11y ago
Why does something come next? Maybe we're already doing it right.
- soared 11y ago
  Step 1 in grinding innovation to a halt: Assume you're right and can't be improved.
  - gozur88 11y ago
    Not at all. I just think it's unreasonable to assume just because some arbitrary time period has passed we ought to be doing something different.
erichocean 11y ago
> The bigger question is, why are we still programming the way we did 20yrs ago? It's been a problem longer than that, and the culprit (ironically) is Fred Brooks. Yes, the guy we hand the "I didn't get a Turing award, all I got was this lousy Fred Brooks award" T-shirt to people. If you don't know, Fred Brooks was the manager of the first large scale programming project at IBM that actually tried to use a programming language, as opposed to machine code/assembler and the toolset and paradigms people used with that approach. Anyway, long story short, the project was deemed a "failure", and this Fred Brooks guy, presumably in a bit of ego-damage control and to save his professional reputation, did something interesting: he claimed that anyone would have failed, not just him, and that there is no possible solution to the problem that fundamentally fixes it. (Literally: "there is no silver bullet.") Well, Brook's knee-jerk proclamation about killed all research into the "programming is hard" problem at the academic level. People now strive for x% improvement but firmly believe--after literally one bad experience--that fundamental improvement is impossible. But maybe, just maybe, we're "doing it wrong" as it were and we were wrong to give up after literally one bad experience by a pointy-headed boss in CYA mode on a major project. I firmly believe that we're doing programming wrong, that Fred Brooks was (and is) wrong, and that 50 years from now, we'll look back at a million monkeys (referring to myself) typing out text to the computer and laugh at how primitive we all are today.

by WWKong 11y ago

merlinsbrain 11y ago

I think Backend-as-a-Service providers are a good step towards a place we want to be, although I still think we're not super close to using such services to deploy complex business logic on. Services like parse cloud code and AWS lambda are another step closer. Context: We (me + couple of collaborators) are writing a similar platform for ourselves, although the purpose is dogfood more than $.

xyzzy4 11y ago
Parse is shutting down though.
- merlinsbrain 11y ago
  While I view them as pioneers in the space, the fact that executed their cloud code functionality, and did it well is enough for the rest of us to take it from here :) Perhaps it's even a part of the (now) open source parse-server? I am not sure, but as I am building a similar thing I will definitely be having a closer look at their source code in the coming weeks.
davidjnelson 11y ago
Aws lambda does look like a particularly large innovation regarding complexity management. Anyone have stories on using it to share?
- room271 11y ago
  Nothing amazingly innovative, but I've used it a lot at work. For simple jobs/event processing it is amazing as it removes a load of complexity (logging, monitoring, scaling, deploying). Lambdas tend to be < 100 lines of Javascript which means maintenance and rewriting is trivial. And because the jobs are so simple people don't need to be Javascript experts or aware of the JS ecosystem to write them. Lambda is also very cheap if you have bursty or just very low-volume workloads.

douche 11y ago

But, but, but... The cloud! Social! Containers! Synergy! ScrummBanFall! Seventeen JS dependency managers, and a new one every week! We have all that stuff now! /s

sklogic 11y ago

We have not seen any theoretical breakthroughs in over 20 years anyway. Unlikely programming is going to change fundamentally. But there is a lot of game changing practical advances which totally overturned the way we design systems. Microcontrollers are powerful and dirt cheap now. Low end FPGAs are more accessible than ever. GPGPU is a dramatic game changer, and it is dead easy to use it these days. RAM is nearly infinite. SSDs are cheap and fast. 1gbps networks are everywhere. CPUs have dozens of cores. So, yes, on a practical side everything changed.

mbrock 11y ago
Yeah, practical and cultural shifts determine how the theoretical foundations come into play. Ten years ago, if you said you were into functional programming, most people wondered if you were crazy and why you didn't just program in a real, normal language. Fifteen years ago, garbage collection was considered slow and mostly only suitable for "scripting." Twenty-five years ago, there was Haskell, Erlang, Common Lisp, Smalltalk, and so much cool technology and visionary ideas. For most of the time since, it's all been considered weird, fringe, academic stuff. The past decades of industrial talk about best practices and methodology doesn't seem to have been wildly successful, and now we're looking at other ideas in a diverse way. So it's an interesting time.
- Roboprog 11y ago
  Slight nitpick: I would have said "20 years ago" about garbage collection. As soon as Java came out, full GC (vs ref count) somehow became OK. Disclaimer: Java programmers get jobs, so I am one. My feeling about it is "The elegance of C++ at the speed of a Lisp". Fortunately, we are starting to get better language front ends which can reuse the old JVM binaries, as well as having a GC-ing VM that has had decades and $millions thrown at it.
- Roboprog 11y ago
  I hear you on the FP part, though. Forget "higher order functions" and such, just the idea of "pure function" was hard to get across to some coworkers 10 years ago. "Why would you want to trace the dataflow through the routines, as a pipeline, rather than just whacking on the DATA DIVISION, er, beans / instance variables, as needed???"

rpgmaker 11y ago

I think you are asking for the utility-zation of programming (which is coming) and since that development will make a lot of developers obsolete, I for one don't want that to happen before I'm "retired".

gozur88 11y ago

Why does something come next? Maybe we're already doing it right.

soared 11y ago
Step 1 in grinding innovation to a halt: Assume you're right and can't be improved.
- gozur88 11y ago
  Not at all. I just think it's unreasonable to assume just because some arbitrary time period has passed we ought to be doing something different.

erichocean 11y ago

> The bigger question is, why are we still programming the way we did 20yrs ago? It's been a problem longer than that, and the culprit (ironically) is Fred Brooks. Yes, the guy we hand the "I didn't get a Turing award, all I got was this lousy Fred Brooks award" T-shirt to people. If you don't know, Fred Brooks was the manager of the first large scale programming project at IBM that actually tried to use a programming language, as opposed to machine code/assembler and the toolset and paradigms people used with that approach. Anyway, long story short, the project was deemed a "failure", and this Fred Brooks guy, presumably in a bit of ego-damage control and to save his professional reputation, did something interesting: he claimed that anyone would have failed, not just him, and that there is no possible solution to the problem that fundamentally fixes it. (Literally: "there is no silver bullet.") Well, Brook's knee-jerk proclamation about killed all research into the "programming is hard" problem at the academic level. People now strive for x% improvement but firmly believe--after literally one bad experience--that fundamental improvement is impossible. But maybe, just maybe, we're "doing it wrong" as it were and we were wrong to give up after literally one bad experience by a pointy-headed boss in CYA mode on a major project. I firmly believe that we're doing programming wrong, that Fred Brooks was (and is) wrong, and that 50 years from now, we'll look back at a million monkeys (referring to myself) typing out text to the computer and laugh at how primitive we all are today.