Programmimg Pearls (1985)

https://dl.acm.org/doi/10.1145/4284.315122

by edent • 4 years ago

106 26 4 years ago

dl.acm.org

macintux• 4 years ago

I thought the title here had a typo, but no, indeed, the typo is at the ACM website (but not the paper itself).

Some choice tidbits in there.

The job’s not over until the paperwork’s done.

tkhattra2• 4 years ago

bentley revised and updated some of his "programming pearls" columns and published them in 2 editions of books published circa 1986 and 2000. they are among my favorite computer science books, and a great companion to more theoretical data structures, algorithms, and software engineering texts. a great mix of theory, engineering, rules of thumb, insight, creativity etc., all presented lucidly. highly recommended!

vram22• 4 years ago

Yes, those two books are Programming Pearls and More Programming Pearls. I have both, and they are good. In one of them there is a section or chapter with a few examples of advanced uses of awk, involving awk's associative arrays, to do some non-trivial work in very few lines of code[1]. He shows or says that the equivalent programs in C would be much longer and harder to write.

[1] Even more so than in most other common examples where awk programs are shorter than those in other languages.

satyanash• 4 years ago

Allocate four digits for the year part of the date: a new millenium is coming -- David Martin, Norristown Pennsylvania

2038 is 15 years away right now; this article was published 15 years before 2000.

bombcar2• 4 years ago

Even in 1985 you could foresee wanting to reference something after 2000 - terms for a thirty year loan, for example.

Harder to see reasons past 2038 back in 1970.

nerdponx• 4 years ago

Harder to see reasons past 2038 back in 1970

I still find myself confused at this one. Did people in 1970s not imagine that any particular program or database would "survive" for 30+ years? Was the expectation that programs written in the future could set the epoch to a later date?

Now that I think about it, I also find it interesting that the epoch date isn't configurable in any system that I'm aware of.

throwawaytemp29• 4 years ago

Y10K bug! Only 4 digit dates.

watersb• 4 years ago

A series of exercises from 1970s, so exercises tend to be good Perl or Bash one-liners these days.

But! The real point of this book is How to Ask Questions.

Anyone who has written an entire AI-based inference engine, when the customer wanted a spreadsheet, will get a kick out of this.

And those of us who haven't (yet) will gain some insight that might prove useful later on.

biryani_chicken• 4 years ago

It's also in archive.org [0] with better quality and several formats for download.

[0] https://archive.org/details/ProgrammingPearls2ndEditionJonBe...

tkhattra2• 4 years ago

i don't think that's the text of the entire book - it looks like a scrape of the book's former website (www.programmingpearls.com).

gregfjohnson• 4 years ago

If this is the first time you’ve heard of Jon Bentley’s “Bumper sticker computer science”, you are in for a rare treat! It is a combination of the hilarious and the deeply insightful. An absolute joy, and a must-read for computer scientists and programmers. It is a distillation of aphorisms and wisdom from an entire generation of many of the world’s best minds in our discipline.

embit• 4 years ago

John B. on quick sort. Just awesome explanation

https://m.youtube.com/watch?v=QvgYAQzg1z8

bhrgunatha• 4 years ago

The analysis of comparisons was both brilliant and illuminating.

eimrine• 4 years ago

Why to avoid asymmetry?

edent• 4 years ago

I was wondering about that. I think it is about having the ability to go A->B without being able to go B->A.

But, as with many of the Pearls, it is heavily context dependent. And if you aren't well versed in "primitive" computing paradigms, you'll be confused.

epgui• 4 years ago

It's a bit hard to explain this one, but symmetry is a form of simplicity. This might make more sense to a physicist or mathematician.

ezekiel68• 4 years ago

This is only an opinion --but it's the opinion of someone who has been involved in software engineering since the 1990s:

Since this quote is in the section of general advice, I feel this advice applies mainly to the analysis and design of systems. Here's an example: You want to make a command line program (or it could be an API) that can behave differently, depending on certain conditions. So you have an analysis and design problem, which is: how do you cover these different scenarios (flexibility) without making the program/api too difficult to use (complexity)?

If you hard-code the choices into the system, it gets a part of the job done, but there is no flexibility and so your system will be useless to those who need the outcome to match certain common use cases. But, on the other hand, if you require users to type in a long list of parameters every time they use the system (complexity), users will avoid this solution because it is simply too difficult to use for the most common scenarios.

Symmetry in this sense means striking the right balance among the aspects of usefulness and simplicity so that your system will match the needs of its intended users. In my hypothetical case, the programmer might provide a config file which lists comments showing the default values for the config options. If a user needs to tweak this behavior slightly from the defaults, they can set the config values as it suits them in the config file once, rather than needing to remember to type the overrides in as command-line params each time.

Again -- this is one simple example. When defining a data model (a different realm where symmetry applies), it is common to take many iterations to "get it right" so that the system can properly reflect a real-world problem, such as how to represent that 'many students take many classes at the college'. Early efforts tend to be "asymmetric" in the sense that they fail to capture key relationships between important concepts by making the data model too "flat" or simplistic. Further modeling efforts, though, may make the opposite mistake by trying too hard to faithfully capture every possible corner case, including those which either seldom occur or have no practical value (such as recording whether any instructors took leaves of abscence during a semester, when the point of the system is to capture student attendance and grades).

toolslive• 4 years ago

"asymmetry" typically involves exceptional state/behaviour. It's an extra cost while you're building it, and it's an extra cost while maintaining it. For example, a customer wants something special but it will only be needed by that customer.

NorSoulx• 4 years ago

I co-designed and developed one of the early SMS content platforms in Norway back in 2000. I had bought and read Programming Pearls, and used ideas from this book to implement number portability routing/handling when it was introduced for mobile operator phone numbers in Norway.

Programmimg Pearls (1985)

Related Stories