6 ms·

This is not a nice job. The first "issue" is that ``DoSomething accesses x directly rather than through the parameter'', but then goes on to talk about types.

by geocar 12y ago

This is not a nice job. The first "issue" is that ``DoSomething accesses x directly rather than through the parameter'', but then goes on to talk about types. I think this is a big part of why we are bad at programming: A because 6 therefore Go Fish. I have noticed that when a program is small enough that I can see all of it, then I can reason about all of it, and when I cannot see all of the code, then I cannot. I may resort to note-taking or trying to remember while flipping tabs quickly, or even outright guessing, but I certainly am not reasoning about it. I do not buy that typing variables, or lambdas, or long method names (like `Equal`), or having "compile time", or `null` or "function signatures" offers anything like the gains had by able to see all of the program, so I'm disinclined to waste energy on what I view as premature optimisation.

tel 12y ago
I disagree strongly. Good types can serve as very adequate reasoning tools for programs at large. This is the source of claims in Haskell/ML/Etc where "if it compiles it works" is used to guide 90% of even massive refactoring endeavors. It can be hard to believe how useful good types can be.
- geocar 12y ago
  I don't understand you. Do you believe "good types" in a 1000 line program is easier to reason about than a 20 line program?
  - jfoutz 12y ago
    Can't speak for tel, but i believe that. Types establish the rules of the game, and the compiler backs you up enforcing those rules. On the other hand, i'm the kind of guy that has read 20 lines of code and missed possible null value bugs. Sucks when you have to tell customers to wait for the next point release before they can use this new feature.
    - geocar 12y ago
      Why would you make a customer wait for a "point release" for a program that is only twenty lines long? I wonder if you thought I meant "a bug in 20 lines" when I meant a "20 line program". EDIT: e.g. 20 lines is enough for SQL http://web.archive.org/web/20060505221834/http://kx.com/q/e/s.k http://web.archive.org/web/20060505221834/http://kx.com/q/e/...
      - deleted 12y ago
        [deleted]
      - Dylan16807 12y ago
        How many functions do I have to read simultaneously in those 20 lines? Good use of types can isolate functions from each other. The typical '1000 line program' could be compacted like your program is and all fit onscreen at the same time, if you really wanted. It's not anywhere close to 50 times as much code.
        geocar 12y ago
        None of the lines have more than 4 functions on them (that's the parse utilities which has a bunch of short helpers on it), and most have only one function. Most of the functions are independent, with the exception of the parse utilities, so it's easier to list the exceptions: cre depends on col, w depends on w0 and w1; v and w are used in e (for tokenising); where (wh) is reused by select (sel) and update (upd). c and a are used for the pull parser.
      - tormeh 12y ago
        >http://web.archive.org/web/20060505221834/http://kx.com/q/e/s.k http://web.archive.org/web/20060505221834/http://kx.com/q/e/... What is this blasphemy?!
        geocar 12y ago
        It's part of kdb http://kx.com/ http://kx.com/ , a rather fast and powerful database, which is written in a language called k. Here's an excellent introduction to K: http://archive.vector.org.uk/art10010830 http://archive.vector.org.uk/art10010830 Most kdb users use Q though, which is something else.
  - deleted 12y ago
    [deleted]
  - tel 12y ago
    I don't think you can make comparisons like that and feel good about them. I certainly believe that there are 20 line programs which are harder to reason about than some 1000 line programs with types. That's a big silly, though, I'd believe the same even without the "with types" caveat. So, here's what I believe: * Types impose logical structure on programs which is continuously checked, high-level, and very human interpretable * All things being equal, shorter programs are easier to comprehend than longer programs * If I were to list the things which aid program comprehensibility then types + most of the things on the list in this blog post actually go *far* higher on that list than "short length" (Edit: I should add, given what came after this point, that "all things being equal" above is, in my eyes, a very difficult hypothesis to satisfy.)
    - geocar 12y ago
      > I don't think you can make comparisons like that and feel good about them. I think most professional programmers could write a relational database in under 1000 lines. Arthur did SQL92 in 20: http://web.archive.org/web/20060505221834/http://kx.com/q/e/s.k http://web.archive.org/web/20060505221834/http://kx.com/q/e/... I think this example is perfectly illustrated: I find it more valuable than anything else I have found to have the entire program all on one screen. > If I were to list the things which aid program comprehensibility then types + most of the things on the list in this blog post actually go far higher on that list than "short length" I think there are so many useful and successful applications that "use types" and so many useful and successful applications that do not "use types" that types are probably irrelevant for success. That many of those useful and successful programs are very large suggests that size has very little (or nothing at all) to do with success. But comprehensibility? I cannot imagine what universe would have a large program as being "easier to comprehend" than a short program.
      - tel 12y ago
        > I find it more valuable than anything else I have found to have the entire program all on one screen. Then we'll merely have to agree to disagree. I personally think this example is remarkable levels of incomprehensible. I'm not going to claim that my personal opinion has any level of generality, though. More power to you if that page of code is easy to comprehend. > I think there are so many useful and successful applications that "use types" and so many useful and successful applications that do not "use types" that types are probably irrelevant for success. The existence of examples both positive and negative is insufficient to demonstrate that some cause has no effect. You might strengthen that to say that in your experience the use of types has zero correlation with "useful and successful". I think with a little qualification there we could again get to a point where we'd merely have to agree to disagree. It's also vital to point out the selection bias incurred by either of our experiences. > I cannot imagine what universe would have a large program as being "easier to comprehend" than a short program. I could try to demonstrate examples of both, but it'd just be my opinion as to that selection. So, instead of trying to be comprehensible, I'll just state for posterity: Offhand, I believe it would be very easy to write a 1000 line (or even larger) implementation of SQL92 which I would find to be far more comprehensible than the example you've linked. In particular, I believe in this case that attempting to make that code fit on one page is a significant detriment to its comprehensibility. And again, I'm not going to try to convince you but merely state that as the fact of my opinion.
  - mannykannot 12y ago
    A false dichotomy. How many well-designed, well-typed 1000 line programs can be turned into 20-line programs simply by dropping the typing requirement?
    - geocar 12y ago
      Straw man. I'm not proposing "dropping the typing requirement". I think having the program small and fit on the page is more important than types or no types. To that end: I don't even want to have the argument about types because I think they're so irrelevant. I'm sure most professional programmers could write an SQL92 implementation in around 1000 lines; Again, types or no types. Here's Arthur's SQL written in 20 lines (including lexing and parsing): http://web.archive.org/web/20060505221834/http://kx.com/q/e/s.k http://web.archive.org/web/20060505221834/http://kx.com/q/e/... Here's Steve Apter's relational (not SQL) database in 16: http://nsl.com/k/t.k http://nsl.com/k/t.k
      - mannykannot 12y ago
        "I don't even want to have the argument about types..." But that is exactly what you chose to do in your original post.
        geocar 12y ago
        No it is not. I'm happy to see an argument that (having or not having types) is more important than a short program. but I'm not happy having an argument whether to have a language with types versus one without. That's what "I think types are irrelevant" means. It seems like at least some people realise this e.g. https://news.ycombinator.com/item?id=8999077 https://news.ycombinator.com/item?id=8999077 but if after re-reading my post you disagree, let me know how I could better articulate what I mean.
        mannykannot 12y ago
        I should have written 'the post to which I was replying' rather than 'your original post.' With regard to your larger issue, almost all programs other than exercises are vastly larger than a screenful, so either the way all software is written is completely wrong, or your preference for screen-sized programs is irrelevant to the real problems of writing real-world software. Just as professional mathematicians need to be able to follow proofs that occupy more than one page, professional programmers need to be able to reason about code that occupies more than one page.
  - tormeh 12y ago
    Depends whether the 20 lines are stack-based assembly or not... Anyway, what is initially written in 1000 lines can very rarely be written in 20.
stcredzero 12y ago
I have noticed that when a program is small enough that I can see all of it, then I can reason about all of it, and when I cannot see all of the code, then I cannot. You've made a powerful observation about how programmers and human minds in general interface with complex systems. What if you had language semantics that could let you ignore most of your codebase with 100% reliability? I've had a long career dealing with very complex "enterprise" software for multi-nationals. Semantic tricks that let you make far-reaching deductions and securely ignore most of the code are absolutely vital in contexts like that. It was precisely in the parts of the code where things weren't structured to allow this, that things broke down, and everyone dreaded to check-in code. I'm disinclined to waste energy on what I view as premature optimisation. There are certain contexts where one already knows that this sort of thing is not premature optimisation. (Granted, lots of programmers seem to make a fetish of acting like they are in such a context, when they really aren't. Analogous to: http://xkcd.com/538/ http://xkcd.com/538/ )
- geocar 12y ago
  Most of my professional life has been reading other people's code and finishing other people's programs. One thing I've noticed is that nobody has ever asked me to help fix a small codebase. Another thing I've noticed is that having well documented interfaces between small components is extremely effective at improving isolation time. Another thing I've noticed is that interfaces with two or fewer arguments (none of which boolean) tend to be used correctly more often than interfaces with a large number of arguments, or booleans. I would very much enjoy having a conversation about those language semantics. I haven't noticed any language semantics that would be useful in that way, however I have noticed a number of these "disciplines" that are helpful at reducing search time, reducing defect count and increase performance (run-time and programmer). What exactly are you thinking about?
  - enjoy-your-stay 12y ago
    I really like your observations, and have noticed pretty much the same thing. Your point about the boolean arguments especially, I can't tell you the number of times I've painstakingly documented the parameter in the /// section of the function (in c#) just to make sure it's clear what passing false actually means. I should just create an enum{ doTheDance,dontDoTheDance} with two values instead, often thought about it, but for some reason never actually done that.

by geocar 12y ago

tel 12y ago

I disagree strongly. Good types can serve as very adequate reasoning tools for programs at large. This is the source of claims in Haskell/ML/Etc where "if it compiles it works" is used to guide 90% of even massive refactoring endeavors. It can be hard to believe how useful good types can be.

geocar 12y ago
I don't understand you. Do you believe "good types" in a 1000 line program is easier to reason about than a 20 line program?
- jfoutz 12y ago
  Can't speak for tel, but i believe that. Types establish the rules of the game, and the compiler backs you up enforcing those rules. On the other hand, i'm the kind of guy that has read 20 lines of code and missed possible null value bugs. Sucks when you have to tell customers to wait for the next point release before they can use this new feature.
  - geocar 12y ago
    Why would you make a customer wait for a "point release" for a program that is only twenty lines long? I wonder if you thought I meant "a bug in 20 lines" when I meant a "20 line program". EDIT: e.g. 20 lines is enough for SQL http://web.archive.org/web/20060505221834/http://kx.com/q/e/s.k http://web.archive.org/web/20060505221834/http://kx.com/q/e/...
    - deleted 12y ago
      [deleted]
    - Dylan16807 12y ago
      How many functions do I have to read simultaneously in those 20 lines? Good use of types can isolate functions from each other. The typical '1000 line program' could be compacted like your program is and all fit onscreen at the same time, if you really wanted. It's not anywhere close to 50 times as much code.
      - geocar 12y ago
        None of the lines have more than 4 functions on them (that's the parse utilities which has a bunch of short helpers on it), and most have only one function. Most of the functions are independent, with the exception of the parse utilities, so it's easier to list the exceptions: cre depends on col, w depends on w0 and w1; v and w are used in e (for tokenising); where (wh) is reused by select (sel) and update (upd). c and a are used for the pull parser.
    - tormeh 12y ago
      >http://web.archive.org/web/20060505221834/http://kx.com/q/e/s.k http://web.archive.org/web/20060505221834/http://kx.com/q/e/... What is this blasphemy?!
      - geocar 12y ago
        It's part of kdb http://kx.com/ http://kx.com/ , a rather fast and powerful database, which is written in a language called k. Here's an excellent introduction to K: http://archive.vector.org.uk/art10010830 http://archive.vector.org.uk/art10010830 Most kdb users use Q though, which is something else.
- deleted 12y ago
  [deleted]
- tel 12y ago
  I don't think you can make comparisons like that and feel good about them. I certainly believe that there are 20 line programs which are harder to reason about than some 1000 line programs with types. That's a big silly, though, I'd believe the same even without the "with types" caveat. So, here's what I believe: * Types impose logical structure on programs which is continuously checked, high-level, and very human interpretable * All things being equal, shorter programs are easier to comprehend than longer programs * If I were to list the things which aid program comprehensibility then types + most of the things on the list in this blog post actually go *far* higher on that list than "short length" (Edit: I should add, given what came after this point, that "all things being equal" above is, in my eyes, a very difficult hypothesis to satisfy.)
  - geocar 12y ago
    > I don't think you can make comparisons like that and feel good about them. I think most professional programmers could write a relational database in under 1000 lines. Arthur did SQL92 in 20: http://web.archive.org/web/20060505221834/http://kx.com/q/e/s.k http://web.archive.org/web/20060505221834/http://kx.com/q/e/... I think this example is perfectly illustrated: I find it more valuable than anything else I have found to have the entire program all on one screen. > If I were to list the things which aid program comprehensibility then types + most of the things on the list in this blog post actually go far higher on that list than "short length" I think there are so many useful and successful applications that "use types" and so many useful and successful applications that do not "use types" that types are probably irrelevant for success. That many of those useful and successful programs are very large suggests that size has very little (or nothing at all) to do with success. But comprehensibility? I cannot imagine what universe would have a large program as being "easier to comprehend" than a short program.
    - tel 12y ago
      > I find it more valuable than anything else I have found to have the entire program all on one screen. Then we'll merely have to agree to disagree. I personally think this example is remarkable levels of incomprehensible. I'm not going to claim that my personal opinion has any level of generality, though. More power to you if that page of code is easy to comprehend. > I think there are so many useful and successful applications that "use types" and so many useful and successful applications that do not "use types" that types are probably irrelevant for success. The existence of examples both positive and negative is insufficient to demonstrate that some cause has no effect. You might strengthen that to say that in your experience the use of types has zero correlation with "useful and successful". I think with a little qualification there we could again get to a point where we'd merely have to agree to disagree. It's also vital to point out the selection bias incurred by either of our experiences. > I cannot imagine what universe would have a large program as being "easier to comprehend" than a short program. I could try to demonstrate examples of both, but it'd just be my opinion as to that selection. So, instead of trying to be comprehensible, I'll just state for posterity: Offhand, I believe it would be very easy to write a 1000 line (or even larger) implementation of SQL92 which I would find to be far more comprehensible than the example you've linked. In particular, I believe in this case that attempting to make that code fit on one page is a significant detriment to its comprehensibility. And again, I'm not going to try to convince you but merely state that as the fact of my opinion.
- mannykannot 12y ago
  A false dichotomy. How many well-designed, well-typed 1000 line programs can be turned into 20-line programs simply by dropping the typing requirement?
  - geocar 12y ago
    Straw man. I'm not proposing "dropping the typing requirement". I think having the program small and fit on the page is more important than types or no types. To that end: I don't even want to have the argument about types because I think they're so irrelevant. I'm sure most professional programmers could write an SQL92 implementation in around 1000 lines; Again, types or no types. Here's Arthur's SQL written in 20 lines (including lexing and parsing): http://web.archive.org/web/20060505221834/http://kx.com/q/e/s.k http://web.archive.org/web/20060505221834/http://kx.com/q/e/... Here's Steve Apter's relational (not SQL) database in 16: http://nsl.com/k/t.k http://nsl.com/k/t.k
    - mannykannot 12y ago
      "I don't even want to have the argument about types..." But that is exactly what you chose to do in your original post.
      - geocar 12y ago
        No it is not. I'm happy to see an argument that (having or not having types) is more important than a short program. but I'm not happy having an argument whether to have a language with types versus one without. That's what "I think types are irrelevant" means. It seems like at least some people realise this e.g. https://news.ycombinator.com/item?id=8999077 https://news.ycombinator.com/item?id=8999077 but if after re-reading my post you disagree, let me know how I could better articulate what I mean.
        mannykannot 12y ago
        I should have written 'the post to which I was replying' rather than 'your original post.' With regard to your larger issue, almost all programs other than exercises are vastly larger than a screenful, so either the way all software is written is completely wrong, or your preference for screen-sized programs is irrelevant to the real problems of writing real-world software. Just as professional mathematicians need to be able to follow proofs that occupy more than one page, professional programmers need to be able to reason about code that occupies more than one page.
- tormeh 12y ago
  Depends whether the 20 lines are stack-based assembly or not... Anyway, what is initially written in 1000 lines can very rarely be written in 20.

stcredzero 12y ago

I have noticed that when a program is small enough that I can see all of it, then I can reason about all of it, and when I cannot see all of the code, then I cannot. You've made a powerful observation about how programmers and human minds in general interface with complex systems. What if you had language semantics that could let you ignore most of your codebase with 100% reliability? I've had a long career dealing with very complex "enterprise" software for multi-nationals. Semantic tricks that let you make far-reaching deductions and securely ignore most of the code are absolutely vital in contexts like that. It was precisely in the parts of the code where things weren't structured to allow this, that things broke down, and everyone dreaded to check-in code. I'm disinclined to waste energy on what I view as premature optimisation. There are certain contexts where one already knows that this sort of thing is not premature optimisation. (Granted, lots of programmers seem to make a fetish of acting like they are in such a context, when they really aren't. Analogous to: http://xkcd.com/538/ http://xkcd.com/538/ )

geocar 12y ago
Most of my professional life has been reading other people's code and finishing other people's programs. One thing I've noticed is that nobody has ever asked me to help fix a small codebase. Another thing I've noticed is that having well documented interfaces between small components is extremely effective at improving isolation time. Another thing I've noticed is that interfaces with two or fewer arguments (none of which boolean) tend to be used correctly more often than interfaces with a large number of arguments, or booleans. I would very much enjoy having a conversation about those language semantics. I haven't noticed any language semantics that would be useful in that way, however I have noticed a number of these "disciplines" that are helpful at reducing search time, reducing defect count and increase performance (run-time and programmer). What exactly are you thinking about?
- enjoy-your-stay 12y ago
  I really like your observations, and have noticed pretty much the same thing. Your point about the boolean arguments especially, I can't tell you the number of times I've painstakingly documented the parameter in the /// section of the function (in c#) just to make sure it's clear what passing false actually means. I should just create an enum{ doTheDance,dontDoTheDance} with two values instead, often thought about it, but for some reason never actually done that.