futuremint

Something else is I also don't really like IDEs. They really are a symptom of a larger problem. And the code navigation tools that ship with most Smalltalk's really suck. They're like looking at the code through a straw, and its really hard to quickly grasp the pattern of how things hang together unless there is a comment describing it.

I still maintain a production application I wrote with Seaside, however my day job now entails Sproutcore & Rails.

At one start up a few years ago, my title on my business card was even "Code Poet".

I also happen to have an undergrad degree in Creative Writing with a focus in Poetry.

IMHO, studying poetry gives one practice in saying only what you mean and focusing on the semantics and syntax of language both technically & aesthetically. I also think that one should have an education in Liberal Arts to truly understand great design; whether that's software architecture, visual design, or business models.

I can't count the # of times my tests were failing on new code I wrote and it took me one second to look at is and say, "Oh yeah... this" and just flip -> to =>. So easy.

Other questions: are the plants an invasive species? will they crowd out other plants? I imagine if they can be thrown "anywhere" they don't need much water/soil to survive. Like most of the weeds growing around my backyard.

Not being rich, but being able to use my imagination and reason to figure out logical conclusions, I have come to realize that it is not about what you have, or who you are, but about how you're being. In the end everyone dies naked and alone regardless of how much or little money/friends/love/whatever you have.

The pension isn't using that money (right now anyway), so the VC is free to do with it what they want, and in the end the money comes back to the pension in multiples.

At least this is my understanding talking to an actual VC (not in a fund-raising situation, just casually).

This might be a story that lends itself to that. Maybe. I read this book in high school and thought it was ok then, but I didn't really understand why the people I knew who read it thought it was so great. I didn't do any research about the era this was written in though, so I don't really know if it'd help or not.

It certainly is trippy though and an entertaining read in the least.

However I believe they've moved their official headquarters somewhere to the wilds of Connecticut.

But he should totally charge an hourly rate instead of free. I know people would pay for it.

Apparently a gribble is a wood boring crustacean. Interesting.

My time is much better spent face-to-face in the real world that the time-suck that is facebook.

Also... chances are really good that if they're trying out your gem, they've tried out other gems. They've probably already had to install XCode at some point in the past. If they're a developer used to using OS X, they probably installed XCode out of habit as soon as they got their new Mac booted up.

It is a little early to talk about the sky falling about this XCode thing until we see if a gcc toolchain is shipped as a free optional install on future hardware.

The day a Mac isn't shipped with gcc somewhere in the box (DVD, memory stick, HDD, SSD) is the day you might have a point.

When you upgrade to a new version of Pharo, you're upgrading your IDE with it. When there is a bug in your system its easy to fix but its pretty tedious to make sure you track every little patch and make sure they're re-applied the next time you build a fresh image. The style of putting your overrides into a method category named the same as your package doesn't sit right with me. There are a lot of conventions like that that are hard to discover that you're expected to "just know". You're expected to peruse mailing lists frequently.

For example I found it really easy to hack in emacs-like key bindings for cursor motion... but I never load those changes into new images just because my code is slightly different from new code and I don't feel like tweaking it every time there are image updates... I've just given in and use the images as-is in the interest of moving forward.

If you run into a memory leak or slip up with some bad code in development, all of those leaked objects hang out in your image until you re-build a new image, or can manage to destroy them manually (I've had mixed results with the latter).

I repeatedly have been bitten by doing something stupid in development and have my image balloon to hundreds of MBs. You can't just Ctrl-C out of that situation... you better hope you have a backup image hanging around and that your most recent changes were committed to Monticello, or else you'll have to go recover them all manually and commit, then load them into a fresh image.

A lot of the libraries you'll find are half-baked. It is a lot easier to whip up something in Smalltalk than other languages (like say, Java), however the community isn't large enough to get enough people doing enough things for the platform to get some good quality work going outside of a few main projects (like Seaside).

Smalltalk's image-based nature does not play well with the host OS. There are some great packages for interfacing to the OS, but you'll be spending some time learning the unique ways they 'smalltalk-ize' typical OS interface areas differently than a language such as Ruby.

Now I still think Smalltalk is awesome. But I'm a lone developer at a tiny company and its akin to using a Formula-1 car to commute to work. One would be more comfortable in a boring Honda Civic. I just don't have enough resources to use it in production is all. F1 cars require large teams, but they're awesome technology!

Lately I've gone back to using Ruby, Rails, and a little Node.js for this company as those are more pedestrian technologies right now. I know one would object to Node.js being "pedestrian", but it really is pretty simple to wrap your mind around, its just Javascript and has decent documentation and isn't too much code to look over.

Smalltalk on the other hand has code for everything, so if you're averse to reinventing the wheel you'll find yourself reading a lot of (good quality) code to figure out what is where and what you should use that is already there. There also isn't a great way to get an idea of what is in libraries you might find on SqueakSource without reading through all of the code, most of it is poorly documented.

In the end, Smalltalk is awesome and frustrating at the same time. Image-based development is both a blessing and a curse. Some conventions of the culture I think are bad practices (e.g. "the code is the documentation, so we don't need to write documentation").

The actual language of Smalltalk is pretty nice and it is fun to read through posts like this because the simplicity of the language allows for easy learning of different algorithms. The underlying algorithms are pretty transparent.

It also makes it relatively easy to read through code to figure out what's going on and you learn a lot about implementation details by doing this.

Edit: forgot to mention, his Cog VM is pretty nice! It definitely helped improve performance of the system as a whole from slow & pokey to feeling quick and more modern.

Node & couch together are a pretty nice combo though, it's just JSON & JavaScript all the way. There is no context switching between programming languages like what is typical using Ruby or whatever for your application layer.

Been shoveling lots of ice & snow in my spare time instead :(

I personally think that apps in this style are better long-term than native apps for most business-y things.

So I did some research, and most people who have written them will tell you that in cases like this, training on past data doesn't correlate well with current & future data.

The stock market of 2011 is not the market of 2008.

But what do I know, not like I've actually done it :)