Today we have Java yielding, thread ranting, REST lecturing, and identity insight.
Yield! · On the Chaotic Java weblog, Java “yield return” code published. Anyone who’s gotten comfy with Ruby’s yield/block idiom quickly starts to wish that every language had it. I haven’t had the time yet to do a deep-dive on this, but that’s definitely on the to-do list.
Threads ewwwwwwww · Roman Shaposhnik has The problem with threads, a nice succinct explanation of why, from a programmer’s point of view, they pretty well suck. I freely admit that since coming to Sun, my opinion on this has shifted 180°, from “threads are tough but worthwhile” to “Let’s find some combination of functional programming and message passing so ordinary people never see threads”. Roman has some of the reasons why.
REST Hard? · Patrick Mueller (who’s appeared here before) has how RESTy need we be wondering, how far down the path of pure REST, as notably taught by Joe Gregorio, we need to go. The question is worth asking, but I think Patrick goes off the rails, claiming “Here's my thought on the lack of adoption of REST: it’s complicated for anything but the GETs.”
Um, evidence please? I just finished building a 100%-pure-REST data store; it’s only a few thousand lines of code and a few weeks work, and that’s coding in pure grim unforgiving C, using the poorly-documented and without-a-safety-net Apache module API.
Identity Lock-in · Dave Winer’s been saying this really smart thing for years and years: “People come back to places that send them away.” For an example, think of Google. In Lock-in and the web, day 2 he applies the principle to the identity world. The conclusion: “A vendor will come along and they’ll store your identity but give you complete freedom to move it where ever you want when ever you want at no cost. They’ll make it easy to do so. And they'll get rich doing it, if they want to.” Yup.
Contributions
· Technology (90 fragments)
· · Concurrency (76 more)
· · Identity (44 more)
· · Java (123 more)
Comment feed for ongoing:
From: Patrick Mueller (Aug 05 2007, at 11:35)
Your "100% rest-store" (very cool btw) has at least two RFC's worth of data definition and semantic behind it.
Note what I said in my post about this being complicated: "Not technically, but semantically." Once the semantics have been defined, a sponge could implement the technical details (now that's going off the rails, perhaps).
How many calendar years and person-hours were spent on defining atomPub semantics? That's where I have issues today; implementing PUT, POST, DELETE logic in anything (but c, heh) is child's play; defining what that PUT means is something else entirely.
[link]
From: Charles Oliver Nutter (Aug 05 2007, at 12:28)
Re threads: I'd say the problem isn't threads as a system or runtime-level concept; the problem is that they should probably not be exposed to the user, and the user should never have to worry about them. It's generally the same as what you're saying: we should build systems and use languages that can take advantages of multiple threads (i.e. multiple cores) without looking like today's threading APIs and concurrency models.
Given that OO isn't going anywhere and isn't going to transparently multithread, I think we've got a lot of work to do to completely hide concurrency from users. But eliminating explicit thread APIs (as is done in some of the Java concurrency utilities) is a good first step.
Languages like Ruby that not only have explicit thread APIs but also allow users explicit control over the lifecycles of those threads (stop, kill, raise) should be considered a step backward.
[link]
From: Dan Jemiolo (Aug 05 2007, at 14:32)
I think you've mis-read Pat's comment, particularly the second-to-last paragraph. He isn't saying that non-GET situations are fundamentally hard; rather, there is not clear argreement among RESTafarians on the "official" way to apply the other HTTP verbs. So, you may have rules and conventions that cover all your edge cases and work very well for your project; we have our own conventions in Project Zero, and I'm sure there is a lot of overlap between the two sets. It's the fact that there is not 100% overlap (and neither of us is accusing the other of being "wrong") that is causing confusion among non-RESTafarians.
REST is great, but just reading the HTTP spec and Fielding's thesis has not made implementing it as easy as 1-2-3. If that were the case, forums such as rest-discuss would be quieter and full one-answer threads.
[link]
From: Alan Little (Aug 05 2007, at 22:58)
“Let’s find some combination of functional programming and message passing so ordinary people never see threads”
Hell yes. Ten years ago, remember, hiding memory allocation form ordinary people was controversial and believed by many people to be too inefficient for "real" work.
[link]
From: Eric Cestari (Aug 06 2007, at 03:00)
on threads ewwwww.
I've recently started using Erlang. And the design exactly what you're talking about.
Joe Armstrong explains it here :
http://armstrongonsoftware.blogspot.com/2006/09/why-i-dont-like-shared-memory.html
(one of the commenters on Roman's post did mention Erlang, yet I thought it deserved another mention here :)
[link]
From: Andrew (Aug 06 2007, at 13:12)
On threads...
Whenever I read an article about threads being too hard for mere mortals it always reminds me of those studies that find the majority of people believe themselves to be superior car drivers. The implication in these threads-are-too-hard articles is always that whilst the author can handle the complexity there aren't many other people that can.
Threads have been around for a long, long time in the embedded world and despite ever increasing complexity that code almost always just works. When was the last time that you heard somebody complaining that their (non-smart) cell phone locked up or spontaneously rebooted in the middle of a call?
I can tell you first hand that this isn't because the engineers that work in the embedded space are somehow smarter than the average Java developer working for a bank. It's just that we've had a lot more experience with threads and we have access to some great visualization tools.
It'll take time for the rest of the world to catch up to the experience level and toolset of the embedded world (with DTrace Sun clearly has a leadership position here) but I have absolutely no doubt that it will happen.
[link]