My initial impression is good. After a bit of difficulty related to the new App World 3 (I recommend sticking with v2 for now), my data and applications are restored and I am chugging away.

The keyboard

While most smart phones now use soft keys, I still prefer the Bold’s hardware keyboard. Those who share the preference will absolutely love the new Bold’s keyboard. For one thing, it is larger and wider, with a slight curve, making it easier to reach the keys on the outside. It feels very nice to use as well. Many will scoff, but I think that this is just about its most attractive feature; after all, the keyboard is so integral to the Bold experience that it makes a disproportionate difference in the “feel” of the phone.

Touch Screen

The touch screen is pleasantly surprising. The screen itself is crisp and bright, and very touch responsive. I was not a big fan of the new layout on OS 6, but with the touch screen it is quite easy and even efficient to use.

The screen is also slightly larger with a better resolution. Users of the Torch or other smart phones won’t see it, but Tour/Bold and Curve users will appreciate the boost in screen real estate.

The OS

OS 7 deals with most of the issues I had with OS 6. It is much faster, in part due to the new phone’s hardware. Transitions and effects are now hardware-accelerated, reducing the time (and power) required to process them. Not only is it faster than the slow, bogged down experience I had with OS 6, but it is snappier and more responsive than any BB I have owned to date. Even the Desktop-based interactions, like backups and sync, are much faster.

Additionally, universal search is faster and indexes much more quickly. Once painful to use in OS 6, it is now the fastest way to find applications and messages.

Battery life

Blackberry has always been king of battery life. No other smart phone ever comes close to a BlackBerry, and that has traditionally been one of the (extremely few) advantages of shipping much slower hardware.

That said, the new Bold has a smaller battery than my last Bold (the 9650), but appears to last every bit as long. Whether it is due to efficiency gains in the software or the faster hardware, it has made a difference.

It is not intuitive, but just as a heavier vehicle will use more gas with an under powered-engine, software can draw a lot of power when the hardware cannot keep up. This is especially true of embedded programming, where the environment places such constraints on resources. My suspicion is that the combination of GPU-accelerated graphics and better reception are helping to keep the OS from pegging the CPU so heavily. In any case, it is a welcome enhancement.

The ugly

I still can’t send pictures or video directly from the browser. You can only send or post a link, or go to the trouble of saving the file, sending it, and deleting it. I would not think it should be too hard to add this feature, and a number of folks miss it. It is one of those “super app” features that make BB pleasant to use. It saves time by linking apps tightly.

Conclusion

If you have been hanging onto your old Bold or Tour because of OS 6, now is the time to upgrade. It is well worth the money (to me, anyway) to get the new Bold 9930. it is everything I had hoped that my last phone would be, and BB users are going to love it. It is good to see RIM roll with the punches and get back up again.

Submit article

It feels pretty top heavy, though. I think they tried to bolt the QNX UI on top of BB OS, but without the power and efficiency underneath the hood to make it perform adequately on my handset. The 9650 seems high end for OS 5 but low end for OS 6. Some of the rendering, smooth scrolling, and transparency effects really bog down the system, at least on the 9650’s hardware.

The only other real problem I have with it is that it is missing a feature I really like from OS 5 – the ability to send a picture via MMS directly from the browser.

For a while, I used an OS 5 theme which eliminated many of the more expensive UI elements, like app tabs, but at some point I lost the ability to use themes, even after a clean install.

So for now, I’m back to OS 5, and my phone is much snappier again. Oh well. Better to be a big fish in a little pond, I suppose.

Submit article

The Playbook has suffered from a rash of poor reviews, largely due to the lack of apps and RIM’s decision to release without  the native PIM suite ready. These things obviously detract from the experience, especially the absence of email and messaging software.

I try to take the long view, though. This is a brand new tablet platform, and software environment will eventually get a complete host of apps, some useful, some not, just as is the case with the Apple app store as well as the Android marketplace. For the moment, though, it is mostly filled with what appear to be very mediocre experiments with the platform. Very few are worth the money at the moment.

The system is very slick, though. The navigation becomes very natural with very little effort, and the browser is lightening fast. The bridge functionality is excellent, although it will frustrate the unenlightened (read: non-Blackberry users) that it requires a Blackberry hand set to use.

Bridge is extremely cool. It gets overlooked as a stop-gap until RIM releases the official, native PIM, but it gives Blackberry users something important that a more typical suite might easily overlook. Messages are pushed to a Blackberry, rather than synchronized, as is the case with IMAP. Bridge maintains control over those messages on the hand held, rather than the tablet. That’s the right way, because a phone is going to stay with you much more than a tablet (new toy syndrome notwithstanding).

Bridge gives me an extra piece of awesome, too. The Bridge Browser, while not running at native speed, provides a decent web experience without tethering charges. That not only saves me money, but it keeps me feeling young by letting me pretend that I am sticking it to the man, and you just can’t put a price on that.

Therefore, I really hope that bridge is not condemned once RIM releases their PIM suite. I really want to see them add to it and give it the polish that RIM is so good at. I hope it continues as a special extra for BB users, and becomes fully integrated, which is one of the major areas of polish were RIM lords it over the competition

On another note, I also very humbly ask that whoever is in charge of the keyboard make it behave exactly as it does on my Blackberry. I am tired of having to type apostrophes and capitalize with a separate button, thank you very much.

Submit article

I have to admit that I occasionally resort to goto myself. This week was one such an occasion. But before you pick up your torch and farming implement of choice and join the mob heading for my castle gates, please consider that  Dijkstra’s letter was complaining about unrestricted goto, which was a popular feature of languages at the time. It was an unstructured precursor of the subroutine and structured programming, which put goto on a leash and taught it not to bark at the neighbors. In restricting goto to local jumps, as most modern languages supporting the feature do, the beast became much less fearsome. In fact, a while loop is just a structured goto, as is try/catch (albeit with a little extra magic.)

Perl, of course, does not impose such restrictions on a programmer (although it does prohibit jumping into blocks that require initialization, such as other functions.) With a little discipline, though, goto is a feature and quite useful. It can be used to make extremely complex loops explicit and easy to follow as well as allow a loop to break to any outer loop in the current call stack.

As an example, I recently wrote a function to increment a string of arbitrary alphanumeric characters, where letters must maintain their case but increment as base-26 numbers and numbers increment normally (base 10). For example, if a letter increments past z, it becomes a and the next character to the left is then incremented. The increment logic fit into a function that took two of these strings and calculated all possible values in between to support some limited set operations against two alphanumeric ranges.

My original code for the increment logic was grisly at best. It took a series of nested while loops and state variables that were incremented or decremented as needed. I avoided recursion because the sequences were of arbitrary length. Breaking the code into subroutines made it more complex to maintain loop state. Using goto allowed me to break apart the logic into blocks without the overhead or state-passing necessary to shoehorn the logic into subroutines. I was able to label each part clearly and jump between them as needed to increment or “carry the 1.” I reduced the size of the code to just a couple dozen lines, including safety checks, and found that the goto code was much easier to read and reason about.

That said, I want to emphasize strongly that goto should be kept local. Jumping to outer function calls makes the logic of a program difficult to reason about and changes scope in confusing ways. But as a way of structuring complex loops and iterative logic, you just can’t beat goto.

Submit article

At the dawn of time…

The old BBS is terribly antiquated by today’s standards. A sysop (or webmaster for you young folk) would dedicate perhaps half a dozen phone lines to their server, running MajorBBS (which was not a PHP-powered forum), Angelfire (which was not a defunct web hosting company), or Wildcat. Each had their strong points, but they usually had some form of user-to-user chat, in-system messaging, file sharing, and games (who remembers spending all night playing Legend of the Red Dragon or Tradewars?)

The Internet freed us from this more intimate world. Email now worked between all systems, and in-house email either conformed or disappeared. Prodigy and CompuServe died, while AOL adapted (for a while, anyway). Files could be shared simply and quickly, and anyone with basic knowledge of HTML and an ad-supported account somewhere could participate.

Modern day

These days it’s for granted that everyone and everything is connected. With Twitter, even an everyday Joe can be sure that all of their friends are kept up to date on how much they are enjoying that ham sandwich.

The social networking trend is interesting to me because I see it as a shift back to the more intimate realm of the BBS. Counter to the culture of full exposure engendered by the Internet, folks are gravitating toward sites that provide a more limited experience. Even the most curmudgeonly of us grudgingly accept Facebook and use it to filter our social lives online.

Networking sites provide a safe haven – a controlled community, much in the style of the old BBS. We prefer their primitive messaging to full-featured email clients when communicating with our friends and family, not because we are Luddites, but because it is more personal. There is something quite uncomfortable about sending your mother an email at hotmomma288@yahoo.com.

Looking back

This is something of a rehash of an article I wrote last year. In fact, reading back, I even took the same grumpy tone :). I was a bit late signing up for Facebook, but I have to admit that I enjoy it. Now, if they could just port Legend of the Red Dragon over…

Submit article

PHP was designed with the reverse in mind. In its first release, it could have been considered to be a DSL for web-based applications. It was written to specifically address the needs to writing web applications, and is now building toward a more general purpose language. In all likelihood, this is the wrong way around. It certainly does not fall into the bottom-up design Shangri-La of which Paul Graham is such a proponent.

In reality, though, web-based applications are driving the industry. PHP is still very relevant in that domain. From very early on, PHP was centered on functionality that is considered basic to any web-based framework. Functionality without which each library is simply a thin wrapper over CGI. Features like easy access to GET and POST variables, session handling, header control, and database access have been built into PHP from, if not the beginning, then close enough that dinosaurs like myself don’t remember it ever being otherwise.

PHP has its own share of frameworks, too, which allow the programmer to painstakingly map SQL schema to XML or vice versa. They carefully abstract the logic out of the view and force the programmer to jump through hoops to write a simple application (although, for complex applications, this often makes the programmer’s life *much* easier.)

PHP does not need any of this. In fact, the most pragmatic framework I have used to date for PHP is the Simple PHP Framework, which is just a set of useful classes to automate some of the more tedious areas of web development. What it does not do is get in the programmer’s way. It is Occam’s razor at work in the world of web development. From the SPF website, quoting a non-existent link:

“All the web frameworks in the world won’t turn a shitty programmer into a good one.”

What PHP is not is elegant. It does not have beauty of prose, nor those features that make languages like ML and Lisp so exciting, such as closures, functions-as-objects, or lazy evaluation. Instead, PHP is, above all, a practical language. Instead, it has less sexy features, such as built-in support for XML, XSLT, and Xpath, support most databases, and the built-in ability to serialize to and from JSON and cookie strings.

It is easy to overlook how simple PHP makes many tasks that are complex in other frameworks. For example, Django’s form library is large and complex. I’ve no doubt that most other frameworks have equally Byzantine systems for developing reusable forms. In PHP, one might just write:

function input($type, $name, $display, $value)
{
    < ?
        <label>< ?= $display ?>
        <input type="<?= $type ?/>" value="< ?= $value ?>" />
    ?>
}

The function could be refined to separate the template and the code by putting the HTML into a separate include:

function input($type, $name, $dispaly, $value)
{
    include 'templates/input.inc.php';
}

Simple, right? Which is not to say that PHP’s faults are not legion. That said, I think that PHP sometimes does a better job of building toward general purpose programming than many other languages do of building toward web development.

Submit article

I think I understand the pull of social networking sites.  When I was a teenager, playing on my dad’s old Apple or, if he would let me, his spanking new 486 with an 8 color monitor, I would spend hours waiting to get into some local BBS with half a dozen phone lines so I could explore.  And it was exploring.  Back then, system running Angelfire, Wildcat, and MajorBBS were ahead of the game, with email, chat, message boards (then called forums) and games.  Ah, for the hours I wasted playing Tradewars :)

What made these work was the combination of discovery and socializing.  I knew the other folks who used the BBSs in my town.  I saw them on the forums and in the chat rooms.  We fought each other in Tradewars and Legend of the Red Dragon.  You met new friends and interacted in a unique environment (without the risk of getting stuffed into a locker at school, no less).

Social networking sites are just the latest incarnation of this.  Of course they are popular with teenagers; social networking is part and parcel of being a teenager.  My wife teaches college-level courses for high schoolers, and they are constantly sneaking onto MySpace or Facebook (or texting) during class.  Back in my day, we just passed notes.

I must admit to having recently signed up for a Facebook account.  It is neat to be able to look up old college buddies and see what people are doing and where they have ended up.  It is the 30-year-old’s equivalent of an octogenarian checking the obituaries every day for familiar names.  Of course, I have not yet stooped to a MySpace account.  If I wanted a scrolling background, embedded sound, and blinking, marquee text, I would go back to 1998 and build a website in Frontpage.

Submit article

It should be pointed out that newLISP is an interpreted language with primary emphases on low memory usage, short start-up time, and efficient implementation. In that, newLISP is exceptionally successful; the amount of functionality that has been packed into an executable of just over 250 Kb is impressive. Automatic memory management is fast and simple and requires little overhead. In terms of speed, newLISP compares favorably to other interpreted languages (e.g. Perl and Python).

It also needs to be mentioned that newLISP is not Common Lisp. The name newLISP seems to indicate that newLISP modernizes and replaces Common Lisp. The FAQ on newLISP.org does take a decidedly populist tone with regard to other lisps. This is unfortunate, because newLISP is a very different language than CL or Scheme and is not truly in competition with them.

I’d like to discuss of a few of the more significant sticking points for potential users.

Macros

newLISP is a purely interpreted language. This has some important implications in its implementation. Macros are disimilar to compiled lisps. Most importantly, there is no compile-time expansion. All expansion is performed at runtime and with the overhead of a function all. In fact, newLISP macros are more like functions with lazy evaluation.

However, this does not completely diminish the power of newLISP macros. newLISP’s operator, letex, may be used to both expand and evaluate a block of code. Using the args function and implicit indexing, variable capture may be avoided in macros. Here is an extremely basic macro to iterate over the lines of a file using both letex and args:

(define-macro (dolines)
    (letex ((var (args 0 0))
                    (file (open (args 0 1) "read"))
                    (body (cons 'begin (rest (args)))))
        (while (set 'var (read-line file))
            body)
        (close file)))
 
(dolines (line "/path/to/file")
    (println line))

Variable capture

This is a real issue when writing newLISP. The function args can prevent capture by functions’ parameters, but there is no equivalent to Common Lisp’s gensym to dynamically create unique symbols. Fortunately, it is not difficult to write our own:

(define _gensym:_gensym)
 
(define (gensym:gensym (ctx MAIN))
    (if (_gensym (name ctx))
        (let ((new-sym (string "gensym-" (_gensym (name ctx) (+ 1 (_gensym (name ctx)))))))
                 (or (sym new-sym ctx) (gensym ctx)))
            (begin
                (_gensym (name ctx) 0)
                (gensym ctx))))

This demonstrates two other features of newLISP, contexts and dictionaries, which I will go into in more detail shortly. For now, it will suffice to explain that contexts are lexical namespaces (context symbols are typically denoted in the form context:symbol, similarly to CL packages) and dictionaries are a way to use contexts as an associative namespace.

Note that this implementation of gensym is dependent on the maximum integer value on the system. newLISP will wrap into negatives after the max integer, so the maximum number of symbols possible to create is generally twice the value of the max integer. However, symbols that have been deleted will be recycled.

Hash tables

newLISP does not use hash tables (see here for an explanation of why). This is a show-stopper for many. Without joining the (often heated) debate over this, newLISP does provide the same functionality as a hash through its dictionaries:

(define dict:dict) ; create the dictionary
(dict "foo" "bar") ; associates "foo" to "bar" in dict
(dict "foo") ; retrieves "foo" from dict

Or, programmatically:

(context dict "foo") ; => "bar"
(context dict "foo" "baz") ; sets foo:bar "baz"

Dynamic scope

newLISP is dynamically scoped. Because it is an interpreted language, much computation and memory is saved by avoiding the complexities of lexical scoping.

newLISP’s contexts do implement static scopes that can be used to create lexically enclosed modules and closures. Within the context, though, variable lookups are dynamic to the context. In the example above (gensym), _gensym is a context dictionary and gensym is a default functor (a function assigned to a symbol with the same name as its context is defined as a functor in newLISP). Within gensym:gensym, scope is dynamic to the gensym namespace, which is lexically isolated from the default namespace, labeled MAIN.

Garbage collection

newLISP uses a form of memory management called ORO (one reference only). From the newLISP documentation:

Memory management in newLISP does not rely on a garbage collection algorithm. Memory is not marked or reference-counted. Instead, a decision whether to delete a newly created memory object is made right after the memory object is created.

Empirical studies of LISP have shown that most LISP cells are not shared and so can be reclaimed during the evaluation process. Aside from some optimizations for primitives like set, define, and eval, newLISP deletes memory objects containing intermediate evaluation results once it reaches a higher evaluation level. newLISP does this by pushing a reference to each created memory object onto a result stack. When newLISP reaches a higher evaluation level, it removes the last evaluation result’s reference from the result stack and deletes the evaluation result’s memory object. This should not be confused with one-bit reference counting. ORO memory management does not set bits to mark objects as sticky.

newLISP follows a one reference only (ORO) rule. Every memory object not referenced by a symbol or context reference is obsolete once newLISP reaches a higher evaluation level during expression evaluation. Objects in newLISP (excluding symbols and contexts) are passed by value to other functions. As a result, each newLISP object only requires one reference.

The intuitive assumption is that this results in slow evaluation, but it does not. Nor is newLISP’s evaluation speed burdened by a garbage collector.

newLISP’s ORO rule forces newLISP to constantly allocate and then free LISP cells. newLISP optimizes this process by allocating large chunks of cell memory from the host operating system. newLISP will request LISP cells from a free cell list and then recycle those cells back into that list. As a result, only a few CPU instructions (pointer assignments) are needed to unlink a free cell or to re-insert a deleted cell.

The overall effect of ORO memory management is a faster evaluation time and a smaller memory and disk footprint than traditional interpreted LISP’s can offer. The lack of garbage collection in newLISP more than compensates for its high frequency of cell creation/deletion. Note that under error conditions, newLISP will employ a mark and sweep algorithm to free un-referenced cells.

Implicit indexing

Implicit indexing is syntactic sugar for indexed access to elements in a list:

(let ((lst '(1 2 3 4 5)))
    (lst 3))
=> 4

It also works for nested lists:

(let ((lst '(1 2 3 (4 5))))
    (lst 3 1))
=> 5

Prospective users often remark that this syntax breaks conventional semantics and makes it far more difficult to do meta-programming. The function nth exists in the language and may still be used for this purpose:

(let ((lst '(1 2 3 4 5)))
    (nth 3 lst))
=> 4

Concurrency and distributed computing

newLISP is not threaded. This in particular was a challenge for me. However, I have found that due to newLISP’s small size and quick start-up, forking new processes is quite painless. There are few programs where one would want to start hundreds or thousands of threads, and newLISP is able to launch a large number of processes in less space than a single instance of the Python interpreter.

Using the new Cilk-inspired API, concurrent programming is simple, cheap, and expressive. Additionally, there are few of the challenges associated with threaded programming.

newLISP also comes with built-in functions for distributed computing, permitting forms to be easily sent to other nodes over TCP/IP for evaluation:

(net-eval remote-server-ip expr-to-evaluate timeout response-handler)

Conclusion

newLISP packs a lot of power into its small size. Some of its more powerful built-in features include:

• a fast, simple concurrency API
• regular expressions (PCRE)
• native C library access
• XML parsing
• pattern matching
• HTTP networking
• sockets
• cross platform GUI server (using Java)
• bayesian training and probability analysis
• cross platform support – newLISP uses only standard libraries

newLISP does not deserve the pariah status to which many relegate it. While newLISP cannot replace a compiled language for the most intensive tasks, it remains a fun, artful language and is excellent for exploratory programming and rapid prototyping, while remaining fast and powerful enough for the final product.

Submit article

My previous experience with Java was as a less experienced programmer and I had some difficulty with the type system. I learned on dynamically typed languages. My first experience with static typing was in modern functional languages, where type was inferred automatically by the compiler. Explicit type declarations felt archaic and overly wordy.

My experience this time around, however, was more positive. This is primarily due to three factors.

NetBeans

NetBeans is Sun’s Java IDE. Because it is mostly limited to Java, its syntax formating is excellent. It takes a lot of code to abstract the ability of an IDE to format multiple languages (in particular, the ability to format both C-style languages and Lisp-style languages using the same application primitives presents difficulty). NetBeans has the Apple advantage in this; one language to support means that it can have excellent support for that language. Of course, this means that projects that use multiple languages are more difficult to develop using NetBeans, so perhaps this tradeoff is not worth it.

Java’s self-documentation is very nice, too. NetBean’s code-hinting is superior to most, although it can get in the way.

The GUI builder is also extremely nice. Swig and AWT can be a real trial in a language as wordy as Java (although I think Sun prefers us to call it “explicit.”)

Classes

I initially had some difficulty writing entire programs in objects. Most languages I use that are object oriented are multi-paradigm. Classes are available, but then utilized within functional or procedural code. Because of this, I tend to regard classes as a sort of extra-powerful type struct, only to be used when a type becomes complex enough that the extra work of encapsulated it within a class becomes advantageous.

It’s (unfortunately) common to see new Lisp programmers try to simulate OO in Lisp using closures and hashes (especially if they’ve read a few Paul Graham essays). I don’t particularly see that OO improves Lisp; closures and templates provide roughly the same functionality. Exactly replicating closures in OOP or objects in functional programming would be moot. They are different styles; Java-style programming is as uncomfortable in Lisp as Lisp-style programming is in Java.

While writing my initial applications, though, I realized something: classes are a formalized closure syntax. They are a function that builds functions and closes over their variables.

This freed me to use a style of abstraction in Java that felt much more comfortable to me without the drawback of attempting to use the wrong paradigm for the language. I could now program using classes and objects in a manner consistent with how I mentally model my applications.

Something I missed quite a bit was pattern matching. It is very helpful to declare local variables based on the pattern of the argument(s) passed to a function, but that would not be useful in Java, since the primary type mechanism in Java is the class rather than the list. Method overloading provides much of the same functionality, but idiomatic of Java.

Write once, run everywhere

Lisp pioneered the virtual machine. Lisp is compiled into code that is run within the Lisp interpreter. But Lisp is not commonly installed on computers, so distribution of Lisp software becomes a real challenge. One of the advantages of having a huge amount of money behind a language is that Java is installed on virtually every computer a program may end up on.

It’s common in Lisp to have to code various parts of the program differently depending on the operating system and Lisp distribution. For example, very few Lisps support multi-threading on OSX. It makes it agonizing to write threaded software for a multi-platform application.

Java does not have this problem. A feature is available on all platforms or none at all. While this means that the language sometimes suffers from the lack of a particular feature, it also means that there is a guarantee against discovering too late that a feature used in the core of your program will not limit its utility on other operating systems.

Conclusion

Java is better than I had given it credit for. With NetBeans taking care of checking your work for you, I am beginning to suspect that the many buggy Java programs are due to poor programming rather than a problem inherent in Java itself.

I still have some doubts as to how useful it would be for a very large project; my experience has been that object orientation and inheritance results in unnecessary complexity.

For small projects and GUI applications, though, Java seems to be a fair choice.

Submit article

This has also kept many imperative languages moving forward. Python may be the most lispy, but there is also Ruby, which conceptually borrows heavily from languages like lisp and Smalltalk. Even Javascript has lambda functions (although in JS they are called function literals), which has made possible powerful libraries such as Prototype.

Few lisps have ever borrowed from imperative languages, though, as if the borrowers have absolutely nothing to offer themselves. A few concepts have made it in. OOP, via CLOS, although OOP is often just extra weight in lisp. Storing functions as data makes much of OOP needless in lisp.

newLisp, a dialect of lisp that uses s-expressions in a high level, interpreted language, has borrowed from imperative languages, and has done an excellent job of maintaining its lispy character despite it. Regex is built into the interpreter and is used in many functions:

(regexp {brown fox$} "the quick brown fox")
(replace {brown fox$} "the quick brown fox" (upper-case $1))

Iterative control structures are built into the interpreter, rather than be implemented through macros. Common Lisp’s LOOP is very powerful but not very idiomatic of lisp and not very elegant to use (in fact, many of those involved in the original development of the language did not like LOOP, feeling that it was not lispy enough). In newLisp, iterators definitely have a lispy feel to them:

(dotimes (i 10) (println i))
(dolist (n '(foo bar baz bat)) (println n))

Other similar looping functions in newLisp are dolist, doargs, and dotree. There are also while, until, unless, and do functions, which all work about as you would imagine in a lisp.

No language will survive in a pure form. Concepts may – s-expressions and lists – but lisp must be willing to evolve on a larger scale. Lisp was built to evolve, so it’s a shame that so few of the people who continue to plough ahead in the language want it to.

Submit article