This prototype is a failure of both design and usability. It's an offense and a joke against anyone who expects to be able to interact with a machine in an efficient and intelligent manner.
- It's ugly as hell
- A beginner is bombarded with way too many things to click on
- An expert is annoyed by useless buttons and waste of space
Sure, you can turn it off, but who wants to configure and reconfigure UI preferences for the rest of their lives (sidenote: reminds me of eclipse)? Sensible defaults, please.
Contrast this with Apple, whose designs often define what good design and usability means. In their apps:
- The appearance is simple, well-designed, elegant
- The only actions present are those deemed most necessary to the user
- Tons of functionality is hidden under shortcut keys, modifier clicks and context menus for expert users (after years on OS X, I still discover hidden elegance as a result of their zealous attention to detail)
Not at all. The things discovered are unessential to getting things done. It's usually just a nicer way or more of a "wow, I can't believe they thought of this crazy edge case".
Really like this counterpoint after all the LISP elitists so often snub other langs. The Ruby version is much more elegant and readable, in this little example. Would love to see more comparisons, specifically hacking around the lack of macros in other langs.
It's hardly much of a counterpoint considering Ruby took a great many ideas from Lisp. If anything, it's a rant about syntax. Overall though, it shows that Lisp did get it right. People love Lisp so long as it's dressed up to look like a non-Lisp.
Being a Lisp enthousiast myself I often find those LISP elitists are people new to the language repeating the tired arguments we have heard so often before.
I "got it" after reading a bulk of SICP and watching some buddy-lectures at http://academicearth.org/courses/the-structure-and-interpret... (I've also started SICM: it's awesome how they use Scheme.[1]) Nevertheless there's still a level I have yet to reach that I hope to achieve with Clojure (which has recently jumped to the top of my list of languages to learn). While Lisp (Scheme in particular, though CL is nice too) is near my heart, my brain still thinks in Python, Python makes me Happy, and that hinders my speed and concentration when I do stuff in Lisp. I liken it to my experience trying to (unsuccessfully) master Dvorak. The layout was easy to memorize so I could touch-type, I could easily see the benefits, and if I ever get spasms in my hands I'm going to force myself to switch over, but dropping from 80-100wpm down to 10-30wpm was too much loss that I didn't let my finger-muscles relearn and so I'm still with QWERTY.
[1] Even though it's trivial I still adore this simple example:
guile> (define D derivative)
guile> (define f (literal-function 'f))
guile> (define f^2 (expt f 2))
guile> (pe ((D f^2) 't))
(* 2 (f t) ((D f) t))
Add in the little things like being able to have boolean-returning-functions ending with '?', Lisp is very free.
Both lisp(s) and smalltalk took me about 18 months of decently serious use before I had a 'I get it moment'. Stick with it and it will come.
I'm hoping that if I keep at it with Haskell, that eventually I'll have my 'I get it' moment with it as I think I can learn a ton from when I get it, much like I did with Lisp and Smalltalk.
I've learned things from many different languages but the two I've learned the most from where Lisp and Smalltalk.
Every time I see a new shiny text editor for mac, I'm like "meh". I would have been excited in my pre-vim days, but now? Nothing touches vim, unless it improves on vim.
Agreed. This is the second time this has happened to me in the last few months. Using GitHub repo followers as a spam list is unacceptable and makes me immediately dislike the project that the spammer is trying to make known.
One thing that wasn't mentioned was template bundling with sprockets. A hack/workaround was posted at https://gist.github.com/989891 but I would really like to know if there is or will be a recommended way of doing it.
The latest Sprockets beta has JST support, heavily inspired by Jammit's approach. Load either the ejs or eco gem in your app, then put a "foo.jst.ejs" or "foo.jst.eco" in your load path. Require it from JS and you'll be able to access the compiled template as JST["foo"].
Cool! I use a version of haml-js that's been modified to work well in the browser. (https://github.com/wintondeshong/haml-js). Jammit allowed me to set the template function as Haml and it just worked, by passing the content of the jst files to the Haml() function. Is there an equivalent in sprockets?
UPDATE: As much as I like Haml, I think I'll just switch to eco, since it seems better integrated for now, and... CoffeeScript! Now all I need is haml-coffeescript / eco-haml. Well it turns out this does exist: https://github.com/9elements/haml-coffee. But I don't know how much work I'd need to do to get it working with the sprockets asset pipeline?
