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

Programs should be Small

mkhadikov.com

Post reply on HN
Print view View original

51–60 of 75 posts

Re: Programs should be Small

#51

Post by meaty »

gruseom wrote: post #48
meaty wrote: post #20

I love all these articles which are wholly ignorant of how complex software is in reality and how such advice isn't necessarily good. Sometimes decomposition results in problems at the other end of the scale such as communication performance, data duplication, extremely nested abstractions, messaging complexity, contract and API versioning hell etc. Getting the sweet spot between monolithic coupled blobs and fragment…

[Edit: deleted pointless bit here.] If your comment consisted simply of its second and fourth paragraphs it would be better in every way and you would have contributed something of value.

I've read a thousand versions of this blog post over the years. It's decidedly abrasive as I'm tired with reading it to be honest. There is nothing new to be added to the discussion apart from people blindly falling over the same point, which is ignorant and not very well thought out and is not based on reality.

Apologies if you are personally offended, but my point still stands.

Re: Programs should be Small

#52

Post by abecedarius »

bnegreve wrote: post #10
moe wrote: post #4

A good program is 500 lines or less.

Wow, it seems rather arbitrary. Can you elaborate?

In 500 lines you can write a self-hosting compiler, a checkers AI, a usable text editor, a compiling-to-DFA regex matcher, Bayes net inference, or a ray tracer, to mention the first examples that come to mind. (Ordinary lines, not golfed.) Most programs aren't so polished, but when yours gets 10 times longer than a Lisp compiler, it's worth asking why.

Re: Programs should be Small

#53

Post by vanwaril »

bitwize wrote: post #46
mimog wrote: post #37

Isn't this "the Unix way"? I have seen this style of small cohesive programs promoted a lot in Linux/Unix literature so the advise isn't really breaking any new ground. Look at git for instance. The advise is of course sound but it goes against the "enterprisy" way of doing things, in part because they tend to be using huge frameworks from the get go.

It used to be. It may still be if you hang out on #suckless. But most of the Linux folks these days love their huge monolithic PulseAudios and systemds.

And why would you say systemd is monolithic? Have you looked at the source-code for it? Have you looked at how services are configured with it? I would argue its far more modular than sysVinit.

Re: Programs should be Small

#54

Post by vanwaril »

xrt wrote: post #40

Beyond complexity management, breaking a design into many small programs opens it up to a rich set of well-known and proven OS services. Things like hardware memory protection, multi-processor support, queues, mutexes, monitoring, and cross language support. I'll take Unix over some language+standard library _any day_.

and it also opens it up to a rich set of well-known problems: sharing between processes and memory management, lock issues, system-call latencies, not to mention dealing with the monolithic environments that are almost definitely changing between each instance of your program you want to run (this 'environment' includes the shell, userspace services, kernel version and features...). Decomposing a program into multiple programs isn't always a good idea, there is a very broad trade-off here that needs to be evaluated for the needs of every program.

Re: Programs should be Small

#55

Post by vanwaril »

lukego wrote: post #38

My current theory is that a good program should compile in less than 1 second into an executable of less than 1 megabyte.

My current theory is that this is an arbitrary one. Its really, really, really easy to cross a megabyte with statically linked libraries.

Re: Programs should be Small

#56

Post by mairbek »

meaty wrote: post #20

I love all these articles which are wholly ignorant of how complex software is in reality and how such advice isn't necessarily good. Sometimes decomposition results in problems at the other end of the scale such as communication performance, data duplication, extremely nested abstractions, messaging complexity, contract and API versioning hell etc. Getting the sweet spot between monolithic coupled blobs and fragment…

I totally agree that software development is somewhat non-trivial. I'm not saying that small programs would solve all problems you might face. Would you system be more maintainable? I think yes.

> Getting the sweet spot between monolithic coupled blobs and fragmented latent deathtraps is an art which can't be puked out in a blog post. It takes literally years of experience and some guesswork and testing and thinking.

I agree in the blog post, proper decomposition is the key if you want to write a good systems, and to be honest is really hard to achieve.

Re: Programs should be Small

#57

Post by ams6110 »

pixl97 wrote: post #8
moe wrote: post #4

A good program is 500 lines or less.

I type at least 60,000 characters before inserting a line break. I joke, but I've seen some php before that was at least 600 chars before line breaks, I have no idea how they wrote it like that.

Editors that wrap long lines for display.

Re: Programs should be Small

#59

Post by mairbek »

meaty wrote: post #44
sorbits wrote: post #39

Earlier quoted context omitted.

Adding to that, his stated advantage of not having to limit yourself to one platform also seems opposite of my experience (i.e. keeping all on the same platform is an advantage). When you have a big system with disjoint parts written in different languages, re-use and refactoring is a pain, and redundancy is almost certain to creep in (and with redundancy often comes inconsistency).

Yes heterogeneous systems are much easier to deal with, although from experience certain systems are a pig to deal with from end to end (anything Microsoft as a rule). Different languages are just different forms of integration and the mantra of integration is hell should be in the forefront of everyone's mind, always.

Depends on tools you use, I found Apache Thrift and Protobuf pretty to be sophisticated tools for integration between services.

Re: Programs should be Small

#60

Post by marcosdumay »

IvyMike wrote: post #47
mimog wrote: post #37

Isn't this "the Unix way"? I have seen this style of small cohesive programs promoted a lot in Linux/Unix literature so the advise isn't really breaking any new ground. Look at git for instance. The advise is of course sound but it goes against the "enterprisy" way of doing things, in part because they tend to be using huge frameworks from the get go.

On the other hand, think back to the famous macro- v. micro-kernel debate. The kernel itself is huge, and the "small cohesive service" philosophy microkernel advocates ended up never really taking over the world.

That's because kernels perform differently from user software (they have more optimizations available), and a lot of big code needs that extra performance.

That's a fact that still didn't change, but user level code is getting more powerful (mainly for virtual machines), and computers are still getting faster. So, it's still too early to declare the race finished.

Anyway, none of that has any relevance to how one should organize user level code.

Post reply on HN