7 ms·

Can Programming Be Liberated, Period? (2008) [pdf]

43 points by sktrdie 9y ago

LoSboccacc 9y ago
no. the hard part was never programming anyway but mapping the real world ever mutating quirks into regular structures
- catnaroek 9y ago
  Maybe in your corner of the world. In mine, programming in and of itself, i.e. devising mechanically executable (a.k.a. algorithmic) solutions to well-specified problems, is by far the hardest task.
  - blunte 9y ago
    Well, polish your resume. Sounds like your job actually could be replaced by a computer.
    - catnaroek 9y ago
      Thanks for your concern. Of course I'm constantly learning new skills to avoid being left behind. However, present-day artificial intelligence is still very far from being able to replace my job.
  - LoSboccacc 9y ago
    if it's well specified but hard to convert into an executable it's time you invest in selling a transpiler into your specific domain - however, if the problem is creating the algorithm and not whatever language you're using then we're telling the same thing
    - catnaroek 9y ago
      It's a completely different well-specified problem each time.
kabdib 9y ago
One common interview question I've run across is to write the code for a simple four-function calculator, the kind that you can find for a dollar or two in nearly any convenience store, right next to the pencils and erasers. Hey, it's all just buttons and a display doing simple things, right? Only it turns out to be a fairly complicated task, with a lot of corner conditions, even when you treat the math library as a given and leave out all the really low-level stuff (button handling, display refresh, etc.). You're not going to get to a usable calculator by having a casual conversation with a user interface builder. "Computer, make that button green, um, no ... yellow" is comparatively easy. "Computer, now make that button add the two numbers together" is begging so much of the specification that it's not really programming any more. And if you do go deeper and try to teach the computer about pending operations, number entry and a stack (to handle parenthesis), you're programming again, only with a lousy IDE.
- userbinator 9y ago
  One common interview question I've run across is to write the code for a simple four-function calculator, the kind that you can find for a dollar or two in nearly any convenience store, right next to the pencils and erasers. Coincidentally, I've previously posted here a detailed model/explanation of how those work: https://news.ycombinator.com/item?id=9456444 https://news.ycombinator.com/item?id=9456444 They're usually based on a 4-bit mask-ROM microcontroller running at several kHz. Very "simple" in relative terms to most computers today, and in hindsight I could probably write the code for one quite quickly, but I bet the 99% of programmers who haven't ever really given a thought to how they work in detail would struggle to come up with an accurate description in an interview. Also worth reading: https://news.ycombinator.com/item?id=6302364 https://news.ycombinator.com/item?id=6302364
  - psyc 9y ago
    I’m about to do a 4-bit 4 op calculator with only logic gates, for a project. Not that I could do it in an interview!
  - lgas 9y ago
    Out of curiosity, in the description you linked you say it's a two-register model but then you mention R, O and I but only refer to O as a register. You refer to both R and I as accumulators. I assume at least one of them is also a register, but that would suggest it's a three-register model, no?
tzahola 9y ago
Oh boy. This reminds me of the utterly failed attempts of the last 30 years to eliminate programmers. You know, when companies were telling us that creating business software will be as simple as connecting a few boxes on a flowchart, and their intelligent snake oil-driven framework will automatically translate that into working software. Even managers will be able to do that, right?! Funny how we ended up needing more programmers than ever.
- pacala 9y ago
  Sadly, it was a bubble. While media pushes stories about self driving trucks and cars, big compute is sucking the air out of the it job market at an accelerated pace.
- catnaroek 9y ago
  In all fairness, business would be wise to dispense with much of the pointlessly low-level technology it uses. You want to automate a business process? Then formalize the business process itself, not the tool that you think could help you automate it. And do it in a programming language, of course.
  - Terr_ 9y ago
    Reminds me a little of: http://thecodelesscode.com/case/231 http://thecodelesscode.com/case/231
  - blunte 9y ago
    Formalizing the process is a noble goal, but there will always be clients that want your formalized process with "just a few tweaks". I think we should endeavor to formalize as much as is reasonably possible, pushing the bulk of the developer work to dealing with the special cases. But even that will eventually result in a small formal core surrounded by layers and chunks of customizations.
    - catnaroek 9y ago
      > Formalizing the process is a noble goal, but there will always be clients that want your formalized process with "just a few tweaks". The client owns the process - it's their business after all - so they can define it however they wish. I'm not arguing for canned software. I'm arguing for a programming language in which business processes can be defined directly. (I'm aware of the existence of BPMN, ARIS, and other business process modeling tools, but those fall short of being actual programming languages.)
markbnj 9y ago
It's always interesting and amusing to read these sorts of articles. This has been a recurring dream and topic of conversation since well before I wrote my first program in 1975. It's easy to understand why. We've built these super fast number crunchers and added thick layers of abstraction that let us do useful things like encoding videos and tweeting. These things seem magically elevated above and beyond the simple operations from which they are assembled, and it's tempting to think we can continue piling up abstractions until we get to "intelligence." I suspect, though, that the fundamental metaphors of human intelligence, whatever they are, far transcend "processing" the way our number crunching machines work now. That's why analogies to the way we interact with others ("Why can't I just tell the machine what I want?") fall woefully short of providing any insight into how we might program computers in the future. As long as the computers we are programming are processors of the same sort we program now, they will remain far, far too simple to ever understand what we want and act on our desires. To the extent they get part of the way to that ideal it can only be by relying on deeper and deeper layers of software, which at some point has to be written in the old-fashioned way. If that remains true then it would probably be dangerous to allow ourselves to get too far removed from the way things really work. We already know how painful it can be to end up relying on stuff nobody understands any more to provide critical functions.
- blunte 9y ago
  That's my favorite: "Why can't I just tell the machine what I want?" (Often preceded by "What I want is simple.") When people tell me something like that, I start asking questions about what they want. It only takes one or two questions to evoke a reply from them of, "Oh, I don't know... maybe it should do this, or maybe it should do that; it kind of depends..." And therein lies the real problem. When the end user cannot even clearly define (or even decide!) what they want when a certain situation comes up, how could a computer possibly know? Put the user next to a good developer, and I promise the bottleneck will be the user.
  - deleted 9y ago
    [deleted]
  - catnaroek 9y ago
alexandercrohde 9y ago
I don't understand why this is a goal... Yes if machines could self-teach the way humans do, they'd be really powerful. However, in many ways programs are better than people, and we try to get people systems be MORE like software. Often times you want a system with hard, uncompromising rules, following a strict process without exceptions (e.g. an ATM). Bank tellers try to be non-human and ATM-like. The real dichotomy is between predefined systems and adaptive systems, and there are times we want each. Also, despite the author's fantasy, I don't see any reason to believe life as a whole would be better if computers did both.
z3t4 9y ago
A lot of apps are just read write update to a database, and binding the data to views. I think "programming" such apps could be simplified, eg SQL++ where you make queries by talking to the computer ...
- blunte 9y ago
  Not a chance. You just described the surface area. The complexity is in the business rules and logic behind those IO interfaces. We could develop tools that would build those interfaces from words you speak, but until you can speak deterministic logic and rules to the computer to define the behaviors you need, you still need programmers. In fact, I would argue that the programmer/developer is less a person who types code and more a person who helps a user decide the rules of the systems they have requested.
matthew349hall 9y ago
This can easily be related to how lots of educators think that every kid should learn how to code, e.g. "It's the new literacy." Well, considering how illiterate most kids are at school it'd help to focus there as well.
heartles 9y ago
I'm not sure if we hugged it to death, or if the website's down for maintenance, but looks like the site is unavailable. Thankfully there's archive.org snapshots: https://web.archive.org/web/20171226133115/http://www.wisdom.weizmann.ac.il/~dharel/papers/LiberatingProgramming.pdf https://web.archive.org/web/20171226133115/http://www.wisdom...

43 points by sktrdie 9y ago

LoSboccacc 9y ago

no. the hard part was never programming anyway but mapping the real world ever mutating quirks into regular structures

catnaroek 9y ago
Maybe in your corner of the world. In mine, programming in and of itself, i.e. devising mechanically executable (a.k.a. algorithmic) solutions to well-specified problems, is by far the hardest task.
- blunte 9y ago
  Well, polish your resume. Sounds like your job actually could be replaced by a computer.
  - catnaroek 9y ago
    Thanks for your concern. Of course I'm constantly learning new skills to avoid being left behind. However, present-day artificial intelligence is still very far from being able to replace my job.
- LoSboccacc 9y ago
  if it's well specified but hard to convert into an executable it's time you invest in selling a transpiler into your specific domain - however, if the problem is creating the algorithm and not whatever language you're using then we're telling the same thing
  - catnaroek 9y ago
    It's a completely different well-specified problem each time.

kabdib 9y ago

One common interview question I've run across is to write the code for a simple four-function calculator, the kind that you can find for a dollar or two in nearly any convenience store, right next to the pencils and erasers. Hey, it's all just buttons and a display doing simple things, right? Only it turns out to be a fairly complicated task, with a lot of corner conditions, even when you treat the math library as a given and leave out all the really low-level stuff (button handling, display refresh, etc.). You're not going to get to a usable calculator by having a casual conversation with a user interface builder. "Computer, make that button green, um, no ... yellow" is comparatively easy. "Computer, now make that button add the two numbers together" is begging so much of the specification that it's not really programming any more. And if you do go deeper and try to teach the computer about pending operations, number entry and a stack (to handle parenthesis), you're programming again, only with a lousy IDE.

userbinator 9y ago
One common interview question I've run across is to write the code for a simple four-function calculator, the kind that you can find for a dollar or two in nearly any convenience store, right next to the pencils and erasers. Coincidentally, I've previously posted here a detailed model/explanation of how those work: https://news.ycombinator.com/item?id=9456444 https://news.ycombinator.com/item?id=9456444 They're usually based on a 4-bit mask-ROM microcontroller running at several kHz. Very "simple" in relative terms to most computers today, and in hindsight I could probably write the code for one quite quickly, but I bet the 99% of programmers who haven't ever really given a thought to how they work in detail would struggle to come up with an accurate description in an interview. Also worth reading: https://news.ycombinator.com/item?id=6302364 https://news.ycombinator.com/item?id=6302364
- psyc 9y ago
  I’m about to do a 4-bit 4 op calculator with only logic gates, for a project. Not that I could do it in an interview!
- lgas 9y ago
  Out of curiosity, in the description you linked you say it's a two-register model but then you mention R, O and I but only refer to O as a register. You refer to both R and I as accumulators. I assume at least one of them is also a register, but that would suggest it's a three-register model, no?

tzahola 9y ago

Oh boy. This reminds me of the utterly failed attempts of the last 30 years to eliminate programmers. You know, when companies were telling us that creating business software will be as simple as connecting a few boxes on a flowchart, and their intelligent snake oil-driven framework will automatically translate that into working software. Even managers will be able to do that, right?! Funny how we ended up needing more programmers than ever.

pacala 9y ago
Sadly, it was a bubble. While media pushes stories about self driving trucks and cars, big compute is sucking the air out of the it job market at an accelerated pace.
catnaroek 9y ago
In all fairness, business would be wise to dispense with much of the pointlessly low-level technology it uses. You want to automate a business process? Then formalize the business process itself, not the tool that you think could help you automate it. And do it in a programming language, of course.
- Terr_ 9y ago
  Reminds me a little of: http://thecodelesscode.com/case/231 http://thecodelesscode.com/case/231
- blunte 9y ago
  Formalizing the process is a noble goal, but there will always be clients that want your formalized process with "just a few tweaks". I think we should endeavor to formalize as much as is reasonably possible, pushing the bulk of the developer work to dealing with the special cases. But even that will eventually result in a small formal core surrounded by layers and chunks of customizations.
  - catnaroek 9y ago
    > Formalizing the process is a noble goal, but there will always be clients that want your formalized process with "just a few tweaks". The client owns the process - it's their business after all - so they can define it however they wish. I'm not arguing for canned software. I'm arguing for a programming language in which business processes can be defined directly. (I'm aware of the existence of BPMN, ARIS, and other business process modeling tools, but those fall short of being actual programming languages.)

markbnj 9y ago

It's always interesting and amusing to read these sorts of articles. This has been a recurring dream and topic of conversation since well before I wrote my first program in 1975. It's easy to understand why. We've built these super fast number crunchers and added thick layers of abstraction that let us do useful things like encoding videos and tweeting. These things seem magically elevated above and beyond the simple operations from which they are assembled, and it's tempting to think we can continue piling up abstractions until we get to "intelligence." I suspect, though, that the fundamental metaphors of human intelligence, whatever they are, far transcend "processing" the way our number crunching machines work now. That's why analogies to the way we interact with others ("Why can't I just tell the machine what I want?") fall woefully short of providing any insight into how we might program computers in the future. As long as the computers we are programming are processors of the same sort we program now, they will remain far, far too simple to ever understand what we want and act on our desires. To the extent they get part of the way to that ideal it can only be by relying on deeper and deeper layers of software, which at some point has to be written in the old-fashioned way. If that remains true then it would probably be dangerous to allow ourselves to get too far removed from the way things really work. We already know how painful it can be to end up relying on stuff nobody understands any more to provide critical functions.

blunte 9y ago
That's my favorite: "Why can't I just tell the machine what I want?" (Often preceded by "What I want is simple.") When people tell me something like that, I start asking questions about what they want. It only takes one or two questions to evoke a reply from them of, "Oh, I don't know... maybe it should do this, or maybe it should do that; it kind of depends..." And therein lies the real problem. When the end user cannot even clearly define (or even decide!) what they want when a certain situation comes up, how could a computer possibly know? Put the user next to a good developer, and I promise the bottleneck will be the user.
- deleted 9y ago
  [deleted]
- catnaroek 9y ago

alexandercrohde 9y ago

I don't understand why this is a goal... Yes if machines could self-teach the way humans do, they'd be really powerful. However, in many ways programs are better than people, and we try to get people systems be MORE like software. Often times you want a system with hard, uncompromising rules, following a strict process without exceptions (e.g. an ATM). Bank tellers try to be non-human and ATM-like. The real dichotomy is between predefined systems and adaptive systems, and there are times we want each. Also, despite the author's fantasy, I don't see any reason to believe life as a whole would be better if computers did both.

z3t4 9y ago

A lot of apps are just read write update to a database, and binding the data to views. I think "programming" such apps could be simplified, eg SQL++ where you make queries by talking to the computer ...

blunte 9y ago
Not a chance. You just described the surface area. The complexity is in the business rules and logic behind those IO interfaces. We could develop tools that would build those interfaces from words you speak, but until you can speak deterministic logic and rules to the computer to define the behaviors you need, you still need programmers. In fact, I would argue that the programmer/developer is less a person who types code and more a person who helps a user decide the rules of the systems they have requested.

matthew349hall 9y ago

This can easily be related to how lots of educators think that every kid should learn how to code, e.g. "It's the new literacy." Well, considering how illiterate most kids are at school it'd help to focus there as well.

heartles 9y ago

I'm not sure if we hugged it to death, or if the website's down for maintenance, but looks like the site is unavailable. Thankfully there's archive.org snapshots: https://web.archive.org/web/20171226133115/http://www.wisdom.weizmann.ac.il/~dharel/papers/LiberatingProgramming.pdf https://web.archive.org/web/20171226133115/http://www.wisdom...