

Atlas: Visual IDE for Cappuccino Applications - nailer
http://280atlas.com

======
stephen
As a professional programmer, I'm torn between the upside of open source
software (primarily that I can use it without getting budget approval and a
nightmare enterprise sales cycle involved) and the downside of it making it
harder for programmers to make a living building software tools (although
support contracts come close).

I admit I'm just as guilty as the next for saying "I won't use X unless its
open source" but I really do hope the 280north guys do well with Atlas. As a
profession, I think it would be nice if they were able to build great tools
and actually, you know, get paid for it.

Case in point is Hibernate--I'm less of a fan of it than I used to be, but the
insane number of projects using it for very real higher-productivity/lower-
development-cost gains to me means its author, Gaven King, should be very well
off right now, not just landing a nice salaried position at JBoss-now-Redhat.

Co-workers and I have occasionally mused about how to help open source
developers get income from their work in a non-invasive way. E.g. not having
to pin your hopes on being the next SpringSource-type acquisition. Nothing
ground breaking yet. Has anyone seen good approaches for this?

~~~
jerome_etienne
what about a non-commercial use license for free, and a commercial use license
for a fee ?

\- the software's author get money from his work and thus can go on provide
good software to people

\- only the ones with money needs to pay

\- people without money get your product for free... you dont loose money as
they wont buy your product anyway and they give you community and
adverstissement for free.

<http://www.longtailvideo.com/> jw player seems to do well with this schema.

am i missing something ?

~~~
dagw
I actually think the way they are doing it is now is quite good. The
underlying framework and API are all open source and free to use, but they
charge for what seems to essentially be an IDE.

You're free to develop apps with their framework for free using your text
editor of choice, and if you really want you can write your own IDE and other
tools on top of their framework to ease development. However if you want to
use their IDE you have to pay.

~~~
jerome_etienne
said like that it makes good sense. thanks

------
anshul
No linux version... They talk of targeting windows in another month. Is a
linux version planned?

They should consider going the balsamiq route... ie provide that in-
browser/git thingy he talks about in the dev video as a free demo possibly
with limitations _and_ with strategically placed upsells. This will allow non-
mac people to use the app and provide for a try before you buy. They could of-
course charge for this as a product or a service and/or beta charge for it.

I am not a cappuccino or a cappuccino app user at this point. The user base I
deal with does seem to react to loading times and loading perceptions quite a
bit. The improvements promised by 0.8 mark the first point it seems it could
be viable for me to do a mini-app in cappuccino (thanks mainly to the loading
related improvements promised). Atlas seems interesting too. Would try if I
could.

~~~
boucher
Linux support should come with windows support, because of the way we're doing
it.

------
gommm
I'm currently developing an app in Cappucino and it's quite sweet... I'm not
sure if I'll actually use the IDE, but I'll pay anyway because I want to
support their work

------
jerome_etienne
dont bother would be my advice

1\. i clicked and failed to find any release. only a video and a mailing list.

2\. only a beta _will_ be released and you will have to pay 20$ to get it. To
pay to debug their code? the offer is not that compelling.

let hope those are just glitch during the launch

~~~
geuis
I agree. I haven't been much of a fan of Cappucino since seeing a review at a
Google JS meetup several months ago. I have just never been sure what the
point of a language written on top of javascript is. The whole point of really
knowing not only the core language but also the inconsistencies between IE and
the rest of the browsers is that I want to build web apps that perform fast
and robustly. Abstracting that away into yet another layer that runs
moderately slowly on the 70% of common browsers just means that it runs that
much more slowly. To be fair, I give all the credit in the world to the 280
North guys, but charging $15 for access to a beta program for an environment
and language that really has no broad adoption is just not worth it.

~~~
nrr
"I agree. I haven't been much of a fan of the NeXTstep class library since
seeing a review in [a prominent publication of the period] several months ago.
I have just never been sure what the point of a language written on top of C
is...

"To be fair, I give all the credit in the world to the NeXT guys, but charging
$3500 for a microcomputer without a vast application library and that really
has no broad adoption is just not worth it."

That said, here's how I see things.

(1) 280 North took a broken environment and tried to apply a not-entirely-
broken substrate atop it. Is it going to be slow? Sure, but consider also that
Javascript is inherently slow to begin with.

(Slow begets slower, blah blah, I don't want to hear it. I don't care.)

(2) It's a start, and when it comes to 280 North's business practices, I'd be
willing to bet that there might very well be a standalone compiler for
Objective-J at some point if enough people ask for it.

... if I don't beat them to it first. It's getting close to the point where
I'm considering just hacking something together in OCaml to scratch my own
itch in this vein.

(3) The 280 North guys are smart guys. They listen. Complain. Send them mail.

~~~
boucher
On point number 2, the compiler ships with the open source project. It's
written in Javascript. It runs in the browser, or on the command line.

We are planning on getting a new compiler in 2010, and it will still do all
those things. It will also be more robust, introduce some sorely needed new
features, and with any luck be faster to boot.

With respect to point one, I'm not sure anyone commenting in this thread
really understands the complexity of optimizing application performance in the
browser. On an absolute level, message passing is slower than function
calling. But taken in context, that's a small percentage of what happens in an
application.

Cappuccino, because its an application framework, can make certain assumptions
to dramatically improve performance. Assumptions that can not be made here and
there by individual app developers. For example, coalescing DOM updates and
drawing events on the run loop. Combining timers together to minimize
overhead. Delegating events from the document level to prevent unnecessary
build up of event handlers. On the tools front, we can strip some dead code
from projects, automate spriting of all app resources, target different code
paths to different browsers automatically, and a slew of other things.
Performance is complicated.

------
aw3c2
___What is Atlas?_ __- > ___Atlas is a development tool for building
Cappuccino applications._ __

Is it some MacOS thing?

~~~
swombat
<http://lmgtfy.com/?q=cappucino+applications>

