Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming Is Mostly Thinking (2014)

agileotter.blogspot.com

Post reply on HN
Print view View original

311–320 of 339 posts

Re: Programming Is Mostly Thinking (2014)

#311

Post by Labo333 »

In my experience (slightly tweaked towards data science and AI research), programming is also experimenting, be it playing with the data, testing a new idea or even debugging.

There is a reason why LISPers (I'm not one of them though) praise so much REPL-driven development: the REPL is a laboratory.

Also, how much time did you spend testing a library, looking on the internet how to install it, debugging the weird compiler errors? In the end you found the one option that made everything work but it took you hours of research and experimentation.

Re: Programming Is Mostly Thinking (2014)

#312

Post by effed3 »

Somemone say success is 1/10 genius 9/10 hard work (and a big supply of pencil paper and erasers), to -create- something (software too) is understanding how to do it right, not only how to do it work, is know the 'rules' (often standing on the shouders of giants) to maybe one day update (break too) those rules.

Re: Programming Is Mostly Thinking (2014)

#314

Post by elwell »

taneq wrote: post #263
xandrius wrote: post #177

Earlier quoted context omitted.

10/20 minutes to sharpen a pretty dull kitchen knife with some decent whetstones. Also, as someone famous once said: if I had 4 hours to sharpen an axe, I'd spend 2 hours preparing the whetstones.

If I had 2 hours to prepare whetstones I’d do 1 hour of billable work and then order some whetstones online.

If I had 1 hour of billable work, I'd charge per project and upfront, to allow me to claim unemployment for the following weeks.

Re: Programming Is Mostly Thinking (2014)

#315

Post by nathan_compton »

One of the things I find interesting about the limited general intelligence of language models (about which I tend to be pretty deflationary) is that my own thought processes during programming are almost entirely non-verbal. I would find it to be incredibly constraining to have to express all my intermediate thoughts in the form of text. It is one of the things that makes me think we need a leap or two before AGI.

Re: Programming Is Mostly Thinking (2014)

#316

Post by earnesti »

indigoabstract wrote: post #131
brabel wrote: post #101

Great article. I just want to comment on this quote from the article: "Really good developers do 90% or more of the work before they ever touch the keyboard;" While that may be true sometimes, I think that ignores the fact that most people can't keep a whole lot of constraints and concepts in their head at the same time. So the amount of pure thinking you can do without writing anything at all is extremely limited. M…

I had the same thought as I read that line. I think he's actually describing Linus Torvalds there, who, legend has it, thought about Git for a month or so and when he was done thinking, he got to work coding and in six days delivered the finished product. And then, on the seventh day he rested. But for the rest of us (especially myself), it seems to be more like an interplay between thinking of what to write, writing…

> I think he's actually describing Linus Torvalds there, who, legend has it, thought about Git for a month or so and when he was done thinking, he got to work coding and in six days delivered the finished product. And then, on the seventh day he rested.

That sounds a bit weird. As I remember, linux developers were using semi-closed system called BitLocker (or something like that) for many years. For some reason the open source systems at that time weren't sufficient. The problems with BitLocker were constantly discussed, so it might be that Linus was thinking about the problems for years before he wrote git.

Re: Programming Is Mostly Thinking (2014)

#317

Post by fennecfoxy »

brabel wrote: post #101

Great article. I just want to comment on this quote from the article: "Really good developers do 90% or more of the work before they ever touch the keyboard;" While that may be true sometimes, I think that ignores the fact that most people can't keep a whole lot of constraints and concepts in their head at the same time. So the amount of pure thinking you can do without writing anything at all is extremely limited. M…

It's not even that, it's also the iceberg effect of all our personal knowledge-bases; I'd rather experiment on my machine figuring out how I want to do something rather than read endless documentation.

Documentation is a good starter/unblocker but once I've got the basics down then I'll run wild in a REPL or something figuring out exactly how I want to do something.

Pure thinking planning is a good way to end up with all sorts of things that weren't factored in, imo. We should always encourage play during the planning process.

Re: Programming Is Mostly Thinking (2014)

#318

Post by QuercusMax »

dave78 wrote: post #240
patmcc wrote: post #231

Earlier quoted context omitted.

I'm going to take a stab here: you've never used cvs or svn. git, for all its warts, is quite literally a 10x improvement on those, which is what it was (mostly) competing with.

I started my career with Clearcase (ick) and added CVS for personal projects shortly after. CVS always kind of sucked, even compared with Clearcase. Subversion was a massive improvement, and I was pretty happy with it for a long time. I resisted moving from Subversion to Git for a while but eventually caved like nearly everyone else. After learning it sufficiently, I now enjoy Git, and I think the model it uses is be…

Subversion was a major improvement over CVS, in that it actually had sane branching and atomic commits. (In CVS, if you commit multiple files, they're not actually committed in a single action - they're individual file-level transactions that are generally grouped together based on commit message and similar (but not identical!) timestamps.) Some weirdness like using paths for branching, but that's not a big deal.

I actually migrated my company from CVS to SVN in part so we could do branchy development effectively, and also so I personally could use git-svn to interact with the repo. We ended up eventually moving Mercurial since Git didn't have a good Windows story at the time. Mercurial and Git are pretty much equivalent in my experience, just they decided to give things confusing names. (git fetch / pull and hg fetch / pull have their meanings swapped)

Re: Programming Is Mostly Thinking (2014)

#319

Post by JohnFen »

brabel wrote: post #101

Great article. I just want to comment on this quote from the article: "Really good developers do 90% or more of the work before they ever touch the keyboard;" While that may be true sometimes, I think that ignores the fact that most people can't keep a whole lot of constraints and concepts in their head at the same time. So the amount of pure thinking you can do without writing anything at all is extremely limited. M…

> writing code should be actually seen as part of the "thinking process"

I agree. This is how I work as well. I start coding as quickly as possible, and I fully plan on throwing away my first draft and starting again. I do a fair bit of thinking beforehand, of course, but I also want to get the hidden "gotchas" brought to light as quickly as possible, and often the fastest way is to just start writing the code.

Re: Programming Is Mostly Thinking (2014)

#320

Post by JonChesterfield »

swiftcoder wrote: post #310
xiwenc wrote: post #283

Earlier quoted context omitted.

Git is a special case i would say . Because it is fairly self contained. It had minimal dependencies on external components. It mostly relied on filesystem API. Everything else was “invented” inside of Git. This is special because most real world systems has a lot more dependencies. That’s when experimentation is required. Because one cannot know all relevant API’s beforehand and their behaviors. Therefore the only w…

> Git is a special case i would say . Because it is fairly self contained. It had minimal dependencies on external components. It mostly relied on filesystem API. Everything else was “invented” inside of Git. This type of developer tends to prefer building software like this. There is a whole crowd of hardcore C/C++/Rust devs who eschew taking dependencies in favour of writing everything themselves (and they mostly n…

It's really easy to remember the semantics of C. At least if you punt a bit on the parts that savage you in the name of UB. You know what libc has in it, give or take, because it's tiny.

Therefore if you walk through the woodland thinking about a program to write in C there is exactly zero interrupt to check docs to see how some dependency might behave. There is no uncertainty over what it can do, or what things will cost you writing another language to do reasonably.

Further, when you come to write it, there's friction when you think "oh, I want a trie here", but that's of a very different nature to "my python dependency segfaults sometimes".

It's probably not a path to maximum output. From the programming is basically a computer game perspective it has a lot going for it.

Lua is basically the same. An underappreciated feature of a language is never, ever having to look up the docs to know how to express your idea.

Post reply on HN