6 ms·

> A basic observation about the human programming process is > that it is incremental. No one writes the entirety of their > program in a single go, c

> A basic observation about the human programming process is > that it is incremental. No one writes the entirety of their > program in a single go, clicks compile + publish, and never > looks at the code again. Programming is a long slog of > trial and error, where the length of the trial and the > severity of the error depend heavily on the domain and the > tooling. I don't know about others but I've done this quite a few times. When I have to write some code for a personal project of moderate size (10k LOC) I like to just sleep on it for a while, stay up very late, chug some coffee, and write the entire program. After that I click compile and run a few times, fix any variable names that I've undoutably misspelled, and then maybe 1 or 2 bugs. It's basically delaying starting a project until you have a perfect mental image of what that code needs to do, how it looks, and understand mentally every tradeoff you're making. I wish I could do this with larger code bases but unfortunately, from my own experience, planning time is exponentially related to the projected lines of code. A 5K to 10k LOC project usually takes me on the order of 2 weeks of thinking. If you go higher than that you're talking about months. If you wanted to change the world of programming I would think of a way to abstractly describe dataflows in the vain of unix pipes. Define every part of the transforms you need to do on incoming data, where those responsibilities should be, and then link them together. Current abstraction methods are subpar: they require inherent complexity, are language specific, and are not easy to change after you've using them (unless you have adapters on every part of the code base which in it's own right becomes a mess).

Groxx 9y ago
Yeah, I'd call this the difference between "discovering how to program a thing" and "programming something you already understand". Discovering as you go is totally fine, and dominates what I write. It's also very nearly your only option when learning something new. Sitting on millions of lines of code, integrating with dozens of other systems... you often simply don't know what you need to do up-front, so you iterate and explore until you do. Gradually tightening the constraints of the system fits this kind of thing perfectly and I love when it's easy to achieve. It gets you both a faster start and a safer finish. In contrast, entirely agreed - I've written a few low-kLOC projects start-to-finish with basically no problems. But I knew exactly what I was going to do before I started actually coding. The (significant) time leading up to that was spent more-thoroughly understanding what and how I wanted to do, and at some point it all clicked in an "oh. so that's how. OK, might as well build it now" moment.
- mcphage 9y ago
  > It's also very nearly your only option when learning something new. Also your only option when working with other developers.
  - Groxx 9y ago
    Making it so this isn't true with multiple developers is one of the benefits of waterfall-style programming. Design an API up-front, divvy up work, build it. As long as the design is good and you don't do stupid shit, it's entirely possible to work in parallel without getting in each other's way. But yes, it absolutely compounds the issues. Everyone involved has to thoroughly understand it all / their role in it, and getting to that point likely takes longer than discovering it as you go :)
- LrnByTeach 9y ago
  I guess , most of the programmers experience these two approaches ( at any given time only one approach) > "discovering how to program a thing" and "programming something you already understand".
- barry-cotter 9y ago
  This is why rewriting from scratch goes so much faster than doing it the first time. You know what you’re doing and how to do it.
AboutTheWhisles 9y ago
What you are describing sounds very close to this https://github.com/LiveAsynchronousVisualizedArchitecture/lava https://github.com/LiveAsynchronousVisualizedArchitecture/la...
- gravypod 9y ago
  Are there any projects that use this? This is kind of what I'm looking for
  - AboutTheWhisles 9y ago
    None yet, it is still early and a bit rough around the edges, but it is under active development if you want to get involved.
catnaroek 9y ago
> I wish I could do this with larger code bases but unfortunately, from my own experience, planning time is exponentially related to the projected lines of code. Hence more work has to be done on expressing solutions to big problems as the composition of solutions to smaller problems. Which is fundamentally an algorithms problem. > Current abstraction methods are subpar: they require inherent complexity, are language specific, and are not easy to change after you've using them (unless you have adapters on every part of the code base which in it's own right becomes a mess). Programming languages exist to implement algorithms, which in turn exist to solve problems. If your language of choice is getting in the way to implementing the algorithms you need to solve problems, you have to switch languages, not anything else.
- seanmcdirmid 9y ago
  Not everything can be done through algorithms, actually, a lot of programming involves just designing parts, where to hold state, interactions between components, basically what is called architecture.
  - catnaroek 9y ago
    > where to hold state Wherever it makes the most sense for the algorithms you want to implement. > interactions between components Again, driven by the needs of the algorithms, and, most importantly, their proofs of correctness.
    - seanmcdirmid 9y ago
      That is a very simplistic 1D view of programming. Quicksort is an algorithm, algorithsm are often reused. A UI framework is not an algorithm, and it is most definitely if you are writing a UI.
      - jack9 9y ago
        > A UI framework is not an algorithm I think it is. A framework is a pattern of behaviors. You have inputs, transforms, and outputs. Some are connected, some you leverage by use case - standard library of a utility or core namespace (e.g. from flask import jsonify)
psyc 9y ago
Yes, I've done that quite a few times too. Write code for 1-2 months straight without ever compiling. When I'm done, it generally compiles and runs fine after about 20 minutes of fixing silly bugs. That requires designing the system on paper (actual paper) in quite a lot of detail first. But other times I start with a skeletal outline of input - middle - output, and evolve the middle in small increments, refactoring along the way. In either case, I always write about 5 drafts of everything at every level - the method level, the class level, and the system level. And I consider that my secret weapon - the writing of 5, sometimes 10, drafts. Understanding the problem is key, as others have said. It's my belief that we seldom understand the problem in any detail until we've basically written a working system, and we'd do that fact the most justice by beginning a second draft as soon as the first working version is 'done'. That generally won't fly in the workplace, and that's one of the main reasons I avoid the workplace.
- jack9 9y ago
  > Yes, I've done that quite a few times too. No, neither have. You misunderstand the algorithm suggested. Even if you had 0 bugs, you're still going through the process described. The overwhelmingly common case you then describe: > When I'm done, it generally compiles and runs fine after about 20 minutes of fixing silly bugs. How is this not exactly what the article describes? > Programming is a long slog of trial and error, where the length of the trial and the > severity of the error depend heavily on the domain and the tooling.
  - gravypod 9y ago
    This article describes live programming which is something that dates back to some of the older programmers. It's a common methodology that crops up often. It's not about the number of times it takes you to run something or finding spelling errors. Fixing spelling errors still counts as "running the first time" as long as you're not changing the structure of the code. This article describes the idea of an interactive programming environment with a single language for all problems. This method of development, as described in this article, is very common in industry but not very productive. It is still lot of trial and error and in that same time I can be doing something that I know I will do correctly.
userbinator 9y ago
Also known as the Feynman Algorithm. I've done that quite a few times too, and found it to be faster than trying to "design as you go" and having to constantly debug and make incremental changes to fix things (which also tend to have the effect of making the code messier.) If you think everything through and then write the code, the only bugs tend to be minor, spelling-related and such, but otherwise the code usually "works the first time".
- gonzo41 9y ago
  Yeah i do this mostly, but it's hard to be agile when all I want to do is ponder a problem for a sprint. I also find writing a plan helpful if only enumerate the issues at hand. It always changes but its good to start with. I find generally this approach leads to less production crippling errors.
  - AnimalMuppet 9y ago
    Extreme Programming has this idea of a "spike". It's throwaway code that you write just to figure out how to do something. (The name comes from trying to "nail something down", I think.) That's not quite just thinking for a sprint, but it's in the same direction.
versteegen 9y ago
You're not serious about writing out 10kLOC in a day, though, are you? I think the most I've ever managed in one day was <2kLOC, and that's already an extreme outlier.
- gravypod 9y ago
  Let's say comments make up 10% of my lines, white space makes up 10% of my lines, and a single } makes up another 10% of my lines. That makes 7000 lines. Let's say every line is filled with 80 characters that I have typed (no auto indent). Let's assume there are 5 characters in the average word and I type at 80wpm. With those paramaters it would take about 23hr to type. Luckily I have an IDE, I comment a lot, and I indent and make a lot of whitespace to separate ideas between lines.
  - tom_mellior 9y ago
    If you work for 8 hours (28800 seconds) without any breaks, 10k lines comes out to one line every 2.88 seconds. I'll choose not to believe you.
    - Roboprog 9y ago
      Java bean IDE vomit-in-files? Not my cup of tea, but sorta plausible.
      - TheCoelacanth 9y ago
        That's not writing 10k lines of code. It's having an IDE generate 10k lines of code.
  - paulddraper 9y ago
    If your typing speed is the limiting factor in writing code...I really don't know what to think.
    - klibertp 9y ago
hyperpallium 9y ago
Is it the complexity of the solution (LOC), or complexity of the problem? Better abstractions for solutions are great, better abstractions for problems would be even better, but I'm not sure they'd help all that much for understanding difficult problems... perhaps more data on the problem would help, but that's often lacking.
rhapsodic 9y ago
>I don't know about others but I've done this quite a few times. When I have to write some code for a personal project of moderate size (10k LOC) I like to just sleep on it for a while, stay up very late, chug some coffee, and write the entire program. After that I click compile and run a few times, fix any variable names that I've undoutably misspelled, and then maybe 1 or 2 bugs. It's basically delaying starting a project until you have a perfect mental image of what that code needs to do, how it looks, and understand mentally every tradeoff you're making. IOW, the mental version of BDUF (Big Design Up Front).
- AnimalMuppet 9y ago
  Which, for a small system, can work, because you can hold the whole design in your head, and because you can write the whole thing before any requirements change. Try to scale that up, though, and you get into the usual BDUF disasters.
jcelerier 9y ago
> If you wanted to change the world of programming I would think of a way to abstractly describe dataflows in the vain of unix pipes. Define every part of the transforms you need to do on incoming data, where those responsibilities should be, and then link them together. there are plenty of people programming in datflow languages where you do exactly this (eg LabView, Max/MSP, PureData, vvvv, etc...). Guess what: after some time it just becomes shit too, because making such graphs is freakin hard. exhibit A: http://1cyjknyddcx62agyb002-c74projects.s3.amazonaws.com/files/2014/11/screenshot.jpg http://1cyjknyddcx62agyb002-c74projects.s3.amazonaws.com/fil... exhibit B: https://ni.i.lithium.com/t5/image/serverpage/image-id/184872i5D184D60A62CEF6F?v=1.0 https://ni.i.lithium.com/t5/image/serverpage/image-id/184872...
- gravypod 9y ago
  Just because it hasn't worked before doesn't mean that there isn't a good way, that has yet to be created, for describing data flows and modularizations of systems.

Groxx 9y ago

Yeah, I'd call this the difference between "discovering how to program a thing" and "programming something you already understand". Discovering as you go is totally fine, and dominates what I write. It's also very nearly your only option when learning something new. Sitting on millions of lines of code, integrating with dozens of other systems... you often simply don't know what you need to do up-front, so you iterate and explore until you do. Gradually tightening the constraints of the system fits this kind of thing perfectly and I love when it's easy to achieve. It gets you both a faster start and a safer finish. In contrast, entirely agreed - I've written a few low-kLOC projects start-to-finish with basically no problems. But I knew exactly what I was going to do before I started actually coding. The (significant) time leading up to that was spent more-thoroughly understanding what and how I wanted to do, and at some point it all clicked in an "oh. so that's how. OK, might as well build it now" moment.

mcphage 9y ago
> It's also very nearly your only option when learning something new. Also your only option when working with other developers.
- Groxx 9y ago
  Making it so this isn't true with multiple developers is one of the benefits of waterfall-style programming. Design an API up-front, divvy up work, build it. As long as the design is good and you don't do stupid shit, it's entirely possible to work in parallel without getting in each other's way. But yes, it absolutely compounds the issues. Everyone involved has to thoroughly understand it all / their role in it, and getting to that point likely takes longer than discovering it as you go :)
LrnByTeach 9y ago
I guess , most of the programmers experience these two approaches ( at any given time only one approach) > "discovering how to program a thing" and "programming something you already understand".
barry-cotter 9y ago
This is why rewriting from scratch goes so much faster than doing it the first time. You know what you’re doing and how to do it.

AboutTheWhisles 9y ago

What you are describing sounds very close to this https://github.com/LiveAsynchronousVisualizedArchitecture/lava https://github.com/LiveAsynchronousVisualizedArchitecture/la...

gravypod 9y ago
Are there any projects that use this? This is kind of what I'm looking for
- AboutTheWhisles 9y ago
  None yet, it is still early and a bit rough around the edges, but it is under active development if you want to get involved.

catnaroek 9y ago

> I wish I could do this with larger code bases but unfortunately, from my own experience, planning time is exponentially related to the projected lines of code. Hence more work has to be done on expressing solutions to big problems as the composition of solutions to smaller problems. Which is fundamentally an algorithms problem. > Current abstraction methods are subpar: they require inherent complexity, are language specific, and are not easy to change after you've using them (unless you have adapters on every part of the code base which in it's own right becomes a mess). Programming languages exist to implement algorithms, which in turn exist to solve problems. If your language of choice is getting in the way to implementing the algorithms you need to solve problems, you have to switch languages, not anything else.

seanmcdirmid 9y ago
Not everything can be done through algorithms, actually, a lot of programming involves just designing parts, where to hold state, interactions between components, basically what is called architecture.
- catnaroek 9y ago
  > where to hold state Wherever it makes the most sense for the algorithms you want to implement. > interactions between components Again, driven by the needs of the algorithms, and, most importantly, their proofs of correctness.
  - seanmcdirmid 9y ago
    That is a very simplistic 1D view of programming. Quicksort is an algorithm, algorithsm are often reused. A UI framework is not an algorithm, and it is most definitely if you are writing a UI.
    - jack9 9y ago
      > A UI framework is not an algorithm I think it is. A framework is a pattern of behaviors. You have inputs, transforms, and outputs. Some are connected, some you leverage by use case - standard library of a utility or core namespace (e.g. from flask import jsonify)

psyc 9y ago

Yes, I've done that quite a few times too. Write code for 1-2 months straight without ever compiling. When I'm done, it generally compiles and runs fine after about 20 minutes of fixing silly bugs. That requires designing the system on paper (actual paper) in quite a lot of detail first. But other times I start with a skeletal outline of input - middle - output, and evolve the middle in small increments, refactoring along the way. In either case, I always write about 5 drafts of everything at every level - the method level, the class level, and the system level. And I consider that my secret weapon - the writing of 5, sometimes 10, drafts. Understanding the problem is key, as others have said. It's my belief that we seldom understand the problem in any detail until we've basically written a working system, and we'd do that fact the most justice by beginning a second draft as soon as the first working version is 'done'. That generally won't fly in the workplace, and that's one of the main reasons I avoid the workplace.

jack9 9y ago
> Yes, I've done that quite a few times too. No, neither have. You misunderstand the algorithm suggested. Even if you had 0 bugs, you're still going through the process described. The overwhelmingly common case you then describe: > When I'm done, it generally compiles and runs fine after about 20 minutes of fixing silly bugs. How is this not exactly what the article describes? > Programming is a long slog of trial and error, where the length of the trial and the > severity of the error depend heavily on the domain and the tooling.
- gravypod 9y ago
  This article describes live programming which is something that dates back to some of the older programmers. It's a common methodology that crops up often. It's not about the number of times it takes you to run something or finding spelling errors. Fixing spelling errors still counts as "running the first time" as long as you're not changing the structure of the code. This article describes the idea of an interactive programming environment with a single language for all problems. This method of development, as described in this article, is very common in industry but not very productive. It is still lot of trial and error and in that same time I can be doing something that I know I will do correctly.

userbinator 9y ago

Also known as the Feynman Algorithm. I've done that quite a few times too, and found it to be faster than trying to "design as you go" and having to constantly debug and make incremental changes to fix things (which also tend to have the effect of making the code messier.) If you think everything through and then write the code, the only bugs tend to be minor, spelling-related and such, but otherwise the code usually "works the first time".

gonzo41 9y ago
Yeah i do this mostly, but it's hard to be agile when all I want to do is ponder a problem for a sprint. I also find writing a plan helpful if only enumerate the issues at hand. It always changes but its good to start with. I find generally this approach leads to less production crippling errors.
- AnimalMuppet 9y ago
  Extreme Programming has this idea of a "spike". It's throwaway code that you write just to figure out how to do something. (The name comes from trying to "nail something down", I think.) That's not quite just thinking for a sprint, but it's in the same direction.

versteegen 9y ago

You're not serious about writing out 10kLOC in a day, though, are you? I think the most I've ever managed in one day was <2kLOC, and that's already an extreme outlier.

gravypod 9y ago
Let's say comments make up 10% of my lines, white space makes up 10% of my lines, and a single } makes up another 10% of my lines. That makes 7000 lines. Let's say every line is filled with 80 characters that I have typed (no auto indent). Let's assume there are 5 characters in the average word and I type at 80wpm. With those paramaters it would take about 23hr to type. Luckily I have an IDE, I comment a lot, and I indent and make a lot of whitespace to separate ideas between lines.
- tom_mellior 9y ago
  If you work for 8 hours (28800 seconds) without any breaks, 10k lines comes out to one line every 2.88 seconds. I'll choose not to believe you.
  - Roboprog 9y ago
    Java bean IDE vomit-in-files? Not my cup of tea, but sorta plausible.
    - TheCoelacanth 9y ago
      That's not writing 10k lines of code. It's having an IDE generate 10k lines of code.
- paulddraper 9y ago
  If your typing speed is the limiting factor in writing code...I really don't know what to think.
  - klibertp 9y ago

hyperpallium 9y ago

Is it the complexity of the solution (LOC), or complexity of the problem? Better abstractions for solutions are great, better abstractions for problems would be even better, but I'm not sure they'd help all that much for understanding difficult problems... perhaps more data on the problem would help, but that's often lacking.

rhapsodic 9y ago

>I don't know about others but I've done this quite a few times. When I have to write some code for a personal project of moderate size (10k LOC) I like to just sleep on it for a while, stay up very late, chug some coffee, and write the entire program. After that I click compile and run a few times, fix any variable names that I've undoutably misspelled, and then maybe 1 or 2 bugs. It's basically delaying starting a project until you have a perfect mental image of what that code needs to do, how it looks, and understand mentally every tradeoff you're making. IOW, the mental version of BDUF (Big Design Up Front).

AnimalMuppet 9y ago
Which, for a small system, can work, because you can hold the whole design in your head, and because you can write the whole thing before any requirements change. Try to scale that up, though, and you get into the usual BDUF disasters.

jcelerier 9y ago

> If you wanted to change the world of programming I would think of a way to abstractly describe dataflows in the vain of unix pipes. Define every part of the transforms you need to do on incoming data, where those responsibilities should be, and then link them together. there are plenty of people programming in datflow languages where you do exactly this (eg LabView, Max/MSP, PureData, vvvv, etc...). Guess what: after some time it just becomes shit too, because making such graphs is freakin hard. exhibit A: http://1cyjknyddcx62agyb002-c74projects.s3.amazonaws.com/files/2014/11/screenshot.jpg http://1cyjknyddcx62agyb002-c74projects.s3.amazonaws.com/fil... exhibit B: https://ni.i.lithium.com/t5/image/serverpage/image-id/184872i5D184D60A62CEF6F?v=1.0 https://ni.i.lithium.com/t5/image/serverpage/image-id/184872...

gravypod 9y ago
Just because it hasn't worked before doesn't mean that there isn't a good way, that has yet to be created, for describing data flows and modularizations of systems.