Camelia, the Perl 6 bug

IRC log for #cqrs-perl6, 2011-04-21

| Channels | #cqrs-perl6 index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
10:36 mac left #cqrs-perl6
11:17 masak joined #cqrs-perl6
14:36 birdwindupbird joined #cqrs-perl6
15:51 masak PerlJam: re "the antithesis of DDD". I'm reading the DDD book by Evans now. it's becoming increasingly clear to me that DDD is not just full of tautologies.
15:53 PerlJam Got an example that makes that clear?
15:53 masak the book keeps going into situations, dialogs between devs and domain experts.
15:54 masak it emphasizes that the domain model usually starts out kinda small but not too well-suited, and with DDD it can evolve into something that acts as the bridge between the programming team and the domain experts.
15:56 masak I'd guess settling on one domain model at the start and then never really going back and improving it is a very common thing.
15:57 masak that matches what Evans said in a recorded lecture I watched: that people are far too quick to settle on a model. usually, they pick the first one that seems to do what they want, and don't consider the handful of other candidates, some of which might have been better in some way.
15:58 PerlJam aye
16:00 PerlJam that's a common pattern.  You see it on IRC all the time too.  How many times have you tried to help someone who already thought they had a solution to their problem?  They'd already decided on a certain model for their problem domain even though they may not have considered (or even understood) other options.
16:00 masak that's the X/Y problem, isn't it?
16:00 PerlJam yes.
16:01 masak it's a difficult one not to make.
16:01 masak we tend to go about our lives applying previous experience.
16:01 PerlJam well ... I tend to think of it as insufficient application of critical thinking.
16:01 masak right.
16:02 masak TimToady once complimented me on saying "what general principle am I missing here?" :)
16:02 masak he said that it's not common to realize that there is a box outside of which one ought to think.
16:02 PerlJam yep
16:03 masak but I'm generally just as bad as anyone at that.
16:03 PerlJam I wonder how pervasive this pattern is.  when I think about it a little more, I see it in my kids too.  Sometimes they have problems with their homework that largely stem from the fact that they have already decided they don't know or can't find the answer they're looking for.
16:04 masak most of the nicer proofs or theories I know in mathematics have to do with solving a problem by changing the problem into an easier one. Fourier transforms, logarithms, projections...
16:04 PerlJam If you stop thinking that way and start asking questions and getting to "first principles" you invariably see that there's a larger context that you should be paying attention to
16:05 masak aye.
16:06 masak in the CQRS course, there were many moments of the form "we've learned as coders to try to optimize for X at any price, but it turns out that $customer doesn't really *care* that much about X"
16:07 masak some examples I can think of are 3NF and database consistency.
16:07 PerlJam perhaps this is just a sign that our species is on the cusp of evolutionary greatness.  We know enough to know when we're thinking wrongly (sometimes), but we don't know enough to will "right thinking" into our mind's default state  :)
16:07 masak s/3NF/database normalization/
16:07 PerlJam yes!  those are perfect examples.
16:07 PerlJam It's how we're taught in school though.
16:07 PerlJam "you should always normalize because it's better"
16:07 masak PerlJam: that's a nice way of viewing things. (the evolutionary "you are here" view)
16:08 masak turns out, normalization is great for OLTP, but the opposite is great for OLAP.
16:08 masak this was well-known in the 70s.
16:08 masak a lot of great things seemed to be happening in the 60s and 70s with programming. and then mainstream happened. or something.
16:09 masak everything got bulldozed over by SQL, CRUD, and useless point-and-click interfaces.
16:09 masak even OO has been mostly corrupted that way, I think.
16:11 masak Greg told us on the course about a place he went to, where they greeted him with "We don't even know why we would need an architect! We've already..." -- and the person waved a copy of the Gang of Four book with lots of bookmarks in it -- "...put all of the patterns in our system."
16:11 masak "Every single one. Some of them it was tough to find a use for, but we made it."
16:12 PerlJam I think your observations are a manifestation of "the future is here, just not evenly distributed"
16:12 masak indeed.
16:12 masak the observations are explained by a theory involving a small number of sources of real inspiration, along with plenty of cargo culting.
16:12 PerlJam heh
16:12 PerlJam indeed
16:13 PerlJam In a way that's how I came to use perl.
16:14 masak I'm not surprised.
16:15 PerlJam I met pmichaud, he was clearly someone to draw inspiration from and he suggested I learn perl.  Later when I "came into my own" in perldom, I read more of TimToady's philosophies and such and again I recognized a "spark" and so gravitated towards it.
16:15 PerlJam Had I just been a work-a-day coder, I would have never gotten into Perl 6 even if I had used Perl 5 forever
16:15 masak :)
16:16 masak I must have been a fly buzzing around the light of Perl 6 around 2003-2004. but it's a bit lost in the mists of memory for me.
16:21 masak &
16:55 birdwindupbird left #cqrs-perl6
17:20 masak went for a walk. somehow I'm really comforted/enthused by the thought of living in the cusp of evolutionary greatness -- a time when one still has to put some effort into willing "right thinking" into our mind's default state. :)
17:22 masak PerlJam: anyway, one thing I meant to say earlier but never really got around to is that "Model-Based Design" is what happens when one makes sure that the code really adheres to the model, doing a sort of whirlpool back-and-forth if it doesn't (or if new concerns appear on the horizon, as they tend to).
17:23 masak and I think it's a point well worth making, because the relation between design and code tends to be waterfall, even in cases when a lot of other parts of the process aren't. for reasons we discussed above.
17:23 masak Evans calls it "knowledge crunching", which seems in concept very similar to what we call "whirlpool development".
17:27 PerlJam Just remember that the whirlpool is just a convienent model for a more complex interaction  ;-)
17:29 masak of course. if we could guess at or approximate the center whirlpoint, we'd just jump there. :P
17:35 masak waterfall, on the other hand, is a much more direct metaphor.
17:56 masak so maybe that's what DDD is, at core. "iterate your model".
18:05 PerlJam masak: sounds about right to me.
18:13 masak but the way those iterations are done also seems important. keeping the uqiquitous language in lock-step between domain people, architect people, and code people.
18:19 masak oh, and apparently it's at least moderately important that the architect has his hands in the code at least some of the time. otherwise things risk degenerating into a one-way street again.
18:21 PerlJam yep.  Communication is paramount.  If the architect is disassociated from the code, then there needs to be even more communication between him and the rest of the team.
18:21 PerlJam especially if the architect is also the primary contact with the customer.
18:23 PerlJam (I think a no-code-architect is possible, just the chances of success go dramatically down if the communication doesn't go dramatically up)
18:23 masak from what I understand of conventional projects, a significant re-focusing is made on what purpose the model is to serve.
18:24 masak it's no longer just going to point the way towards how the code will be organized.
18:24 masak it's more like... it's going to be in constant discussion, mediated by all the people on the project, on what shape the code will have.
18:37 PerlJam That's the "perfect world" scenario  :)
18:38 PerlJam The trick is just keeping the people on the same page.
18:39 masak from what I understand, DDD means to do that *through* the model and through a ubiquitous language.
19:09 masak re "perfect world" scenarios, I think that's the way it'll always be. the path the project actually takes through the solution space will deviate from some imagined ideal in many ways, and lessons will have to be learned through the noise of the deviations.
19:40 birdwindupbird joined #cqrs-perl6
19:57 PerlJam masak: I took a project management course once where the instructor did a really good job showing the deviations.   He went through this whole metaphor where you're the captain of a boat and the crew is your team and periodically you check your course and adjust for new information etc.
19:57 PerlJam The only problem with the metaphor is that in a boat, where you're going doesn't often move  :)
20:01 jnthn It works if you're guiding an attack submarine towards an enemy boat though. :)
20:02 PerlJam or maybe just two boats.  You're trying to rendezvous with another boat that's not trying to rendezvous with you.  :)
20:05 masak this reminds me of another metaphor that's been circling in my head lately. that of programming as a board game.
20:05 masak I'm almost at the point of blogging about it.
20:05 masak there are big similarities in how at the start of a board game, one knows too little about the later phases but still has to make a lot of big decisions, and program design.
20:07 moritz that's why you play a board game multiple times :-)
20:08 masak yes, and you try to find patterns, just like with programming.
20:08 masak sort of condensing repeating occurances down into general themes.
20:09 masak the big difference between the game and programming is that in the game, the opponent is a competing intelligence (human or artificial).
20:09 moritz speaking of which: http://boardgamegeek.com/boardgame/34585/keltis seems deceptively simple at first
20:09 moritz but makes a whole lot of fun with 3 or more players
20:09 masak whereas in programming the only "enemy" is the crappiness and restrictions of the physical world.
20:50 masak left #cqrs-perl6
20:52 masak joined #cqrs-perl6
20:58 birdwindupbird left #cqrs-perl6
20:58 masak left #cqrs-perl6
21:04 masak joined #cqrs-perl6
21:39 masak left #cqrs-perl6

| Channels | #cqrs-perl6 index | Today | | Search | Google Search | Plain-Text | summary