[antonovka]

Some comments; I'm focusing on the negatives below, but I'll note that Cappuccino is a truly fantastic idea and exactly what web development should be.

Obj-J is more verbose than regular JavaScript. More use of objects and method selectors than callback functions. I usually prefer callbacks to delegate objects. It's easy to just make a catch-all object and use that with an anonymous function if you'd rather not specify a class for something that requires a delegate method, though it's not idiomatic Cappuccino/Cocoa.

I have to agree here -- delegates are a really poor replacement for closures, which is one thing JS can do pretty well. Delegates are definitely idiomatic Objective-C (although, Obj-C now has blocks), but it'd be nice if the standard libraries embraced closures.

Awful debugging. Worse than regular JS debugging. Usually can't even easily tell what line a syntax error is on.

I found this to be an enormous issue, especially due to the fact that without a compiler, I tended to have stupid type errors cropping up that took way too long to debug.

Mostly non-existent documentation. Still in rapid development, things change a lot. If you don't already know how to use Cocoa, expect to be totally lost.

The lack of stable releases, a clean binary installation (don't clutter up my system), proper documentation, et al, makes the project fairly difficult to approach -- especially without a type-checking compiler and poor debugging support. It's a bit of a moving target if you're going to try and use it, and there's a lot of gotchas that will require you to go to the source to figure them out.

[boucher]

Not sure what you mean by lack of stable releases. Are you saying that the releases are not stable, or that the release schedule is not stable?

I believe our releases have been fairly solid, but I do admit they don't follow any predictable schedule. We'd like that to change, but there are higher priority problems for us at the moment.

We also do offer a clean installer. First, all of cappuccino works without installing anything. It's self contained in a single app folder. Second, the tools all come bundled in one installer, which puts files wherever you like, defaulting to /usr/local/share/objj. We ship the documentation with the same download.

And as for the type-checking compiler part, we actually have an experimental type-checking runtime available on github. Improvements are, as always welcome. But not having a type-checking compiler is certainly par for the course in the JavaScript world, so I don't quite see how it counts against Cappuccino.

All that being said, yes it is young, yes it is a moving target, and yes there's a lot of work left to be done.

[antonovka]

Not sure what you mean by lack of stable releases. Are you saying that the releases are not stable, or that the release schedule is not stable?

Both -- the releases were generally infrequent and tended to have issues that require running the latest versions from git to resolve.

We also do offer a clean installer. First, all of cappuccino works without installing anything. It's self contained in a single app folder. Second, the tools all come bundled in one installer, which puts files wherever you like, defaulting to /usr/local/share/objj. We ship the documentation with the same download.

My experiences trying to build from source (which was necessary as the releases fell considerably behind the development with requisite bug fixes) resulted in a bit of a mess in my home directory and the destination root (as well as interdependencies between), rather than just building cleanly in-place, but perhaps I was operating it incorrectly.

And as for the type-checking compiler part, we actually have an experimental type-checking runtime available on github. Improvements are, as always welcome. But not having a type-checking compiler is certainly par for the course in the JavaScript world, so I don't quite see how it counts against Cappuccino.

The primary count against Cappuccino vs straight JS is the difficulty in tracking down issues when they inevitably emerge. It sounds like things might have improved for Safari 4 users, however.

Not that I wouldn't mind type-checking for JS, too.

All that being said, yes it is young, yes it is a moving target, and yes there's a lot of work left to be done.

Absolutely. Please don't take my criticism as anything but friendly intent.

[tlrobinson]

Note that you don't actually need to run the installer. You can just add "Tools/objj/bin" from the download or "$CAPP_BUILD/Release/env/bin" from the build to your PATH.

We probably don't make that clear anywhere, sorry.

[tolmasky]

Regarding delegation, I feel both closures and delegation have their place. We have been adding closure-based API in the areas we feel make sense (things that have a single expected callback return for example). However, I feel that things like TableView delegates and data sources still benefit much more from the delegate model than the closure model, and yes its because its more restrictive. If you look at NSTableView, it has many many datasource and delegate methods that are intricately related, and forcing you to group them in an object leads to better code in my opinion.

Perhaps more importantly, delegates and data sources allow you to do the Interface Builder-style visual development that we are aiming for. There really is no way to do this sort of thing with closures, unless you consider "double click on an object and type some code" to be visual development, which I do not. This is why I think closures make a lot of sense for things like network connections, callbacks for panels, etc. but less sense for things that in the common case really do represent connections and interactions between objects.

Interestingly though, we have recently been thinking of ways of "allowing both" easily. In other words, either making everything closure based behind the scenes and providing additional APIs for delegate, or making everything delegate based and transparently creating anonymous delegate objects for closures.

[tumult]

Yeah I find that delegation makes more sense in an OO context when the states between the delegate and other object are closely entwined. TableView data source is a perfect example, basically the two states need to stay consistent with each other but provide several standardized methods for modifying or reporting changes to state, which is where I think delegate methods shine. "Just waiting for something to return" is where I think they tend to be cumbersome when you have lambdas at your disposal.

In this regard I think JS and Obj-C are now starting to converge, which is interesting.