Live data from Hacker News

How to build apps pragmatically

alextoussaint.com

41–50 of 51 posts

Re: How to build apps pragmatically

#41
post #10

More often than otherwise, I’ve found code duplication preferable over abstraction. I only abstract code when I understand the problem space really, really well (I.e. have solved it before), or when I can have some certainty the wrong abstraction won’t cost me too much time to fix.

It does seem that this lesson takes at least a decade to internalize, and as such one can usually estimate the level of experience a person has based upon how much they embrace “DRY” as a hard rule vs a guidepost.

I've been programming for over 20 years, and I can't say I've ever regretted being too DRY. I'll take abstraction any day.

Re: How to build apps pragmatically

#42

> Try to build a complex server-rendered web app with PHP because "It's more inclusive" or "it has better frontend performance". See you in 2030. Like Facebook, WordPress and MediaWiki? Bashing PHP is a popular pastime, but front-end performance and inclusion are not to be scoffed at. Especially not if your target audience has a different standard of living than that of a major European city. Personally, I'm much mor…

> Like Facebook, WordPress and MediaWiki?

Yes, exactly. Facebook, Wordpress, and even MediaWiki have had man-centuries put into them.

If you want a polished result in less time, you should consider a different approach than server-rendered PHP for everything.

Re: How to build apps pragmatically

#43
I'd add from my experience: decide if you want to have a product at the end or learn something. I've tried a few times to "do this thing while also using X to learn about it". Every time I did learn about X. Rarely did I ever end up with the expected end product though (because learning and trying new things gets in the way of actually completing until I ran out of time/steam)

Re: How to build apps pragmatically

#44

why is this trash got submitted? author picked Django but trash talk PHP. Apple to Apple. shouldn't you compare Django to laravel? Wikipedia, WP, Facebook and countless other site/project have been build with PHP. so...like WTF? HN is going down in quality with trash like this.

> author picked Django but trash talk PHP. Apple to Apple. shouldn't you compare Django to laravel?

I understand that as exactly what was written. Plain old PHP is the old thing here. It could be a PHP vs Laravel comparison instead of PHP vs Django as well.

Re: How to build apps pragmatically

#45
post #14

More often than otherwise, I’ve found code duplication preferable over abstraction. I only abstract code when I understand the problem space really, really well (I.e. have solved it before), or when I can have some certainty the wrong abstraction won’t cost me too much time to fix.

It takes time to build the kind of self confidence and humility it takes to allow a code base to sprawl for a while until you've seen enough examples to have an idea where it's going. The first thing I like to do is solve the problem, period. Without inventing anything, just simply write code to cover most cases. Then I'll start improving on it in small ways, cutting down on duplication and inventing abstractions; un…

This. 1000x this.

Re: How to build apps pragmatically

#46

More often than otherwise, I’ve found code duplication preferable over abstraction. I only abstract code when I understand the problem space really, really well (I.e. have solved it before), or when I can have some certainty the wrong abstraction won’t cost me too much time to fix.

"duplication is cheaper than the wrong abstraction" i think i read that in POODR by sandi metz

Her book with Katrina Owen “99 Bottles of OOP” lays out an even better case for this I think. Particularly useful is the introduced language to help measure the state of a codebase (“shamelessly green” vs “incomprehensibly concise” etc).

Also quite like Fowler’s observation in Refactoring that (to paraphrase) abstractions are earned, not enforced.

Re: How to build apps pragmatically

#47
post #41
post #10

Earlier quoted context omitted.

It does seem that this lesson takes at least a decade to internalize, and as such one can usually estimate the level of experience a person has based upon how much they embrace “DRY” as a hard rule vs a guidepost.

I've been programming for over 20 years, and I can't say I've ever regretted being too DRY. I'll take abstraction any day.

Well, the pain you get from this is hard to peg as being due to over-DRYing, it manifests as bad abstractions, which are hard to trace the origins of.

Re: How to build apps pragmatically

#48

> Try to build a complex server-rendered web app with PHP because "It's more inclusive" or "it has better frontend performance". See you in 2030. Like Facebook, WordPress and MediaWiki? Bashing PHP is a popular pastime, but front-end performance and inclusion are not to be scoffed at. Especially not if your target audience has a different standard of living than that of a major European city. Personally, I'm much mor…

> Like Facebook, WordPress and MediaWiki? Yes, exactly. Facebook, Wordpress, and even MediaWiki have had man-centuries put into them. If you want a polished result in less time, you should consider a different approach than server-rendered PHP for everything.

Of course they've had lots of man-time poured into them: they've existed for a long time. But there were first versions of all of those, too, and first versions of tonnes of other complex server-rendered sites and apps.

Mocking inclusion and front-end performance is quite contradictory to "Use The Right Tool". There are several cases where server-side rendering has a place and there are several frameworks and approaches that help with the complexity, just like there are cases when client-side interactivity is a better choice and you can pick a framework that will help with performance and cross-browser issues - and complexity, which exists on the client side as well.

Re: How to build apps pragmatically

#49

why is this trash got submitted? author picked Django but trash talk PHP. Apple to Apple. shouldn't you compare Django to laravel? Wikipedia, WP, Facebook and countless other site/project have been build with PHP. so...like WTF? HN is going down in quality with trash like this.

> author picked Django but trash talk PHP. Apple to Apple. shouldn't you compare Django to laravel? I understand that as exactly what was written. Plain old PHP is the old thing here. It could be a PHP vs Laravel comparison instead of PHP vs Django as well.

Since when is PHP older than Python?
Post reply on HN