The Case for Slow Programming • Hacker News Board

Re: The Case for Slow Programming

#271

Post by notduncansmith » Tue, Dec 02, 2014, 2:43 PM UTC

sysk wrote: post #188

woah wrote: post #141

Earlier quoted context omitted.

I found go to be quite cumbersome in comparison to npm. Magic folders in the filesystem and such. With node you never have to do more than npm install and everything is ready.

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…

Hear, hear!

npm is without a doubt the best module system I've come across in my years of development. RubyGems is kind of a pain, .NET dependency management is a joke, Python is super fragmented, and Go doesn't have one. Godeps is an okay tool, and `go get` is cute, but I have yet to use a package manager that couldn't stand to borrow a thing or two from npm.

Re: The Case for Slow Programming

#272

Post by notduncansmith » Tue, Dec 02, 2014, 2:49 PM UTC

NateDad wrote: post #222

ploxiln wrote: post #208

Earlier quoted context omitted.

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…

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 app is behaving differently on their respective machines, only to fix the problem and unwittingly break another project in the most expensively subtle of ways.

I'd really like to think I'm missing something though, I certainly don't presume to be more insightful than the collective Go team.

Re: The Case for Slow Programming

#273

Post by rumcajz » Tue, Dec 02, 2014, 2:53 PM UTC

spacemanmatt wrote: post #246

rumcajz wrote: post #175

Earlier quoted context omitted.

Programmers are craftsmen. They need vocational schools. Academia is not up to the job.

Career vocational software craftsman here. Academic background in math and science have served me well as I self-taught all the CS and application development skills I have collected over the years. Vocational training probably would not have hurt, but I don't see how it could fit a traditional curriculum; I have only accelerated my pace of learning as the internet and quality of free tools and instructional material…

Well, what I wanted to say was that the "craft", i.e. skills learned when working on a real project with experienced developers, is something I use all the time. Academic knowledge less so. Take, for example, complexity theory. I use that once a day or even less. And in 95% of those cases I could just consult a simple cheat sheet (stuff like "sorting is O(n log n)").

Re: The Case for Slow Programming

#274

Post by UK-AL » Tue, Dec 02, 2014, 2:58 PM UTC

The main issue are not the developers. In my experience its the pressure the company puts developers under. Most developers would love to take time develop well designed software. But most companies push, push, push for more features in x time. The first thing that gets cut is design discusion and the ability to go back and improve old code.

The older the developer, the harder they are to push around(They've seen it all before, probably been a manager before) and probably why we have a agist industry because companies like developers they are easy to manipulate.

Re: The Case for Slow Programming

#275

Post by benihana » Tue, Dec 02, 2014, 3:00 PM UTC

>This is why I believe that we need older people, women, educators, and artists

Remember, if you're a young man, or you don't have the title of artist or educator, you're obviously not a people person and you're fucking up software, shitlord.

Re: The Case for Slow Programming

#276

Post by ncphillips » Tue, Dec 02, 2014, 3:05 PM UTC

This is exactly how I work. It can seem a slower when you tell your boss you just scraped everything to start over, but it's actually super efficient. It never takes nearly as long to rewrite an application. On my latest proejct for example, I took 1 week to think about the problem and play around with different data schemas, then I spent 3 weeks writing the program. It worked well enough, but there were a lot of holes, and it was a god damn mess to read.

I rewrote the entire project in two days. That's right, what took me 3 weeks of playing around only took me 2 days the second time around, and it was well worth the effort. The refactoring increased security tremendously, and made many parts of the code so much cleaner and readable it brings a tear to my eye.

What's even more important is that I was able to easily add new functionality which would have taken a lot of effort to implement because of the way things were written before. Had I left things the way they were, or tried to refactor without a complete rewrite, I would have just introduced more bugs and got really frustrated.

Re: The Case for Slow Programming

#277

Post by petepete » Tue, Dec 02, 2014, 3:08 PM UTC

m0nastic wrote: post #54

I hesitate to recommend my process to other people, because I don't think I'm a very good programmer. But for the past year or so, I find that I program best by actually writing out my program in a notebook (in my case a quad-ruled lab notebook). I don't even start typing until I have it laid out pretty much in it's entirety on paper. This sounds ridiculous (and I can imagine it's not practical for all types of progr…

This is the way I work too. I don't handwrite pseudocode, but I draw data structures and relationships in varying degrees of granularity at least until I'm sure I understand the problem. Only then do I begin writing tests and coding.

Re: The Case for Slow Programming

#278

Post by lectrick » Tue, Dec 02, 2014, 3:09 PM UTC

jsilence wrote: post #180

rapind wrote: post #168

Earlier quoted context omitted.

I now love german culture. It's like finding my soulmate.

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.

Re: The Case for Slow Programming

#279

Post by ep103 » Tue, Dec 02, 2014, 3:16 PM UTC

Argorak wrote: post #45

wellpast wrote: post #22

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. Our goal is architectural soundness. I believe the biggest fallacy of our industry is we think the only way to get these is to go "slow". Not true. What we're really saying…

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

This is pronounced like zoo Gig?

Re: The Case for Slow Programming

#280

Post by klibertp » Tue, Dec 02, 2014, 3:20 PM UTC

dschiptsov wrote: post #254

aercolino wrote: post #217

Earlier quoted context omitted.

Yes, someone in another thread is discussing about skill sets to be learned to engineer software, but I think academy already does a decent job. To engineer a good architecture you need time to thoroughly think and explore alternatives. Coupled with deep field knowledge and an even deeper know how, gained by means of experience. And to build the best is impossible by definition: you can only hope to build a better on…

That's why, perhaps, in pre-Java era, in good schools they taught "big ideas in CS" instead of Java syntax and how to OO everything. Algorithms, Data Structures and reasoning behind them, Scheme courses of CS basics (based on SICP) and Operating Systems, so a student could understand the principles and design decisions. Then such student could code in any language, because syntax and common idioms are much less impor…

> I know syntax of about dozen languages, but I am inferior programmer due to lack of appropriate theoretical background. I could spent days trying to figure out, should a request be a closure or an assoc or this fancy but costly "persistent-map", and these nuances like aliasing and locality in Clojure and CL.

I have a deep understanding of various areas of CS and maths and I never resort to "Ctrl-C/Ctrl-V" to get things I don't understand done. I rather spend enough time to understand them. Every. Single. Time. Ah, and I didn't attend a university almost at all.

You could do the same, you know? If I could learn all of this, without any help from friends or from lecturers or from senior programmers (until very late in my learning), basically with books alone (from a library - that was before the Internet!), then you could have done this easily. But you didn't and now you're whining and shifting the blame and making others responsible for your personal failure to learn.

Really, stop that and start learning for yourself, it's not too late!