DISCLAIMER+SPECIAL NOTE: 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! ;)
—
[Post]
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.
Eric Fleischman 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.
Here’s why,
PLEASE NOTE: I don’t want to take things out of context, nor suggest that Eric is stating something that he’s not. With this disclaimer in place, my own interpretation of his point was that the alternative — in essence, a synchronous-only programming methodology — is the better choice. [see: Synchronous vs. asynchronous for more detail.]
Well, like I said, I don’t completely disagree: From an atomic level (speaking in terms of the hardware side of any given device, and even more particular, low-level bus operations), I really have no choice but to agree with Eric. But from a distributed computing, and in particular, a distributed programming methodology perspective, the notion of using a synchronous-only approach to the sending and receiving of messages between nodes sends shivers of pure, unfiltered fear down my (functional)XML hacking spine.
[OffTopic.Commentary.Start()]
I don’t know if you have ever experienced shivers of pure, unfiltered fear before, but let me just state that while I’ll claim you’re a liar, driven by politically-based intentions if you were to tell them I said this,
(((5 sisters) + (18 years)) == A personal, forever lasting foundation built upon shivers of pure, unfiltered fear) = true ; I mean false! I MEANT FALSE!!!! ***
[OffTopic.Commentary.End()]
Moving on! >>
Even with my spine still tingling, Eric’s comment does provide a fantastic example as to the importance of things likes closures and continuations. In short,
If multithreaded programming is the spawn of Satan, and (apparently) distributed programming Satan himself…
If nothing else, at least we can rest, reasonably assured that goodness will prevail, by containing the evilness (e.g. side effects) of multi-threaded, asynchronous programming methodologies to then continue forward in such a manner as to implement an atomic operation approach to asynchronous distributed programming.
Of course this is nothing new or revolutionary; as the title suggests, there’s a word for this kind of programming methodology: Functional
Enjoy your ((fun)ctional)) Saturday!
—
*** NOTE: For you Scheme purists out there, while you’ll need to place some additional restraint upon your desire to open up DrScheme to showcase, yet again, how the expression itself is worthless, syntactically offensive foo, please note the clever placement of the semi-colon before rescinding my claim of booleanic truth!
Of course, while it is only you and I that know the clever little trick I just pulled on the compiler, I can promise you one thing: Not even one of my sisters were fooled. Trust me on this: Regardless of whether the compiler took note of the switch, I can assure you that each and every one of them took note of each and every attempt to stear them off course, compiling whichever pieces “THEY DAMN WELL PLEASE!!!” into their newly versioned program: “Beat Mark Senseless (Without Ever Lifting A Finger)” version 2007 (thats the actual version number, not the year of its release. For you confused Microsofties: You’re just going to have to trust me on this one. ;) Extended Note: For you confused Unix-weenies, maybe “Beat Mark Senseless (Without Ever Lifting A Finger)” version 0.2007.0.0 will help? :D).
In short: I’m a dead man.
Again. (and again, and again, and a …)
Bye :)
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.
@Taylor,
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.
@Jason,
>> 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. > you've certainly done a fair bit of nudging yourself, thanks for that
I like & very like this iv@testtest.cz