Hacker News Reader

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.

> It's also very nearly your only option when learning something new.

Also your only option when working with other developers.

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 :)

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".

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.

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.

> 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.

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.

Note that isn’t the meaning of live programming, at least according to the definition laid out in Chris Hancock’s 2004 dissertation where he introduces the word. Of course, other definitions have been created to include more conventional programming practices (e.g. in Lisp and Smalltalk) or performance oriented live coding, but we are all talking about significantly different things at that point.

> 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/fil...

exhibit B: https://ni.i.lithium.com/t5/image/serverpage/image-id/184872...

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.

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".

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.

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.

What you are describing sounds very close to this

https://github.com/LiveAsynchronousVisualizedArchitecture/la...

Are there any projects that use this? This is kind of what I'm looking for

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.

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.

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.

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.

Java bean IDE vomit-in-files?

Not my cup of tea, but sorta plausible.

That's not writing 10k lines of code. It's having an IDE generate 10k lines of code.

If your typing speed is the limiting factor in writing code...I really don't know what to think.

80 wpm and still a limiting factor in programming? That would be pure genius, I think...

OK, I can see that by the numbers it is possible, if you have planned everything so well that you don't waste any time getting stuck or rewriting. While I do this for much smaller amounts of coder, 10k LOC is so much that I don't think I could possibly plan it out that well, and also keep it in my head. Personally I find that my plans fall apart once I actually start to write out the code and notice many things I forgot, and usually I find the code is much uglier than expected and I try to find better ways.

> 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.

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.

> 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.

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.

> 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)

You have those, but you don't have core algorithmic property of an effective method that can be computed within a finite amount of time and space. It isn't even very meaningful.

In the meta sense, you might be able to come up with an algorithm that makes connections automatically, but then...it is meta.

Unifying algorithm and architecture has been somewhat of a holy grail of PL, being able to express your whole program (including your frameworks) as just procedures would be very convenient, but no one has figured out how to do that.

> you don't have core algorithmic property of an effective method

If a software framework doesn't have idioms, I'm not sure it's a framework. Examples of frameworks that have no case for using it dont do well.

It’s more like it doesn’t make sense. Of course they have idioms, but idioms are not deterministic decision methods.

Don't be dense. How a controller in an MVC framework maps to a url and provides an execution path through the framework is an algorithm. The fact you plug in multiple values to make that happen (including the executing function) is the idiom that results in a consistent algorithm. You can alter this, which isn't a compelling argument.

A UI framework is better understood as an algorithm plus a psychological model of your user. You must understand what they are thinking at every step of the way, guide them to the answers they want, and help them avoid pitfalls.

This is by its very nature a less deterministic solution than a pure algorithm.

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.

>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).

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.