Java VM Puts Shackles On Development Tools

I love showing off Smalltalk. It never ceases to impress people with what you can do with it. One thing java developers find strange is no pauses in your work flow. What do I mean by that? Smalltalk compiles on the fly and immediately links in the new code. The time to compile one little piece is almost instantaneous to us. But, to developers not used to this environment, it feels weird. The Smalltalk IDE image comes up immediately (pick any Smalltalk and it's the same story). Strange, it takes a few minutes to even start up Eclipse. Smalltalk just feels like magic and we've been taught to mistrust magic.

But, this post is not about how foreign Smalltalk is to java developers, but how still in 2007 with dynamic languages finally getting recognition that few people are screaming for the capabilities of a Smalltalk VM. The productivity of Smalltalk owes not only to its dynamic nature, but to its always running and lively IDE. It's a living environment. Objects are alive and not dead. Why are there not other environments that do this? (OK, Lispers, I didn't forget about you...anyone else?) And why aren't these environments in the newer dynamic languages (Ruby, Python, Groovy, etc)? Have the shackles of the java runtime environment ruined us?

Or maybe the problem is just that we are always thinking of runtime and not development time. Java places a lot of barriers in the way of developers in the name of security. Why not have a specific VM purely for development? One that could dynamically load classes and code. One that could take snapshots of the running system and save the state for later. One that could compile incrementally and keep all of the bookeeping in order so that our tools stay snappy. One can dream.

Now, for Ruby and Python, there is no excuse. They have their own VM and why don't they support IDEs to implemented in themselves? Java, Groovy, and Scala have the excuse of the java VM. One of my hopes for Ruby was a Smalltalk-like IDE, but sadly, I don't think it will ever happen. The first step would be not to throw away the source code when they compile.

The thing that makes Smalltalk IDEs so cool is that they are alive. The VM supports object mutability and snapshotting state. The whole IDE is written in Smalltalk and is part of the live development system. You don't have to restart anything to try something out or shut down the everything to run a new tool. It morphs into what you want and let's you do what you want. No shackles.

This is what I want from the new generation of dynamic languages. I wonder how hard it would be to have a development java VM. Hmmm....

Omaha Dynamic Language Group

Has it already been a month? Wow. We have a stupendous talker this month, Axel Jenson. He will be presenting the us the new Flex framework and showing off the next verion of ECMAScript: ActionScript! This promises to be a talk that you will be talking about for months. I've heard it will make you instantly download Flex and try out all the cool things it has.

Want more? How about sponsorship from ProKarma, Inc. (eSymbiosis)! They will be providing us with a door prize, pizza, and drinks.

This is one exciting meeting that you can not afford to miss. I will see you all there!

Topic	Flex/ActionScript
Speaker	Axel Jensen
Time	April 3, 7-9pm
Location	UNO's Peter Kiewit Institute (PKI) building 1110 South 67th Street Omaha, NE

Where Did Use Cases Go?

I've always liked use cases as an analysis/design tool. I was even the lead developer on a now defunct use case management tool. What ever happened to them? I never hear any one talking about them anymore. Sad really. They were an important part of the journey to understanding user needs. It made gathering easier as well as grouping functionality together. When done right, domain modeling was a breeze. Sure, you never got all of the use cases before design started, but at least you had a good idea of what the goals of the system are. I'm still shocked when I get on a team and the goals of what the software is to do is not clear.

It seems in the rush for agility that people threw away use cases as well. I don't know why. I think stories are a horrible mechanism for understanding. They are the lazy man's use case. Modeling the main domain objects and a good cut at use cases is crucial before you start coding. It will save countless hours. Now, this might seem un-agile. But, thinking about your problem and trying to get a good grip on it before you start coding IS agile. Writing use cases does not end when you start designing or when you start coding. It's a continual process. Use cases are needed to be not only for the knowledge of the developer, but also so that the client knows exactly what you are building. They are to be done together. And as any experienced developer will tell you, you never know everything about what you're building. Customers and developers need each other. Use cases are proof of that.

Use cases rock.

Omaha Dynamic Language Group

The great talks keep coming and this month we have none other than Matt Secoske talking about Domain Specific Languages (or as you might have read about: DSLs). This looks to be an all out blitz to the senses and one that will be talked about for ages. I think it's safe to assume, you need to get out and see for yourself. Matt will show how dynamic languages are perfect to implement DSLs in. It's at the same place we had last month and should be great. See you all there!

Topic	Domain Specific Languages
Speaker	Matt Secoske
Time	March 6, 7-9pm
Location	UNO's Peter Kiewit Institute (PKI) building 1110 South 67th Street Omaha, NE

Made it home...

I made it home and I was exhausted! But, I did write down some more ideas:

1. Seats in the airport should double as beds. And they should be more comfortable.
2. There should be a stock of pillows for people sleeping in the airport when bad weather hits.
3. Lower volume on the intercom. In fact, get rid of the damn thing. It's annoying and there's only so many times I want to hear about "orange" security level. Place more terminals with good information and have it be up to do date. The biggest problem over the weekend was lack of information. Rumors ran rampant and a terminal with information would have stopped most of it.
4. No leaning back chairs on airplanes. They are simply a BAD DESIGN. They are good for one passenger and bad for another. Either that or make more room on the airplane.
5. Don't lie. If you don't know the answer, tell me. If the answer is unpleasant, then tell me. Imagine my surprise when I was told that my luggage was following me through the cancellations, but in fact, it is still in Memphis.
   

OK, that's all of the extra ideas. I think flying could be so much nicer. Everyone I talked to complained about security, but I think we are stuck with that situation. I know people will probably roll their eyes, but it was good to turn that negative energy into creativeness. It also got me thinking of other things as well. But, more on that later!

Stuck in Memphis

I've been at the Memphis airport all day long trying to get home. The weather has not been nice. Hopefully, tomorrow I'll be able to get somewhere, but I'm thinking it might just be another day of waiting. I spent most of the day waiting in line when flights were canceled and it got me thinking. Instead of complaining about a bad situation, how would I fix it? So, I started to spend my time brainstorming ideas to make canceled flights easier on everyone. Here's my list:

1. Create more than one line. I would divide them up by flexibility of travel plans. I notice a lot of time is spent with just a few passengers. You could use one line to determine what the needs are and then pass them on to more dedicated lines. This would speed things up for everyone on the whole.
2. Updated information on the boards. Most of the problem is that you don't know what's going and there's no confirmation that you're doing the right thing. It's chaos. Some road signs would answer most people's questions (flight delayed - for how long - and yep, it's canceled and with the reason!).
3. Send flight information to your cell phone for each of your flights. If it gets canceled and they automatically rebook, then notify me. If the default is unacceptable, then I'll wait in line. But, give me options. I'm thinking the default would the best for most people and reduce the line size.
4. "Feed" the line. People are generally tired, cranky, and hungry. Pass out refreshments while they wait in long lines. It will keep the natives peaceful.
5. Workout a deal with a local taxi company to pick up the slack to take people to the hotel. I waited an hour tonight just to get to the hotel.
6. Workout a deal with the tourism department to show around town if their flight is canceled. They have time to waste and might want to venture out.
7. Have shuttles from the hotel that take people to malls or Wal-Mart. Why? Because you don't have your luggage and might want a fresh set of clothes.
8. Have private areas in the airport. I would spend money just to have a small place to prop up my feet and take off my shoes. I'm thinking something with walls and a Laz-E-Boy chair.
9. Better food. Airport food is expensive and junky. Sometimes I would give anything for some vegetables and something healthy. How hard can that be?
   

Well, that's all I can think of right now on 2 hours of sleep. I'm sure I'll think of more tomorrow. Good night.

Books on Design

In one of my comments, someone asked me the book that I would recommend from Rebecca Wirfs-Brock. And I thought why not just put some of my favorites into a list? So, here's my list in no particular order, but all of these come highly recommended:

• Designing Object-Oriented Software : THE book on OO design and analysis. This one keeps it simple and is awesome. Mrs. Wirfs-Brock will always be one of my heroes that I aspire to.
• Domain Driven Design: And I'm not saying this because of my involvement with TimeAndMoney. Eric is not a great mentor, but an awesome author. If you want to learn how to write REAL DSLs, this is the book. Learn to talk through your domain. Read this cover to cover. There is not one paragraph not to be savored. I went to the first Smalltalk Solutions just to meet him. Seriously...
• The Design Patterns Smalltalk Companion: This is the book where you learn a lot of the hidden secrets in Smalltalk and that all of the design patterns started there. This is an awesome book and reads better than the original. Buy this even if you don't know Smalltalk. It's that good.
• Structure and Interpretation of Computer Programs: I don't know one person who has read this and not have had the way they look at software be different. Learn to be a magician. This opened a lot of possibilities for me. It made me much more creative in my solutions.
• Prefactoring: A lot of Agile enthusiasts got upset with this book because they didn't read it. This book dares to followers to do what they say: Think about their designs. This is also a great book if you want to learn more about DSLs. All good OO models are DSLs. If you're not doing a language with your models, you are doing something wrong.
• Agile Software Development: Robert Martin hits a home run with this book. This is what people who think Agile is about no design, should read this. Being agile is about thinking. I know a lot of Agilists get that, but I have come across many who think it's all about coding and no thought. This book goes beyond Agile and talks about good ole great design.
• Software Fundamentals: These articles were written before I even knew what a computer was and they are still relevant today as they were then. You'll either walk away from this bewildered at what we keep rediscovering or notice how a lot of stuff that seems new is really rebranded. This book is just an awesome tomb of software experience from one of the early innovators. His views on encapsulation really changed the way I look at design. Awesome book.
• A functional pattern system for object-oriented design: Functional programming for object-oriented programmers. I love functional programming and by studying it. My thoughts on development and design have changed. This book shows that they both can share ideas from each other and become stronger. This is a fantastic book that should get more accolades. It shows what great things can be done if OO and functional programmers put their powers together for good.
• Every single book that Martin Fowler has had his name on or associated with. They all rock. Analysis patterns is really the crowning jewel (again, if you want to do DSLs, learn from the master). But, all of his books are easy to read and will teach you volumes.
  

I could go on all night, but I'll stop here for now. I didn't even get to the books that I love from Gerald Weinberg, Donald Norman, Shlaer-Mellor, and more, but I will make that for another blog entry. Also, I'm a big junkie for all of the pattern series books. Nothing takes my money quicker than a pattern book. They are chock full of ideas on design and clever solutions.

Dynamic Language User Group Is Back!

The holidays are over and it's time to get back to programming in the languages we love. I'm happy to announce we have a new location this month courtesy of Matt Payne. It's located at UNO's Peter Kiewit Institute (PKI) building! So, why the change you dare ask? Here's the blurb:

Room PKI 269 is nice because it has about 25 machines, each connected to the Internet, and a large screen projector at the front of the room. A laptop may be connected to the projector or you can just use the PC at the front of the room. Almost every room in PKI has a large screen projector at the front of the room with a PC and a laptop connection. All of the rooms have white boards.

WOW! I would like to give extra special thanks to Heather Blockovich of Tek Systems for all of her help. So, when are we meeting at our bright new shiny place? February 6 is the date usual time of 7-9pm. Of course, I'm always up for a little chit chat before.

Now, for the most important announcement (drum roll please): the speaker! Ben Heath will be providing a special evening of discussion on Common Lisp and his Netflix project. Ben is a passionate programmer with years of experience and is a Lisp and dynamic language lover. It's going to be an exciting talk for sure! I can't wait.

And if that wasn't all, Tek Systems will be joining us with food, refreshments, and maybe a few suprises! Yes, we have sponsorship for this meeting. Now, I have to ask what better way to spend an evening with free food, great place, great people, and awesome Lisp coding?! It's just too good! I look forward to seeing everyone.

Topic	Lisp and Netflix
Speaker	Ben Heath
Time	February 6, 7-9pm
Location	UNO's Peter Kiewit Institute (PKI) building 1110 South 67th Street Omaha, NE

Some Self Philosophy

From the Self 4.1 Programmer's Reference, Chapter 4, A Guide to Programming Style:

In short, to maximize the opportunities for code reuse, the programmer should:

• avoid reflection when possible,
• avoid depending on object identity except as a hint, and
• use mirrors to make reflection explicit when it is necessary.

This is the summary to a portion of the chapter entitled, "Behaviorism versus Reflection". It's best explained in this three paragraphs:

One of the central principles of SELF is that an object is completely defined by its behavior: that is, how it responds to messages. This idea, which is sometimes called behaviorism, allows one object to be substituted for another without ill effect—provided, of course, that the new object’s behavior is similar enough to the old object’s behavior. For example, a program that plots points in a plane should not care whether the points being plotted are represented internally in cartesian or polar coordinates as long as their external behavior is the same. Another example arises in program animation. One way to animate a sorting algorithm is to replace the collection being sorted with an object that behaves like the original collection but, as a side effect, updates a picture of itself on the screen each time two elements are swapped. behaviorism makes it easier to extend and reuse programs, perhaps even in ways that were not anticipated by the program’s author.

It is possible, however, to write non-behavioral programs in SELF. For example, a program that examines and manipulates the slots of an object directly, rather than via messages, is not behavioral since it is sensitive to the internal representation of the object. Such programs are called reflective, because they are reflecting on the objects and using them as data, rather than using the objects to represent something else in the world. Reflection is used to talk about an object rather that talking to it. In SELF, this is done with objects called mirrors. There are times when reflection is unavoidable. For example, the SELF programming environment is reflective, since its purpose is to let the programmer examine the structure of objects, an inherently reflective activity. Whenever possible, however, reflective techniques should be avoided as a matter of style, since a reflective program may fail if the internal structure of its objects changes. This places constraints on the situations in which the reflective program can be reused, limiting opportunities for reuse and making program evolution more difficult. Furthermore, reflective programs are not as amenable to automatic analysis tools such as application extractors or type inferencers.

Programs that depend on object identity are also reflective, although this may not be entirely obvious. For example, a program that tests to see if an object is identical to the object true may not behave as expected if the system is later extended to include fuzzy logic objects. Thus, like reflection, it is best to avoid using object identity. One exception to this guideline is worth mentioning. When testing to see if two collections are equal, observing that the collections are actually the same object can save a tedious element-by-element comparison. This trick is used in several places in the SELF world. Note, however, that object identity is used only as a hint; the correct result will still be computed, albeit more slowly, if the collections are equal but not identical.

Basically, the above is basically placing more value on "duck typing" (the new word for behaviorism) than reflection. I've always placed myself in the "behaviorist" camp and anyone that knows me rolls their eyes when I rip into my "@#$%^& not another data structures and controllers architecture!" It's because I place more value on the behavior than I do the data. It has a lot to do with my mentors enlightening me to the teachings of the brilliant Rebecca Wirfs-Brock (yes, she is still my hero).

Sorry for my digression, but why did I quote all of this? First off, I always thought of duck typing and reflection as tools in my bag. I have never thought about why I would pick one over the other. I do tend to pick non-reflective solutions where I can (It seems Joshua Bloch does the same from his Effective Java book as well). The reason being that most people understand behavior, but reflection is not so obvious.

OK, enough background, and on to my real point. This all got me thinking about why I've always been squeamish with reflective GUI, persistence, and rule engine frameworks. Now, before I begin, I love my OO-relational mapping tools and rules engines, but somehow they have always seemed like they were breaking encapsulation. And in fact, they are for great benefit (which outweighs the encapsulation violations). They are going underneath the covers of your objects and exposing them to a privileged few. Now, this gives us great power and takes a lot of things out of our hands. These frameworks do a lot of heavy lifting and breaking encapsulation has always seemed like a small price to pay. But, how could we do it without reflection? Ah, there's an interesting question, no?

Is this mental aerobics going to get us anywhere? I don't know. But, I bet the journey will be fun. So, what do we have in our arsenal right now? Well, off hand you can name the Memento pattern and we could have a simple hash table object that we get values in and out of the object. This could work for all of the frameworks I listed. But, it seems cumbersome and still prone to major changes in the object topology. We're still depending on data, just putting a common interface on an object. Perhaps, this is the point of "Mirrors" in Self is to provide this type of functionality, albeit consistently. It's also slow because we have to keep taking snapshots if we want to track changes (which means we have to ask for the data and then do compares). But, we could use the Observer pattern and trigger events on any change to an object at the end of some change transaction.

Another tool can be found in Allen Holub'sexcellent article about alternatives to getters/setters in GUIs using the Builder pattern. Now, the solution is very specific, but it's a turn on the Memento pattern. I like that fact that it's more about behavior where I have to send an object that understands the messages and reacts to those messages instead of being passive. But, it still seems the Memento pattern wins because it can be more generic (at its simplest: get(key) and put(key, value)).

I'll leave this article as a point to ponder. There might not be an answer. But, I think a pure behavior approach is more understandable and simple than a reflective one. If anyone has any thoughts, please send them to me. I'll post any further thoughts as I have them. I'm always thinking of ways to preserve encapsulation in my designs. Just remember, Alan Kay wished he had called object-oriented programming, "message-oriented programming". It enforces the black box nature of objects and strong communication semantics. It keeps designs simple and easily reasoned about. Now, don't get me wrong, I don't hate reflection. I just feel like we should always seek alternatives, like inheritance it holds awesome power. But, in the wrong context can cause maintenance issues. Just because you have a tool doesn't mean you have to use it. Besides, forcing constraints on yourself, can cause interesting thoughts on your future designs.

Smaller Is Better

"The smaller the object, the more forgiving we can be when it misbehaves." -John Maeda, "The Laws of Simplicity"

This quote was talking about real world objects, but I think it's doubly true for software objects. If we keep our objects small in our design (single responsbility), we will be more forgiving when errors arise. Why? Small objects are easy to test, debug, and well, fix. In fact, the fix is obvious because the object is so small. It's time to make our objects small and build layers of domain specific languages on top where each layer is simple to comprehend and understand. It would make our designs "more forgiving" to the ones who have to maintain it.

Magnetic Fields Metaphor

Got this cool Alan Kay note:

Magnetic Fields:
Find a central metaphor that's so good that everything aligns to it. Design meetings are no longer necessary, it designs itself. The metaphor should be crisp and fun.

Metaphors are a hotly debated topic in XP/Agile circles and I've never understood why. Alan Kay's quote resonates with me because when you have a good metaphor for your system, you can easily make design decisions as they arise. It keeps your design cohesive and simple. Of course, if your metaphor doesn't fit, it can have the opposite effect. I don't force metaphors, but when one pops that fits...I grab it whole-heartedly. But, I will take the time to brainstorm for one. The metaphor should be your compass that helps you navigate through your design decisions.

Language Of The Year

Following the tradition after reading "The Pragmatic Programmer" to have a new language to learn every year, I have decided to learn Self. I have spent loads of time reading every article and book I can on prototype-based programming. As well as playing around with languages like Io, Slate, and even Javascript, but I always wanted to play with the real thing. Now, that I have a Mac, I can finally get to do that. This is going to be so much fun!

Feed Change

When blogger.com updated their software, it stopped updating my blog feed for some odd reason. So, my feed URL has changed to: http://blog.blainebuxton.com/atom.xml. Please update your readers and I apologize for any inconvenience it might have caused. Thanks for reading!

I did make a few changes to where index.rdf will now still be updated from atom.xml in the meantime. Again, thanks for everyone's patience on this matter.

Java And Simplicity

I was reading 10 Reasons Why Java is Drifting Away because I'm always curious to what other people think of the changes in Java. And I came across this comment:

I believe, simplicity of language is VERY UNDERESTIMATED asset.

See, I worked for years with c++. I liked templates, they were
giving me a 'mental satisfaction'. I liked to check generated
assembler, emmited own instructions when not satisfied.

But that's not way how programs should be made.
Once switched to java, I apprecitated simplicity of java.
Java followed KISS principle, provided simple language,
simple tools (javac, javadoc, javah ... ).

Now, we are loosing this important asset.
Converted c++ programmers ask their templates and operators.
Converted c# programmers ask their properties and closures.
Coverted script programmers want their dose of language sugar.

Java creators made java simple - and not simpler then it should be.
We should apprecitate and preserve it (in rational way).

OK, I'm sure that some of the Smalltalkers and Lispers out there either have their jaws on the floor or hurt bellies from laughing so hard. I know I did at first and then it struck me. We have failed. We have failed to educate on what simple can truly be. When I think of simplicity in language design, I think of Self, Smalltalk, Forth, and Scheme. Java wouldn't even come close. But, there's an army of developers out there that haven't seen better and that is sad.

Sure, we could easily laugh at the uneducated, but it's our fault. Instead we should be sharing and telling. I spent time at RubyConf showing off Squeak and have been known to hang out at the local Java user's groups talking all things dynamic. I enjoy showing people the power that's out there and the great thoughts that have preceded us. It's exciting to see Java getting some of these capabilities and programmers demanding them! The future is bright, but there are still some we haven't reached.

Next time, you hear someone call Java simple, don't snicker. Show them something simple. Who knows maybe someday I'll be able to program in Self because it will be the defacto standard. A boy can dream can't he?

Favorites Of 2006

Every year I like to do my favorites of the year. I normally post it on one of the music boards I'm on. But, it's fun to read previous years' lists. This year was simply incredible. I love a lot of different genres and I was overwhelmed. So, without further ado, my favorites of 2006:

1. Unexpect-In a Flesh Aquarium
2. Muse-Black Holes And Revelations
3. Into Eternity-Scattering Of Ashes
4. Pure Reason Revolution-The Dark Third
5. Peeping Tom-Peeping Tom
6. Axamenta-Ever-Arch-I-Tech-Ture
7. Hammers Of Misfortune-The Locust Years
8. Die Apokalyptischen Reiter - Riders On The Storm
9. OSI-Free
10. Ghoul-Splatterthrash
11. Frost*-Milliontown
12. AFI-December Underground
13. Strapping Young Lad-New Black
14. Mars Volta-Amputechture
15. Dragonforce-Inhuman Rampage
16. Estradasphere-Palace of Mirrors
17. Cradle of Filth-Thornography
18. Black Stone Cherry-Black Stone Cherry
19. Trivium-The Crusade
20. The Faceless-Akeldama

Zero Mass Design

First off, if anyone can get me a copy of Dave Thornburg's "Zero Mass Design", please send me an email as soon as possible. I was reading "Programmers At Work" again and this time I reading the interview with Scott Kim. And this was interesting to me:

He has a little book called "Zero Mass Design", the premise of which is that if you're going to work on something - for instance, you're going to write a book, or you want to write some software, or you are about to embark on any project that requires planning -- start with a simple design. But it's more extreme than just keeping it simple; you start with a design so simple that it won't work. That requires a great deal of discipline because you go into the project with the premise that you will fail; until you've tried something and actually seen it fail, yoiu don't know how simple you can get.

Does it sound familiar? Sounds sort of agile doesn't it? The explanation that he gives next is the best I've read for "Do The Simplest Thing Possible" mantra of XP. Read on:

Dave Thornburg's example, from James Adams' book "Conceptual Blockbusting", is the Mariner IV spacecraft. It had large solar-cell panels that unfolded. The problem, as stated, was to have a mechanism that slowed down the panels as they unfolded so that they wouldn't break when deployed. So, they tried oil, but that was sort of messy, and they tried springs; they did all sorts of things. The day for the launch was coming nearer and nearer. What were they going to do? Remember, the problem as stated was to find a way to slow down the panels, or to find a braking mechanism. Finally, somebody had the brilliant idea to try it with nothing, so they tried it and the panels shook and shivered but nothing broke. If you state the problem with assumptions, you're going to get them. You're got to pare back and pare back and pare back. Starting with a very simple design has wonderful advantages, but it requires a pyschological twist; you have to expect that it will fail and enjoy that.

I like to get requirements stated in goals which is a trick I learned from use cases. Get the problem stated as a goal and a lot of assumptions can be removed. You'd be surprised how well it helps. The point is not only to "Do The Simplest Possible Thing That Will Work", but state the problem as "Simply As Possible". It removes assumptions and thus, doesn't color your design with needless complexity. Those words slapped me in the face and it seemed everything came together. Wow.

How To Make Sure Your Fans Don't Find You

Change your name for American audiences. One of my favorite bands for a long time has been Die Apokalyptischen Reiter. Imagine my shock and surprise when I saw that they had a new album out called "Riders on the Storm". Imagine how delighted I was that it was excellent. Imagine my dismay when I found out that it wasn't their first album in 6, but 3! What?! They had an album come out in between which I guess they tried to rename themselves only for American audiences. On this album and only in America, they were called "The Apocalyptic Riders". Huh? I've been a fan since their first album and I think it's funny I missed this album because of it. Of course, Die Apokalyptischen Reiter is German for
"Riders of Apocalypse". Why the name change? Oh well, who cares? One of my favorite bands are back and I got two new albums by them this year. I should be happy and I am! I just would have liked to been listening to one of them now for 3 years....I got a lot of time to make up!

Great Post On Smalltalk and Parsers

Gilad Brocha has a blog and he made great post recently on Parser Combinators in Smalltalk. It's a great read with lots of funny quotes:

tangent: No Virginia, Smalltalk does not have operator overloading. It simply allows method names using non-alphanumeric characters. These are always infix and all have the same fixed precedence. How can it be so simple? It’s called minimalism, and it’s not for everyone. Like Mies van der Rohe vs. Rococo.

He makes more and it's a great read. I almost got diet pepsi all over my new Mac while reading it. I tend to stand on the same fence that thinks functional and object-oriented programming compliment each other well. I'll even go as far and say they need each other. I ran across this blog because of my recent interest in Self and Factor. Fun stuff!

Don't You Want To Own a Lisp?

If you want to read something funny, go and read Volkswagen Lisp. I was laughing the entire post. I'm amazed at how many different uses and what people had turned their Bugs into! Cool post.

The First Week With Mac

I've had my Mac for a little over a week now and I'm feeling comfortable with it. I like how the most common defaults are just selected for you and it seems a lot of thought has been put into the interface. For example, usually there are no OK buttons on dialogs and it generally selects the right default for you. The screens are just simply gorgeous!

I love the quickness of putting it to sleep! Wow! Booting it up from scratch is slow, but I've only had to do that once so far. I just put it to sleep. Nice.

I'm enjoying Dashboard and I've already gone a little nuts with it. I think I have something like 8 widgets. I have a weather one, two quotes of the day, inspiration for the day, word of the day, unix command lookup, ruby documentation, and a thesaurus.

Switching between applications is nice. It took me a little time to get into the multiple windows per application way of thought. In Windows, everything is a window with no grouping by application. Mac groups windows by applications and makes it super easy to switch between.

The only problem I've had is re-learning key mappings for Eclipse and Squeak. They are generally the same, but it's the apple key versus alt key on Windows. The keyboard is a laid out a little differently too, but I'm not complaining. It's just taking a little to get used to.

I'm loving Self. It makes the whole reason for getting the Mac worthwhile. I've been going through the tutorials and I've only scratched the surface. But, language-wise I'm so impressed with Self. They take their simplicity seriously!

On more thing, I can now read postscript files directly! Yippee! They get converted automatically to PDF and that is wonderful. I can see I'm going to go super crazy with academic papers. Mac will be my pipe for my crack.

My Mac didn't come with an AirPort card and the battery lasts 1 minutes. I'm missing my wireless and I got to have battery power. All in all, I'm having fun with it. Right now, I'll be staying in both Windows and Mac. But, there's a lot of cool things on the Mac that I still need to explore like XCode. I'll keep you posted!