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

Going Fast Slowly

varnish-cache.org

Post reply on HN
Print view View original

51–60 of 77 posts

Re: Going Fast Slowly

#51

Post by draw_down »

jacquesm wrote: post #37
draw_down wrote: post #6

Earlier quoted context omitted.

Dijkstra wrote that in 1988. Things change. The prevailing wisdom changes over time. Is anybody really proudly counting lines of code at this late date? Is there anyone out there who doesn't love an all-red diff? Is there anyone who really thinks the prolix version of a function is better than the concise one, all else equal? Who is getting paid by line of code, or has to meet a a quota of LOC?

The hell it does. Dijkstra's words are as important, if not even more important than when they were first written. The whole problem is that we keep re-inventing the wheel and all associated problems over and over again. We never put the lessons learned the hard way to practice in the long run. New generation -> rinse, repeat.

I get that you have axes to grind, but that all doesn’t actually have anything to do with what I was talking about, which is essentially that nobody thinks “lots of lines of code” is a good thing anymore.

I work in a startup full of twentysomethings. None of them have read “Mythical Man Month” but they all know the bit about how adding engineers to a late project makes it later. It takes time, but these things find their way into the conventional wisdom.

It’s not 1988 anymore. Not everything changes, but some things do.

Or do you think we all still need to be reminded that “goto” is bad and we shouldn’t use it?

Re: Going Fast Slowly

#52

Post by jacquesm »

jeremyjh wrote: post #50
jacquesm wrote: post #40

Earlier quoted context omitted.

It's an APL compiler, written in another APL dialect, which is about as dense as you can get in terms of lines-of-code. APL is one of the few really high level languages.

It looks like a lot of the lines of diffs are to HTML/XML files related to the certification of the code, rather than executable code. So, definitely not very dense. https://github.com/Co-dfns/Co-dfns/commit/78d0e38f8ba2e1de9f...

Looks plenty dense to me:

https://github.com/Co-dfns/Co-dfns/blob/master/cmp/a.cd

Re: Going Fast Slowly

#53

Post by kevinb7 »

I wonder if this project, at least VCL compiler part of it, could've benefited from the use of a parser generator. I understand going slow, but using a parser generator would've allowed for faster development of VCL freeing up time to add more features so it isn't so hard to write for.

Re: Going Fast Slowly

#54

Post by thaumaturgy »

jamesb93 wrote: post #33
thaumaturgy wrote: post #28

Earlier quoted context omitted.

Software-as-art has lost a lot of ground to software-as-business, and in software-as-business, somewhere up the chain there is a management-level individual who isn't really sure how to measure either progress or code quality. There are myriad tools designed for these people though, and they all chose the simplest (and wrong) solutions to the problem: progress is SLOC added and bug reports clsoed per day. The height…

Do you have any suggested reading around software as art vs business? You pretty much began to articulate the things I've been thinking about lately.

I wish! If there's a good book out about it, I'd love a recommendation too. I lived it though, writing my first "software" as a youth in the mid-80s. I've seen a lot of change in computing. And not all "get off my lawn" bad, just different.

I see software now as having three different faces: software-as-art, software-as-business, and software-as-engineering. The 80s and 90s had a lot of activity in software-as-art. I was mostly following Mac culture at the time, so I saw this through Bungie, Ambrosia, BareBones, and hundreds of smaller indie developers. The environment at the time enforced the software-as-art discipline, because downloading a program happened over 14.4kbps or slower, or 28.8kbps if your parents had good jobs, and came along with yelling that often sounded like, "get off the phone!" "But I'm downloading!" Installation media was 700K or 1.4MB, and that had to have all your code, art, sound, and other resources.

That's mostly all gone now. Bungie of course got married to Microsoft, which pissed off Mac enthusiasts way more than when Jobs announced a partnership with MS to get Office on the Mac. They've done well. Panic are the only old-school indie commercial desktop software developers I can think of off the top of my head that are still pretty true to their roots.

A lot of software of course just became free. I enjoy so much more high quality software at no cost now, which is really only possible because of the massive benefits of scale that have come from all the tools that have trickled down from software-as-business.

Software-as-business really took off. Apple, Microsoft, Sun, Oracle and others were always kinda big, but not the impossibly large megacorps that they are now. Most of them were still vulnerable to serious mistakes, and that was good, because it meant the users still had some power. Now, mistakes in software development don't really matter to these companies unless they impact 8 figures of quarterly revenue, and that's a process that has zero room for software-as-art.

Software-as-engineering is mostly stillborn, languishing in academia or a few places with rigorous standards (like NASA) or still finding its footing in modern DevOps. I still hold out hope that eventually this aspect will get some love too. I think it will be necessary, eventually, but maybe not until after I've written my last line of code.

Re: Going Fast Slowly

#55

Post by 0xCMP »

pdonis wrote: post #2

From the article: "I no longer think about code lines as an asset to be accumulated, but rather as an expenditure to be avoided." The obvious Edsger Djikstra reference: [I]f we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. http://plasmasturm.org/log/linesspent/

I like lines-spent as a measure, but I wish I could figure out a hybrid measure which didn't hurt lines which confirm/narrow the state space (such as the "unnecessary asserts to show programmer intent").

Somehow being able to distinguish this would help avoid insanely complicated code (of which usually can be much, much simpler), but doesn't encourage anyone to literally ignore all error checking and do everything as some kind of chained-single-line-expression abomination [1].

[1] Something I often see in functional JS and regular python from time to time.

Re: Going Fast Slowly

#56

Post by nineteen999 »

jacquesm wrote: post #38
nineteen999 wrote: post #30

> This is why Varnish is written in "pidgin C" style and lousy with asserts which don't do anything, except clarify programmer intent, and in case of mistakes, stop bad things before they get out of hand. Today I learned a new name for my C coding style.

'Assert early and often'. Check your assumptions all the time, nine out of ten times that's where your bugs will hide.

My C programs always start as a few skeleton .h files with include guards, and a few .c files that are basically an ever growing list of asserts() on any pointer to a structure or variable, or on any value where it is expected to be within a certain range.

Gradually I feed my structs and typedefs into the .h files and replace the asserts with (hopefully) working code.

Re: Going Fast Slowly

#57

Post by jeremyjh »

jacquesm wrote: post #52
jeremyjh wrote: post #50

Earlier quoted context omitted.

It looks like a lot of the lines of diffs are to HTML/XML files related to the certification of the code, rather than executable code. So, definitely not very dense. https://github.com/Co-dfns/Co-dfns/commit/78d0e38f8ba2e1de9f...

Looks plenty dense to me: https://github.com/Co-dfns/Co-dfns/blob/master/cmp/a.cd

Yes, the code is dense, but changes to it don't make up most of the lines of diffs, and I really doubt the XML making up the diffs is edited as text; its a tool or generator.

Re: Going Fast Slowly

#58

Post by zbentley »

bovermyer wrote: post #11
lucideer wrote: post #9

Earlier quoted context omitted.

Chiming in to say I agree with the sibling (dead) comment (not sure why it ended up dead). Djikstra's words (and the article's) are clearly correct, but hardly revolutionary or contrary to modern belief today. The real question is: why, despite a prevailing belief in modern software software engineering that red diffs are beautiful and cathartic things to be celebrated, and that the great spectre of technical debt is…

Because technical beauty is not the only metric measured by businesses.

> technical beauty is not the only metric measured by businesses.

technical beauty is not the only^M^M^M^M^M^M^M^M a metric measured by businesses.

Re: Going Fast Slowly

#59

Post by p1necone »

josephg wrote: post #47
bt848 wrote: post #20

10 LOC/h is spectacularly good over a long time period. Congratulations, from a varnish user. I recently tried to set expectations in a coding interview that was scheduled for 3 hours. I told them that was enough time to read the spec, develop a simple test case, and begin or possibly complete an implementation of part of the spec. I also told them that I wasn't interested in a shop that hired people based on their a…

I've been doing tech interviews professionally for a large tech interview platform that you would have heard of. We have a timed coding challenge, but code quality is something we explicitly look for. Making slow but steady process with good testing is a great signal for us too, even if they don't get very far through our challenge within the allocated time. That said, occasionally we have people who work very quickl…

I hope it's communicated that they're not expected to finish. If I was given a coding challenge with a time limit I would assume I was expected to finish inside the time limit and make any sacrifices that needed to be made to achieve that - including ignoring testing and hoping I just don't make too many mistakes.

Re: Going Fast Slowly

#60

Post by iamaelephant »

jchook wrote: post #3

“Slow is smooth, and smooth is fast” Old military saying that I repeat often because I have relearned so many times that shortcuts cause more work (read: problems and rigidity) in the long run. Choose one: get it done right, or get it done right now.

In motorcycle racing there's the phrase, "a fast rider has slow hands".
Post reply on HN