3 ms·

It's kind of depressing, but I tend to agree. What works for absolute beginners does not and will not work for experts because it's inherently limiting. A lot o

It's kind of depressing, but I tend to agree. What works for absolute beginners does not and will not work for experts because it's inherently limiting. A lot of the "let's make programming more accesible for beginners" experiments have already been performed and they didn't cause more beginners to become experts (nor did they empower experts). IMO[0] we really need to move closer to mathematics and precision to actually achieve software that you can rely on. That means foundational work in PL semantics, type theory, PL pedagogy, etc. [0] And this is just my opinion because I have no actual rigorous research to back this up. At least I can admit that, contrary to most of the people who are agitating for approach A or B to software development. EDIT: s/studies/rigorous research/. "Study" can mean anything from "I though about it for 5 minutes" to "rigourous randomised trials", so I shouldn't use that term.

sillysaurus3 12y ago
we really need to move closer to mathematics and precision to actually achieve software that you can rely on. What's meant by reliability?
- lomnakkus 12y ago
  That's a good question. Speaking for myself... I'd settle for some comibined metric of "fewer security bugs" and "fewer unintentional behaviors" (per spec). You could argue about UX and such, but most of the real damage that's caused by defective software is basically about security bugs. The "fewer unintentional behaviors" bit is triciker, but math and precision (about what you want) can help with that. Usually a (mathematical) spec is shorter and more concise than the program implementing it.
  - sillysaurus3 12y ago
    HN couldn't have been designed via spec.
    - lomnakkus 12y ago
      Huh? I'm pretty sure it started out as an (informal) spec in somebody's head, which was then modified to account for the inflow of noobs like me :) At the very least the modding system required some abstract analysis to account for trolls and such.
      - seanmcdirmid 12y ago
        I think the distinction is between agile (we'll start with a vague spec, and flush it out as we go) and waterfall (we'll start with the perfect spec before we start coding). Obviously, there are many points in between. Nice concise mathematical specs are rare in practice, not because programmers are incapable of expressing such specs (and most probably aren't), but most programming problems are not expressible rigorously via math; they might not even be amenable to much analysis (so called "wicked" problems are common in programming).
        Dewie 12y ago
        I'll take a guess that something like pure functions lend themselves to formal, concise specs. Pure functions are, in the end, just input and output, not something complex like a program that outputs some complex bitmap every 30 milliseconds. Haskell has found pure functions to be very practical to have as 'distinguished citizens'; there are enough problems which can to a great degree be expressed with pure code. Someone might say "but Haskell itself doesn't solve practical programming problems", or whatever. The point isn't Haskell or pure functional programming per se; it's just an example of things that easily lend themselves to formal specs. Whether more complicated, perhaps effectful programs lend themselves to formal specs (I think ATS might be able to express such specifications) is more hard to answer.
        sillysaurus3 12y ago
        HN was written in a language where functional style is the norm, and yet HN couldn't have been designed via spec. I say this as someone who has thoroughly studied HN's codebase. If you spend time examining it, it becomes evident that most of the features were extemporaneous. There is little which was thought out in advance. The recipe for HN was: do the most important thing each day; repeat for 2000 days. Such a recipe is fundamentally anti-spec, because by day 5 your spec is outdated. Spec xor exploratory programming. The codebase is the spec.
  - vertex-four 12y ago
    The problem is that once you get to defining your specs as programs themselves, they can have bugs, and the closer those specs get to maths, the less the people who actually define the specs in the first place - usually neither programmers nor mathematicians - can understand them, reducing the likelihood that anyone will notice the deviations between the spec and what users actually want. Additionally, frankly, "reliable software" isn't something that's needed at least 99 times out of 100. Software that more-or-less gets some specific task done is. Those tasks can change from day to day, and generally require a few tries before the person who gave the task is even sure what they want, so RAD is more of a necessity than spec-based development. Basically, we now have this entire class of information workers, and very few tools to give them that are any better than an Excel spreadsheet for the most part. I don't see the article as trying to give traditional programmers new tools, it's trying to give information workers new tools, and probably traditional programmers will find some of those useful.
    - jamii 12y ago
      > I don't see the article as trying to give traditional programmers new tools, it's trying to give information workers new tools, and probably traditional programmers will find some of those useful. That puts it much more clearly than I managed. Thanks :)
  - Joeri 12y ago
    Eventually though, software has to solve a real problem for a human being, and real problems (and humans) tend to be messy. A spec should model the problem and its solution, and will inevitably be sort of messy as a consequence. I also doubt that any spec survives implementation. Solutions must be adapted as the understanding of a problem and its appropriate solutions grow, and it is almost impossible to gain that understanding without experimentation (partial implementation).
electronvolt 12y ago
Dijkstra (the one who has a graph algorithm named after him, aside from being a really influential computer scientist in many ways) argued more or less exactly what you're arguing: that formal methods (that is, formally proving, mathematically, that your code will behave as it should) are the appropriate way to teach computer science/programming. His argument is basically that computer science is very hard applied math, and should be treated as such. You might find https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/E... an interesting read, if you haven't read it before. There's been some interesting discussion of it on HN in the past, too.
- jamii 12y ago
  Dijkstra also complained about lazy students who wasted valuable computing time on assemblers instead of just writing out the machine code by hand. I am strongly in favour of mathematical methods but that doesn't preclude exploratory work or visualisation. The idea that mathematicians spend all their time constructing rigorous theories and proofs is a complete illusion. It is common practice (outside of the Bourbaki school, at least) to alternate between building intuition through examples and solidifying intuition through rigorous proofs. See eg http://terrytao.wordpress.com/career-advice/there%E2%80%99s-more-to-mathematics-than-rigour-and-proofs/ http://terrytao.wordpress.com/career-advice/there%E2%80%99s-... (by Terence Tao, one of the most talented mathematicians alive). By comparison, we are extraordinarily lucky in programming in that everything we deal with is computable and representable. It is far easier for us to display examples and visualise systems. So while I agree that more understanding of mathematics and proof would aid in programming complex systems and I have certainly found that my degree in maths was a good preparation for programming, I don't see why we shouldn't also take advantage of the power of computers to help build the intuition that is necessary for rigour.

sillysaurus3 12y ago

we really need to move closer to mathematics and precision to actually achieve software that you can rely on. What's meant by reliability?

lomnakkus 12y ago
That's a good question. Speaking for myself... I'd settle for some comibined metric of "fewer security bugs" and "fewer unintentional behaviors" (per spec). You could argue about UX and such, but most of the real damage that's caused by defective software is basically about security bugs. The "fewer unintentional behaviors" bit is triciker, but math and precision (about what you want) can help with that. Usually a (mathematical) spec is shorter and more concise than the program implementing it.
- sillysaurus3 12y ago
  HN couldn't have been designed via spec.
  - lomnakkus 12y ago
    Huh? I'm pretty sure it started out as an (informal) spec in somebody's head, which was then modified to account for the inflow of noobs like me :) At the very least the modding system required some abstract analysis to account for trolls and such.
    - seanmcdirmid 12y ago
      I think the distinction is between agile (we'll start with a vague spec, and flush it out as we go) and waterfall (we'll start with the perfect spec before we start coding). Obviously, there are many points in between. Nice concise mathematical specs are rare in practice, not because programmers are incapable of expressing such specs (and most probably aren't), but most programming problems are not expressible rigorously via math; they might not even be amenable to much analysis (so called "wicked" problems are common in programming).
      - Dewie 12y ago
        I'll take a guess that something like pure functions lend themselves to formal, concise specs. Pure functions are, in the end, just input and output, not something complex like a program that outputs some complex bitmap every 30 milliseconds. Haskell has found pure functions to be very practical to have as 'distinguished citizens'; there are enough problems which can to a great degree be expressed with pure code. Someone might say "but Haskell itself doesn't solve practical programming problems", or whatever. The point isn't Haskell or pure functional programming per se; it's just an example of things that easily lend themselves to formal specs. Whether more complicated, perhaps effectful programs lend themselves to formal specs (I think ATS might be able to express such specifications) is more hard to answer.
        sillysaurus3 12y ago
        HN was written in a language where functional style is the norm, and yet HN couldn't have been designed via spec. I say this as someone who has thoroughly studied HN's codebase. If you spend time examining it, it becomes evident that most of the features were extemporaneous. There is little which was thought out in advance. The recipe for HN was: do the most important thing each day; repeat for 2000 days. Such a recipe is fundamentally anti-spec, because by day 5 your spec is outdated. Spec xor exploratory programming. The codebase is the spec.
- vertex-four 12y ago
  The problem is that once you get to defining your specs as programs themselves, they can have bugs, and the closer those specs get to maths, the less the people who actually define the specs in the first place - usually neither programmers nor mathematicians - can understand them, reducing the likelihood that anyone will notice the deviations between the spec and what users actually want. Additionally, frankly, "reliable software" isn't something that's needed at least 99 times out of 100. Software that more-or-less gets some specific task done is. Those tasks can change from day to day, and generally require a few tries before the person who gave the task is even sure what they want, so RAD is more of a necessity than spec-based development. Basically, we now have this entire class of information workers, and very few tools to give them that are any better than an Excel spreadsheet for the most part. I don't see the article as trying to give traditional programmers new tools, it's trying to give information workers new tools, and probably traditional programmers will find some of those useful.
  - jamii 12y ago
    > I don't see the article as trying to give traditional programmers new tools, it's trying to give information workers new tools, and probably traditional programmers will find some of those useful. That puts it much more clearly than I managed. Thanks :)
- Joeri 12y ago
  Eventually though, software has to solve a real problem for a human being, and real problems (and humans) tend to be messy. A spec should model the problem and its solution, and will inevitably be sort of messy as a consequence. I also doubt that any spec survives implementation. Solutions must be adapted as the understanding of a problem and its appropriate solutions grow, and it is almost impossible to gain that understanding without experimentation (partial implementation).

electronvolt 12y ago

Dijkstra (the one who has a graph algorithm named after him, aside from being a really influential computer scientist in many ways) argued more or less exactly what you're arguing: that formal methods (that is, formally proving, mathematically, that your code will behave as it should) are the appropriate way to teach computer science/programming. His argument is basically that computer science is very hard applied math, and should be treated as such. You might find https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/E... an interesting read, if you haven't read it before. There's been some interesting discussion of it on HN in the past, too.

jamii 12y ago
Dijkstra also complained about lazy students who wasted valuable computing time on assemblers instead of just writing out the machine code by hand. I am strongly in favour of mathematical methods but that doesn't preclude exploratory work or visualisation. The idea that mathematicians spend all their time constructing rigorous theories and proofs is a complete illusion. It is common practice (outside of the Bourbaki school, at least) to alternate between building intuition through examples and solidifying intuition through rigorous proofs. See eg http://terrytao.wordpress.com/career-advice/there%E2%80%99s-more-to-mathematics-than-rigour-and-proofs/ http://terrytao.wordpress.com/career-advice/there%E2%80%99s-... (by Terence Tao, one of the most talented mathematicians alive). By comparison, we are extraordinarily lucky in programming in that everything we deal with is computable and representable. It is far easier for us to display examples and visualise systems. So while I agree that more understanding of mathematics and proof would aid in programming complex systems and I have certainly found that my degree in maths was a good preparation for programming, I don't see why we shouldn't also take advantage of the power of computers to help build the intuition that is necessary for rigour.