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

Simple Software Manifesto

arewesimpleyet.org

Post reply on HN
Print view View original

81–90 of 90 posts

Re: Simple Software Manifesto

#81

Post by anderspitman »

majewsky wrote: post #35

> We target C99 or C11 C is anything but simple. It looks simple on the outside, then beats you to death with undefined behavior and either overexplicitness (if you don't use macros) or nested-macros hell (if you do). Their choice of C is routed more in the authors coming from the Unix community, not in their desire for simple software. If anything, they should start with a truly simple programming language. Somethin…

I disagree. I think C is simple, but not easy[0]. I actually see explicitness as a sign of simplicity. It makes things obvious. Folks always cite undefined behavior, but I can't recall a single instance over the past 12 years of this causing me a day-to-day problem. I'm sure it does bite people though, I just don't relate personally.

[0] https://www.infoq.com/presentations/Simple-Made-Easy/

Re: Simple Software Manifesto

#82

Post by anderspitman »

pcr910303 wrote: post #23

Every software has a reason to be complex. Often software authors desire to make simple software by removing such features regarded ‘complex’ without understanding why those features were introduced (mostly because they don’t use them). The consequences is that people who are in the minority can’t use the software. As a CJK person, the most prominent example is multilingual support in the FOSS community; I still have…

> Every software has a reason to be complex

Yep. The problem is that sometimes the reason is the authors are trying to do the last 80% of work required to add the last 20% of features, which 99% of users will never need.

Re: Simple Software Manifesto

#84

Post by ngneer »

nivenhuh wrote: post #79
adgasf wrote: post #13

Earlier quoted context omitted.

The question is: is this thing inherently complex or is it more complicated than it needs to be? In software there are many things that are more complex than they need to be.

Software development is an additive practice, where opinions and ideas are usually added to a big-ole-shipping-ball of software. I think this is where most complexity comes from. Sometimes it can be a subtractive practice, where a person can delete / simplify, but this happens much less than it should.

Same with security, unfortunately.

Re: Simple Software Manifesto

#85

Post by OrderlyTiamat »

Jwarder wrote: post #34
cocktailpeanuts wrote: post #10

Don't #2 and #3 contradict? > Constraining the user to simple tools encourages creativity and allows the system to be more quickly understood > There is only one correct way to do something, because two ways would be more complex When you encourage creativity with combinations of simple tools, creative people will come up with multiple ways of doing things.

I read the "only one correct way" to be a per-tool guideline. When looking a tool to do a specific task then (ideally) the tool should just process input with minimal futzing with configuration options. If you need to do something special then you should have a special tool.

That seems reasonable. Though in the context of packages etc, i would like to then introduce the term "toolset". Just because a piece of software is a single package doesn't mean it has to be a single tool. It is much more simple to have a bunch of tools for related tasks collected in a single toolset rather then making seperate apps for each one- never mind the overhead that the last approach would create.

Re: Simple Software Manifesto

#86

Post by etripe »

AlexandrB wrote: post #12

What’s wrong with Perl? Also, with no C macros there are no C generics. I wish the author luck in maintaining that mess.

> What’s wrong with Perl?

Looking at their central axioms, I would guess:

1 - simple software breaks in simple ways: weak, dynamic typing means a lot of problems trivially solved by static and/or strong typing.

2 - simple tools: no idea. I remember cpan being fairly great and perldoc being excellent.

3 - one correct way to do thing versus perl's TMTOWTDI central theme

4 - dependencies are part of the system: lots of CPAN modules, so there's a tendency to import black box modules instead of writing it yourself and retaining ownership.

5 - standards are useful but full of cruft: perl has a much larger standard lib than, say, Go or Python as far as I understand.

As to why it would be what's wrong with git: after a cursory glance at the git repo (0), I would guess the problem is that it still contains .perl files?

[0]: https://github.com/git/git/search?l=Perl

Re: Simple Software Manifesto

#87

Post by utopian3 »

ngneer wrote: post #84
nivenhuh wrote: post #79

Earlier quoted context omitted.

Software development is an additive practice, where opinions and ideas are usually added to a big-ole-shipping-ball of software. I think this is where most complexity comes from. Sometimes it can be a subtractive practice, where a person can delete / simplify, but this happens much less than it should.

Same with security, unfortunately.

Ironicaly, complexity is the enemy of security (as I’ve heard quoted a few times)

Re: Simple Software Manifesto

#88

Post by utopian3 »

adgasf wrote: post #13
pron wrote: post #9

Every new generation of programmers starts a crusade to simplify without first trying to understand why we're not "simple" despite the previous generation having done the same. Of course, one possible explanation could be that without a constant crusade for simplicity we'd be in a far worse place; the "permanent revolution" explanation. But is this the right explanation? Turing Award winning computer scientist Fred B…

The question is: is this thing inherently complex or is it more complicated than it needs to be? In software there are many things that are more complex than they need to be.

Zawinski's Law

> “Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”

Re: Simple Software Manifesto

#89

Post by Supermancho »

gerbilly wrote: post #65
Supermancho wrote: post #59

Earlier quoted context omitted.

> For example, there is one 'correct way' to unscramble a rubiks cube Thats not true from a mechanical standpoint. From start, rotate an edge 180degrees. Now you can turn it right 180 or left 180. Making 2 coins show the same face (when they differ) doesnt have one correct algorithm, in the same vein. Developers necessarily interact with apis at this level and generalize from these choices.

The integrity of my rubik's cube analogy isn't critical to my argument, but... Even allowing for equivalent rotations as you mention, the method humans use to unscramble a rubik's cube is far far from optimal because we can't grok a scrambled rubik's cube then just execute the optimal solution. Also this is just pedantry because WLOG you could just name those equivalent 180 rotations as a single operation anyway.

> you could just name those equivalent 180 rotations as a single operation anyway.

That isnt true insofar as there are decisions that are based on arbitrary perception and categorization. What you could do is irrelevant because that is an assumption to create a generalization. GL with whatever.

Re: Simple Software Manifesto

#90

Post by als0 »

> POSIX should probably be replaced when the time is right.

Everyone loves to bash POSIX. The idea of replacing it lingers on, but has anyone considered the idea of updating POSIX to remove the gnarly parts? This is a somewhat incompatible change and would have to be versioned appropriately.

Post reply on HN