pozorvlak

Yeah, that sounds like a reasonable term to use.

> The closest I've come, weirdly, was tutoring a friend through a design pattern class.

It's a bit old now, but I think it's probably still worth reading the GoF book - it's clearly written, and much better than most subsequent imitators. In particular, each pattern comes with a "when not to use this" discussion, that more people should pay attention to :-/

> I've always wanted just a simple list of the names, maybe with linked single paragraph descriptions

Would http://wiki.c2.com/?CategoryPattern do?

> what is the formal name of doing that, specifically, the formal name of the category to which attr_accessor and has_many belong to?

I'm not sure. Adding methods to a class at runtime is called "metaprogramming" (which has the more general meaning of "writing code that writes or modifies code"). I don't know of a name for a method that performs metaprogramming, though.

Then again, we live in the era of Docker, in which it's commonplace to ship an entire Linux filesystem along with your web app. So shipping a Smalltalk VM (2.6MB for Pharo 5.0) shouldn't be too much of a stretch.

You missed the "created: 3246 days ago" bit, then? :-) But you're right that I don't spend much time here - thanks for the welcome!

> it's not clear what the difference is between patterns and.... maybe idioms?

You're right, it's not a clear distinction. But for our purposes, the important point about design patterns is "must be reimplemented from scratch for each use". Have you read the Gang of Four book? Their patterns all require the programmer to define a bunch of new classes from scratch each time the pattern is used. Compare the Decorator pattern (https://en.wikipedia.org/wiki/Decorator_pattern) to Python's decorators - the pattern requires the programmer to create new classes, forward methods, etc, but the Python feature requires the programmer to write one line of code (which then does all the class-creation and method-forwarding under the hood). The Python feature has successfully obviated the need for the pattern. You still need to write the same amount of application-specific business-logic code, but the machine handles all the tedious plumbing for you. Similarly, attr_accessor and has_many handle the tedious plumbing of getters/setters and collections-backed-by-join-queries, respectively. So the necessary abstraction features have already been added, and there's nothing left to fix. An interesting intermediate case is the Iterator pattern in Python (https://en.wikipedia.org/wiki/Iterator_pattern). Python still has explicit iterators, but standardises the interface so library code can make use of user-provided iterators. It also provides a convenient language-level facility for building iterators, using generator syntax. Haskell, arguably, has entirely absorbed iterators into the language, replacing them with lazy lists.

It's worth noting that the key property of Ruby that allows for things like attr_accessor is the ability to add methods and fields to an object or class at runtime, and thus to do so programmatically. Lisp can similarly dispense with a lot of patterns that are necessary in Java, because Lisp has compile-time code generation in the form of macros. Peter Norvig's talk on this is great: http://norvig.com/design-patterns/ppframe.htm

On the other hand, it's possible to make (core language + standard library) too small. A particularly bad thing to leave out is a module/separate compilation system, ensuring that a zoo of incompatible module systems will grow up.

You may enjoy Guy Steele's talk "Growing a Language": https://www.youtube.com/watch?v=_ahvzDzKdB0

true = \x.\y.x

false = \x.\y.y

attr_accessor, as it happens (http://ruby-doc.org/core-2.0.0/Module.html#method-i-attr_acc...) is implemented in C code, but one could implement it in Ruby, so I'd count it as part of the (standard) library, and creating accessors is just using a library method. In, say, Java setters and getters have to be written by hand (or autogenerated by some external system like an IDE), so they're a pattern. On the other hand, the way Ruby translates `foo.bar = 3` into a call to `foo`'s `bar=` method is not alterable by user code, so it's part of the language.

MVC in Rails is an interesting case. You have to create new classes according to the pattern (either by hand or using `rails generate`), but there's also some library support in the form of Model and Controller classes you're expected to inherit from, and which handle much of the View/Controller plumbing for you. I'd say it's still a pattern, though.

Is that done on a per-subreddit basis, or a whole-site basis? If I submit mostly my own content to proggit but mostly other people's content to other subreddits, will the proggit filter hate me?

Oh, right - you can vary the shape of the diagonal lines, provided each "arm" has rotational symmetry about its mid-point.

OK, so we've got three infinite families and the trivial solution (only one piece - is that your sporadic solution?). I think that might be all: each piece can contain 4, 2, 1 or 1/2 of the original square's corners, since (lacuna) all pieces must contain the same number of corners and further subdividing the corners (into 1/3s, say) would mean some pieces don't touch the centre (another lacuna).

I suspect this line of argument can be taken further, but wanted to post it before someone else did :-)

Edit: no, that doesn't work, because we already have a dissection into two pieces, and |S_2| = 2. Dammit. Not all of the symmetries of the square must map pieces to pieces.