[HN Gopher] Perlis's Programming Epigrams
___________________________________________________________________
Perlis's Programming Epigrams
Author : nomilk
Score : 47 points
Date : 2024-04-17 03:43 UTC (19 hours ago)
(HTM) web link (www.cs.yale.edu)
(TXT) w3m dump (www.cs.yale.edu)
| nomilk wrote:
| Mentioned here: https://www.youtube.com/watch?v=agw-
| wlHGi0E&t=1h45m40s
| tgv wrote:
| Edgy. I wouldn't pay too much attention of them. E.g.
|
| > 9. It is better to have 100 functions operate on one data
| structure than 10 functions on 10 data structures.
|
| I'm sure that isn't always the case. At the very least, it
| shouldn't lead to mixing data structures.
| dgb23 wrote:
| This is very very sound advice. How many _actual_ data
| structures are there in our day to day? Trees, graphs, buffers,
| arrays, hashmaps, state machines... Yet we tend to overspecify
| operations as if they are special (see: many applications of
| OO), when they really aren't.
|
| Another angle to look at this is moving complexity and
| specificity into data and away from functions. It's a recipe
| for success: HTTP/REST, SQL, CLI utilities etc.
| cess11 wrote:
| Some of them are pretty obsolete, reflecting old conflicts and
| languages that are no longer in use, or obsolete due to
| hardware advancements, like the quip about lispers not caring
| about computational performance.
|
| But that one is very good advice. A data structure that can
| represent a tree and be used with filter/map/reduce (e.g. list
| or array) can get you very far, and the functions can carry
| semantics instead of names attached to the data.
| pfarrell wrote:
| A few are dated but number 74 is one I think about a lot when
| programming. Is it possible that software is not
| like anything else, that it is meant to be discarded: that the
| whole point is to see it as a soap bubble?
|
| Important to remember this was written in the early '80's at the
| end of Perlis's long career. For most of these to stay relevant
| and humorous 50 years later is pretty impressive.
| veddox wrote:
| I've seen several of these before in SICP and other places, but
| happy to find a longer collection here! Perlis just has his own
| style and humour...
| veddox wrote:
| A list of my favourites:
|
| 3. "Syntactic sugar causes cancer of the semicolon."
|
| 14. "In the long run every program becomes rococo - then
| rubble."
|
| 19. "A language that doesn't affect the way you think about
| programming, is not worth knowing."
|
| 55. "A LISP programmer knows the value of everything, but the
| cost of nothing."
| Jtsummers wrote:
| https://dl.acm.org/doi/10.1145/947955.1083808
|
| https://dl.acm.org/doi/pdf/10.1145/947955.1083808 [pdf]
|
| Hurray for more open access from ACM, here's the original
| publication with the 10 missing epigrams.
| rjolley45 wrote:
| I like this one a lot: "A language that doesn't affect the way
| you think about programming, is not worth knowing."
|
| I frequently see newer programmers trying to learn as many
| languages as possible to list them on their resume...what they
| don't realize is that learning syntax is pretty much irrelevant
| to programming skill. Choose one language, master the building
| blocks, then choose another that works completely differently. Do
| this two or three times, and all of the sudden you can write in
| any language you want because you understand the fundamentals.
| eternityforest wrote:
| There's _some_ value, in that language choice is often about
| ecosystem and legacy issues, so there 's often reasons to use a
| language even if it by itself isn't interesting.
|
| But, if you know one OOP language you can pretty much start
| working on any of them with a few Google(Or ChatGPT I guess)
| requests.
|
| Beginner programmers can easily get in a "Using what they know"
| trap though, and sometimes it's some obscure thing like VB.Net
| they happened to learn first, stuff that might teach you
| programming fundamentals, which is good, but it won't teach you
| about making use of modern tooling and all the random stuff
| mainstream projects use.
___________________________________________________________________
(page generated 2024-04-17 23:02 UTC)