esessoms
But, yes, looking forward to really using it at work this week. I hope to have more useful/constructive feedback for you after that.
One concern I have is there doesn't seem to be any sort of persistence. I can argue that this is actually a feature: if you don't know what you need to be working on when you sit down at the keyboard, you have bigger problems. (I may be influenced by Jeff Atwood in this respect.) In practice, however, it might prove useful to carry over unfinished tasks from one session to the next. Maybe a simple persistence scheme like that used by TiddlyWiki would be enough to get the job done?
Also finished tasks disappear. It would be nice to be able to review and figure out where the day went. But that way lies feature creep.
But, anyway, those issues are minor compared to finally getting workflow right (for me, YMMV). I'm really excited.
Thanks for sharing this!
So while the tools are roughly equivalent in capability, if you're new to configuration management in general I think you'll have a lot better success getting started with Puppet.
Either way, good to know.
...gets back to work hacking in SBCL.
Scheme may be simple, but scheme macros are not. They go way overboard in trying to protect you from yourself. I'm glad to see Arc moving back in the direction of CL macros, which I think makes it a very interesting alternative to Scheme.
But, seriously, they've been talking about this GPU work for upwards of a 1.5 years now. Usually we get something to play with, even if it's pretty badly broken (I'm thinking NDP here), so the lack of code here is pretty atypical. The accelerate link above is news to me, though, so that's helpful. Hope to see more soon!
* EDIT (to back up my 1.5 years claim):
earliest mention, May 15, 2008: http://www.cs.chalmers.se/Cs/Grundutb/Kurser/svh/Slides/may-...
Chak's own work, Jan 10, 2009: http://www.citeulike.org/user/iff/article/3872848 http://www.cse.unsw.edu.au/~chak/papers/LCGK09.html
and, of course, accelerate ("reference implementation") was only released Aug 17, 2009: http://hackage.haskell.org/package/accelerate
http://blog.digsby.com/archives/68
The license agreement is simply worded so as to make this possible.
I only assert that once your (well, my) code base grows beyond a certain size---for me, a few thousand lines, but probably an individual threshold---JS can start to become unwieldy. That "unwieldy-ness" is a problem that Java/GWT does solve. In these cases I prefer Java precisely because it is more constraining.
I think such a developer (one that has strong knowledge
of both JavaScript and Java/Python/Objective-C and still
feels compelled to use one of the abstractions) doesn't
really exist - at least not in any significant numbers.
First, history: Roughly ten years spent programming in JavaScript (it's hard to believe it was that long) before GWT came out in 2006. Immediately tried GWT, found it too heavyweight, and returned to JavaScript (jQuery, specifically) for another two years, before finally really moving to GWT over the course of the last six months.
Experiences: It really is not possible to write a significant GWT program without good knowledge of JavaScript. I think, on average, every Java class I write has one JSNI (JavaScript Native Interface) method, usually to work around some deficiency in the library but sometimes just to circumvent Java's type system. That's not counting the classes that are pure JSNI that exist to wrap up some JavaScript functionality.
It has also been my experience that it takes roughly 4 lines of GWT code to do the work of 1 line of JavaScript (with a good library such as jQuery). That's from comparing LOC counts on a handful of medium-sized projects I implemented with both technologies.
So, why? The thing that keeps me using GWT even though it is an incomplete abstraction that requires more code is organization. Partly that comes from the fact that OOP is a better fit for GUI programming than the functional paradigm. Mostly it comes from having a nice build system that lets me organize my code in the traditional Java hierarchy. There are lots of ways to try to organize large JavaScript projects---I think I've tried them all---and none have every really felt satisfactory to me.
In the end, most of the time when I'm writing a web page I reach for jQuery first. But when the functionality of a web page crosses over some ill-defined threshold such that I start thinking of it as an application in itself, I change my tools and reach for GWT, all for the benefit of (to me) better organized code.
YMMV.
(Edited for formatting.)
And there's this very exciting new development:
http://webanywhere.cs.washington.edu/wa.php
Just for completeness, I'll add this link:
Really, though, the problem is one of established vendors with a lock on the market and, consequently, little motivation to improve their products. Sound familiar? At first pass, this would seem like prime breeding ground for startups, but there are serious barriers to entry.
The biggest obstacle for new products is just that visually impaired users are taught to use JAWS from the get-go: they have the educational market. Yes, they hate it, but when you can't see it's very hard to comparison shop. All screen readers have a big learning curve.
Then, if someone could find your product, evaluate it, and like it, well... most people in the target market are not self-sufficient, and would not actually be able to pay for it. (You would have to market to the charities and grant foundations that purchase the products for most users.)
Oh, and did I mention that it's not easy to write a screen reader in the first place?
As much as I would love to see a startup come into the arena here and change the rules, I think instead we just have to hope for the success of these various open-source projects, and be glad that there are people who take this problem very seriously and are working on it.
Until then, designers and programmers will have to cater to the various quirks of the market leaders. This article is one of the best guidelines for that I've seen.
Working a job was the worst thing I ever did for my health. Now that I'm at a startup, I get plenty of sleep and exercise and eat healthy, home-cooked vegetarian meals. And the stress involved in working for myself is so much less that that of working for a PHB... I could never go back.
In the last two years, I've lost 50 pounds. I recently completed my first century. I'm in the best shape of my adult life. I sincerely attribute all this to being my own boss and setting my own schedule. Am I really the only one who finds the startup life superior???
But to answer the question posed by the article, FFI binding to the C erl_interface quickly gets very nasty, with lots of manual memory management. (It was the first thing I tried, since PLT has such great FFI support.) It's actually much easier to just speak the wire protocol, esp. with the Distel source to build on.