The Case for Slow Programming • Hacker News Board

Re: The Case for Slow Programming

#341

Post by glurgh » Thu, Dec 04, 2014, 9:31 AM UTC

dang wrote: post #329

glurgh wrote: post #328

Earlier quoted context omitted.

You're not really stacking your long-run odds any more than you're stacking your odds by playing the lottery a lot. The odds are stacked in favour of anyone who submits a lot and submits early rather than in favour of someone who submits well.

I'm not sure what you mean by submitting "early", or what experience you're drawing on here (your account has submitted zero stories!), but am pretty sure that the odds favour a user who submits a lot that is good [1] and that the latter is where the emphasis should be. We're also working on systems to amplify this effect, so it is going to get more true with time. The point as far as karma goes is not to be attached…

I guess I just found the response "submit more, it evens out in the end" a bit glib (as is, 'your account has submitted zero stories'). I do have some experience submitting stories as well as plenty of just reading and commenting on the site. It seems to me the current system amplifies negative tendencies like being 'first to post' or reposting variants of the same story.

I'm perfectly happy to take your word that you're working on something better.

Re: The Case for Slow Programming

#342

Post by GFK_of_xmaspast » Thu, Dec 04, 2014, 12:33 PM UTC

edpichler wrote: post #331

GFK_of_xmaspast wrote: post #253

Earlier quoted context omitted.

Historically, cathedrals might stand unfinished for decades at a time. Also the early days railroads were famous for brutally exploiting labor in order to get built as soon as possible. Haven't you heard of John Henry?

I haven't heard of him. I did not understand you. It seems you believe there isn't collaboration to build cathedrals, railroads, and feature-length films.

Of course not. What I'm saying is that these are very much not examples of well-run projects that aren't exploitative of labor.

Re: The Case for Slow Programming

#343

Post by dennisgorelik » Fri, Dec 05, 2014, 8:17 AM UTC

robert_tweed wrote: post #191

Argorak wrote: post #45

Earlier quoted context omitted.

> I largely agree w/ the argument here, but "slow" is going to be self-defeating nomenclature, and is also inaccurate. Business doesn't want slow. So if we're pitching slow, we're setting ourselves up to lose and the speed-hackers are going to win. German has a very nice word for that: "zügig". It means "speedy" as well, but goes a bit towards "stable", "steady" and "friction-free". It's the good kind of fast, which…

I like this word, we should adopt it. It says a lot about the German mindset that they have a word for this. I don't think English has any equivalent (but it's a big language so I wouldn't be surprised to find out I'm wrong). We do have a very similar and pretty common idiom though: "slowly-but-surely", often used in the phrase "slowly but surely wins the race". This of course comes from The Hare and the Tortoise in…

https://translate.google.com/#auto/en/z%C3%BCgig zügig -> swift

Re: The Case for Slow Programming

#344

Post by the_why_of_y » Sat, Dec 06, 2014, 11:28 AM UTC

aoakenfo wrote: post #61

A flurry of hacks tends to beat the "correctly designed" way: http://www.jwz.org/doc/worse-is-better.html

"A flurry of hacks" indicates you did not understand worse-is-better:

http://www.dreamsongs.com/Files/worse-is-worse.pdf

"This advice is corrosive. It warps the minds of youth. It is never a good idea to intentionally aim for anything less than the best, though one might have to compromise in order to succeed"

Re: The Case for Slow Programming

#345

Post by the_why_of_y » Sat, Dec 06, 2014, 11:53 AM UTC

EdSharkey wrote: post #320

angersock wrote: post #298

Earlier quoted context omitted.

BeOS !== NextSTEP http://en.wikipedia.org/wiki/BeOS

I brought up NextSTEP because it was a notable success that was not mentioned by the parent comment. And arguably, NextSTEP is a success story because of its design which enabled it to crossover successfully into mobile through iOS. NextSTEP's blueprint allowed iOS to operate at a performance level that other OS'es and architectures could not match when it debuted. BeOS was fine, but it was rightly or wrongly seen as…

Agree with you that NextSTEP is well designed (at least in the upper layers, not necessarily the Mach-based kernel...) but the reason why it succeeded where BeOS failed are not technical: BeOS failed because of network effects (market too small for ISVs) and Microsoft actively preventing OEMs from installing it, and NextSTEP avoided both of these problems by being bought by Apple.

iOS is not really running on a "resource-constrained" platform; the first iPhone already had 128MB RAM, which was a lot of RAM for a PC in 1999, in particular considering the low screen resolution. Apple just got the timing right; the mobile hardware became powerful enough to run "real" OSes (instead of things like Symbian or WinCE that were actually developed for resource-constrained hardware) around 2005.

Re: The Case for Slow Programming

#346

Post by eropple » Mon, Dec 08, 2014, 5:44 PM UTC

4ydx wrote: post #262

eropple wrote: post #190

Earlier quoted context omitted.

Simplicity for simplicity's sake isn't a virtue. I often feel that Go chooses that path ideologically, whereas real world use cases should have more innings (yes, it's the generics and shitty type system thing again, I'm not expecting us to agree, I'm just pointing it out). To that end, Go doesn't work for me. I use a fairly straightforward stack atop the JVM because I can hold the whole thing in my head (nothing in…

And the issue isn't so much whether or not a programmer can hold the "entire system" in their head so much as, if they don't need to, they can be doing a whole lot more. This is, after all, what computers are good for.

I can do a lot more when I can trust my system to evaluate my code and throw compile-time errors. I can't trust Go's you're system in the same way I can Scala.

I noted the simplicity of the stack mostly to forestall the usual tired complaints about complexity, nothing more. What you call "academic", I call "building at scale."