Of course…it has been left to we developers to uphold and maintain these standards of programmer usability….so I would like to declare a new position/job title!

PUX! Programmer User Experience….Lead…er

Comments: “Don’t worry about it, mine smells even worse.” “Yeah, just put a peg on your nose and ignore it.” “Other fridges don’t have nearly as much stuff in them.” “Why don’t you mention the ugly fridge magnets on the front door?” “Clean it yourself!”

I liked your assumption about Apple’s policy. I wouldn’t be the least bit surprised if you were right.

For example (stupid examples, but examples nonetheless), let’s say you type in the directory you want to go to, but forgot to type ‘cd’:

$ directory1
$ cd !!

That will get you what you want. Or lets say you typed in cd but forgot the directory (of course, cd without an argument will take you to your home directory, but let’s say you’re already there):

$ cd
$ !! directory1

Will get you what you wanted. Stupid examples, but it shows the power of it.

For video out..I suppose there is a possibility for it to have a dongle to allow for this in the future. I’d be tempted to see if the ipod video out dongle works on it.

I also don’t know that this iPDA will be a success. I just don’t feel like it has a market except for the executive types that just like to have the new toys yet don’t know how to use them.

On the 3G front though…the $30 a month for unlimited data is not bad and I think is actually a selling point.

Do you suppose Apple’s strategy since the iPhone is to release a low-end version of a product, then release newer, better ones? Amazon did it with the Kindle. It makes a certain amount of sense: you can see what features users are most hungry for. Of course, Apple isn’t really one to add those features as much as just add features, so it seems more like playing it safe to me: release a low-end product that you know works, then add features incrementally, knowing it works all the way. That’s good too, but it allows for solid rants when the first product comes out (especially after so much hype).

http://www.amazon.com/Googling-Security-Much-Google-About/dp/0321518667/

Should be a good read.

http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_543~129241,00.html
http://www.top500.org/blog/2009/11/15/great_leap_jaguar

Me: “What? there’s no tenth function?” Clojure: “Write it yourself. (defn tenth [seq] (nth seq 10))”

Write it yourself is pretty much clojure’s answer for any question. You got a problem with the language? Change it. You don’t want to change it? Fine, don’t use clojure.

* dosync
* alter
* macros
* auto-gensyms
* defmulti
* destructuring
* persistent data structures
* the *-in functions
* maps as functions
* *warn-on-reflection*
* metadata that is just data

Cheers!

Usage variations could be like the following:
(slice coll [index])
;; and/or simply: (slice coll index)
(slice coll [start end])
(slice coll [start end stride])

And, to get the equivalent of Python slices
where the numeric values are not supplied,
like coll[::-1] and such, you could use any non-numeric such as :_ as a placeholder, like:
(slice coll [:_ :_ -1]).

After thinking about this, I searched and found the following thread that talks about similar stuff – not exactly the same, but has some implementation ideas:
http://www.mail-archive.com/clojure@googlegroups.com/msg17443.html

Python’s my favorite language, but I’ve been learning about Clojure because of the way it handles concurrency. It has its own elegance and consistency in other ways.

Consider this, just to focus on some of what is mentioned in this post: In Python you can slice lists and tuples and strings and even the “generator-like” xrange, but not generators. In Python, if you have a list of lists like:

x = [['a', 'b', 'c'], ['d', 'e', 'f'], ['g', 'h', 'i']]

You can do:
x[0][0]
to get ‘a’, whereas in Clojure you might do:
(ffirst x).

Similarly:
x[0][1:]

would give you ['b', 'c'], whereas in Clojure,
you might do:
(nfirst x)

And:
x[2]
Would give you
['g', 'h', 'i']
similar to (nth x 2) in Clojure.

But if you had, say, a generator that returned generators instead… consider the following toy example that returns the same values as above:

x2 = ((chr(x+i) for i in xrange(3)) for x in (97, 100, 103))

You couldn’t handle it the same way in Python since trying to slice x2 (or the generators it produces) would give you:
TypeError: ‘generator’ object is unsubscriptable

But, you can (arguably more consistently than Python in this respect), use those same Clojure functions on Clojure’s lazy equivalent:

(def x2 (for [x [97 100 103]]
(for [i (range 3)] (char (+ x i)))))

(for creates “list comprehensions” in Clojure, but unlike in Python, list comprehensions are lazy in Clojure.)

I am not saying here that Python should have slicing of generators. It works in its own way with generators getting consumed as you call next(). But Clojure has its own goodness going on with its immutable and persistent data structures. Python is awesome, but Clojure is worth delving more into.

I could do without the JVM, but a better functional programming language would be something to talk about.

“It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.” -Alan Perlis

Matter of fact, that’s the same for namespaces/packages.

Good news for a n00b is they can just ignore all that for the most part. You just need to learn the base functions. Then you add more over time.

e.g. you can learn to use (first seq) and (rest seq) and combine those to your hearts content. Then when you stumble upon (ffirst seq) you realize you no longer have to write (first (first seq)) How often do you need ffirst -well, not nearly as much as first or nth.

Lisp programmers like a large library of composable variations on a base set of functions. That is kind of a highlight of functional programming. But in OOP the Smalltalk language takes a similar approach: many variation of base methods, e.g. the collection API.

I am not sure why Python would prefer a “one way for one thing” approach, but that would certainly not be the Lisp way.

My biggest question regarding the 10/GUI video is: does having all of the windows in a horizontal array actually make the windows easier to find than our current random window model? They suggest it does, but I’m not sure I’m convinced. If you applied some GUI math for distance traveled I bet you could figure it out, but if the horizontal array wins, I bet it’s only by marginal means. I think accessing windows on the ends of the array would still be cumbersome.