I'm sure you are right. I'm going to have to be good at making these arguments with my coworkers (or find somewhere else to work, maybe? :) ) so I appreciate the depth people are going to.
One of my next bouts of confusion is going to come from trying to figure out what's already done. Like I read a Brodal paper once one purely functional heaps implemented using a forest of persistent skew-binomial trees. But is that sort of thing already all done? Do I just find a heap and know that find-min and reduce-key are as fast as they can be? That'll be interesting. I also want to play around with a parallel knapsack solver. Also I want to integrate clojure with JMonkeyEngine and do some parallel graphics/physics stuff. Still, the riskiest part of this all is the programming environment, as I see it. The language is pretty unreadible, so say many people who haven't given it the 3 weeks (that part doesn't bother me -- just gotta learn it). But things like the errors not referencing clojure line numbers? No way that I have figured out how to step through code in a debugger? Well, it's a hard sell without an 800-core machine sitting right in the room begging to be programmed on. On Mon, Jan 12, 2009 at 12:53 AM, Adrian Cuthbertson < adrian.cuthbert...@gmail.com> wrote: > > Bear with the trials and tribulations (of grokking > functional/clojure). It takes a few weeks of trying things out, > absorbing the documentation and group archives, watching the group > posts and then suddenly there are one or two "aha" moments and then > the flood gates open! When you've crossed the threshold, it's too late > - you can never go back. You'll want to go and redo everything you've > ever done imperatively! For me the "aha" moments came when I first > (really) understood reduce, map and fn. I'd reccomend focusing on > those and trying to (first) do all your looping constructs with those > rather than loop/recur - that forces you to learn to think functional > while loop/recur still lets your mind stick to imperative patterns. > > Regards, Adrian. > > On Mon, Jan 12, 2009 at 7:24 AM, e <evier...@gmail.com> wrote: > > here's a good explanation: > > > http://groups.google.com/group/clojure/browse_thread/thread/3c22b35f079e0de6/95fc0b334ab77c1f > > > > I wasn't thinking about closures since I've only recently even learned > what > > they are. I actually don't know if it will ever occur to me to use them, > > but it sounds like they are the reason we are encouraged to jump through > > such hoops even for local variables. closures allow them to "leak". > > > > It's funny, whenever I tried to be all safe like this and take the time > to > > make stuff safe in C++, coworkers would say, "we are grown-ups. At some > > point you gotta stop being a paranoid programmer. Document the usage, > and > > woe be it unto the user who doesn't 'RTFM'". > > > > Another thing is to make the common case easy . . . .and uh, mutable > local > > variables are pretty darn common, as Rich anticipated when he predicted > that > > people would be excited about the 'with-local-vars' macro. I was > thinking > > the same thing, "fine, I'll learn how to write macros, then". I can see > > that this issue comes up again and again with everyone who walks in the > > door, and it probably will continue to. Who knows, maybe Rich will > change > > the world. It sure will take a lot of energy. That's for sure. > > > > On Sun, Jan 11, 2009 at 10:27 PM, Timothy Pratley < > timothyprat...@gmail.com> > > wrote: > >> > >> > thread should own the memory that's created. Each thread should have > >> > its own asynchronous stack to push local variables onto that no one > >> > else is allowed to see. > >> > >> Just for the record, Clojure does support local variable that behave > >> exactly as you would expect them: > >> (with-local-vars [x 3] > >> (while (> @x 0) > >> (var-set x (- @x 1))) > >> @x) > >> -> 0 > >> > >> Using an atom is unnecessary in this case because access is totally > >> local. Using an unsafe atom set is a bad habit, as discussed in detail > >> on another thread: > >> > >> > http://groups.google.com/group/clojure/browse_thread/thread/6497e7c8bc58bb4e/c5b3c9dbe6a1f5d5 > >> > >> However as you have already seen there are more elegant ways to write > >> the solution without either. > >> > >> > >> > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
