121–130 of 133 posts
Computer software is a form of literature. The most important thing is how well the language of this corpus persists. That only happens through usage.
Thus, by slide 6, I was prepared for a "because: Lisp" argument, and .. there it was.
MJD says Alexander's central question is "How can you distribute responsibility for design through all levels of a large hierarchy, while still maintaining consistency and harmony of overall design?" The only "solution" to this question in software that I'm aware of is, "hire a charismatic architect and let them do all the design" which is terrible. Thinking about my team, I'd say probably a third of them are interes…
The hardest thing for a lot of people to hear is, "you're not wrong, but the thing you're thinking about isn't the essential one." Architecture is about finding the principles and axioms that apply to the situation. It also requires an ability to "let go," in that if your design is good enough, you are no longer personally necessary because the rest has been made obvious, and anyone can implement it.
Elegant thinking can seem obvious, and transmits a great deal of understanding simply. The purpose of architecture is to formulate something that benefits in scale to the efforts of multiple cheaper, less experienced people.
MJD says Alexander's central question is "How can you distribute responsibility for design through all levels of a large hierarchy, while still maintaining consistency and harmony of overall design?" The only "solution" to this question in software that I'm aware of is, "hire a charismatic architect and let them do all the design" which is terrible. Thinking about my team, I'd say probably a third of them are interes…
My impression was that design patterns are just shared vocabulary, not something to aspire to use (other than realizing there was an existing "word" that would succinctly describe your jumbled spaghetti sentence and using that instead). Edit: I've been wanting to read A Pattern Language for a while, but this snippet from Amazon made me chuckle. If I didn't know better, I would have given it a 50/50 shot of being from…
I think that's what they are in the industry right now. We all use the same vocabulary, and it makes sense to share a lot, since we're mostly doing the same thing. The slides' point seems to be that there's this other concept, which is that each project should develop a language for speaking of the project, perhaps more specific to the project. But also not just a list of "things people use currently". Your new proje…
MJD says Alexander's central question is "How can you distribute responsibility for design through all levels of a large hierarchy, while still maintaining consistency and harmony of overall design?" The only "solution" to this question in software that I'm aware of is, "hire a charismatic architect and let them do all the design" which is terrible. Thinking about my team, I'd say probably a third of them are interes…
Would you mind sharing what you mean by "a punishingly minimal aesthetic"? Is it overly concise to the point of not being reasonably comprehendible?
I will email you privately about it.
MJD says Alexander's central question is "How can you distribute responsibility for design through all levels of a large hierarchy, while still maintaining consistency and harmony of overall design?" The only "solution" to this question in software that I'm aware of is, "hire a charismatic architect and let them do all the design" which is terrible. Thinking about my team, I'd say probably a third of them are interes…
Good architecture is leadership based on transparent principles. The hardest thing for a lot of people to hear is, "you're not wrong, but the thing you're thinking about isn't the essential one." Architecture is about finding the principles and axioms that apply to the situation. It also requires an ability to "let go," in that if your design is good enough, you are no longer personally necessary because the rest has…
Thanks for elaborating on this.
I'm a bit young for perl, but I've had rather extensive experience with python at my last job, and it's my understanding that perl has a similar "global" solution with for elem in collection: and the `__iter__()` function. Correct?
no. perl5 can deal natively only with finite lists, not general iterators over infinite (lazy) lists. of course you can design an iterator over lazy lists, but you got no language support as with __iter__, other than using tie callbacks. only perl6 supports lazy lists and coroutines and yield. but iteration is only a trivial part of a design pattern. as the name says, a pattern is matching certain conditions, like nu…
> but you got no language support as with __iter__, other than using tie callbacks.
Also the perl way would be to implement infinite streams, ala MJD's HOP[0].
[0]: http://hop.perl.plover.com/book/pdf/06InfiniteStreams.pdf
Earlier quoted context omitted.
'Like what? Seriously? Do you have any evidence to backup the assertion of design techniques that are appropriate for some situations but not others? Otherwise you're just kidding yourself.' Really? This requires proof? I would have thought it was self evident. Take the Flyweight pattern mentioned previously - appropriate when you have thousands (millions, billions...) of entities and memory is constrained.
How can it be self evident? You made a statement saying `Some are appropriate for some situation but not others` You've listed one example of Flyweight, but without any sources to backup the claim it's appropriate when memory is constrained.
Concepts are supposed to be the Design Patterns in the sense mentioned in the slides. But they could use more user friendly names. (no, I do not mean developer friendly)
Via the curry-howard-lambek(-...) correspondence, Category Theory is a pattern language for programming. It has a very rigorous criterion that justifies calling a logical/mathematical/programmatic construct a pattern: a pattern is a universal construction. Bear with me if you would like. I'm doing this off the cuff and I doubt I'm good enough to communicate what I want in a single Internet comment :) A universal cons…
A true Program is not really an Arrow, as it deals with mutable unknown state that cannot be reduced to a known set of inputs completely. (Where functional and monadic programming gets awkward or impure.) There may also be multiple outputs and inputs at any stage in the process, an Arrow limits you to one output and input vector making actual programming awkward. Forces the kinds of composition you can describe.