Live data from Hacker News

Ask HN: CS papers for software architecture and design?

news.ycombinator.com

31–40 of 104 posts

Re: Ask HN: CS papers for software architecture and design?

#33
I'm surprised no one has mentioned the David Parnas papers: "On the Criteria To Be Used in Decomposing Systems into Modules" is an all-time classic [1]. Much more philosophical than most of the suggestions here so far, but this paper really drove home to me the importance of abstraction in software design. (Also covered in the Morning Paper [2].)

[1] https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/crit.... [2] https://blog.acolyer.org/2016/09/05/on-the-criteria-to-be-us...

Re: Ask HN: CS papers for software architecture and design?

#34
post #7

Oldie but goodie: Large-scale cluster management at Google with Borg [1]. Kicked off the mainstream idea that maybe (dev)ops shouldn't care about servers and Linux service configuration or where exactly their code runs. [1] - https://static.googleusercontent.com/media/research.google.c...

[deleted]

Re: Ask HN: CS papers for software architecture and design?

#35
I liked reading: Program design in the UNIX environment by Rob Pike. Sometimes, when I think about which features to add to a program I step back to see, whether a combination of program would actually yield better results. A practical view into what orthogonality could mean in the tooling world.

[1] https://nymity.ch/sybilhunting/pdf/Pike1983a.pdf

Re: Ask HN: CS papers for software architecture and design?

#36
post #35

I liked reading: Program design in the UNIX environment by Rob Pike. Sometimes, when I think about which features to add to a program I step back to see, whether a combination of program would actually yield better results. A practical view into what orthogonality could mean in the tooling world. [1] https://nymity.ch/sybilhunting/pdf/Pike1983a.pdf

Awesome recommendation

Re: Ask HN: CS papers for software architecture and design?

#37
post #9

For me, the most influential was "Out of the Tar Pit". From the abstract: "Complexity is the single major difficulty in the successful development of large-scale software systems. Following Brooks we distinguish accidental from essential difficulty, but disagree with his premise that most complexity remaining in contemporary systems is essential." [1] https://github.com/papers-we-love/papers-we-love/blob/master...

I agree that's a wonderful paper to read, but has it had significant influence in the mainstream?

I read this more than 5 years ago, I think from a recommendation on HN. But I must have gotten something different out of it than most people.

It is advocating a particular architecture. But that architecture is essentially LAMP, as far as I can tell. It's what we ALREADY do!!!

From the paper:

FRP is currently a purely hypothetical approach to system architecture that has not in any way been proven in practice. It is however based firmly on principles from other areas (the relational model, functional and logic programming) which have been widely proven.

In FRP all essential state takes the form of relations, and the essential logic is expressed using relational algebra extended with (pure) user- defined [18] functions.

[18] By user-defined we mean specific to this particular FRP system (as opposed to pre- provided by an underlying infrastructure)

-----

- All essential state takes the form of relations This is a database. (SQL deviates from the relational model, but I don't view that as important here. An SQL database stores everything as relations.)

- Logic is expressed using pure user-defined functions This is PHP / CGI / FastCGI. PHP is imperative, but the entire program is a pure function, because the request state is cleared between every request.

What am I missing? I'm being totally serious -- this is what I got out of it when I read it 5 years ago.

You can quibble with the details of PHP or Rails not being pure functions, but I believe what's important is the architecture, not how the source code looks. The essential state is in the database, in the form of relation. Accidental state is thrown away.

TL;DR -- PHP/MySQL is functional and relational.

Re: Ask HN: CS papers for software architecture and design?

#38

Earlier quoted context omitted.

I agree that's a wonderful paper to read, but has it had significant influence in the mainstream?

Not yet, but I suspect that is partly the mainstream not catching up to the ideas it contains yet.

See my sibling comment -- I honestly believe it's describing what people already do. I'm curious what someone who's read the paper (like I have) thinks.

Re: Ask HN: CS papers for software architecture and design?

#39
post #37

Earlier quoted context omitted.

I agree that's a wonderful paper to read, but has it had significant influence in the mainstream?

I read this more than 5 years ago, I think from a recommendation on HN. But I must have gotten something different out of it than most people. It is advocating a particular architecture. But that architecture is essentially LAMP, as far as I can tell. It's what we ALREADY do!!! From the paper: FRP is currently a purely hypothetical approach to system architecture that has not in any way been proven in practice. It is…

FRP is a constrained environment, which makes it easier to reason about. PHP is comparatively unconstrained, so when reading code you can’t make as many shortcut assumptions. Of course you could write in PHP in accordance to the rules, but subsequent maintainers, including the future you, cannot trust this self-imposed discipline. In other words, you wouldn’t argue that assembler is just fine because through vigor and discipline you can build PHP-like application. Similarly, PHP is not well-suited to stand in for FRP.

Re: Ask HN: CS papers for software architecture and design?

#40
post #37

Earlier quoted context omitted.

I agree that's a wonderful paper to read, but has it had significant influence in the mainstream?

I read this more than 5 years ago, I think from a recommendation on HN. But I must have gotten something different out of it than most people. It is advocating a particular architecture. But that architecture is essentially LAMP, as far as I can tell. It's what we ALREADY do!!! From the paper: FRP is currently a purely hypothetical approach to system architecture that has not in any way been proven in practice. It is…

FRP is like excel or well constructed makefiles in that the runtime understands the data flow. Then on updates to any data, you walk through the dataflow graph, running pure functions to update each node.
Post reply on HN