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

Your code may be elegant, but mine works

omniti.com

Post reply on HN
Print view View original

91–100 of 174 posts

Re: Your code may be elegant, but mine works

#91

Post by courtf »

frenchy wrote: post #70
MrZongle2 wrote: post #24

My code might not be that elegant, but it's maintainable . I've followed "hey, it works" developers who knocked out functionality quickly. Their by-product was Lovecraftian code.

This is a far better metric. Elegance, while a worthwhile goal, is at its best a vague notion and at its worst, a guise for all sorts of leaky abstractions.

I adore elegance, but over time have come to understand that edge cases tend to creep into those "leaky abstractions," and you can find yourself unraveling things, at least partially, in order to solve bugs.

There's no shame in this IMHO, and lots of very good programmers have to add inelegant shims to solve specific edge cases. I enjoyed reading this article (previously linked on HN by another) which I think has some relevance here: http://www.gigamonkeys.com/code-reading/

Re: Your code may be elegant, but mine works

#93

Post by bnegreve »

lostcolony wrote: post #31

I live by a comment Joe Armstrong made on this (from Erlang and OTP in Action): "Make it work, then make it beautiful, then if you really, really have to, make it fast." (The quote continues "90 percent of the time, if you make it beautiful, it will already be fast. So really, just make it beautiful!")

> 90 percent of the time, if you make it beautiful, it will already be fast.

In fact, I disagree with this. The reason is that "elegant" usually means "decoupled" whereas many optimizations actually consists in "recoupling" to take advantage of special cases or to share resources among various decoupled objects.

Designing software to be fast and elegant is actually quite challenging problem. Of course, that makes it even more interesting.

Re: Your code may be elegant, but mine works

#94

Post by Ologn »

> "You hate testing!" 

I started working as a Unix sysadmin in 1996, and while I have always written programs, and have been doing so more heavily lately, I never wrote a program with someone else before. All of my programming has either been programs completely written by me, or small patches sent to existing open source projects. The purpose of testing aside from the most rudimentary always eluded me.

A few months ago I wrote my first program along with a good, professional programmer. I would code, he would code, I would code. He was good, but I noticed some of his changes would break my code. It occurred to me that testing is something of a communication device. I create functionality, I implement the test, then I tell other commiters to run the test suite before commiting code. If the tests do not complete, they know their code will break functionality I made.

I guess this is obvious, but when I read top reasons to do TDD etc. it is usually not mentioned as a prominent reason to do testing, if it is mentioned at all. I do not find tests beyond the most simple kind helpful in my code, but it starts becoming more useful when you have other people modifying the code.

Re: Your code may be elegant, but mine works

#96

Post by jarrett »

Edmond wrote: post #59
fennecfoxen wrote: post #37

Earlier quoted context omitted.

It's also worth noting that he's talking about things like "if your client needs a Christmas promotion and you deliver on Dec 29". This sounds about right. But if you're in a time-sensitive situation and your code will only be used for a brief period of time, your business needs are probably very different than a code-and-maintain-forever situation (e.g. a SaaS offering). I am currently developing and maintaining a s…

> But if you're in a time-sensitive situation and your code will only be used for a brief period of time, your business needs are probably very different than a code-and-maintain-forever situation (e.g. a SaaS offering). I think this captures the central problem in our current software development state of affairs. Because as developers we are stuck with primitive tools that make doing even trivial stuff time consumi…

This is a problem, and I've long mused over possible solutions. Every time I think about it, I come to the conclusion that the solution isn't a new approach to software engineering, a new language that blows away every paradigm, some abstraction that promises to make app development simple, or any other silver bullet.

Indeed, the only "solution" I see is a solution in just the loosest sense. Namely: We continue incrementally improving languages, frameworks, libraries, and coding practices--a process that has been going on since software began. That's a disappointing answer, but I think it's the only answer, and I'll explain why.

The complexity of the tools we use is a result of their great flexibility and power. For example, a Ruby on Rails app is a huge agglomeration of technology, including HTML, JavaScript, jQuery, CSS, SCSS, Ruby, the Rails framework, and usually a number of other, project-specific technologies. All of these technologies must be learned (no small task), and their quirky interactions with each other must be managed. One sometimes thinks, "There must be a better way! There must be some abstraction that can hide all this technology." But I challenge anyone to design such a thing.

Each of those technologies is mature. Each one has had tremendous effort put into designing the simplest possible API without sacrificing power and flexibility. Even technologies with a lot of baggage, like HTML, CSS, and JavaScript, have seen substantial improvements in recent years. Given that, does anyone think they can do better? Can anyone do everything these technologies do and present a radically simplified API? Remember, you can't sacrifice power and flexibility and just support the most common use cases. Almost any application will need at least one thing that's unique or idiosyncratic.

This is why people use Rails (or similar tools) for custom apps instead of Wordpress. Wordpress has many off-the-shelf plugins that provide commonly-needed features. From a site maintainer's perspective, Wordpress abstracts away most of the complex web programming inherent in those features. But for serious app developers, that's almost never good enough. The plugins never seem to work exactly as you need them to, and they rarely talk to each other the way you would like. A short ways into the project, you're forced to either hack up your plugins, which is a maintenance disaster, or code your own plugins, which means you're really just using Wordpress as an inferior Rails substitute.

Re: Your code may be elegant, but mine works

#97

Post by Gracana »

kyberias wrote: post #55
nateabele wrote: post #45

I used to work at OmniTI. The real irony of this article is that it was written by a guy who's (in)famous for his indecipherable Perl one-liners. I think that's about all that needs to be said.

> I think that's about all that needs to be said. Yeah, and that's like a perfect definition for "ad hominem" argument.

No it's not. If the author's methodologies result in undecipherable code, that's quite relevant to the discussion.

Re: Your code may be elegant, but mine works

#99

Post by dsrguru »

varjag wrote: post #36
ninjac0der wrote: post #16

... and as expected, it's always the manager, not coding types that state this so aggressively. I know the servers are beefy at OmniTI, so I suspect there might be a code problem related to handling the load. If I see sloppy code, or have to write sloppy code, I move to another company, and will continue to do so. So how's that employee turnover rate (hint, use the internet archive and check the about us page)?

I am a coder type, and I mostly support the sentiment. Over the years, I gradually drifted from doing things the Right Way to doing things that are good enough. Doing things elegantly in practice unfortunately adds zero flexibility for non-trivial changes in business direction: you simply can't foresee everything. One swift decision at mid-management level and your elegant framework suddenly becomes an unwieldy Titan…

> Doing things elegantly in practice unfortunately adds zero flexibility for non-trivial changes in business direction: you simply can't foresee everything. One swift decision at mid-management level and your elegant framework suddenly becomes an unwieldy Titanic impossible to put into a quick turn.

Yes and no. If you're writing very elegant statically typed functional code like in Haskell or ML, you're going to have to be elegant at the design level, and yes, you might have trouble adapting to new requirements. But if you're in a domain where requirements aren't always set in stone, you're probably using a more dynamic environment where you don't have to be what the OP called "elegant" at the design level (e.g. his unrealistic caching layer example), but you can still write elegant code at the micro level (within functions, classes, etc.), which will almost certainly lead to substantially less technical debt and shouldn't cost much if any more time than quick hacks at the micro level.

Post reply on HN