json.py is intended to be a straightforward implementation that can be easily duplicated in other languages.
"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.
Friday, August 05, 2005
Do American programmers have the right to work in America?
Update: Someone commented...
US Constitution does not garantee employment opportunity for any specific type of job.And of course this comment is correct. So I clarified the title of this entry. See the parenthesis.
This comment really misses the point of the referenced article. The visas are intended to bring in temporary skills from outside the US where those skills are in short supply.
If US citizens are unable to even *apply* for the more than 50,000 open positions, how can anyone tell that these positions cannot be filled by Americans? That is the point... the powers that be are circumventing the purpose of the visas (i.e. fill a temporary labor shortage) in order to gain an advantage over American workers (i.e. bring in more labor and lower the demand for salaries) that is unintended by the visa laws.
Is that more clearly stated? This is not about a right to work. It is about a law and the circumvention of that law for anti-competitive purposes at a time when many Americans are losing careers and only replacing them with lower paying jobs. That may well be a trend of the emerging global economy, but that does not excuse the practices by the US department of anti-labor in these 50,000 plus positions. There is no right to work, but neither is there a right to exclude Americans from applying for jobs in America, for crying out loud. Get real.
While the APP is 'just a' publishing technology and Atom is 'just a' syndication technology, there are five reasons to that microprotocols - namespaced module extensions that inform and affect application behaviour - will appear as an alternative to WS and SOAP based technologies by targeting enterprise computing concerns like reliable messaging and tracking.Hmmm.
Via the Register...
EDC believes PHP's recent glorious past is over, as customers spend money on "more important" technologies to build mission critical systems and vendors like Microsoft and Sun Microsystems make more of a concerted marketing push around alternatives such as ASP.NET and JavaServer Pages (JSP).
SOAP vs. HTTP... Phil Windley blogs about Randy Ray's talk at OSCON 2005. Ray suggests an example where SOAP is better than HTTP. Phil's paraphrasing...
The CalculateRoute API allows not just a start and end point, but also an arbitrary number of waypoints along the way (to calculate the route for an entire trip).But we can get WSDL and SOAP to fall down flat as well. This route calculator takes a fairly simple list of values. A more complex calculator could take fuzzy values... for example a preference rather than a requirement to travel through a particular location, or a preference to travel through a particular location if the total trip time is not more than N time units, or...
Since this is a constant resource—the route won’t change (much)—this should be a GET request with a URL. Designing such a GET request is difficult. There’s no real standard for creating a REST protocol. There’s no WSDL.
The example can easily exceed the ease of expressing in WSDL. Then what's the value of WSDL? WSDL maps fairly well onto currently popular imperative languages, not very well onto constraint logic programming languages or deductive logic languages, or...
GET in HTTP seems to me similar to an object reference. Sometimes a query is needed to get the reference in the first place. But once I have it, I can "dereference" it over again.
I suppose POST is the means to do the query, and POST can take arbitrary data just like a parameter in a WSDL definition.
So I guess I don't get the argument. Certainly WSDL is not the end of the story except for some small set of convenient API's similar to those you'd write in Java, C#, or C++.
Matt Stansberry writes...
What is holding High Performance Computing back?
With the hardware becoming commoditized, why aren't more companies using HPC? According to a report from IDC and the Council on Competitiveness, minimal support from software vendors and a lack of training are the culprits...
Writing code to take advantage of the new clusters means scrapping the code written for the scale up models of the past, an expensive proposition.
Thursday, August 04, 2005
Ted Leung writes about Portland...
Being at the convention center is helping me to discover more about Portland. The free ride zone for the Max train is a thing of beauty. I had thought Seattle's bus free ride zone was good, but the Max train beats that all to pieces. Combine that with Portland's short city blocks, and wonderful downtown, and it's all very appealing. I've had lots of conversations (usually on the way to meals) about how nice Portland is.This is where we are supposed to tell you how much it rains in Portland. That's a tough sell this time of year... typically nothing but blue skies for weeks.
But there is a reason OSCON is not held in Portland in November.
Wednesday, August 03, 2005
A photo from an OSCON 2005 attendee shows why I live in Oregon. This spot is about an hour from my house. It doesn't get any better than this for me. If you don't like the rare 90F days in the summer, just drive over the Coastal Range an hour and you are likely to get 60F because the hot valley is sucking all the moisture in from the Pacific. Camping on the beach in August often means you'll be wearing sweatshirts and jackets in the afternoon.
Jonathan Robie, in an interview with Jon Udell, captures the reason for failure of the object database market better than any explanation I've seen...
JR: OQL is a nice language. The grammar of XQuery has benefitted a lot from it, and some of the implementation has too. Of course, it wasn't commercially relevant for the object database vendors to implement OQL in any kind of complete way.
JR: Every object database had a different market, and a different model, and people weren't looking for interoperability between ObjectStore and POET, because why would you use them for the same thing?
Someone who proposes to run Windows on servers ought to be prepared to explain what they know about servers that Google and Yahoo don't know...Aw, just go read it. There are too many gems to quote.
The NYT front page is a list of people who write for the NYTs. Del.icio.us is a list of people who are interesting. You can see them side-by-side. You can see how little overlap there is...
Start-up environments are more like home work environments. This is probably the most productive the company is ever going to be...
Meetings count for work, just like programming, but they're so much easier.
Chris Double writes in a comment about Factor and his concurrency model...
I'm also keen to look into capabilities and how support for that could be added. But I'm completely unknowledgable in that area at the moment.I intend to look into this with Termite and hopefully discuss this with Guillaume and I hope others.
The basic idea is to give each process its own set of known capabilities and aquire new capabilities from other processes (some coming from the "outside" world). A capability would be the ability to send a message to another process and some fundamental actions like spawning a new process, file I/O, etc. Joe Armstrong's work on unifying these actions as all being message sends would help with the design.
This implementation would require capabilities (e.g. process ID's and perhaps node ID's) to be unguessable and unforgeable. Rather a Pet Naming scheme would make capabilities more usable for developers.
Similarly connections to the outside world, e.g. the Internet, would apply the concept to URL's and so on.
Update: This reminds Chris of Plan 9. Just so... Plan 9 I recall has the same ability to map a tree of names (i.e. file system) onto a set of capabilities (i.e. the actual files, drivers, etc.) such that any given user's tree of names will refer to potentially *different* objects, based on the capabilities that user has.
Tuesday, August 02, 2005
As relayed by Blaine Buxton...
"Finally, the days where a novice programmer can know all of a language are gone, at least for the languages in widespread industrial use. Few people know "all of C" or "all of Java" either and none of those are novices. It follows that nobody should have to apologize for the fact that novices do not know all of C++. What you must do - in any language - is to pick a subset, get working writing code, and gradually learn more of the language, its libraries, and its tools."
-Bjarne Stroustrup from "Why is C++ So Big?"
"If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual."-Dan Ingalls from Design Principles Behind Smalltalk
Catching up with things missed while on vacation. Bill hÓra writes...
Technically speaking a list module is so simple, so trivial, that my best guess has been that we developer types just haven't bothered to do it... Socially and commercially however having a unified list format that isn't buried in HTML is going to be insanely valuable. The problem with HTML lists is that you can't get at them, class them, tag them, most importantly, share them...Whatever happened to microformats? List up to three things:
- Item 1 here.
- Item 2 here.
- Item 3 here.
...it's the XML, stupid.This is my way of saying I *still* don't get XML. I make no apologies.
For the record, I had the same reaction to OPML. I still don't get that XML either.
Do we need OPML *and* MSFT Simple List Extension? Do we need either? I am unconvinced.
- ► 2011 (19)
- ► 2009 (40)
- ► 2008 (402)
- ► 2007 (388)
- ► 2006 (261)
07/31 - 08/07
- json-py update
- The Right to (Apply for) Work?
- Things That Make Me Go Hmmm
- Crystal Ball of Mud
- Liberation Theology
- Arbitrarily Complex Messages
- Why I Live in Portland
- Why I Live in Oregon
- Whither Object Databases
- Gems: Servers, Blogging, etc.
- Adding Capabilities
- In a Nutshell
- Lists. Really? Can we expect better?
- The Problem with Data
- ▼ 07/31 - 08/07 (16)
- ► 2004 (534)
- ► 2003 (286)
- Patrick Logan
- Portland, Oregon, United States
- I'm usually writing from my favorite location on the planet, the pacific northwest of the u.s. I write for myself only and unless otherwise specified my posts here should not be taken as representing an official position of my employer. Contact me at my gee mail account, username patrickdlogan.