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

The Case for Slow Programming

ventrellathing.wordpress.com

Post reply on HN
Print view View original

331–340 of 346 posts

Re: The Case for Slow Programming

#331

Post by edpichler »

GFK_of_xmaspast wrote: post #253
edpichler wrote: post #108

Really liked this part: " And the latest clever development tools, no matter how clever, cannot replace the best practices and real-life collaboration that built cathedrals, railroads, and feature-length films."

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.

Re: The Case for Slow Programming

#332

Post by NateDad »

notduncansmith wrote: post #272
NateDad wrote: post #222

Earlier quoted context omitted.

Go's model is pretty good. This is why there's just a single $GOPATH and every package has exactly one location on disk, so even if 100 dependencies use the same subdependency... you only have to update one spot if it needs a patch. And again, this only needs to be done at development time. It's baked in when you compile, and from there on, deployment is just a file copy of your binary. No dependencies during deploym…

Maybe I'm missing something, but this seems like a bad idea to me. What if projects are relying on differing versions of the same package? What if two developers collaborating on the same project have different versions of that dependency installed? Sure, it's space-efficient, but disk is cheap, and developer hours are expensive. I certainly wouldn't want two employees burning man-hours trying to figure out why some…

So, in theory, any particular import path should be stable. There are no "different versions" of the same import path. A different version would be a different path.

So, for example, github.com/natefinch/lumberjack is an import path. When I wanted to change the API, I have to put my project at a different import path so I don't break projects that use this version. I could just make a new github repo called lumberjack-v2 and that would work fine.

Of course, reality and theory don't always see eye to eye, and the Go community realizes this. That's why there are several community-made tools to help out.

The most well-respected one is godep, which has the ability to pin revisions on your dependencies. That is, it'll look at the git commit hash (or equiv for hg/bzr/svn) for every repo that you depend on, and record it in a file in your repo. It can then reset those dependencies to those specific hashes. Then all members of your team just need to use godep to make sure they're all using the exact same git commits for all dependencies. Bam - now you're insulated from someone updating a dependency with breaking changes, and your team can test new revisions and decide when they want to start using them.

Godep has a second function that lets you copy all your dependencies into your repo and renames all import statements to reference the copied paths. This is an even more extreme version of the above, which not only insulates you from changes in dependencies, but also insulates you from those dependencies disappearing entirely.

Re: The Case for Slow Programming

#333

Post by natefinch »

simplify wrote: post #264
NateDad wrote: post #58

Earlier quoted context omitted.

Try Go, seriously. There's just the one tool. No package manager, no dependencies... And the code it produces is the same. Just a binary. "Here, have this tool, just run it." It's small, simple, and the community actively searches out simple solutions.

No package manager or dependencies seems strange. What would you call all the projects on this page? https://code.google.com/p/go-wiki/wiki/PackageManagementTool...

There's no required package manager. By default, your VCS is your package manager. You can write code for a long long time with just the default go tool. Those are optional tools that you can use once you become comfortable with the language and understand their tradeoffs. You really don't need any of those tools until you want to write a professional project with multiple people on a team.

Re: The Case for Slow Programming

#334

Post by lmm »

einhverfr wrote: post #324
lmm wrote: post #226

Earlier quoted context omitted.

> I threw together a form builder by re-purposing old code from a side project that took me two years to polish. My proof of concept let an admin change guidance on the fly, without touching HTML. Fields could be re-sequenced, data types changed. Business rules could be linked to fields dynamically, and applied to single fields or entire form sections. Data was saved to a SQL Server (already in wide use in the estate…

First, I sympathize with your reaction against building in functionality that is not required. This typically causes a lot of problems. However, for a library, that is less of an issue because you aren't maintaining it. It sounds to me like the guy used what was essentially a library he had previously developed to do this and that's a step towards having the flexibility in the right place. > Why would your way have b…

> My largest open source project does a lot with database stored procedures. We use all the tools you mention above, and we have written some of our own tooling to make that easier. So I don't think there is any reason why those tools don't work. So you have to spend a little time on tooling? That gets paid off many times over.

Programming logic in the database, or config files, is a huge antipattern I've seen many times. People seem to have this huge blind spot where you can take the exact same piece of logic and label it "code" or "not code" and in one case it will be subject to review and signoff and all that and in the other it won't be.

You can always write your own programming language and tools, but you're unlikely to do better than the existing ones. So why not just use one of them?

Re: The Case for Slow Programming

#335

Post by jsilence »

lectrick wrote: post #278
jsilence wrote: post #180

Earlier quoted context omitted.

Please note that another german culture is to be overly pedantic in following rules, no matter if their initial intention applies or whether we just set them five minutes ago. Rules are followed because. This culture makes administrative processes bulky and tedious and tiring. It often fuels my Ungeduld, because I want to get s t done zügig.

Sounds like an opportunity to convert all the paperwork to some kind of IT-powered workflow.

First you'd have to file all the neccessary application forms for a project like that. Good luck! ;-)

And even if you succeed, in the end there'd be a rule that requires the Pdf to be printed, signed, copied, filed, scanned and filed again, digitally.

Re: The Case for Slow Programming

#336

Post by JackFr »

thaumaturgy wrote: post #60
JackFr wrote: post #14

He makes a reasonable point, but this piece is largely a strawman. And > For the same reason that many neuroscientists now believe that the fluid-like flow of neuronal firing throughout the brain has a temporal reverberation which has everything to do with thought and consciousness, good design takes time. is just pure nonsense.

> but this piece is largely a strawman In what way?

> As long as everyone makes frequent commits, and doesn’t break anything, everything will come out just fine.

He is presenting the arguments and beliefs of his intellectual opponents in a way they probably have not or would not, and then attacking that argument.

Now in a piece like this there is nothing wrong with that -- but in terms of the strength of an argument, it is no greater than just enthusiastically stating his preference.

Re: The Case for Slow Programming

#337

Post by kendallpark »

bitwize wrote: post #285

Here are my Reddit comments on this story: I've always programmed thus: * Try to assimilate a mental model of the bit I'm working on, and as much of that bit's dependencies as is practical, into my head. This may involve fiddling with the code and seeing how it breaks when I do certain things to it, or hammering at it inside a REPL or similar. The bit that I'm concerned about could be a single method, but is usually…

This, exactly.

When DHH lambasted TDD at Rails Conf earlier this year I felt vindicated. TDD enthusiasts market the practice like TDD is a one stop shop for better code. Fad diet style. IT WORKED FOR ME, IT'LL WORK FOR YOU. THIS ONE WEIRD TRICK WILL GET YOU PROGRAMMING BETTER.

I think TDD works great for certain personality types. Definitely not mine. (I'm like you, as far as I can tell.) I find that writing tests first inherently makes assumptions about the shape of the code that I'm going to write. I so often zoom out and say "no, no, no, I'm going at this all wrong" and completely change the way I'm structuring my code. If I've written test-first, then that's two places (my code and the tests) that I need to completely redo the structure. And 2x the programming time for refactoring.

I will advocate TDD for debugging. Test-first is wonderful for isolating software bugs and resolving them.

Re: The Case for Slow Programming

#338

Post by notduncansmith »

NateDad wrote: post #332
notduncansmith wrote: post #272

Earlier quoted context omitted.

Maybe I'm missing something, but this seems like a bad idea to me. What if projects are relying on differing versions of the same package? What if two developers collaborating on the same project have different versions of that dependency installed? Sure, it's space-efficient, but disk is cheap, and developer hours are expensive. I certainly wouldn't want two employees burning man-hours trying to figure out why some…

So, in theory, any particular import path should be stable. There are no "different versions" of the same import path. A different version would be a different path. So, for example, github.com/natefinch/lumberjack is an import path. When I wanted to change the API, I have to put my project at a different import path so I don't break projects that use this version. I could just make a new github repo called lumberjac…

Godep is definitely a good tool. One thing that gives me pause, though, is that this functionality is not built into `go get`. Failing to put hard versioning into the canonical package manager seems short-sighted to me. I'd much prefer that over something like the race detector.

Re: The Case for Slow Programming

#339

Post by sysk »

ploxiln wrote: post #208
sysk wrote: post #188

Earlier quoted context omitted.

npm (and the CommonJS module system) is the #1 reason I use Node.js. I don't care if Javascript is ugly, npm totally makes up for it. I don't get why most module systems implicitly import symbols in the scope (Python, Ruby) or worse, those that pollute the global scope (PHP). Brew (Ruby) is not that bad but Python's package ecosystem is a complete mess (distutils, setuptools, pip, etc.). Cabal (Haskell) is pretty goo…

npm is easily the worst. Python is a lot better. I hold the C library model as the golden standard, so we're not going to see eye-to-eye. The worst part of npm is the sub-dependencies. Having enabled them, they proliferate endlessly. Each time I improve the efficiency of deploying a strictly controlled tree of modules, the front-end devs manage to double the number in use. 200, 350, 650, over 1000... oh and these imp…

We definitely have a philosophical disagreement. The fact that an app (especially a server side one where storage is usually cheap) has hundreds of dependency signals to me that the package system is successful. It tells me that there is a lot of code re-use going on and that it's presumably easy to import new dependencies. By now, I believe the number of NPM packages outnumbers any other package manager by far despite being relatively new.

So basically, I think your point is that a project should have as few dependencies as possible whereas I think the opposite is good. Both philosophies have their pros and cons. If you are writing mission critical software that handles financial data, it's probably a good idea to know about every line of code that gets executed. However, if your goal is to release something as fast as possible, have a more manageable code base and security is not as critical, using lots of dependencies makes sense.

Re: The Case for Slow Programming

#340

Post by lonelybug »

I don't understand why so many software developers/engineers believe engineering without design is a good practice.

Maybe you should read this article http://martinfowler.com/articles/designDead.html.

Martin fowler is one of the people draft the manifesto for agile software development.

If you still call yourself software engineer, then, remember agile != no design.

Post reply on HN