Quotes Page
I finally updated my fave quotes page. Check it out here. I've been meaning to do it for awhile. Enjoy! Also, let me know if I wrongly attributes any quotes. Smalltalk on!
Thursday, January 06, 2005
More thoughts on debate on getters/setters
Carrying on the discussion from previous. Here's some more thoughts:
1. Property objects. (Each instance variable would be it's own object)
2. Naming accessors with _ so that they look unnatural (not a big fan of this, but I'm trying to get thoughts flowing)
3. Change the language in some way. I don't like the restricting paradigm of java, but how could we change smalltalk. Maybe something more self like where instance variable access and method calls look the same.
4. Development-time method wrappers. Put wrappers in to monitor calls to accessors and warn on non-local access if it has been marked "private". The method wrappers could then be removed at run-time. We have the most dynamic language of all! How can we make it do what we want?!
And that's all I can think of right now. If I think of more, I'll blog them! Wouldn't it be cool to come up with a solution to the getter/setter debate once and for all! =) Of course, it might be like the early vs. late bound language debate and thus, never be solved...But, I think this one can be solved.
Carrying on the discussion from previous. Here's some more thoughts:
1. Property objects. (Each instance variable would be it's own object)
2. Naming accessors with _ so that they look unnatural (not a big fan of this, but I'm trying to get thoughts flowing)
3. Change the language in some way. I don't like the restricting paradigm of java, but how could we change smalltalk. Maybe something more self like where instance variable access and method calls look the same.
4. Development-time method wrappers. Put wrappers in to monitor calls to accessors and warn on non-local access if it has been marked "private". The method wrappers could then be removed at run-time. We have the most dynamic language of all! How can we make it do what we want?!
And that's all I can think of right now. If I think of more, I'll blog them! Wouldn't it be cool to come up with a solution to the getter/setter debate once and for all! =) Of course, it might be like the early vs. late bound language debate and thus, never be solved...But, I think this one can be solved.
The debate without end
It seems my discussion on "getters/setters" is having a lively discussion at James' and Andreas' blog. Both sides of the argument give great points. But, perhaps we are missing one another. Maybe we should ask ourselves. How could we compromise? I think we can all agree that encapsulation and consistency are things to keep in high regard. We shouldn't have to sacrifice one for the other. Is the obvious answer data objects? Objects with simple getters/setters methods, but encapsulated inside of a behavior object? I'm thinking out loud here. There's a lot of things that we could do with these data objects. They could notify of changes (good for persistence and gui models) without cluttering up the behavior objects and no one outside of the behvaior object should know about them. You could exchange data objects (since all access is via methods).Hmmm, I think I might need to do implement a model using this technique. I'm curious as to what other people might think would be a compromise to this or an alternative implementation. My point is that if we can't decide on which is better (and frankly, while I still side on the side of getters/setters. I still think both have their pluses and minuses), then maybe we should think of a better solution that has the bits that both sides like. Send me email. I'd be glad to discuss this!
It seems my discussion on "getters/setters" is having a lively discussion at James' and Andreas' blog. Both sides of the argument give great points. But, perhaps we are missing one another. Maybe we should ask ourselves. How could we compromise? I think we can all agree that encapsulation and consistency are things to keep in high regard. We shouldn't have to sacrifice one for the other. Is the obvious answer data objects? Objects with simple getters/setters methods, but encapsulated inside of a behavior object? I'm thinking out loud here. There's a lot of things that we could do with these data objects. They could notify of changes (good for persistence and gui models) without cluttering up the behavior objects and no one outside of the behvaior object should know about them. You could exchange data objects (since all access is via methods).Hmmm, I think I might need to do implement a model using this technique. I'm curious as to what other people might think would be a compromise to this or an alternative implementation. My point is that if we can't decide on which is better (and frankly, while I still side on the side of getters/setters. I still think both have their pluses and minuses), then maybe we should think of a better solution that has the bits that both sides like. Send me email. I'd be glad to discuss this!
Wednesday, January 05, 2005
Getters And Setters Redux
Is anything more hotly debated in OO development? Here's an article eloquantly arguing against them. Now, in the past, I have been strongly in the use getter/setters camp. Recently, I started to not use getters/setters to see if I got any new insights. At first, it felt weird and unnatural, but I soon got over that. I started to not use getters/setters for the exact reason listed in the article because I had seen too much code depend on the getters/setters and knowing too much about the internal representation of an object. Now, in java, you can restrict access to getters/setters through protected and private (which by the way, I think private is evil, but protected is broken as well...I think protected should only be used by the object and its inheritance heirarchy, but that's another discussion). I also wanted to not use getters/setters after watching the a Self video where they used methods and variables interchangebly. But, in most languages, there is a difference in calling a method and accessing a veriable. And that is the one thing I missed when I stopped using getters/setters, the consistency! In both java and Smalltalk, instance and local variable access looks identical and its easy to make a mistake (think a newbie or a really late night at work). So, am I saying that I think consistency is more important than encapsulation? NO! But, I do think they are equally important. You can achieve encapsulation with getters/setter by either restricting access (at the language level), placing them in a different spot in the source code (like at the bottom, make it hard to get to!), or through categories (I frequently put my getters/setters in an accessing/private category and never look at it unless I absolutely need it). You can even use method wrappers to make sure the sender is self and report otherwise. So, while I agree with the article, I still like to use getters/setters for the reason of consistency. I think it's up to a good programmer to keep encapsulation enforced. Oh, one more thing, one good reason for keeping your getters/setters is that if you ever need to do anything extra when an instance variable is set, you can do it through the setter and it's easy to add debug code in a getter (like a break point). I use my setters to ensure parent relationships are kept consistent (there's that word again!). Setters can also fire change events which are important for persistent frameworks and GUIs. One important thing that I am starting to realize with this debate is that it is a personal style issue of the programmer. Both sides have pluses and minuses and it's up to each shop/developer to make their choice. The worst is to mix both paradigms. Remember keep it consistent!
Is anything more hotly debated in OO development? Here's an article eloquantly arguing against them. Now, in the past, I have been strongly in the use getter/setters camp. Recently, I started to not use getters/setters to see if I got any new insights. At first, it felt weird and unnatural, but I soon got over that. I started to not use getters/setters for the exact reason listed in the article because I had seen too much code depend on the getters/setters and knowing too much about the internal representation of an object. Now, in java, you can restrict access to getters/setters through protected and private (which by the way, I think private is evil, but protected is broken as well...I think protected should only be used by the object and its inheritance heirarchy, but that's another discussion). I also wanted to not use getters/setters after watching the a Self video where they used methods and variables interchangebly. But, in most languages, there is a difference in calling a method and accessing a veriable. And that is the one thing I missed when I stopped using getters/setters, the consistency! In both java and Smalltalk, instance and local variable access looks identical and its easy to make a mistake (think a newbie or a really late night at work). So, am I saying that I think consistency is more important than encapsulation? NO! But, I do think they are equally important. You can achieve encapsulation with getters/setter by either restricting access (at the language level), placing them in a different spot in the source code (like at the bottom, make it hard to get to!), or through categories (I frequently put my getters/setters in an accessing/private category and never look at it unless I absolutely need it). You can even use method wrappers to make sure the sender is self and report otherwise. So, while I agree with the article, I still like to use getters/setters for the reason of consistency. I think it's up to a good programmer to keep encapsulation enforced. Oh, one more thing, one good reason for keeping your getters/setters is that if you ever need to do anything extra when an instance variable is set, you can do it through the setter and it's easy to add debug code in a getter (like a break point). I use my setters to ensure parent relationships are kept consistent (there's that word again!). Setters can also fire change events which are important for persistent frameworks and GUIs. One important thing that I am starting to realize with this debate is that it is a personal style issue of the programmer. Both sides have pluses and minuses and it's up to each shop/developer to make their choice. The worst is to mix both paradigms. Remember keep it consistent!
Tuesday, January 04, 2005
Cool Digital Art
Check out Joe Vinton's Digital Art right now. It's incredible stuff! His art is scenic futuristic landscapes. They are simply breath taking! But, what is that in the distance? It's a hot air ballon! What better way to fit the "Back To The Future" theme of Smalltalk than a futuristic landscape with balloons. Incredible stuff and it makes great backgrounds for Squeak if I do say so myself.
Check out Joe Vinton's Digital Art right now. It's incredible stuff! His art is scenic futuristic landscapes. They are simply breath taking! But, what is that in the distance? It's a hot air ballon! What better way to fit the "Back To The Future" theme of Smalltalk than a futuristic landscape with balloons. Incredible stuff and it makes great backgrounds for Squeak if I do say so myself.
Top Twenty
Every year I like to do a top 20 of my favorite albums from the year. It's sometimes hard to pick just 20, so I pick a few honorable mentions. I listen to a lot of music and this year I spent a good amount of time catching on some stuff. I bought a lot of old Depeche Mode and went back to purchase a lot of the old Earache catalog. I even got into a new genre of electronic music called chip music. It's made completely on 4 or 8 bit computers (gameboy advance and old commodroe and atari computers). Fun stuff! I did manage to listen to a lot of new music and this year was EXCELLENT. So here's my list of faves:
Honorable Mentions:
Every year I like to do a top 20 of my favorite albums from the year. It's sometimes hard to pick just 20, so I pick a few honorable mentions. I listen to a lot of music and this year I spent a good amount of time catching on some stuff. I bought a lot of old Depeche Mode and went back to purchase a lot of the old Earache catalog. I even got into a new genre of electronic music called chip music. It's made completely on 4 or 8 bit computers (gameboy advance and old commodroe and atari computers). Fun stuff! I did manage to listen to a lot of new music and this year was EXCELLENT. So here's my list of faves:
- Ayreon-Human Equation
- Assemblage 23-Storm
Wow! Assemblage 23 continues to impress with his brand of Depeche Mode inspired electronics. The lyrics and music are such a perfect fit. This is not happy music. Everything is damn near perfect. This is the way to do quality electronic music. - Vader-The Beast
GRRRRR! The album that got me back into extreme metal. This will rip you a new one and keep coming. - Trevor Rabin-National Treasure
Cheese and pomp. What more do you want in a movie soundtrack. I love this. It's overblown and ompous. Great arrangements and melodies with a hint of modern rock and electronics. Gorgeous to these ears! - Black Label Society-Hangover Music Vol. 1
Moody guitar driven southern rock. No one does it better than Zak. - Ozric Tentacles-Spirals In Hyperspace
Another album from the masters of space rock! Swirling arrangements of rock guitar and keyboards. The perfect mix. - Dream Evil-The Book Of Heavy Metal
Cheesy 80's metal with tongue in cheek lyrics. This album just makes me smile. I love it! Anyone who doesn't think these guys are having the time of their lives, needs to check themselves into the funny farm. - Into Eternity-Dead Or Dreaming
Prog metal, death metal, and a healthy dose of ass kicking thrash. I love it! - Dillenger Escape Plan-Miss Machine
Not what I expected. The music is still crazy, but in a different way. More like Mr. Bungle and I like the direction change. Lots of sick math rock still, and more unpredictable. - Decapitated-The Negation
Death metal that doesn't stop punishing. This is played with such vigor that you can't help but not bang your head. - Megadeth-The System Has Failed<
Megadeth comes back with an album that I never thought they would. This should have been the follow-up to Rust In Peace. It just flat out rocks. Dave remembers how to do metal right. Great to hear afterthe slew of bad albums (4 to be exact). - Behemoth-Demigod
Grandoise metal that still remains to be melodic and memorable while beating you into submission. This is not for one with heart problems. - Cradle of Filth-Nyphetamine
Cradle of Filth has to be the most consistent band ever. A new album and still not one disappointing moment. I love this band. - Estradasphere-Quadropus
The rightful heirs to the throne left by Mr. Bungle. In fact, i think these guys have surpassed them. Rock with everything thrown in. These guys know no boundaries. A rollercoaster ride that always surprises and never a dull moment. - Mastodon-Leviathian
ROCK! Extreme rock with lots of crazy drumming. This time its a little more subtle and it allows the songs to breathe more. Love it! - Vehemence-Helping The World To See
Melodic death metal that stays close to the brutal edge of things. Lots going on and lots of head banging. - Damageplan-New Found Power
Dimebag will be missed. His swansong was not his finest work, but not too many can come close to Pantera's great albums. A great album is what he left us that was varied and showed off his chops. The metal worlds has lost another great. - Exodus-Tempo Of The Damned
The exodus attack returns and shows us how thrash is made! WOW! These guys along with megadeth are the come backs of the year. Lots of reunited bands have done awful albums. But, this exceeded all expectations. It was great seeing them live too. - Arsis-A Celebration Of Guilt
Surprise of the year. Super melodic, but very fast and brutal. The new breed of death metal. - Kataklysm-Serenity In Fire
These guys vary up a lot on this release and this one sticks to you like peanut butter on the roof of your mouth. WOW!
My absolute favorite album this year. I can not praise it enough! A modern progressive masterpiece. Nuff said!
Honorable Mentions:
- Cannibal Corpse-The Wretched Spawn
A guilty pleasure. Brutal florida death metal. These guys keep getting better and more complex with each release. Forget the horror movie lyrics...Listen to those guitar lines! DAMN! - Alabama Thunderpussy-Fulton Hill
BIG RIFFS. Southern metal steamroller style. One of my fave bands of the genre. I love the new vocalist! - Alarum-Eventuality
For those of us who miss Atheist and Cynic, meet Alarum. Progressive death that will keep you on your toes. Good stuff! - Shift-Nasum
The finest grindcore. - Saliva-Survival Of The Sickest
This is 80's metal updated with a 90's sound. I loved this! - Killswitch Engage-The End Of Heartache
A repeat of their earlier albums, but these guys have the melodic hardcore style down.
Omaha Smalltalk User's Group Meeting
It's getting near that time of the month again! So, instead of staying at home with snow up to your eye balls. Why don't you come on down and see what all of the fuss is about? Come see the inspiration for countless languages, Smalltalk. Alan Wostenberg will be giving an updated presentation on running FIT in VisualWorks. Here's all of the details:
When: Jan 11, 2005, 7pm - 9pm
Where: Offices of Northern Natural Gas
1111 S 103rd Street
Omaha Nebraska 68154
Office is at 103rd & Pacific. Guests can park in the Northern visitors parking area back of building, or across the street at the mall. Enter in front door, we'll greet you at the door at 7:00pm. If you arrive a bit later, just tell the guard at the reception desk you're here for the Smalltalk user meeting in the 1st floor training room.
It's getting near that time of the month again! So, instead of staying at home with snow up to your eye balls. Why don't you come on down and see what all of the fuss is about? Come see the inspiration for countless languages, Smalltalk. Alan Wostenberg will be giving an updated presentation on running FIT in VisualWorks. Here's all of the details:
When: Jan 11, 2005, 7pm - 9pm
Where: Offices of Northern Natural Gas
1111 S 103rd Street
Omaha Nebraska 68154
Office is at 103rd & Pacific. Guests can park in the Northern visitors parking area back of building, or across the street at the mall. Enter in front door, we'll greet you at the door at 7:00pm. If you arrive a bit later, just tell the guard at the reception desk you're here for the Smalltalk user meeting in the 1st floor training room.
Monday, January 03, 2005
New Year...New Stuff To Learn
Well, I had time today to sleep and recover from nursing a sick system by spending time away from it. One thing that I like to do every year is set a few goals for myself. These always include learning a few new tricks. In the past, these have included learning Erlang, Lisp, Javascript, Prolog, Ruby, and etc. This year I plan on sinking my teeth into Python, CLIPS, and Scheme. Why so many languages? Well, I don't think Python and Scheme will be far different from things I already know. CLIPS is not too far of a stretch as well, but I really want to get into the way it does things. In the past, what I mainly pull from various languages is a different perspective. I look at programs a lot differently after really getting into Lisp and Erlang. In fact, learning Lisp is what really made me comeback to Smalltalk and realize just how painful and unhappy programming in java made me. I would still love to have a job doing lisp one day just to experience it on a full time basis. Now, yoy might wonder why I would pick Python. Well, I pick Python because a lot of interesting language research seems to be going on with it and I'm liking a lot of the frameworks I'm seeing coming out of the Python community. I picked Scheme because it's supposed to be a cleaner Lisp. It's going to be an exciting year and I hope to learn a whole lot more about craft. I also pray that there's a Camp Smalltalk this year too! If not, maybe I'll go to a Camp Python, Ruby, or Lisp. Now, that would be fun, wouldn't it?!
Well, I had time today to sleep and recover from nursing a sick system by spending time away from it. One thing that I like to do every year is set a few goals for myself. These always include learning a few new tricks. In the past, these have included learning Erlang, Lisp, Javascript, Prolog, Ruby, and etc. This year I plan on sinking my teeth into Python, CLIPS, and Scheme. Why so many languages? Well, I don't think Python and Scheme will be far different from things I already know. CLIPS is not too far of a stretch as well, but I really want to get into the way it does things. In the past, what I mainly pull from various languages is a different perspective. I look at programs a lot differently after really getting into Lisp and Erlang. In fact, learning Lisp is what really made me comeback to Smalltalk and realize just how painful and unhappy programming in java made me. I would still love to have a job doing lisp one day just to experience it on a full time basis. Now, yoy might wonder why I would pick Python. Well, I pick Python because a lot of interesting language research seems to be going on with it and I'm liking a lot of the frameworks I'm seeing coming out of the Python community. I picked Scheme because it's supposed to be a cleaner Lisp. It's going to be an exciting year and I hope to learn a whole lot more about craft. I also pray that there's a Camp Smalltalk this year too! If not, maybe I'll go to a Camp Python, Ruby, or Lisp. Now, that would be fun, wouldn't it?!
Evil is...
Hidden tracks on CDs. I hate them. I really do. One of the joys of having an mp3 player (I have the iRiver 40gb btw) is that I can edit out all of those pesky blank tracks and/or space. Still it takes time to edit the audio and it's just a pain in the rear-end! I have written several quick utilities to help in Javascript that organize and adjust volumes on my mp3s. Now, I just need a utility to remove the blank space and I would be in hog's heaven. I'm just glad for mp3 players because now I only have to edit it out once and I never have to deal with it. Depending on the day, I sometimes just delete the extra tracks because mostly the hidden tracks are just not worth the effort to edit the blank audio out. Word to bands, do not put hidden tracks on your CDs. You're just pissing off everyone and it's not cute anymore. OK, I think that's enough ranting for today.
Hidden tracks on CDs. I hate them. I really do. One of the joys of having an mp3 player (I have the iRiver 40gb btw) is that I can edit out all of those pesky blank tracks and/or space. Still it takes time to edit the audio and it's just a pain in the rear-end! I have written several quick utilities to help in Javascript that organize and adjust volumes on my mp3s. Now, I just need a utility to remove the blank space and I would be in hog's heaven. I'm just glad for mp3 players because now I only have to edit it out once and I never have to deal with it. Depending on the day, I sometimes just delete the extra tracks because mostly the hidden tracks are just not worth the effort to edit the blank audio out. Word to bands, do not put hidden tracks on your CDs. You're just pissing off everyone and it's not cute anymore. OK, I think that's enough ranting for today.
Sunday, January 02, 2005
Back in Nebraska
Well, I was welcomed back in Nebraska with a pager for a sick system and I've been a very busy boy since I've been back. I must admit that it was great to be back in Alabama where people smile and actually talk to you. But, as with all things, it's great to be back in the arms of my loving wife and the comforts of my own house. I spent the new year so far nursing a sick system back to health and it's been no picnic. I have a lot planned for this coming year. I can't wait to see what happens this year. Smalltalk on!
Well, I was welcomed back in Nebraska with a pager for a sick system and I've been a very busy boy since I've been back. I must admit that it was great to be back in Alabama where people smile and actually talk to you. But, as with all things, it's great to be back in the arms of my loving wife and the comforts of my own house. I spent the new year so far nursing a sick system back to health and it's been no picnic. I have a lot planned for this coming year. I can't wait to see what happens this year. Smalltalk on!
Tuesday, December 21, 2004
Journeyman
I didn't even notice, but I've been certified a Journeyman by Ken Causey on Squeak People! WOW! Thanks, man! It made my day. What a nice xmas gift to receive! I'll cut this short because I've got some squeaking to do! Smalltalk on!
I didn't even notice, but I've been certified a Journeyman by Ken Causey on Squeak People! WOW! Thanks, man! It made my day. What a nice xmas gift to receive! I'll cut this short because I've got some squeaking to do! Smalltalk on!
Saturday, December 18, 2004
I love testing
Well, I woke up bright and early this morning and decided to upgrade my Squeak image to the latest 3.8gamma. Well, I found that a lot of my projects do not work now. Crap. Well, I find out that one problem right away is mine and then within one hour I had my project migrated. I was shocked how fast I was able to find the problems and fix them. I didn't need a magic wand or anything, just all of the tests that I now write before I write code. A lot of the tests tested such small pieces that I was able to hone in on the problem quickly and fix it. No massive walk thoughs or cussing. It just re-iterated in my mind that the most important aspect of agile methodologies is test-first. Hell, it should be the most important aspect in any methodology! I was also thankful to keep my tests small. The only project that I have that has huge unit tests (more like acceptance tests) is my Java project and I plan to fix that shortly.
Well, I woke up bright and early this morning and decided to upgrade my Squeak image to the latest 3.8gamma. Well, I found that a lot of my projects do not work now. Crap. Well, I find out that one problem right away is mine and then within one hour I had my project migrated. I was shocked how fast I was able to find the problems and fix them. I didn't need a magic wand or anything, just all of the tests that I now write before I write code. A lot of the tests tested such small pieces that I was able to hone in on the problem quickly and fix it. No massive walk thoughs or cussing. It just re-iterated in my mind that the most important aspect of agile methodologies is test-first. Hell, it should be the most important aspect in any methodology! I was also thankful to keep my tests small. The only project that I have that has huge unit tests (more like acceptance tests) is my Java project and I plan to fix that shortly.
Friday, December 17, 2004
Smalltalk/X
OK, I've been playing around with Smalltalk/X lately and I'm quite impressed with how it has progressed in the past year. It's still a little rough around the edges (I got it to crash several times while trying to restart a method in the debugger) and a few things don't work like you think they might, but overall it's a good experience. I've been using the windows port and I get the feeling that the linux port probably kicks all booty. The code I've seen thus far has been very clean. I ported some of my xml code from Squeak to it and with a few minor tweaks, was up and running in no time! The really cool thing is that they have other languages as well. There's a java, prolog, and even a javascript interpreter. Very cool indeed. I'm still in the beginning stages so my VM crashs could well be a new beginnger clicking the wrong button. I'm excited. It should be a lot of fun exploring!
OK, I've been playing around with Smalltalk/X lately and I'm quite impressed with how it has progressed in the past year. It's still a little rough around the edges (I got it to crash several times while trying to restart a method in the debugger) and a few things don't work like you think they might, but overall it's a good experience. I've been using the windows port and I get the feeling that the linux port probably kicks all booty. The code I've seen thus far has been very clean. I ported some of my xml code from Squeak to it and with a few minor tweaks, was up and running in no time! The really cool thing is that they have other languages as well. There's a java, prolog, and even a javascript interpreter. Very cool indeed. I'm still in the beginning stages so my VM crashs could well be a new beginnger clicking the wrong button. I'm excited. It should be a lot of fun exploring!
Wednesday, December 15, 2004
Monday, December 13, 2004
New Smalltalk Blogger
A great friend of mine just started his very own blog. Please welcome, Andres Valloud, to the world of Smalltalk bloggers. You can read his blog at: Ten is a good number. One of the things I love about Andres is that he speaks his mind and holds nothing back. If he doesn't like something, he says so. Enjoy!
A great friend of mine just started his very own blog. Please welcome, Andres Valloud, to the world of Smalltalk bloggers. You can read his blog at: Ten is a good number. One of the things I love about Andres is that he speaks his mind and holds nothing back. If he doesn't like something, he says so. Enjoy!
Thursday, December 09, 2004
Omaha Smalltalk User's Group
Guess what time of the month it is? Yes, it's time for the monthly Omaha, NE Smalltalk User's Group meeting! The FIT framework will again be up for discussion and anything else everyone wants to talk about. Last month, we talked about "The Genius Within", Refactoring Browser tool, Squeak, and a whole bunch more that I can't think of. I'm sure it will be fun and educational whatever we decide to discuss. Here's the details:
Tuesday, December 14, 7-9pm
Panera @ Eagle Run Shopping Center
13410 West Maple Road
Omaha, NE 68164
We generally meet in the seating in front of the official meeting room. We're still a small group. Just look for a long haired fellow who has a laptop and talks about this super cool language called Smalltalk!
See you all there!
Guess what time of the month it is? Yes, it's time for the monthly Omaha, NE Smalltalk User's Group meeting! The FIT framework will again be up for discussion and anything else everyone wants to talk about. Last month, we talked about "The Genius Within", Refactoring Browser tool, Squeak, and a whole bunch more that I can't think of. I'm sure it will be fun and educational whatever we decide to discuss. Here's the details:
Tuesday, December 14, 7-9pm
Panera @ Eagle Run Shopping Center
13410 West Maple Road
Omaha, NE 68164
We generally meet in the seating in front of the official meeting room. We're still a small group. Just look for a long haired fellow who has a laptop and talks about this super cool language called Smalltalk!
See you all there!
Crushed, Saddened, and In Denial
Anyone that knows me knows that I am huge fan of heavy metal music. They also know that I am a huge fan of Pantera and Damage Plan. Imagine my shock when I heard this morning when I found out that Dime had been shot to death! I thought it was some sort of sick and disgusting joke on the internet, but nope, it was true. His music meant a lot to me. From what I read, he was a caring and fun loving person. I just can't believe his been taken from us. A true metal warrior of the highest caliber and he's been ripped from us by a maniac. I also can't believe all of the injured and dead. I am just shocked. I wish I could pinch myself and this would all be a dream. My condolences go out to all of the families involved. I can't express my emotions and I was just a fan. Brothers in metal forever...
Anyone that knows me knows that I am huge fan of heavy metal music. They also know that I am a huge fan of Pantera and Damage Plan. Imagine my shock when I heard this morning when I found out that Dime had been shot to death! I thought it was some sort of sick and disgusting joke on the internet, but nope, it was true. His music meant a lot to me. From what I read, he was a caring and fun loving person. I just can't believe his been taken from us. A true metal warrior of the highest caliber and he's been ripped from us by a maniac. I also can't believe all of the injured and dead. I am just shocked. I wish I could pinch myself and this would all be a dream. My condolences go out to all of the families involved. I can't express my emotions and I was just a fan. Brothers in metal forever...
Saturday, December 04, 2004
This is what we've been talking about!
If you wonder why we Smalltakers, Lispers, Rubyers, Pythoners, Perlers, and other inhabitants of Dynamica are constantly raving about, then go watch this movie on Self. It brings home the point of what is possible in dynamic environments. The compile/run paradigm is just not needed and you can be so much more productive in lively environments. The movie does a great job of showcasing why simple is better and lively environments are the future. It was interesting to see the Morphic environment in use in Self. I know the version in Squeak was written by the same person, John Maloney. I also noticed a lot of the Etoys-type stuff in there as well. It's nice to see where inspirations are coming from. I would love to play with an instance-based Smalltalk system. How cool would that be? Anyway, the link has a bunch of movies that I hope to spend some time watching! OH BOY WHAT FUN! The movie reminds me that I need to go play with some Self. I download an x86 version a while back, but was to busy to play with it. Maybe now is the time to fire it up....=)
If you wonder why we Smalltakers, Lispers, Rubyers, Pythoners, Perlers, and other inhabitants of Dynamica are constantly raving about, then go watch this movie on Self. It brings home the point of what is possible in dynamic environments. The compile/run paradigm is just not needed and you can be so much more productive in lively environments. The movie does a great job of showcasing why simple is better and lively environments are the future. It was interesting to see the Morphic environment in use in Self. I know the version in Squeak was written by the same person, John Maloney. I also noticed a lot of the Etoys-type stuff in there as well. It's nice to see where inspirations are coming from. I would love to play with an instance-based Smalltalk system. How cool would that be? Anyway, the link has a bunch of movies that I hope to spend some time watching! OH BOY WHAT FUN! The movie reminds me that I need to go play with some Self. I download an x86 version a while back, but was to busy to play with it. Maybe now is the time to fire it up....=)
Sunday, November 28, 2004
Remember: Be Nice
Just a reminder that all of the people helping you this holiday season are working long hours and trying their best to please. I was helping my wife out this weekend at the mall (she owns a kiosk) and I think several people should have remembered the age old rule, "Treat people like you would like to be treated." I was shocked and disgusted how rude people can be sometimes. One man even made an obscene hand gesture after he had walked about and asked for help which I gave. He made the gesture in response to my sales pitch. I never think it's OK to be rude. But, I see it everyday in traffic, at work, at the mall, and just about any public place I go to. It saddenns me. There's never an excuse to be rude EVER. I don't care if you're having a bad day. Smile and treat everyone with respect. Anyway, my one wish is for everyone to be nice to one another. Have patience and remember everyone working behind those counters are people too. You are not better than them because you are the customer. They are not your slaves, they are your amplifiers to get your shopping done more quickly. So, if someone offers you a free chicken wing, politely refuse if you're not interested...don't yell...Don't make an obscene gesture, just BE NICE! Oh yeah, and be nice to your fellow shoppers and human beings as well. Peace, love, and happiness...It's not just for family time and xmas anymore. Do it all the time!
Just a reminder that all of the people helping you this holiday season are working long hours and trying their best to please. I was helping my wife out this weekend at the mall (she owns a kiosk) and I think several people should have remembered the age old rule, "Treat people like you would like to be treated." I was shocked and disgusted how rude people can be sometimes. One man even made an obscene hand gesture after he had walked about and asked for help which I gave. He made the gesture in response to my sales pitch. I never think it's OK to be rude. But, I see it everyday in traffic, at work, at the mall, and just about any public place I go to. It saddenns me. There's never an excuse to be rude EVER. I don't care if you're having a bad day. Smile and treat everyone with respect. Anyway, my one wish is for everyone to be nice to one another. Have patience and remember everyone working behind those counters are people too. You are not better than them because you are the customer. They are not your slaves, they are your amplifiers to get your shopping done more quickly. So, if someone offers you a free chicken wing, politely refuse if you're not interested...don't yell...Don't make an obscene gesture, just BE NICE! Oh yeah, and be nice to your fellow shoppers and human beings as well. Peace, love, and happiness...It's not just for family time and xmas anymore. Do it all the time!
Saturday, November 20, 2004
Weak Typing and Bad Programmers
Alright, I went looking for Javascript info while I was writing my Life Simulation and I found two pages noteworthy: Javascript Rocks and it's nemesis, Javascript Sucks. Both pages have great points and things to ponder. There's a bit that I agree on both of them, but I'm firmly in the camp that thinks Javascript is a powerful lisp-like language encumbered with C syntax that's been messed up by the browser wars. But, enough of my incessant whining, one thing that caught my eye as an against of Javascript is that it is "weak typed". It's described in one the links outside of the Sucks page. It's also been talked about blogs, but I can't remember who's now. The example given is "3" + 1 returns "4". And this is bad. Well, if you think about how tolerant the browsers of HTML, why would javascript be any different? I'm not saying it's a good thing. In fact, I think it's a bad thing, but it's not something to blame the language for. It's the damn programmer who wrote that code in the first place that should be blamed! Javascript is typed (it knows to do the conversion and it will complain when I send it a message it doesn't understand. Basically, the auto-conversion is only on operators). I've never been bit by it because I make sure where I need numbers, I convert them to numbers! Same goes for strings. I don't mix the two and depend on automatic conversion (you should never rely on automatic conversion...SAY WHAT YOU MEAN AND SAY IT MEAN!) I think it's wrong to blame the language and it makes an easy scapegoat for bad programming. If you're surprised by something the language does or you don't like that it does it, then DON'T DO IT! In this case, make sure your objects are converted to the right types and be done with it. If you get surprises anywhere, it's because you didn't code it right. When I make a mistake, the last thing I do is blame the language or compiler. I blame myself. Take responsibility. Stop blaming the language. Languages are only amplifiers. Pick the one that amplifies your thoughts better and be done with it. OK, I'll get off my soapbox for now...=) Bottom line is that I don't want my language to control me...I want to take responsibility when I break my code. Remember, bad code is bad code not matter if the language is weakly, strongly, dynamically, and/or statically typed.
Alright, I went looking for Javascript info while I was writing my Life Simulation and I found two pages noteworthy: Javascript Rocks and it's nemesis, Javascript Sucks. Both pages have great points and things to ponder. There's a bit that I agree on both of them, but I'm firmly in the camp that thinks Javascript is a powerful lisp-like language encumbered with C syntax that's been messed up by the browser wars. But, enough of my incessant whining, one thing that caught my eye as an against of Javascript is that it is "weak typed". It's described in one the links outside of the Sucks page. It's also been talked about blogs, but I can't remember who's now. The example given is "3" + 1 returns "4". And this is bad. Well, if you think about how tolerant the browsers of HTML, why would javascript be any different? I'm not saying it's a good thing. In fact, I think it's a bad thing, but it's not something to blame the language for. It's the damn programmer who wrote that code in the first place that should be blamed! Javascript is typed (it knows to do the conversion and it will complain when I send it a message it doesn't understand. Basically, the auto-conversion is only on operators). I've never been bit by it because I make sure where I need numbers, I convert them to numbers! Same goes for strings. I don't mix the two and depend on automatic conversion (you should never rely on automatic conversion...SAY WHAT YOU MEAN AND SAY IT MEAN!) I think it's wrong to blame the language and it makes an easy scapegoat for bad programming. If you're surprised by something the language does or you don't like that it does it, then DON'T DO IT! In this case, make sure your objects are converted to the right types and be done with it. If you get surprises anywhere, it's because you didn't code it right. When I make a mistake, the last thing I do is blame the language or compiler. I blame myself. Take responsibility. Stop blaming the language. Languages are only amplifiers. Pick the one that amplifies your thoughts better and be done with it. OK, I'll get off my soapbox for now...=) Bottom line is that I don't want my language to control me...I want to take responsibility when I break my code. Remember, bad code is bad code not matter if the language is weakly, strongly, dynamically, and/or statically typed.
Sunday, November 14, 2004
Weekend Project: Conway's Game Of Life In Javascript
OK, I have always loved and found wonderment (is that a word?!) in Conway's Game Of Life. While talking to a friend of mine, the subject of the William Poundstone's "Recursive Universe" came up (I probably started it). Anyway, to cut a long story short, we hit the web and all I found were java versions on the web. I thought this to be very sad. Where are the javascript versions?! I thought it would be a cool weekend project and I thought it would be equally cool to allow you to edit the rules it uses. So, all you recursive emergent behavior freak lovers of the simple, go here right now and enjoy! It runs in IE, Firefox, Mozilla, and Opera. It works best in Mozilla and Firefox since their Javascript implementations are FAST! I had to take out some of my closures to make IE and Opera to work properly, but oh well...
I just love knowing that I now have an implementation of Conway's Life that I can play with anywhere and I can change the rules! How cool is that?!!!!!
OK, I have always loved and found wonderment (is that a word?!) in Conway's Game Of Life. While talking to a friend of mine, the subject of the William Poundstone's "Recursive Universe" came up (I probably started it). Anyway, to cut a long story short, we hit the web and all I found were java versions on the web. I thought this to be very sad. Where are the javascript versions?! I thought it would be a cool weekend project and I thought it would be equally cool to allow you to edit the rules it uses. So, all you recursive emergent behavior freak lovers of the simple, go here right now and enjoy! It runs in IE, Firefox, Mozilla, and Opera. It works best in Mozilla and Firefox since their Javascript implementations are FAST! I had to take out some of my closures to make IE and Opera to work properly, but oh well...
I just love knowing that I now have an implementation of Conway's Life that I can play with anywhere and I can change the rules! How cool is that?!!!!!
Saturday, November 06, 2004
Scripting and Smalltalk
Lots of new dynamic languages have come along and tons of programmers are discovering the productivity gains of no compilation wait times and immediate feedback. But, the environments for these new languages are still based on files and dead systems. One advantage Smalltalk has is that the environment is alive (you can change the environment without shutting down, everything is well ALIVE!) and I think this makes a perfect playground for scripting as well as application development. While most folks use Smalltalk for ultra-complex business applications because they like spending time with their kids, but Smalltalk can also be used for scripting. You see you can get access to the compiler, compiled code, and even the runtime stack (you can even change it!)! Now, even most scripting languages don't give you that kind of power! The only other language I can think of that does is LISP. Anyway, back to the topic at hand. We all know that scripting is helpful for kicking off systems, moving files around, querying the state of a running application, and etc. This is available off the shelf for every Smalltalk dialect that I know of. The cool thing about scripting in Smalltalk is that since you have a powerful environment around you, you can write your script in a workspace. Now, if your script gets too big, you can start moving it to classes and refactoring. You can also move scripts to external files and load them in a runtime. Why do you configuration files when you can have runnable code that does it for you? Let the objects do the talking! Scripting is also great in running systems. If you run Smalltalk in headless mode, you can have scripts that query the state of the system while it's running! This can be very powerful and DANGEROUS! But, wait a minute, we have access to the compiled code and we can actually query the compiled code to make sure it doesn't do anything nasty. The bounds are limitless and once you start thingking about them, you wonder why am I writing unix bash scripts and then, you might be wondering, why not have the power of a compiled language, but the expressive power of an interpreted one? Smalltalk is all that and a whole lot more.
Lots of new dynamic languages have come along and tons of programmers are discovering the productivity gains of no compilation wait times and immediate feedback. But, the environments for these new languages are still based on files and dead systems. One advantage Smalltalk has is that the environment is alive (you can change the environment without shutting down, everything is well ALIVE!) and I think this makes a perfect playground for scripting as well as application development. While most folks use Smalltalk for ultra-complex business applications because they like spending time with their kids, but Smalltalk can also be used for scripting. You see you can get access to the compiler, compiled code, and even the runtime stack (you can even change it!)! Now, even most scripting languages don't give you that kind of power! The only other language I can think of that does is LISP. Anyway, back to the topic at hand. We all know that scripting is helpful for kicking off systems, moving files around, querying the state of a running application, and etc. This is available off the shelf for every Smalltalk dialect that I know of. The cool thing about scripting in Smalltalk is that since you have a powerful environment around you, you can write your script in a workspace. Now, if your script gets too big, you can start moving it to classes and refactoring. You can also move scripts to external files and load them in a runtime. Why do you configuration files when you can have runnable code that does it for you? Let the objects do the talking! Scripting is also great in running systems. If you run Smalltalk in headless mode, you can have scripts that query the state of the system while it's running! This can be very powerful and DANGEROUS! But, wait a minute, we have access to the compiled code and we can actually query the compiled code to make sure it doesn't do anything nasty. The bounds are limitless and once you start thingking about them, you wonder why am I writing unix bash scripts and then, you might be wondering, why not have the power of a compiled language, but the expressive power of an interpreted one? Smalltalk is all that and a whole lot more.
Scary Computer Errors
OK, Bill Bumgarner blogged on computer error in Ohio and I must admit it scares the living day lights out of me. I have no doubt that cheating in elections is nothing new. Both the democrats and republicans have been ingenius in their bending of the system. But, this takes it to a whole new ball game. Computers make it very easy to tip the scales. I think this article just rings clear that we election software MUST BE OPEN SOURCE and we must ensure that the software is not tampered in any way. Computers could be used to get rid of most cheating in elections, but they can also be used as very efficient cheaters as well. If we do nothing, we might as well resolve ourselves to a dictatorship.
OK, Bill Bumgarner blogged on computer error in Ohio and I must admit it scares the living day lights out of me. I have no doubt that cheating in elections is nothing new. Both the democrats and republicans have been ingenius in their bending of the system. But, this takes it to a whole new ball game. Computers make it very easy to tip the scales. I think this article just rings clear that we election software MUST BE OPEN SOURCE and we must ensure that the software is not tampered in any way. Computers could be used to get rid of most cheating in elections, but they can also be used as very efficient cheaters as well. If we do nothing, we might as well resolve ourselves to a dictatorship.
Wednesday, November 03, 2004
Omaha Smalltalk User's Group
Guess what time of the month it is? Yes, it's time for the monthly Omaha, NE Smalltalk User's Group meeting! Again, it's going to be an open forum where anything is up for grabs. Last month, we talked about design, moose, nebraska (the distributed environment in Squeak), and croquet. I'm sure it will be fun and educational whatever we decide to discuss. Here's the details:
Tuesday, November 9, 7-9pm
Panera @ Eagle Run Shopping Center
13410 West Maple Road
Omaha, NE 68164
We generally meet in the seating in front of the official meeting room. We're still a small group. Just look for a long haired fellow who has a laptop and talks about this super cool language called Smalltalk!
See you all there!
Guess what time of the month it is? Yes, it's time for the monthly Omaha, NE Smalltalk User's Group meeting! Again, it's going to be an open forum where anything is up for grabs. Last month, we talked about design, moose, nebraska (the distributed environment in Squeak), and croquet. I'm sure it will be fun and educational whatever we decide to discuss. Here's the details:
Tuesday, November 9, 7-9pm
Panera @ Eagle Run Shopping Center
13410 West Maple Road
Omaha, NE 68164
We generally meet in the seating in front of the official meeting room. We're still a small group. Just look for a long haired fellow who has a laptop and talks about this super cool language called Smalltalk!
See you all there!
Hatred and Disgust
Well, I am very depressed about today's election outcome. So, I'm listening to Sorrow's "Hatred and Disgust" album. It seemed to fit the mood perfectly. I guess I should look on the bright side: there's going to be a lot of great grindcore (really angry fast punk metal) coming out because of it...=) But, what I want to know is why is "liberal" considered a dirty word and conservative is not? This page will be black until I stop grieving...=)
Well, I am very depressed about today's election outcome. So, I'm listening to Sorrow's "Hatred and Disgust" album. It seemed to fit the mood perfectly. I guess I should look on the bright side: there's going to be a lot of great grindcore (really angry fast punk metal) coming out because of it...=) But, what I want to know is why is "liberal" considered a dirty word and conservative is not? This page will be black until I stop grieving...=)
Time For Change
Isn't it time to deal with complexity with a simple and powerful language? Read this article and realize Smalltalk could be used to fix the "complexity" problem by dealing with it instead of masking it with more complexity. IT systems are complex. You need a language that can deal with it: Smalltalk. If you want rising IT costs and complexity, do what everyone else is doing. Why not try something new, yet has had lots of time to mature.
Isn't it time to deal with complexity with a simple and powerful language? Read this article and realize Smalltalk could be used to fix the "complexity" problem by dealing with it instead of masking it with more complexity. IT systems are complex. You need a language that can deal with it: Smalltalk. If you want rising IT costs and complexity, do what everyone else is doing. Why not try something new, yet has had lots of time to mature.
Monday, November 01, 2004
John Peel
I just read that John Peel died of a heart attack. The news shocked me. Peel was an influential DJ and took a lot of chances. If it wasn't for him, a lot of the music that I enjoy might not have crossed the atlantic and into my ears. He was responsible for giving a lot of bands their chance when no one else would touch them. The whole genre of grindcore owes a lot to him and in fact, Earache Records has a tribute to him on their front page. I listened to a ton of records from that label when I was in college. RIP. A cultural icon for the underground is gone. He will be missed.
I just read that John Peel died of a heart attack. The news shocked me. Peel was an influential DJ and took a lot of chances. If it wasn't for him, a lot of the music that I enjoy might not have crossed the atlantic and into my ears. He was responsible for giving a lot of bands their chance when no one else would touch them. The whole genre of grindcore owes a lot to him and in fact, Earache Records has a tribute to him on their front page. I listened to a ton of records from that label when I was in college. RIP. A cultural icon for the underground is gone. He will be missed.
Saturday, October 30, 2004
Musicians And Programmers: Why Have One Genre or Technology?
I have been thinking about how close musicians and programmers truly are. I am more confident than ever that programming is functional art. By functional, I mean art that performs some function (aka architecture). The metaphor of a band or orchestra comes to mind immediately. Agile methodologies have brought back the notion of what we always knew to be true: small teams of dedicated programmers can accomplish great things. It seems the mainstream is just catching up even though there have been several books in the past that touched on this subject (Peopleware and Pyschology of Computer Programming just to name two). Much like small groups of musicians can perform great works of music (think chamber music, rock music, etc). Now, these musicians have to work tightly together to make sure that they don't make noise. The same is true for programmers, if we don't pair and communicate, we get noise as well (broken code). Neither is a pleasant experience for our customers (for musicians this is the listener of course). And while a big team can pull off a project, it's rare. It seems the parallel in music is huge orchestras and they are big undertaking (and rare as well). Musicians spend a lot of time studying music (if they are any good), just like we spend a lot of our time studying code (you do study code, right?). I could go on with how we are alike, but I think you get the point. Programming is art and programmers should interact like artists...
So, you're thinking, "Yep, Blaine you're right! I've read this a million times though...What's the point?" Well, I'm going to state my point right now and it's going to seem to be out in left field. My point is we shouldn't bicker about which language is better because it's a moot point. I know, I know, I've been spent a lot of time blogging on why I think certain languages and technologies are better and I will continue doing so. By now, you're probably rolling your eyes and thinking, "Crap, he says arguing about languages is dumb, yet he's still going to do it...What a dummy!" Well, I think computer languages and technologies are like genres of music. I love heavy metal, electronic music, lounge, and weird stuff. Does it mean my tastes are worse than someone who loves classical or jazz? Or even someone who just listens to punk? NO! It's different tastes. Now, ask a musician that question and you will get snickers. It's the same snicker you hear when someone says that language X is better than language Y depending on who you talk to. But, it's all a matter of taste. It's what you like...It's what makes YOU more productive. Smalltalk makes more productive than any other language I have ever used. But, another programmer might say the same about Lisp and another about Haskell. Hell, we can probably find programmers who will scream that java is the most productive for them.
Are they wrong or am I wrong? I don't think any of us are. But, I am frustrated that our industry thinks that there is one genre of music that all of us have to make. How many musicians would be frustrated if the only kind of music that could make was bubblegum pop or freeform jazz? There would be some happy musicians (because they would be making that music anyway) and a lot of frustrated others. I think programmers are in this boat right now. I have the luxury of currently working in the language that I love using, but I know a lot of us who don't. Why can't teams of programmers (much like bands of musicians) get together based on their love for a certain genre of technology? I think the teams would be more productive and the programmers much happier. Now, you might think this might lead to tunnel vision, but you know what? I don't think so. I would love to work with programmers in other languages much like musicians cross genres to get the creative juices flowing. It works the same for us. I might decide to go back to my main love, but I might have new ideas to apply. It would be much better than what we have now.
Anyway, what do I expect to come out of this? I guess I would like to see our industry diversify much like there are different genres of music. I hate one choice. It would be like being forced to listen to one type of music along with everyone else. How boring. Now, I will keep talking about my love of Smalltalk and why I think it makes more productive because I would like to convince programmers to try my genre of technology and fall in love too. It's like playing a song you like for a friend and trying to get them to like it as well. Is the song better than what everyone else likes though? Nope, it's different and fits my tastes perfectly. Hell, I wouldn't be a metal fan if somebody hadn't played me my first Judas Priest song and I wouldn't be programming in Smalltalk if someone hadn't gotten me to use it. So, expect for me to bash less and show off cool things.
I have been thinking about how close musicians and programmers truly are. I am more confident than ever that programming is functional art. By functional, I mean art that performs some function (aka architecture). The metaphor of a band or orchestra comes to mind immediately. Agile methodologies have brought back the notion of what we always knew to be true: small teams of dedicated programmers can accomplish great things. It seems the mainstream is just catching up even though there have been several books in the past that touched on this subject (Peopleware and Pyschology of Computer Programming just to name two). Much like small groups of musicians can perform great works of music (think chamber music, rock music, etc). Now, these musicians have to work tightly together to make sure that they don't make noise. The same is true for programmers, if we don't pair and communicate, we get noise as well (broken code). Neither is a pleasant experience for our customers (for musicians this is the listener of course). And while a big team can pull off a project, it's rare. It seems the parallel in music is huge orchestras and they are big undertaking (and rare as well). Musicians spend a lot of time studying music (if they are any good), just like we spend a lot of our time studying code (you do study code, right?). I could go on with how we are alike, but I think you get the point. Programming is art and programmers should interact like artists...
So, you're thinking, "Yep, Blaine you're right! I've read this a million times though...What's the point?" Well, I'm going to state my point right now and it's going to seem to be out in left field. My point is we shouldn't bicker about which language is better because it's a moot point. I know, I know, I've been spent a lot of time blogging on why I think certain languages and technologies are better and I will continue doing so. By now, you're probably rolling your eyes and thinking, "Crap, he says arguing about languages is dumb, yet he's still going to do it...What a dummy!" Well, I think computer languages and technologies are like genres of music. I love heavy metal, electronic music, lounge, and weird stuff. Does it mean my tastes are worse than someone who loves classical or jazz? Or even someone who just listens to punk? NO! It's different tastes. Now, ask a musician that question and you will get snickers. It's the same snicker you hear when someone says that language X is better than language Y depending on who you talk to. But, it's all a matter of taste. It's what you like...It's what makes YOU more productive. Smalltalk makes more productive than any other language I have ever used. But, another programmer might say the same about Lisp and another about Haskell. Hell, we can probably find programmers who will scream that java is the most productive for them.
Are they wrong or am I wrong? I don't think any of us are. But, I am frustrated that our industry thinks that there is one genre of music that all of us have to make. How many musicians would be frustrated if the only kind of music that could make was bubblegum pop or freeform jazz? There would be some happy musicians (because they would be making that music anyway) and a lot of frustrated others. I think programmers are in this boat right now. I have the luxury of currently working in the language that I love using, but I know a lot of us who don't. Why can't teams of programmers (much like bands of musicians) get together based on their love for a certain genre of technology? I think the teams would be more productive and the programmers much happier. Now, you might think this might lead to tunnel vision, but you know what? I don't think so. I would love to work with programmers in other languages much like musicians cross genres to get the creative juices flowing. It works the same for us. I might decide to go back to my main love, but I might have new ideas to apply. It would be much better than what we have now.
Anyway, what do I expect to come out of this? I guess I would like to see our industry diversify much like there are different genres of music. I hate one choice. It would be like being forced to listen to one type of music along with everyone else. How boring. Now, I will keep talking about my love of Smalltalk and why I think it makes more productive because I would like to convince programmers to try my genre of technology and fall in love too. It's like playing a song you like for a friend and trying to get them to like it as well. Is the song better than what everyone else likes though? Nope, it's different and fits my tastes perfectly. Hell, I wouldn't be a metal fan if somebody hadn't played me my first Judas Priest song and I wouldn't be programming in Smalltalk if someone hadn't gotten me to use it. So, expect for me to bash less and show off cool things.
Monday, October 25, 2004
Saturday, October 23, 2004
PPUID and over charging
I'm MAD at EBAY! GRRRRRR! Alright, here's the deal, their web site design is awful. Everytime I use it, I have to sign in several times especially if I have to do anything with my accounts. I just made an one time payment for seller fees because they sent me a nasty gram stating that I hadn't paid. Well, the fact is that I tried to pay them via Paypal and the web page kept showing an error page. So, I can't pay, well, some mistakes on my side and them charging me more and sending nasty grams. I go to fix the situation (realizing not to use the paypal links) and what do I discover? I have to sign in several times just to get to the page to pay via my credit card (which none of the forms are prefilled like name, address, etc as well). And to top it all off, they ASK ME HOW MUCH MONEY DO THEY WANT?!!!! Hello, you could have prefilled this in for me! So, then I had to sign in two more times (no I'm not making this up) to get to a page to show me the amount again (this time I remember it). So, I try to go back to the credit card page. I have to sign in two more times just for them not to have anything filled out on the credit card page so I have to type everything in AGAIN! GRRRRR! I finally pay, but at this point, I have no faith in any of Ebay's systems. Un-user friendly and the excessive signing in is awful. Why don't they call up their brother at half.com since they own them now and ask them how to do a web UI that doesn't annoy.
Sorry for the rant, but I had to get this off my chest...I don't think I'll be selling much of anything on ebay any more since they love over charging for small mistakes and that damn atrocious UI! If I was Sun or IBM, I would tell them not to advertise that they use my products because they're using them poorly. Or better yet with that extra fee they charged me, they could pay for a good UI designer. Oh yeah, PPUID stands for Piss Poor User Interface Design.
I'm MAD at EBAY! GRRRRRR! Alright, here's the deal, their web site design is awful. Everytime I use it, I have to sign in several times especially if I have to do anything with my accounts. I just made an one time payment for seller fees because they sent me a nasty gram stating that I hadn't paid. Well, the fact is that I tried to pay them via Paypal and the web page kept showing an error page. So, I can't pay, well, some mistakes on my side and them charging me more and sending nasty grams. I go to fix the situation (realizing not to use the paypal links) and what do I discover? I have to sign in several times just to get to the page to pay via my credit card (which none of the forms are prefilled like name, address, etc as well). And to top it all off, they ASK ME HOW MUCH MONEY DO THEY WANT?!!!! Hello, you could have prefilled this in for me! So, then I had to sign in two more times (no I'm not making this up) to get to a page to show me the amount again (this time I remember it). So, I try to go back to the credit card page. I have to sign in two more times just for them not to have anything filled out on the credit card page so I have to type everything in AGAIN! GRRRRR! I finally pay, but at this point, I have no faith in any of Ebay's systems. Un-user friendly and the excessive signing in is awful. Why don't they call up their brother at half.com since they own them now and ask them how to do a web UI that doesn't annoy.
Sorry for the rant, but I had to get this off my chest...I don't think I'll be selling much of anything on ebay any more since they love over charging for small mistakes and that damn atrocious UI! If I was Sun or IBM, I would tell them not to advertise that they use my products because they're using them poorly. Or better yet with that extra fee they charged me, they could pay for a good UI designer. Oh yeah, PPUID stands for Piss Poor User Interface Design.
Busy, Busy, Busy
I haven't been blogging much because I've been too busy. My stint on the java team at work is coming to a close. It's been a lot of fun and the team is truly awesome. But, I believe now more than ever that the language you program in affects the way you think. I've been spending all of my free time on Squeak projects. Here's some of the things I've been working on:
I've been Squeaking a lot and having huge amounts of fun in my free time. I hope to release some of this stuff soon. Time permitting of course...=)
I haven't been blogging much because I've been too busy. My stint on the java team at work is coming to a close. It's been a lot of fun and the team is truly awesome. But, I believe now more than ever that the language you program in affects the way you think. I've been spending all of my free time on Squeak projects. Here's some of the things I've been working on:
- Lazy Collections - Just released. Sending select:, collect:, reject: to a collection doesn't automatically perform the operation, but keeps the block and original collection around. Great if your cascading these calls because it doesn't create a temporary collection for results. I've updated it and hope to put it up on SqueakMap.
- AsyncObjectWrapper - Another small project. It wraps around any object and makes the public calls to the method run in its own process. It can run in async mode or sync mode (waits to return). I'm still playing around with this and it's just a bit of fun with Smalltalk, multiprocessing, and stacks.
- Web Content Manager - I want to add content to my website more easily. Thus, this project is going to allow me to have a nice looking web site and make it easy to update.
- Refactor DialectStream in Squeak. Ew. I wanted to change how the auto formatter in Squeak laid out my code and found a mess. This one is at the lowest priority. But, it would be fun to clean that stuff up. The code isn't that bad, it just needs a little cleaning up so that's easier for everyone to add their own auto-formatter to Squeak for their code.
- JDWP support in the Java project. JDWP is the Java Debugger Protocol. I got a great start on it. I'm about 25% through it and it looks like the rest of the java stuff. It will just take some time. Should be fun to find out where reality diverges from the spec. I haven't found a java spec yet to be 100% right. But, to their credit, the gotchas have been miminal and easy to fix. After that, it's RMI support to the java package! It's getting huge! What started out as a simple way to debug serialization streams has turned into a project that can read in java class files and disassemble byte codes. Lots of more work to be done. The eventual goal is to run java in Squeak!
- Super Secret Project. I can't talk about this one, but it's my top priority. It's going to rock!
- And finally, setting up a linux box to play with.
I've been Squeaking a lot and having huge amounts of fun in my free time. I hope to release some of this stuff soon. Time permitting of course...=)
Saturday, October 16, 2004
No Bugs
Here's a great evidence about the argument that strong typing prevents bugs: No Bugs. While you're at it, visit the Alchemetrics site that it is on. It's a great piece of work proving the strengths of Smalltalk. It's automated stock trading software written in Dolphin. And if I might say so myself, Dolphin kicks butt. I can't wait for version 6! Anyway, Check it out!
Here's a great evidence about the argument that strong typing prevents bugs: No Bugs. While you're at it, visit the Alchemetrics site that it is on. It's a great piece of work proving the strengths of Smalltalk. It's automated stock trading software written in Dolphin. And if I might say so myself, Dolphin kicks butt. I can't wait for version 6! Anyway, Check it out!
Wednesday, October 13, 2004
Too Much Fun
Programmers should not be allowed to have so much fun. I love the new format of the Smalltalk User's Group! We had another great discussion last night (in fact, I don't think any of us wanted to leave). We stayed until Panera closed and they were kind of enough to let us stay a little late. Nebraska and Croquet were shown off and then, we had discussions on pair programming, good design, and a whole bunch more. We even had a new member show up! They were passing through the area and we enjoyed having them. We had a great crowd! WOW! Anyway, I hate to gush, but I love talking about my favorite language with other folks. I would like to thank everyone for coming out. Maybe next month, we can get Alan to show off more FIT (acceptance test framework) or maybe we'll discuss design again. I like keeping the discussion open and interactive. See everyone next month!
Programmers should not be allowed to have so much fun. I love the new format of the Smalltalk User's Group! We had another great discussion last night (in fact, I don't think any of us wanted to leave). We stayed until Panera closed and they were kind of enough to let us stay a little late. Nebraska and Croquet were shown off and then, we had discussions on pair programming, good design, and a whole bunch more. We even had a new member show up! They were passing through the area and we enjoyed having them. We had a great crowd! WOW! Anyway, I hate to gush, but I love talking about my favorite language with other folks. I would like to thank everyone for coming out. Maybe next month, we can get Alan to show off more FIT (acceptance test framework) or maybe we'll discuss design again. I like keeping the discussion open and interactive. See everyone next month!
Monday, October 11, 2004
Lazy Collections
I released another SqueakMap package tonight called "Lazy Collections". Here's the excerpt:
Basically, I implemented new selectors collect:, reject:, and select: called lazyCollect:, lazyReject:, and lazySelect: respectively. Now, these new implementations return a simple place holder object instead of calculating a new collection. It keeps the blocks around. This is useful when you're doing selects and collects in series. It simply combines the blocks. It was a lot of fun to write and it's something that I've blogged about before. It was a short little excursion. I will probably be adding more to it in the future, but I'm very happy with it right now. I hope you enjoy it!
I released another SqueakMap package tonight called "Lazy Collections". Here's the excerpt:
- The idea for LazyCollection is very simple. It takes a functional
approach to the common collection protocol of select:, collect:, and
reject:. By functional, I mean the collection is not changed nor is a new
one created. The blocks are kept around until they are absolutely
needed. I have been wanting this functionality for some time because
it's nice for large collections. If you have a collection in which you are
calling a lot selects, rejects, or collects on, then this will not create
the intermediate collections. It will wait until you ask something of the
collection where it can not delay the answer. This should make these
chained operations must faster on large collections.
This was a lot of fun to program and it's not that big. Take whatever
you want from it!
Basically, I implemented new selectors collect:, reject:, and select: called lazyCollect:, lazyReject:, and lazySelect: respectively. Now, these new implementations return a simple place holder object instead of calculating a new collection. It keeps the blocks around. This is useful when you're doing selects and collects in series. It simply combines the blocks. It was a lot of fun to write and it's something that I've blogged about before. It was a short little excursion. I will probably be adding more to it in the future, but I'm very happy with it right now. I hope you enjoy it!
Sunday, October 10, 2004
Next Omaha Smalltalk User's Group Meeting
It's that time of the month! I hope you're all excited as I am! Again, we're just going to get together and discuss thoughts. I would like to play around with nebraska (a distributed GUI framework for Squeak). It might be fun to play around in...=) I think it would be a lot of fun! As always, anyone curious to experience the love, pleae join us! Here's the details:
For more information, visit the Omaha Smalltalk User's Group Homepage.
It's that time of the month! I hope you're all excited as I am! Again, we're just going to get together and discuss thoughts. I would like to play around with nebraska (a distributed GUI framework for Squeak). It might be fun to play around in...=) I think it would be a lot of fun! As always, anyone curious to experience the love, pleae join us! Here's the details:
- October 12, 2004, 7pm-9pm
Panera @ Eagle Run Shopping Center
13410 West Maple Road
Omaha, NE 68164
For more information, visit the Omaha Smalltalk User's Group Homepage.
Friday, October 08, 2004
Sleep and The Fever that will not die...
OK, so I thought I had it bad on monday...Well, this stuff has now lasted till friday! I've missed a whole week of work and I've been mainly sleeping and eating popsicles...I don't think I've sweated, had more weird dreams, and had so much just plain unpleasantness ever. Oh well, I'll stop complaining and here's to hoping that I get well before monday! I'm ready for this crap to be OVER! Oh yeah, I went to the doctor and everything checked out fine (go figure). Everyone stay well for me!
OK, so I thought I had it bad on monday...Well, this stuff has now lasted till friday! I've missed a whole week of work and I've been mainly sleeping and eating popsicles...I don't think I've sweated, had more weird dreams, and had so much just plain unpleasantness ever. Oh well, I'll stop complaining and here's to hoping that I get well before monday! I'm ready for this crap to be OVER! Oh yeah, I went to the doctor and everything checked out fine (go figure). Everyone stay well for me!
Monday, October 04, 2004
Fever...Stuck in bed...
Alright, I got some of the nastiness stuff you could ever imagine! It sucks! I've been carrying a fever 101-103 for the past two days and holed up in my bed. YUCK! I thought I would see how long I could last before I pass out again. have I ever mentioned that I love my laptop and wireless router? Yep, I'm writing this from my bed!
Alright, I got some of the nastiness stuff you could ever imagine! It sucks! I've been carrying a fever 101-103 for the past two days and holed up in my bed. YUCK! I thought I would see how long I could last before I pass out again. have I ever mentioned that I love my laptop and wireless router? Yep, I'm writing this from my bed!
Sunday, September 26, 2004
Love Is...
here. I miss Infocom. Cool site that will bring back a lot of memories to a lot of old folks out there! Go now and remember the days when Apple ][s and Commodore 64s ruled the world!
here. I miss Infocom. Cool site that will bring back a lot of memories to a lot of old folks out there! Go now and remember the days when Apple ][s and Commodore 64s ruled the world!
Omaha Smalltalk User's Group
I just put up the Omaha Smalltalk User's Group page up finally. Check it out here. Phew! It's been a busy night! If anyone has any suggestions, let me know. I apologize to all of my brethern in the OSTUG. I've been promising the page for a long time. Rejoice, my brothers!
I just put up the Omaha Smalltalk User's Group page up finally. Check it out here. Phew! It's been a busy night! If anyone has any suggestions, let me know. I apologize to all of my brethern in the OSTUG. I've been promising the page for a long time. Rejoice, my brothers!
SmallHttpUnitTest
Alright, I launched my new projects page tonight! Click here to see it! YIPPEE...=) Anyway, I just released my newest project and the one I worked on with Roger Whitney at Camp Smalltalk. Roger had the great idea for an http unit test framework and I helped him make it a reality. It was an awesome experience and I hope to get to work with Roger again in the future. It's taken a while to get the first release out since Roger and myself have been very busy. It might be a long time before the next release since I am currently overwhelmed. Work is very busy and I got lot of stuff to do at home currently. Anyway, check out the project page here. I'm glad to be releasing it and showing off our new toy for people to enjoy! It's a bundle in the Cincom Public Repository. If you have any problems, let me know. This was my first foray into VisualWorks since I left Sprint. It's changed a lot! I hope to use it more in the future.
Alright, I launched my new projects page tonight! Click here to see it! YIPPEE...=) Anyway, I just released my newest project and the one I worked on with Roger Whitney at Camp Smalltalk. Roger had the great idea for an http unit test framework and I helped him make it a reality. It was an awesome experience and I hope to get to work with Roger again in the future. It's taken a while to get the first release out since Roger and myself have been very busy. It might be a long time before the next release since I am currently overwhelmed. Work is very busy and I got lot of stuff to do at home currently. Anyway, check out the project page here. I'm glad to be releasing it and showing off our new toy for people to enjoy! It's a bundle in the Cincom Public Repository. If you have any problems, let me know. This was my first foray into VisualWorks since I left Sprint. It's changed a lot! I hope to use it more in the future.
Great Answers From a Thoughtful Musician on MP3s
One of my favorite artists, Assemblage 23, is about to release his new album, "Storm", this Tuesday. I was reading his website and came across his thoughts on MP3s in his FAQ page which you can read here. An excellent read with well thought out answers. The last answer that he gives almost made me spew coffee on my monitor. This dude just flat out rocks. And yes, I have his new album on special order. I can't wait! It's going to rule! If you have never checked him out, do so now. It's emotional, intelligent electronic music.
One of my favorite artists, Assemblage 23, is about to release his new album, "Storm", this Tuesday. I was reading his website and came across his thoughts on MP3s in his FAQ page which you can read here. An excellent read with well thought out answers. The last answer that he gives almost made me spew coffee on my monitor. This dude just flat out rocks. And yes, I have his new album on special order. I can't wait! It's going to rule! If you have never checked him out, do so now. It's emotional, intelligent electronic music.
Wednesday, September 22, 2004
Accelerating Change
Oh, this looks like a fun conference: Accelerating Change 2004! I will not be able to go this year, but I'm thinking it would be cool to attend this one next year.
Oh, this looks like a fun conference: Accelerating Change 2004! I will not be able to go this year, but I'm thinking it would be cool to attend this one next year.
Sunday, September 19, 2004
I'm not a number, I'm Lifetime, baby!
I offically became the 65th Weight Watcher to become lifetime at the location that I attend meetings. I'm a lifer! It feels great. I'm still sticking with the program (I never want to be what I was formerly). It was a long hard road, one that I couldn't have done without the love and support of my wife. I would also to thank all of the leaders that I've had in the past (Dianne, you rock!).
I offically became the 65th Weight Watcher to become lifetime at the location that I attend meetings. I'm a lifer! It feels great. I'm still sticking with the program (I never want to be what I was formerly). It was a long hard road, one that I couldn't have done without the love and support of my wife. I would also to thank all of the leaders that I've had in the past (Dianne, you rock!).
Thursday, September 16, 2004
Something to Ponder...
Rusty commented in response to AJavaGuy:
How true. I can't tell you how much java code that I have seen that is nothing but data structures and controllers. There's very little "object" code. It's not a jab at java either. Writing good OO code is a skill that saddly a lot of developers do not take the time to learn. I am shocked at how some folks will read every book on patterns, but have never cracked a book on basic OO modelling (no, I'm not kidding, you think this would not be the case). Anyway, it saddens me that writing good object code might be hindering Smalltalk's acceptance. I find Smalltalk enables object think much more easily. I think that a lot of java programmers would write better java code if they learned Smalltalk as their "language of the year". Learning Lisp certainly opened up my eyes and I think I write better code because of it as well. I think more developers should look beyond thei language of choice and learn others no matter what. I'm constantly learning new languages to try to find one better than Smalltalk for me. I haven't found it yet, but I found a lot of cool and interesting ideas that have changed the way I code for the better. Anyway, Rusty's comment got my mind working.
Rusty commented in response to AJavaGuy:
- AJavaGuy says he isn't an idiot but thinks you need to ship a workbench for someone to deploy Smalltalk code. The thing that keeps developers away from Smalltalk is you have to be an object developer to perform well in the Smalltalk environment. Most Java developers are not object developers. And they write the code to prove it.
How true. I can't tell you how much java code that I have seen that is nothing but data structures and controllers. There's very little "object" code. It's not a jab at java either. Writing good OO code is a skill that saddly a lot of developers do not take the time to learn. I am shocked at how some folks will read every book on patterns, but have never cracked a book on basic OO modelling (no, I'm not kidding, you think this would not be the case). Anyway, it saddens me that writing good object code might be hindering Smalltalk's acceptance. I find Smalltalk enables object think much more easily. I think that a lot of java programmers would write better java code if they learned Smalltalk as their "language of the year". Learning Lisp certainly opened up my eyes and I think I write better code because of it as well. I think more developers should look beyond thei language of choice and learn others no matter what. I'm constantly learning new languages to try to find one better than Smalltalk for me. I haven't found it yet, but I found a lot of cool and interesting ideas that have changed the way I code for the better. Anyway, Rusty's comment got my mind working.
Wednesday, September 15, 2004
Eclipse vs. Cincom Smalltalk
Go here right now. It shows a comparison in sizes of Eclipse vs. Cincom Smalltalk. Funny thing is that he didn't even compare the startup times. Generally, I can open and close a Cincom image 6 times before Eclipse has come up once. Maybe I should should post the startup times for each. Now, that would be interesting...I think we would see the 9x or more slower. Anyway, 9x seems to be the going rate for Smalltalk to Java code size. Go here to see Seaside(A Smalltalk framework) vs. Java. And people wonder why I went back to Smalltalk. My fingers were tired of typing!
Go here right now. It shows a comparison in sizes of Eclipse vs. Cincom Smalltalk. Funny thing is that he didn't even compare the startup times. Generally, I can open and close a Cincom image 6 times before Eclipse has come up once. Maybe I should should post the startup times for each. Now, that would be interesting...I think we would see the 9x or more slower. Anyway, 9x seems to be the going rate for Smalltalk to Java code size. Go here to see Seaside(A Smalltalk framework) vs. Java. And people wonder why I went back to Smalltalk. My fingers were tired of typing!
Thursday, September 09, 2004
Version Control At The Method Level
So, I've been in cold arctic known as Filestar Statica and getting used to the local customs again. It's not that hard to get back into it. But, I digress. One thing I never noticed when I was there before was the level of version control. In most Smalltalk systems, the lowest level we version is the method. In other systems (this is not just statica, but also to the land of sciptor), the lowest level is the file. I think having version control at a lower level makes life a lot easier! For one there's less text to deal with (typical Smalltalk methods are less than 7 lines and I would say that even that number might be closer to 3). You see exactly the methods you changed and if someone wants to get fancy and reformat all of your code, you can easily see the changes. It also means we not susceptible to someone rearranging methods in a different order. And lastly, it's great when we have to merge. Merging is no FUN, but when the merge is at a lower level, there's less mergining inside of a method. It seems to me that version control at the file level can be quite messy if you are not careful. It would be great to see method level version control in other systems. It seems strange only to be in Smalltalk. But, count it as another item that makes me more productive and love Smalltalk more.
So, I've been in cold arctic known as Filestar Statica and getting used to the local customs again. It's not that hard to get back into it. But, I digress. One thing I never noticed when I was there before was the level of version control. In most Smalltalk systems, the lowest level we version is the method. In other systems (this is not just statica, but also to the land of sciptor), the lowest level is the file. I think having version control at a lower level makes life a lot easier! For one there's less text to deal with (typical Smalltalk methods are less than 7 lines and I would say that even that number might be closer to 3). You see exactly the methods you changed and if someone wants to get fancy and reformat all of your code, you can easily see the changes. It also means we not susceptible to someone rearranging methods in a different order. And lastly, it's great when we have to merge. Merging is no FUN, but when the merge is at a lower level, there's less mergining inside of a method. It seems to me that version control at the file level can be quite messy if you are not careful. It would be great to see method level version control in other systems. It seems strange only to be in Smalltalk. But, count it as another item that makes me more productive and love Smalltalk more.
Thursday, September 02, 2004
Great quote
Taken from CLIPS User Document:
So, are you a rule maker or breaker?
Taken from CLIPS User Document:
- "If you want to get anywhere in life, don't break the rules — make the rules!"
So, are you a rule maker or breaker?
Tuesday, August 31, 2004
The Nameless Imperial Troops of Statica Fire
In a galaxy far, far away..."AJavaGuy" writes:
OK, here's the deal. I did java for 8 years. For three of those years, I was the lead architect on the projects I worked on. I came back to Smalltalk because I am more productive. Period. I was successful in java, but I can write more functionality in less time,bugs,programmers,hardware, and software in Smalltalk and I want to delight my paying customers. Smalltalk is freedom to do this. I know what I'm talking about when I speak of java. I'm not speaking from a point of view of ignorance. I have spent my share of time on your side of the fence. Have you ever done a project in Smalltalk? My original post was meant to be a rallying call to fellow Smalltalk developers to think of how we could spread the love of the language we adore. Your reply was meant to spread hate and knock us down. But, I'm always up for a good debate. So, I'll preface my comment the same: "pay attention and do nt take this badly" and I will be proud enough of my opinions not to stand cowardly behind some anonymous signature.
Huh? Most java developers that I show Smalltalk to are astonished by the power we have over the environment. They are actually intrigued by the dynamicism of it all. Their complaints usally come from syntax and how foreign the environment seems (no files). All I ever ask from someone is to give me a chance to show them the power. If they decide not to use it, then I'm alright. I know I will not convert everyone. If java makes you more productive, then it's all within your right to use it. But, to say that my apps will not run because I'm shipping my workbench is ludicrous. In fact, I usually start with a clean image and then import my code before I deploy anything. In fact, I strip away all cruft I don't use in my code. Smalltalk allows me to work with a living system and that property allows me to write code faster. I spend very little time tinkering in the environment. I spend most of my time writing code to deploy to my clients. My code always runs and I'm continually delighting my customers with functionality beyond their wildest dreams. How can I do that? because I have time left over to give extra bells and whistles that make my customer's life easier or just plain more features.
The most successful projects that I have ever been on were all Smalltalk. Smalltalkers are the most productive programmers I have ever met. Name one company unsuccessful with Smalltalk and I'll bet it was never the environment or the language.
So, static typing allows you to make less mistakes? Wrong. We run our code a lot more often and without tests, I rarely run into a problem with types in Smalltalk. When will people learn that typing problems are small when compared to logical. So, you're paying a huge bill with very little safety in return. I know I will not convince you of this because I think it's a "religious" argument. We think of software construction differently. I think of it from a craftsman/artist point of view and you look at it from an engineering perspective. Our past experiences have shaped our beliefs. I've been very productive in dynamic languages and you in static ones. It seems you have had some really bad experiences with dynamic langauges. I am truly sorry. But, I've have had bad experiences in static languages. Let'e leave it at that. I will however still try to convert programmers who have open ears and minds. I am always on the lookout for something better than Smalltalk. I'm still looking and I hope to find it. I just know that java/C++/C#/etc ain't it for me.
If you mean most by C++/Java programmers, then yeah, they probably would think Smalltalk syntax is weird, but I wouldn't say ugly. I consider Smalltalk to have one of the most elegant and readable syntaxes available. If you ask most non-programmers, they can easily read Smalltalk and understand the code. I never had a client that would stand to look at java/C++.
Cool...You choose your tool and I'll choose mine. We're both craftsman. We choose different tools to get our jobs done. I think it takes less materials and thought to get my job done with my tools. I have proof just click here for a comparison of the same functionality in Smalltalk and java. But, I don't believe I'll convince you, so you can continue to use your tools if you like. But, I believe I can beat you to market everytime with more functionality (and working).
Fine, let Smalltalk not be in corporations and common engineering. Let it flourish in companies that want the competitive advantage and don't want to be average. I never wanted to be common anyway. I WANT TO BE EXCEPTIONALLY SUCCESSFUL!. So, I'm sorry if my enthusiasm comes off as being smug, but I believe and stand behind what I say. In fact, I'm proud to say it and not hide behind some anonymous moniker. Have a good day.
In a galaxy far, far away..."AJavaGuy" writes:
- I ended up here from a Java blog pointing here. Your attempts at
reading the minds of Java developers are not very successful. I want
you all to pay attention and not take this badly, I'm going to try to
help you understand this.
OK, here's the deal. I did java for 8 years. For three of those years, I was the lead architect on the projects I worked on. I came back to Smalltalk because I am more productive. Period. I was successful in java, but I can write more functionality in less time,bugs,programmers,hardware, and software in Smalltalk and I want to delight my paying customers. Smalltalk is freedom to do this. I know what I'm talking about when I speak of java. I'm not speaking from a point of view of ignorance. I have spent my share of time on your side of the fence. Have you ever done a project in Smalltalk? My original post was meant to be a rallying call to fellow Smalltalk developers to think of how we could spread the love of the language we adore. Your reply was meant to spread hate and knock us down. But, I'm always up for a good debate. So, I'll preface my comment the same: "pay attention and do nt take this badly" and I will be proud enough of my opinions not to stand cowardly behind some anonymous signature.
- The main reason most programmers dislike Smalltalk is *because of*
the dynamic nature of the environment. If you hack away at your
environment all the time, not only do you not get any work done (see
"Macdinking" in the Jargon File), you end up shipping the workbench to
the customer because your app won't run otherwise. Java IDEs produce
code that can be run with a standard JVM.
Huh? Most java developers that I show Smalltalk to are astonished by the power we have over the environment. They are actually intrigued by the dynamicism of it all. Their complaints usally come from syntax and how foreign the environment seems (no files). All I ever ask from someone is to give me a chance to show them the power. If they decide not to use it, then I'm alright. I know I will not convert everyone. If java makes you more productive, then it's all within your right to use it. But, to say that my apps will not run because I'm shipping my workbench is ludicrous. In fact, I usually start with a clean image and then import my code before I deploy anything. In fact, I strip away all cruft I don't use in my code. Smalltalk allows me to work with a living system and that property allows me to write code faster. I spend very little time tinkering in the environment. I spend most of my time writing code to deploy to my clients. My code always runs and I'm continually delighting my customers with functionality beyond their wildest dreams. How can I do that? because I have time left over to give extra bells and whistles that make my customer's life easier or just plain more features.
- The few companies which ignore past experience and try Smalltalk,
will try and only sometimes survive one experience with Smalltalkers
producing code that can't be shipped to the clients, before deciding to
use *any* other language next time.
The most successful projects that I have ever been on were all Smalltalk. Smalltalkers are the most productive programmers I have ever met. Name one company unsuccessful with Smalltalk and I'll bet it was never the environment or the language.
- Dynamic languages are also very easy to make mistakes in, if you're
not incredibly careful with exhaustive test suites. Compiled languages
are simply better for large-scale software engineering.
So, static typing allows you to make less mistakes? Wrong. We run our code a lot more often and without tests, I rarely run into a problem with types in Smalltalk. When will people learn that typing problems are small when compared to logical. So, you're paying a huge bill with very little safety in return. I know I will not convince you of this because I think it's a "religious" argument. We think of software construction differently. I think of it from a craftsman/artist point of view and you look at it from an engineering perspective. Our past experiences have shaped our beliefs. I've been very productive in dynamic languages and you in static ones. It seems you have had some really bad experiences with dynamic langauges. I am truly sorry. But, I've have had bad experiences in static languages. Let'e leave it at that. I will however still try to convert programmers who have open ears and minds. I am always on the lookout for something better than Smalltalk. I'm still looking and I hope to find it. I just know that java/C++/C#/etc ain't it for me.
- There's also a matter of taste--in the opinion of most programmers,
Smalltalk is one of the most hideously ugly languages ever made. I know
you don't agree, but you're a minority opinion. You have to consider
the very real possibility that you're not normal.
If you mean most by C++/Java programmers, then yeah, they probably would think Smalltalk syntax is weird, but I wouldn't say ugly. I consider Smalltalk to have one of the most elegant and readable syntaxes available. If you ask most non-programmers, they can easily read Smalltalk and understand the code. I never had a client that would stand to look at java/C++.
- It's not a matter of ignorance. Basically every professional
programmer knows Smalltalk, from reading Design Patterns if nothing
else, and quite rationally chooses not to use it. Making a prettier GUI
isn't going to change that. We're not idiots, and we're not shallow,
and the pompous attitude that we are makes us treat you with contempt.
We chose the best tool for the job, and it wasn't Smalltalk.
Cool...You choose your tool and I'll choose mine. We're both craftsman. We choose different tools to get our jobs done. I think it takes less materials and thought to get my job done with my tools. I have proof just click here for a comparison of the same functionality in Smalltalk and java. But, I don't believe I'll convince you, so you can continue to use your tools if you like. But, I believe I can beat you to market everytime with more functionality (and working).
- For aimless hacking on your desktop and producing prototypes,
Smalltalk's fine. It's never going to be common in engineering, though.
Fine, let Smalltalk not be in corporations and common engineering. Let it flourish in companies that want the competitive advantage and don't want to be average. I never wanted to be common anyway. I WANT TO BE EXCEPTIONALLY SUCCESSFUL!. So, I'm sorry if my enthusiasm comes off as being smug, but I believe and stand behind what I say. In fact, I'm proud to say it and not hide behind some anonymous moniker. Have a good day.
Monday, August 30, 2004
What's Wrong With Smalltalk?
Well, I've been spending a lot of time with java developers and have been having a mighty fine time. It's been interesting being back in the saddle so to speak. I am more than ever assured that Smalltalk not only rocks, it rocks hard. So, why isn't it considered to be cool? Well, the Java developers at my company have this crazy notion that's it old technology. They even think the tools are not up to par to java's! Eclipse is a great IDE for java, but it is still pale in comparison to a Smalltalk environment. The reason it is because debugging is still on a dead system so to speak in Eclipse. I can't really change a whole lot while debugging. I can make simple changes, but adding methods and instance variables are big NO-NO's. So, it means I'm shutting down my application, writing some code, compile, rinse, repeat. The compile cycle is what is killing me. It takes awhile to bring up the test server (to test my code). And for some changes, I have to do a pretty lengthy compile. Now, if you set up Eclipse right, compile times are nothing (which I see people get wrong quite a bit). But, it's the start up time of the application server that's really killing me. In Smalltalk, I can keep the application server running and never restart it unless I did something terribly wrong. My productivity is still way high in Smalltalk. The java developers think Ruby is cool because its newer technlogy, but while I love Ruby, the environment is still lacking for it as well. I will be glad when FreeRide is completed (looks promising).
So, why do the java developers think their tools are ahead of ours? Eclipse looks mighty pretty and it has a lot of great features. But, pound for pound, we have the same features and more. We have a live world to play in. Eclipse is nothing more than a painting of the world. We are the real thing! I can change the object inspector in the IDE and no shut down! Any change to Eclipse and I have to shutdown and restart. So, why are java tools considered better? The only thing I can think of is the looks. At work, we use VisualAge and well, VisualAge looks old. I'm trying my best to tell them not to judge a book by its cover and there's a reason a lot of people think it's cool. But, they have this notion that us Smalltalkers are just old technology guys hanging onto our past for dear life. It saddens me that they see me this way. I love new technology and I'm constantly studying new languages. But, so far, the one I am most productive is Smalltalk. Period. End Of Story. Ruby and Lisp are great too, but I can still code faster in ST. I would still pick any dynamic language over java/C# any day of the week.
So, here's the rallying call. How do we make Smalltalk not seem old. I think despite it's age, it's still far ahead of the game in a lot of areas and where we lack, we can quickly close the gap. Let's get rid of this stigma that Smalltalk is old technology. We are the future NOW!
Well, I've been spending a lot of time with java developers and have been having a mighty fine time. It's been interesting being back in the saddle so to speak. I am more than ever assured that Smalltalk not only rocks, it rocks hard. So, why isn't it considered to be cool? Well, the Java developers at my company have this crazy notion that's it old technology. They even think the tools are not up to par to java's! Eclipse is a great IDE for java, but it is still pale in comparison to a Smalltalk environment. The reason it is because debugging is still on a dead system so to speak in Eclipse. I can't really change a whole lot while debugging. I can make simple changes, but adding methods and instance variables are big NO-NO's. So, it means I'm shutting down my application, writing some code, compile, rinse, repeat. The compile cycle is what is killing me. It takes awhile to bring up the test server (to test my code). And for some changes, I have to do a pretty lengthy compile. Now, if you set up Eclipse right, compile times are nothing (which I see people get wrong quite a bit). But, it's the start up time of the application server that's really killing me. In Smalltalk, I can keep the application server running and never restart it unless I did something terribly wrong. My productivity is still way high in Smalltalk. The java developers think Ruby is cool because its newer technlogy, but while I love Ruby, the environment is still lacking for it as well. I will be glad when FreeRide is completed (looks promising).
So, why do the java developers think their tools are ahead of ours? Eclipse looks mighty pretty and it has a lot of great features. But, pound for pound, we have the same features and more. We have a live world to play in. Eclipse is nothing more than a painting of the world. We are the real thing! I can change the object inspector in the IDE and no shut down! Any change to Eclipse and I have to shutdown and restart. So, why are java tools considered better? The only thing I can think of is the looks. At work, we use VisualAge and well, VisualAge looks old. I'm trying my best to tell them not to judge a book by its cover and there's a reason a lot of people think it's cool. But, they have this notion that us Smalltalkers are just old technology guys hanging onto our past for dear life. It saddens me that they see me this way. I love new technology and I'm constantly studying new languages. But, so far, the one I am most productive is Smalltalk. Period. End Of Story. Ruby and Lisp are great too, but I can still code faster in ST. I would still pick any dynamic language over java/C# any day of the week.
So, here's the rallying call. How do we make Smalltalk not seem old. I think despite it's age, it's still far ahead of the game in a lot of areas and where we lack, we can quickly close the gap. Let's get rid of this stigma that Smalltalk is old technology. We are the future NOW!
Omaha Smalltalk User's Group
We're back! And we've changed locations. The meetings had stopped for July and August because of issues with the library (they weren't being nice and well, I don't like mean people). Anyway, we found a new place and it's called Panera.
Here's where we'll be meeting:
Panera @ Eagle Run Shopping Center
13410 West Maple Road
Omaha, NE 68164
September 14, 7pm-9pm.
If you're in the area, please feel free to stop by. We're going to do things a little bit differently this time around. There will be no speakers, but bring your favorite utilities and bits of code. I want the sessions to be more interactive and we'll see how it goes. Remember to look for the skinny long haired dude. He doesn't bite and he loves to talk about Smalltalk!
Hope to see everyone there!
We're back! And we've changed locations. The meetings had stopped for July and August because of issues with the library (they weren't being nice and well, I don't like mean people). Anyway, we found a new place and it's called Panera.
Here's where we'll be meeting:
Panera @ Eagle Run Shopping Center
13410 West Maple Road
Omaha, NE 68164
September 14, 7pm-9pm.
If you're in the area, please feel free to stop by. We're going to do things a little bit differently this time around. There will be no speakers, but bring your favorite utilities and bits of code. I want the sessions to be more interactive and we'll see how it goes. Remember to look for the skinny long haired dude. He doesn't bite and he loves to talk about Smalltalk!
Hope to see everyone there!
Thursday, August 26, 2004
Don't Be An Energy Sucker
Go read this article on Avoiding Co-Workers That Could Hold You Back. And remember: Are you an energy taker or giver? BE POSITIVE AND FUNK ON! Don't be a Sir Nose!
Go read this article on Avoiding Co-Workers That Could Hold You Back. And remember: Are you an energy taker or giver? BE POSITIVE AND FUNK ON! Don't be a Sir Nose!
Smalltalk quibbles
Sam Griffith on his blog answers another developer's quibbles about Smalltalk. Now, if you read the quibbles, it's the reason I did the scripting workspace project. It answers all of his complaints. When you save in the workspace, it runs and compiles the code in the workspace. You can dynamically add classes and methods as well. It also works just like Ruby in that there's a context that methods get added to it if you don't specify a class. Ok, ok, I'll stop selling my new little project. Go read Sam's post because it's extremely well-written and he's right on the money.
Sam Griffith on his blog answers another developer's quibbles about Smalltalk. Now, if you read the quibbles, it's the reason I did the scripting workspace project. It answers all of his complaints. When you save in the workspace, it runs and compiles the code in the workspace. You can dynamically add classes and methods as well. It also works just like Ruby in that there's a context that methods get added to it if you don't specify a class. Ok, ok, I'll stop selling my new little project. Go read Sam's post because it's extremely well-written and he's right on the money.
Tuesday, August 24, 2004
Scripting Workspace
I just released the first version of a new project I call the "Scripting Workspace". It's nothing to shout at right now. In fact, it's very simple. But, before I left for Camp Smalltalk, I read about people disregarding Smalltalk because you can't do things in the workspace that you can do in other scripting languages. I thought we needed to provide a bridge for these people. The reason being if they could do what they normally do in other scripting languages, they could see past the workspace and use the full environment. I've found this code to be nice to begin class construction and then move once workspace code got too big. Anyway, it's a little tool that I thought others might like and it's to make people used to JavaScript, Ruby, Python, Perl, etc more comfortable in our world when they are beginning.
It's available on SqueakMap. ENJOY!
I just released the first version of a new project I call the "Scripting Workspace". It's nothing to shout at right now. In fact, it's very simple. But, before I left for Camp Smalltalk, I read about people disregarding Smalltalk because you can't do things in the workspace that you can do in other scripting languages. I thought we needed to provide a bridge for these people. The reason being if they could do what they normally do in other scripting languages, they could see past the workspace and use the full environment. I've found this code to be nice to begin class construction and then move once workspace code got too big. Anyway, it's a little tool that I thought others might like and it's to make people used to JavaScript, Ruby, Python, Perl, etc more comfortable in our world when they are beginning.
It's available on SqueakMap. ENJOY!
Monday, August 23, 2004
Keep it DRY, Shy, and Tell The Other Guy
Andy Hunt and Dave Thomas have hit another home run in their article entitled: "OO In One Sentence".
Here are some of my fave tidbits:
AMEN! I see too much code where they are data structures and everything is accessible. It makes for very messy code. With that said, I also think you should always have accessors for your instance variables, but I don't think those methods should be considerd public by any means. Encapsulation is your friend!
Again, I can not stress this enough. I actually had someone ask me why I thought this was good. Now, I have an article to support my claim. Also, if you plan for concurrency, you will avoid all global variable and class variables (at least stateful class variables). Again, your code will be all the better for it. It also forces you to make your code more modular as well. It just has so many benefits. It just makes your design better. It's like writing tests for your code. Testing always shows defiencies in my code and where I can improve the API.
What do I need to say? Don't Repeat Yourself! AMEN!
What all of us Smalltalkers have known for years and years. But, damn, it's good to hear it again! I'm surprised how many developers that claim to be OO, just don't get this.
Anyway, the article has a lot of good stuff (and it's only 3 pages!) and you have no excuse not to read it. I love their talk on coupling too. I'm not going to say to much more because I didn't want to quote the entire article...=) But, I'm going to be making multiple copies of this articles and keeping it around me.
Andy Hunt and Dave Thomas have hit another home run in their article entitled: "OO In One Sentence".
Here are some of my fave tidbits:
- "The best code is very shy. Like a
four-year old hiding behind a mother’s
skirt, code shouldn’t reveal too much
of itself and shouldn’t be too nosy into
others affairs."
AMEN! I see too much code where they are data structures and everything is accessible. It makes for very messy code. With that said, I also think you should always have accessors for your instance variables, but I don't think those methods should be considerd public by any means. Encapsulation is your friend!
- "Always plan on writing concurrent code
because the odds are good that it will
end up that way anyhow, and you’ll get
a better design as a fringe benefit. Your
code shouldn’t care about what else
might be happening at the same time; it
should just work regardless."
Again, I can not stress this enough. I actually had someone ask me why I thought this was good. Now, I have an article to support my claim. Also, if you plan for concurrency, you will avoid all global variable and class variables (at least stateful class variables). Again, your code will be all the better for it. It also forces you to make your code more modular as well. It just has so many benefits. It just makes your design better. It's like writing tests for your code. Testing always shows defiencies in my code and where I can improve the API.
- DRY
What do I need to say? Don't Repeat Yourself! AMEN!
- “Sending a message” to an object
conveys an air of apathy. I’ve just sent
you an order (or a request), and I don’t
really care who or what you are or (especially)
how you do it. Just get it
done. This service-oriented, operationcentric
viewpoint is critical to good
code. Apathy toward the details, in this
case, is just the right approach. You tell
an object what to do; you don’t ask it
for data (too many details) and attempt
to do the work yourself.
What all of us Smalltalkers have known for years and years. But, damn, it's good to hear it again! I'm surprised how many developers that claim to be OO, just don't get this.
Anyway, the article has a lot of good stuff (and it's only 3 pages!) and you have no excuse not to read it. I love their talk on coupling too. I'm not going to say to much more because I didn't want to quote the entire article...=) But, I'm going to be making multiple copies of this articles and keeping it around me.
Start to salivate
The second edition of Dave Thomas' and Andy Hunt's excellent book on Ruby. Check it out here. I love the first edition. It's one of the best books on a programming language that I have read. The perfect blend of humor and information. I will be buying the second edition immediately. Ruby is changing a lot and it's exciting to watch.
The second edition of Dave Thomas' and Andy Hunt's excellent book on Ruby. Check it out here. I love the first edition. It's one of the best books on a programming language that I have read. The perfect blend of humor and information. I will be buying the second edition immediately. Ruby is changing a lot and it's exciting to watch.
Thursday, August 19, 2004
Smalltalk on Java VM
Check this out. Another Smalltalk running on the JVM (Of course, I only knew of one other, but I had never heard of this one). It's called Talks2. The site is in German, but the Talks2 stuff is in english.
Now, did I mention that it has a full class browser, transcript, and DEBUGGER?! Wait, if that's not enough, you also get become: and full Smalltalk exceptions! How cool is that?! It's a minimal system and they are some rough edges, but DAMN, I am impressed! Great work guys and did I mention the liberal license? They also compile to Java code (not byte codes) and you can see how they implement things. Very cool. I would love to write code that compiled down to JBM byte codes. It would be a fun project, don't you think?
Anyway, chalk it up as another Smalltalk version! Weird thing is that I was looking for RETE algorithms in Smalltalk and ran into this by accident. COOL! Are you still reading this? GO NOW!
Check this out. Another Smalltalk running on the JVM (Of course, I only knew of one other, but I had never heard of this one). It's called Talks2. The site is in German, but the Talks2 stuff is in english.
Now, did I mention that it has a full class browser, transcript, and DEBUGGER?! Wait, if that's not enough, you also get become: and full Smalltalk exceptions! How cool is that?! It's a minimal system and they are some rough edges, but DAMN, I am impressed! Great work guys and did I mention the liberal license? They also compile to Java code (not byte codes) and you can see how they implement things. Very cool. I would love to write code that compiled down to JBM byte codes. It would be a fun project, don't you think?
Anyway, chalk it up as another Smalltalk version! Weird thing is that I was looking for RETE algorithms in Smalltalk and ran into this by accident. COOL! Are you still reading this? GO NOW!
Wednesday, August 18, 2004
Fun Java Discussion
I just came across this and it made me laugh. That's all I'm going to say. Let's just say this is a fun discussion on java. Go see it here.
I just came across this and it made me laugh. That's all I'm going to say. Let's just say this is a fun discussion on java. Go see it here.
Tuesday, August 17, 2004
Philosophy
I've been reading the Rails documentation on their ActiveRecord framework and came across this quote of their philosphy for it:
I love the convention over configuration! Right on!
I've been reading the Rails documentation on their ActiveRecord framework and came across this quote of their philosphy for it:
- Philosophy
Active Record attempts to provide a coherent wrapping for the inconvenience that is object-relational mapping. The prime directive for this mapping has been to minimize the amount of code needed to built a real-world domain model. This is made possible by relying on a number of conventions that make it easy for Active Record to infer complex relations and structures from a minimal amount of explicit direction.
Convention over Configuration:
No XML-files!
Lots of reflection and run-time extension
Magic is not inherently a bad word
Admit the Database:
Lets you drop down to SQL for odd cases and performance
Doesn‘t attempt to duplicate or replace data definitions
I love the convention over configuration! Right on!
J2EEland vs Dynamica
Check this article on J2EE vs. Ruby and Python. You have to read the comments too!
I love this quote:
Hell, I think we as the Smalltalk community need to get off our butts. Smalltalk has been around longer. Our frameworks are more mature and hell, even better! Seaside and Glorp kick a lot of booty. We even have OODBs (Gemstone) that kick booty as well! It seems the a lot of the loyal J2EE masses are figuring out that it's too hard to write systems especially simple ones. In Smalltalk, we can write systems that are not only easy to write, but scale as well! Raise the flag and let's get it on! Of course, I'm happier than a bug in a rug that people are looking at dynamic languages and solutions PERIOD. I would pick Smalltalk as my first choice of development anyday. But, I would gladly program in Ruby or Python instead of Java anyday.
More quotes:
Well, that's what they say...But, is it true? I think we're finding out that if you don't do J2EE "right", then yep, it doesn't scale. But, doing it "right" is very very hard and difficult. Anyway, J2EE developers need to stop reading the books and find out themselves what scales...Think out of the box...It feels great, I promise! Come feel the love!
Now, go read this rebuttal to the comments at Loud Thinking from the creator of Ruby On Rails. And speaking of marketing, check out Ruby On Rails. He's done a great showing off his framework and selling it as well as Ruby. Make me want to sit down and do a video for Seaside to show it off. Hmmmm...Perhaps, I need to get off my lazy bum and do something about it!
Check this article on J2EE vs. Ruby and Python. You have to read the comments too!
I love this quote:
- I know this is an inflammatory statement but it would seem like the smart money is on a shift away from J2EE to Ruby or Python-based web frameworks.
Hell, I think we as the Smalltalk community need to get off our butts. Smalltalk has been around longer. Our frameworks are more mature and hell, even better! Seaside and Glorp kick a lot of booty. We even have OODBs (Gemstone) that kick booty as well! It seems the a lot of the loyal J2EE masses are figuring out that it's too hard to write systems especially simple ones. In Smalltalk, we can write systems that are not only easy to write, but scale as well! Raise the flag and let's get it on! Of course, I'm happier than a bug in a rug that people are looking at dynamic languages and solutions PERIOD. I would pick Smalltalk as my first choice of development anyday. But, I would gladly program in Ruby or Python instead of Java anyday.
More quotes:
- Well, people say that the J2EE solutions are more scalable. A Ruby or Python web app may take less time to get going, but if you're going to run an Amazon or eBay you need something that scales up.
Now, I have no idea if this is true, it's just what they say...
Well, that's what they say...But, is it true? I think we're finding out that if you don't do J2EE "right", then yep, it doesn't scale. But, doing it "right" is very very hard and difficult. Anyway, J2EE developers need to stop reading the books and find out themselves what scales...Think out of the box...It feels great, I promise! Come feel the love!
Now, go read this rebuttal to the comments at Loud Thinking from the creator of Ruby On Rails. And speaking of marketing, check out Ruby On Rails. He's done a great showing off his framework and selling it as well as Ruby. Make me want to sit down and do a video for Seaside to show it off. Hmmmm...Perhaps, I need to get off my lazy bum and do something about it!
Excellent Article
Read this article on Less Software Engineering. He says what I was trying to in my article much better in places. The article is focused mainly on C++ development, but there are a lot of gems included in there. Of course, there were some things that I disagreed, but they were minor squabbles. Here's some excerpts:
AMEN!
I don't like abbreviations and this is why. Without abbreviations, readers of my code know my intentions and they are obvious.
I would say NO GLOBALS, but I generally need at least one. But, I fight it like hell!
AMEN! This isn't a problem in Smalltalk, but is in C++ and Java.
Right on!
OH YEAH! But, I would say your code should be easy enough to read. But, when it's not a little comment can go a long way. I generally need to do this when dealing with third party libraries in Java.
Read this article on Less Software Engineering. He says what I was trying to in my article much better in places. The article is focused mainly on C++ development, but there are a lot of gems included in there. Of course, there were some things that I disagreed, but they were minor squabbles. Here's some excerpts:
- "1. Use creativity to simplify, not to show off.
2. Avoid complexity. Design then code.
3. Be extremist. Maximize simplicity.
Systems always turn out to be more complex than you expect. Guard against this by pushing for the simplest possible design."
AMEN!
- "Every programmer should strive to write code whose behavior is immediately obvious to the reader. If you find yourself writing code that would require someone reading through it to thumb through a manual in order to understand it, you are almost certainly being way too subtle. There is probably a much simpler and more obvious way to accomplish the same end. Maybe the code will be a little longer that way, but in the real world, it's whether the code works and how simple it is for someone to modify that matters a whole lot more than how many characters you had to type."
I don't like abbreviations and this is why. Without abbreviations, readers of my code know my intentions and they are obvious.
- "One of the primary tools for producing maintainable code is minimization of scope. All variables should have scopes consistent with their lifetime and intended use.
There should be almost no global functions or constants."
I would say NO GLOBALS, but I generally need at least one. But, I fight it like hell!
- "Use classes or typedefs instead of raw types like int. If you are using an int (or some other primitive type) to represent some concept, such as dollars, hide the representation via a class or typedef"
AMEN! This isn't a problem in Smalltalk, but is in C++ and Java.
- "Choosing names is one of the most important aspects of programming"
Right on!
- On Comments:
"Don't just repeat what's in the code. The biggest mistake made in documentation is simply to repeat what's already obvious from the code, such as the trivial (but exasperatingly common) example:
// // Increment i. // i ++;
Documentation should provide higher-level information about the overall function of the code -- what a complex collection of statements really means."
OH YEAH! But, I would say your code should be easy enough to read. But, when it's not a little comment can go a long way. I generally need to do this when dealing with third party libraries in Java.
Monday, August 16, 2004
Perfect Design
I am addicted to achieving great design and I love reading about how to do it better. To me, design has always been about getting the most out of the least. I think this is what we admire most in art and music. Artists and musicians making the most out of the least. If you look at the greatness of Bach and Mozart, they were masters at making the most out of a small number of ideas. It's the ingenuity of stretching those few (great) ideas to their maximum while delighting the listener. I think of program design the same way. I want to write the least amount of code to get the most functionality. So, I tend to favor techniques that allow me to type less and don't make me repeat myself. This is why I favor dynamic languages like Smalltalk, Lisp, and Ruby. I also favor those languages because they give more tools to get the most out of my ideas.
Now, there is a huge push in the academic circles of computer science for mathematical purity. I even see this in the industry. I think the static typing advocates like the mathematical purity of typing. Haskell is one of those languages loved by academia. I know I was impressed with the typing system of Haskell initially. It's typing system is a lot better than what you see in Java/C++. It's cool until you get past some of the simple examples and things start to get a little messy. The point I'm trying to get to here is that computers are built on simple mathemtical principles outlined by Turing and Von Neuman. What a lot of folks want to do is extend that model to everything a computer does. But, just because what you are building is based on pure mathematics, doesn't mean the whole system needs to be. I know it sounds absurd. But, buildings have a basis in mathematics too. But, there's that squishy area where user requirements and construction and design meet. It's this squishy area that can not be expressed in math. It's the area where years of contracts have made the art of building business software complicated and hard. The languages we use and ideas we have should be amendable to this fact. I think the dynamic languages are all built on simple mathematics as well, but they relish the fast that the real world is squishy.
So, my point is that I see a lot of designers trying to make great design by making them mathematically perfect or at least adhering to mathematical beauty. I think while this is a lofty goal, they tend to break down in the real world. The best designs make the most out of the least number of moving parts. These designs do not target mathematical purity as the goal. But, the funny thing is that these designs tend to be beautiful in a mathematical sense. Thus, achieving the mathematical purity goal anyway. When I look at good designs (ala Seaside). It seems the goal was to get the most with the least. They certainly achieved it since I believe Seaside is still the easiest and takes the least amount of coding of any of the web frameworks. Also, if you look at the code, there is a sense of wonderment and mathematical beauty. I would be curious as to what design goals they had for it.
The real world is squishy and has lots of rules that don't seem to make sense. Let's embrace this randomness and chaos instead of shunning it because it's not pretty. Let's make our designs of the real world beautiful by writing the least amount of code.
I am addicted to achieving great design and I love reading about how to do it better. To me, design has always been about getting the most out of the least. I think this is what we admire most in art and music. Artists and musicians making the most out of the least. If you look at the greatness of Bach and Mozart, they were masters at making the most out of a small number of ideas. It's the ingenuity of stretching those few (great) ideas to their maximum while delighting the listener. I think of program design the same way. I want to write the least amount of code to get the most functionality. So, I tend to favor techniques that allow me to type less and don't make me repeat myself. This is why I favor dynamic languages like Smalltalk, Lisp, and Ruby. I also favor those languages because they give more tools to get the most out of my ideas.
Now, there is a huge push in the academic circles of computer science for mathematical purity. I even see this in the industry. I think the static typing advocates like the mathematical purity of typing. Haskell is one of those languages loved by academia. I know I was impressed with the typing system of Haskell initially. It's typing system is a lot better than what you see in Java/C++. It's cool until you get past some of the simple examples and things start to get a little messy. The point I'm trying to get to here is that computers are built on simple mathemtical principles outlined by Turing and Von Neuman. What a lot of folks want to do is extend that model to everything a computer does. But, just because what you are building is based on pure mathematics, doesn't mean the whole system needs to be. I know it sounds absurd. But, buildings have a basis in mathematics too. But, there's that squishy area where user requirements and construction and design meet. It's this squishy area that can not be expressed in math. It's the area where years of contracts have made the art of building business software complicated and hard. The languages we use and ideas we have should be amendable to this fact. I think the dynamic languages are all built on simple mathematics as well, but they relish the fast that the real world is squishy.
So, my point is that I see a lot of designers trying to make great design by making them mathematically perfect or at least adhering to mathematical beauty. I think while this is a lofty goal, they tend to break down in the real world. The best designs make the most out of the least number of moving parts. These designs do not target mathematical purity as the goal. But, the funny thing is that these designs tend to be beautiful in a mathematical sense. Thus, achieving the mathematical purity goal anyway. When I look at good designs (ala Seaside). It seems the goal was to get the most with the least. They certainly achieved it since I believe Seaside is still the easiest and takes the least amount of coding of any of the web frameworks. Also, if you look at the code, there is a sense of wonderment and mathematical beauty. I would be curious as to what design goals they had for it.
The real world is squishy and has lots of rules that don't seem to make sense. Let's embrace this randomness and chaos instead of shunning it because it's not pretty. Let's make our designs of the real world beautiful by writing the least amount of code.
Dynamic Freedom Hoedown
Well, James Robertson's blog has been full of activity on the whole dynamic vs. static typing debate. But, I was reading one comment and it really bothered me. Read the fun here and here So, I thought I would post on it.
Dynamic typing is a good idea. I've worked on several projects in the past (Smalltalk, Java, C++, etc). And by and large, the Smalltalk projects have been less error prone. Now, the interesting question is why. And I think it has NOTHING to do with type checking! It has everything to do with the environment. You see, you are constantly running code in a Smalltalk environment and you never let any chunk of code go un-ran for any length of time because you are always checking your work. In Java and C++, you do this less because of the whole code-compile-run cycle. The compile cycle is implicit and incremental in the Smalltalk system. Plus, the type checking system hinders more than it helps. You are typing in a lot of information without getting any benefit. I find I can change my designs quicker and more safely with dynamic typing and TDD. In Java and C++, you have to get the design upfront because it is so hard to change it down the road. The funny part is a design always changes because your understanding changes during the process and it's great for the design to reflect your new found knowledge. I know I am not the only person with the problem. Just read Martin Fowler ("Reefactoring"), Kent Beck ("TDD"), and countless other better than I.
Isn't the point of arguing to argue? NOTHING HAS BEEN PROVEN. Our science is still too new to have hard and fast rules that need no arguing in fact, if we stop, we might as well just give up on improving. I want to keep improving, so I am going to argue where I disagree. Thank you very much.
I think you're confusing when a bug is expensive. I see edit, compile, and runtime as all development activities. I agree bugs are more expensive as THE PROJECT PROGRESSES. And the worst kind of bugs are requirement bugs and those are the expensive ones because they generally require design changes. Smalltalk handles design changes very well while Java/C++/etc doesn't because of the all typing information that gets in the way of the redesign. Besides in Smalltalk, there is no distinction betwen edit/compile/run times. It's all together.
What do you know! I'm a senior architect / developer in the real world too! What's your point? Does the title give you more validity? I think in our industry titles are thrown around way too much to prove points. Anyway, I digress. I think our job as more experienced developers is to educate the less experienced developers. If they don't know how to spell encapsulation TEACH IT TO THEM! If you never show them the way, they will always be lost. They will always be ruining your "perfect" designs. TEACH! It's your duty!
I've worked both sides and I chose. I choose Smalltalk. Not only for the dynamic typing but for its superior environment.
If you don't have a clear understanding of all the objects in your system, then you do a poor job of design. You didn't split the system up into the right modules. You don't need to know about every object, but you should know how the modules fit together and how the objects in the modules you work on work. I think you have the same problem whether you work in Smalltalk or Java or whatever. It's a good/bad design issue.
Repeat after me, TDD, TDD, TDD. Keep saying it because EVERY system needs to do it. Without, enforcing all the types in the world will not fix bugs. Most of the bugs I run into are not interface problems, but internal bugs in the objects. The interface bugs are the easy to fix and no brainer bugs. The harder ones are in which there is an algorthm problem in the drawing of a component on the screen (taking from you example of course).
If you always assume the users of your code will be idiots then the code will be unusable by smart folks as well as idiots. I always think that the people that will be using my system will be smarter than me. I do not want to shackle them in anyway because I want them to be to adapt to circumstances that I never could have imagined when I wrote the code. I firmly believe this because Swing was built assuming the users would be idiots and it's the worst case of design I have ever seen. It just reeks bad design and part of that is because of developers assumed the developers were idiots. Never think of your fellow comrades like that, it's rude and not true. If you think they are idiots, it means they are not as educated as you. Well, your job is to educate them, not protect them.
The average programmer IS NOT AN IDIOT. How dare you! The average developer is a smart person and it's impossible to know everything about computer science. If your developers don't get your designs, then maybe your designs are poor or maybe you need to educate them with what you know. I spend most of time educating and an architect that ridicules and not teaches is not an architect IMHO. It is your job to teach. My dream is to teach what I know so someone will have the time to learn something new to teach me.
You would be amazed. At the company I work at, they come from all walks. Some of had no training and they are excellent developers in their own right. They all varying degrees of expertise and well, they all love to learn. So, yes, I am dealing with people that you say I am not. In fact, the quality of the Smalltalk code is better. Why? Because of the whole constant edit/run cycle that Smalltalk encourages And that's not a dynamic vs. static argument. It's an environment. Static vs. dynamic argument comes into play when we start talking changing designs. In that regard, dynamic always wins. We all need TDD to ensure our code works. There are no short cuts in that arena.
Well, James Robertson's blog has been full of activity on the whole dynamic vs. static typing debate. But, I was reading one comment and it really bothered me. Read the fun here and here So, I thought I would post on it.
- Comment from: Darren Oakey on '2004-08-15T22:28:25-05:00'
I read Peter's post, but with no obvious way to submit a comment on that page, I have come back here. I'll start first stating my amusement at the "you're wrong because.. well.. I say so" approach to argument :)
Anyway. Most of the post is devoted to pointing out that you can do type-safety in Smalltalk. Gee.. Who cares? I'm not attacking Smalltalk I think it has a lot of good things about it, which is why I read Smalltalk blogs.  For that matter, in more traditional languages, you can have complete dynamic types. You can just declare something as an "object".
The argument that I put forwards though was that (please think outside the confines of any particular language) - the conceptual mode of programming towards a specific locked type is SAFER and therefore BETTER.  i.e. - a software program made with a higher level of type safety will have less bugs than a software program without - that's all I'm saying - and that concept wasn't addressed at all.
"oh but I've done a big software project without type safety". Well done. Congratulations.Â
Doesn't say whether it was a good idea
Dynamic typing is a good idea. I've worked on several projects in the past (Smalltalk, Java, C++, etc). And by and large, the Smalltalk projects have been less error prone. Now, the interesting question is why. And I think it has NOTHING to do with type checking! It has everything to do with the environment. You see, you are constantly running code in a Smalltalk environment and you never let any chunk of code go un-ran for any length of time because you are always checking your work. In Java and C++, you do this less because of the whole code-compile-run cycle. The compile cycle is implicit and incremental in the Smalltalk system. Plus, the type checking system hinders more than it helps. You are typing in a lot of information without getting any benefit. I find I can change my designs quicker and more safely with dynamic typing and TDD. In Java and C++, you have to get the design upfront because it is so hard to change it down the road. The funny part is a design always changes because your understanding changes during the process and it's great for the design to reflect your new found knowledge. I know I am not the only person with the problem. Just read Martin Fowler ("Reefactoring"), Kent Beck ("TDD"), and countless other better than I.
I will make some more assertions - if you disagree with these, there is no point in discussing anything, because I see these as "proven" statements. They are part of the frames of reference, not part of the argument...
Isn't the point of arguing to argue? NOTHING HAS BEEN PROVEN. Our science is still too new to have hard and fast rules that need no arguing in fact, if we stop, we might as well just give up on improving. I want to keep improving, so I am going to argue where I disagree. Thank you very much.
1> edit time checking is superior to compile time checking is superior to runtime checking. Just read any McConnell book, or look up ANY metrics on programming. The cost of a bug or error goes up exponentially the later it is detected. It's a documented fact.
I think you're confusing when a bug is expensive. I see edit, compile, and runtime as all development activities. I agree bugs are more expensive as THE PROJECT PROGRESSES. And the worst kind of bugs are requirement bugs and those are the expensive ones because they generally require design changes. Smalltalk handles design changes very well while Java/C++/etc doesn't because of the all typing information that gets in the way of the redesign. Besides in Smalltalk, there is no distinction betwen edit/compile/run times. It's all together.
2> Safer = better. I don't know about you, but I am a senior architect / developer in the real world. Many of the programmers I work with wouldn't be able to spell encapsulation, let alone explain what it means. If, when I build the core libraries people use, I give someone a way of doing something stupid... rest assured - they will..
What do you know! I'm a senior architect / developer in the real world too! What's your point? Does the title give you more validity? I think in our industry titles are thrown around way too much to prove points. Anyway, I digress. I think our job as more experienced developers is to educate the less experienced developers. If they don't know how to spell encapsulation TEACH IT TO THEM! If you never show them the way, they will always be lost. They will always be ruining your "perfect" designs. TEACH! It's your duty!
So - back to the core discussion. Is it (conceptually) better to code with type safety, or better not to. Of course, practically, we all use both. For instance if I made a collection class - I'd make the base collection class with "objects", and then specialize it for each class I actually use.   Of course something like templates/generics give us the best of both worlds - and strongly typed functional languages like Miranda, with pattern matching go even better... but lets look at the extremes - if you are forced to make a choice, which way should you go?
I've worked both sides and I chose. I choose Smalltalk. Not only for the dynamic typing but for its superior environment.
Now - to argue the dynamic type problem, I'll throw out two statements which I'll then support - those statements together logically demonstrate the need for type safety: a) dynamic types are only safe if you have a clear and complete understanding of the objects you are working with and b) in a large system with a lot of programmers of various skills and experience, it is impossible to have a clear and complete understanding of the objects you are working with.
If you don't have a clear understanding of all the objects in your system, then you do a poor job of design. You didn't split the system up into the right modules. You don't need to know about every object, but you should know how the modules fit together and how the objects in the modules you work on work. I think you have the same problem whether you work in Smalltalk or Java or whatever. It's a good/bad design issue.
So.. looking at a) We've done the road example. Let's go back to the train track example, and we can very easily see why even if you can, it is dangerous to do something that wasn't expected by the designers. Suppose in the real world, we have two states, NSW and Queensland, that evolve their train system differently, and end up with different gauges. They eventually decide to communicate, and we have a massive amount of trouble doing so. We end up with all sorts of kludges to stop at the border, transfer cargo and so forth - and it ends up costing us millions and millions...  That's bad right?
Well - suppose instead initially - they had both looked up the US standard. And followed that. The gauges are compatible. Yay.. lots of saved money. However... what we didn't know - and when they drove the trains on and started using the lines, no one thought to mention it, because it didn't occur to anyone - was that NSW early in development had had better suspension technology. Over the years, the superior trains in NSW had allowed much tighter corners than you ever saw in Queensland.
So.. What happens when the press all gets ready and watches for that first passenger train to come screaming down the lines from Queensland? Yes. That's right. The train derails, and hundreds of people die.
A contrived example, sure - but it applies to every part of the system. If I pass a control object to a graphics collection, I EXPECT, because I'm guaranteed - that that object will be able to draw itself. There is zero possible benefit, and an enormous amount of possible danger of passing an object that can't draw itself to a function that draws all the objects in the collection.   While we can say "oh yeah, and this expects objects that behaves as follows" - why shouldn't we ENFORCE that? Even though it might be slightly more work, it is guaranteed to be superior in 100% of cases. Â
Repeat after me, TDD, TDD, TDD. Keep saying it because EVERY system needs to do it. Without, enforcing all the types in the world will not fix bugs. Most of the bugs I run into are not interface problems, but internal bugs in the objects. The interface bugs are the easy to fix and no brainer bugs. The harder ones are in which there is an algorthm problem in the drawing of a component on the screen (taking from you example of course).
And, going to statement b) the reason it is necessary is because in the real world, you have no idea who will next use the class that you've just written. They could be a complete idiot, they certainly won't understand all the assumptions you've made and the thinking you've done to produce the class - and won't have the time to read all (or any of) the documentation you've provided with it. All they see is a function call that they have to send values to.
If you always assume the users of your code will be idiots then the code will be unusable by smart folks as well as idiots. I always think that the people that will be using my system will be smarter than me. I do not want to shackle them in anyway because I want them to be to adapt to circumstances that I never could have imagined when I wrote the code. I firmly believe this because Swing was built assuming the users would be idiots and it's the worst case of design I have ever seen. It just reeks bad design and part of that is because of developers assumed the developers were idiots. Never think of your fellow comrades like that, it's rude and not true. If you think they are idiots, it means they are not as educated as you. Well, your job is to educate them, not protect them.
The greater restrictions, guards, pre/post conditions etc you can place on that function, the BETTER the resulting system will be. ALWAYS. Because the average programmer is a complete idiotÂ
The average programmer IS NOT AN IDIOT. How dare you! The average developer is a smart person and it's impossible to know everything about computer science. If your developers don't get your designs, then maybe your designs are poor or maybe you need to educate them with what you know. I spend most of time educating and an architect that ridicules and not teaches is not an architect IMHO. It is your job to teach. My dream is to teach what I know so someone will have the time to learn something new to teach me.
I think one problem that you are facing understanding this is that you are dealing mostly with what is a very niche language. Your average Smalltalk programmer will be a fairly serious, hardcore developer - because the language itself is not very accessible. You are not daily dealing with people who's entire programming experience is that 4 day introduction to VB course..  But that's the sort of person who ends up using my libraries, and I need every bit of safety I can get my hands on.
You would be amazed. At the company I work at, they come from all walks. Some of had
Sunday, August 15, 2004
Saturday, August 14, 2004
Extreme Late Binding and The Definition Of OOP
I found this over on comp.lang.smalltalk. It's a post by Omaha's very own Alan Wostenberg. We Smalltalkers sure do know how to kick a lot of booty. I also love the quote from Alan Kay at the bottom. Why can't the static dudes understand? SIMPLICITY and LATE BINDING is where it's at! Come feel the love with us! Anyway, without further delay:
I found this over on comp.lang.smalltalk. It's a post by Omaha's very own Alan Wostenberg. We Smalltalkers sure do know how to kick a lot of booty. I also love the quote from Alan Kay at the bottom. Why can't the static dudes understand? SIMPLICITY and LATE BINDING is where it's at! Come feel the love with us! Anyway, without further delay:
- "Static typing prevents certain kinds of failures. Unfortunately, it
also prevents certain kinds of successes." - Ned Batchelder, quoted by
Peter Lund{1}
I had one of these surprise successes today. Situation was: how to
report progress to the interactive user of a very long running
calculation in a remote image. I began by passing the remote calculator
a value model
remoteObject longCalculation: 0 asValue.
The idea was the calculator's inner loop would periodically send #value:
to the model with an update of % done:
RemoteObject>>longCalculation: aModel
1 to: 10 do: [:each | aModel value: (each / 10).
(Delay forSeconds: 1) wait. ]
So far so good. But the advantage of extreme late binding came when I
changed my mind and decided to use a Block of arbitrary code to report
status. Now it happens that Block also responds to #value: and so the
client image can report status in a totally different way:
remoteObject longCalculation: [:percent | Transcript show: percent
printString;tab;flush].
Remote server doesn't know wether client is passing in a numeric
ValueHolder or a Block -- it takes anything that responds to #value: .
It stunned me and my teamates this worked! We're passing a block context
in the client image across the ORB to the server, which evaluates it
inside the client. This little block is far simpler than the distributed
event-change notification mechanism!
Question: Remote blocks work Distributed Smalltalk. Will they still work
in OpenTalk?
Anyway it was a nice late surprise. At compile time I thought I wanted a
numeric ValueHolder, and later, during debug, I decided to use a block.
(while in the debugger, 'natch). Extreme late binding is so liberating
Alan Kay makes it part of his definition of OOP{2}
"OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things. It
can be done in Smalltalk and in LISP. There are possibly other
systems in which this is possible, but I'm not aware of them"
-----
Alan Wostenberg, Omaha
Wednesday, August 11, 2004
Build Your Own Bush
Now, this is too funny. I can't even explain it. Just go here and see for yourself. Silly fun!
Now, this is too funny. I can't even explain it. Just go here and see for yourself. Silly fun!
Happy Guy
Well, it seems this is the nick name they have given me on my new team...=) I haven't had a nick name since I was in junior high (I was called "Apple Man" because all I did was hack on my Apple ][e). Anyway, I love it and think it's cute. Describes me to a T or at least how I would like to be thought of... At least, they didn't come up with any 4 letter words as my nick name...=)
Well, it seems this is the nick name they have given me on my new team...=) I haven't had a nick name since I was in junior high (I was called "Apple Man" because all I did was hack on my Apple ][e). Anyway, I love it and think it's cute. Describes me to a T or at least how I would like to be thought of... At least, they didn't come up with any 4 letter words as my nick name...=)
I'm 34% hippie, man!
Check out this far out test. I hope this doesn't get my Black Sabbath fan club membership revoked...=)
Check out this far out test. I hope this doesn't get my Black Sabbath fan club membership revoked...=)
Tuesday, August 10, 2004
Dynamic vs.Static: More thoughts
Why do static type languages tend to favor more complicated frameworks while dynamic languages prefer easy frameworks? Or maybe it's just me, but I find the frameworks in dynamic languages usually incorporate less code and are easier to understand than their static counterparts. I think it's the mindset. Dynamic developers generally like to be able to change any aspect of their world and don't like shackles. Their frameworks reflect that. Static developers on the other hand want to be protected from themselves and believe that you should protect your code from other malicious developers (look at "Effective Java" for examples of this). So, it makes me wonder if the debate will ever end because of this. It's shackle-less vs. shackled development. The static guys put so much stuff in their frameworks to protect you from yourself, they forget the real problem they are trying to solve(case in point, EJB-entity beans any one? They were to solve persistence, but failed miserably). Give me freedom, give me easy, give me concise, give me dynamic!
Why do static type languages tend to favor more complicated frameworks while dynamic languages prefer easy frameworks? Or maybe it's just me, but I find the frameworks in dynamic languages usually incorporate less code and are easier to understand than their static counterparts. I think it's the mindset. Dynamic developers generally like to be able to change any aspect of their world and don't like shackles. Their frameworks reflect that. Static developers on the other hand want to be protected from themselves and believe that you should protect your code from other malicious developers (look at "Effective Java" for examples of this). So, it makes me wonder if the debate will ever end because of this. It's shackle-less vs. shackled development. The static guys put so much stuff in their frameworks to protect you from yourself, they forget the real problem they are trying to solve(case in point, EJB-entity beans any one? They were to solve persistence, but failed miserably). Give me freedom, give me easy, give me concise, give me dynamic!
Subscribe to:
Posts (Atom)
Posts
