On (define fu-lst (list (lambda (closures continuations asynchronous-operations) aka(functional-programming))))
by M. David Peterson
: If your initial reaction to the titled attempt at a Scheme expression was: "That doesn't even make any sense!" my response to you would be,
- Firstly, how many people on this planet actually know that, technically speaking, it's complete non-sense?
- Secondly, you try writing a title for a piece using a technically correct scheme expression that includes a function, list, a lambda expression, and its evaluation expression, and then come back and tell me that it technically doesn't make any sense! ;)
- Oh, and before you snap open DrScheme, there fly-boy, remember that your technically correct expression must all fit on one line! ;)
Dare Obasanjo recently had this to say about multithreaded-programming,
Dare Obasanjo aka Carnage4Life - (thread.Priority = ThreadPriority.BelowNormal) is Bad?
This is yet another example of why multithreaded programming is the spawn of Satan.
then followed-up with,
FWIW, there is something worse than multithreaded programming....distributed programming. Concurrency on a node is hard, concurrency across N nodes is even harder. :)
To be fair, I don't completely disagree with either of their points. That said, I also don't completely agree, either.
I think you're totally right about the usefulness of functional ideas in this context. And thanks for pointing that out! (It's always good when someone brings positive visibility to the benefits of functional programming.)
I postulate that as software complexity increases (e.g. through heavy reliance on concurrency), the properties of the functional paradigm in general (e.g. limiting or eliminating side effects) as well as features of functional languages in particular (e.g. macros in Lisp, monads in Haskell) will be a great help in solving the next great "hard problems" of computer science and software engineering.
|M. David Peterson
Thanks! Jason Kolb ( http://www.jasonkolb.com ) and I recently had a discussion in which the conclusion was something along the lines that...
"... while it seems that we're each coming at it from a slightly different angle and/or perspective, it seems that we hackers all seem to be (somewhat) independently merging our thoughts and therefore our practices towards the same general area."
I think that is true about the emerging generation of distributed computing. The Ajax trend I believe represents the precursor of the push towards a grid computing-influenced distributed application architecture on the web. Obviously distributed computing and grid computing are like two peas in a pod. In fact, I might even argue they're the same pea! ;) (though they're obviously not.) Both Dare and Eric bring out two very valid points. From an imperative programming perspective, finding yourself in "bug trackdown mode" due to unintentional side effects is infuriating!
In my own opinion, even forcing myself to think in a way that will ensure zero side-effects is frustrating. I would *MUCH* rather just write my code using side-effect free coding methodologies, knowing that in doing so I won't be spending the next six months fixing all of the unintentional side-effect-based bugs in the code I've been writing for the last six months.
Of course the flip-side is that you have to force yourself to write code differently. And I'll be the first to admit that making the switch from an imperative/procedural approach to programming to a declarative/functional can be a bit daunting at first. But to each of you out there that might read this that don't already agree: I promise you; The switch is not as hard as it seems at first -- When the light switch clicks, and the declarative/functional room fills with light for the first time, you'll begin to see things and understand things in ways you had never even realized were possible. And they're SO SIMPLE!
Of course you won't realize just how simple they are until you have a bit of experience behind you, which might sound a bit like an oxymoron. In fact, I guess it kind of is. But the reality of both my own experience, as well as countless others I know in whom feel the same way: When you stop trying to force your code to do things a certain way, and stop think in terms of changing values, capturing events, etc... you reach a point where you are no longer thinking in terms of "How do I do this?" (or worse: "How do I fix this!" ;)) and instead "... and for my next feature I will add ..." In short: Instead of spending the next six months fixing the bugs of the first six months, you'll be spending them adding features, or making your code faster, or -- vacationing ;) :D
Thanks for taking the time to comment, Taylor!
Heh, how true M. It's funny, because every time I think "ok, NOW I know everything I need to know to do what I want to do", I run into another stone that I hadn't looked under before. It's frustrating as hell sometimes, but it's ALWAYS worth the effort to look under them all. However, like you said, sometimes you have to have some relevant experience under your belt before you can truly appreciate things like functional programming. I know I for one would not have looked twice at it early in my programming career--I could churn out code like a champion, and everyone loved that part of it. However I doubt the people that are maintaining that code now love it quite as much, and I sure wouldn't want to go back and work on it now :)
I try to keep myself from feeling like I know it all at all costs now... if someone tells me I need to look at something that I'm not familiar with, I pretty much drop what I'm doing and become familiar with it. I've saved lots of time that way. One of the coolest things about the Internet, IMO, is that I'm surrounded by lots of smart people with diverse backgrounds who can give me a nudge in the right direction (you've certainly done a fair bit of nudging yourself, thanks for that ;), or a good firm digital slap in the face when I'm totally misguided about seomthing.
|M. David Peterson
>> However I doubt the people that are maintaining that code now love it quite as much, and I sure wouldn't want to go back and work on it now :) <<
You gotta appreciate honesty! :D
>> I try to keep myself from feeling like I know it all at all costs now... if someone tells me I need to look at something that I'm not familiar with, I pretty much drop what I'm doing and become familiar with it. I've saved lots of time that way. <<
I'm of the EXACT same mentality -- in fact if I were to characterize my life based on my perceived knowledge, in my teens I did know everything, my twenties I thought I knew everything, in my thirties I've realized I don't know jack and the best I can do is read LOTS of books and just keep hacking until something works.
My guess is by the time I'm fourty I just won't care enough anymore, satisified with a life known as the village idiot (no comments from the peanut gallery! At least not for another six years ;) :D)
On a much more serious note, I do whole heartedly believe that the best way to get somewhere in life is to find others who are heading the same general direction yet don't have a clue where that direction will lead. I don't mean that in a "hazed over drug" context, and more of a Lewis & Clark exploration/adventure. Life can be a lot of fun if you are willing to share what knowledge you have with others who share their knowledge in return, of which the sum can then be used to get to the next undefined step -- whatever that might be.
>> you've certainly done a fair bit of nudging yourself, thanks for that <<
Please see above and count yourself backatchya'd ;)
I like & very like this email@example.com