Hi, while I see many of your points, I disagree with some of them:
We have a tool that allow us to deliver complete and powerful applications in 2-6 weeks (and even less): Pharo. Right now my small company (of myself :) ) is finishing (bah, doing some change requests) for an application for managing thousands of accounts and data. Application was made on Glamour+Magritte+MongoTalk+Some persistence and reporting tool made by myself, based on magritte. Customer is really happy, because now they can obtain reports of any kind instead the shit they have before (made in Delphi, but there is not a problem of delphi itself but the programmer using it) The time to develop from scratch this? Four weeks-man. And if we took off all the work I made to make MongoTalk work, reporting and some personal adjusts to glamour, it would be less than three weeks (is important to know, because that work does not need to be repeated...). (btw, I could do the same for the web, using Seaside) Also, we are working (not yet there, but almost), to accomplish several of the issues not completely done for enterprise: 1) we have DBXTalk, to RDBMS. Is slow, but that's a problem of FFI that we think it will be solved soon (with Threaded FFI) 1.1) we also have a growing set of packages for working with NoSQL (Mongo, Riak, Tokio) 2) we have UI components and powerful frameworks like Glamour, but I agree there is a lot more work needed there 3) we have ways to talk to outside world (FFI, NB)... but also I agree more work is needed there (for instance, I would like to embed pharo into other applications, not just call libraries from pharo) 3.1) we also have SOAP support (never tried, not sure it's status) 4) For remote: we have Ubiquitalk 5) authentication: not sure what you mean but we have cryptography and work for secure connections is on the way (with Zodiac) 6) reporting. Ok, not much here... but there is HPDF package and I will release my HPDFReport and CSVReport classes soon (they are very easy classes anyway, don't expect too much :) for... bach modules... not sure what are you meaning with that... So yes, many of this issues are not really finished or stable (and that's why I see your concerns)... but just think where we were last year. I'm really optimistic about the future. What we really, really need is a book: "Pharo for the Enterprise". Something like the JEE specification, explaining how enterprise customers can use Pharo for their business, right now is a bit confusing, I admit that. Other concern (but this is a no-point for discussion, I just wanted to say it :P): Java and C# are not easy at all to learn. They are hard and ugly and new programmers spend years learning it (if they ever learn it completely)... also it is uncomfortable for starters (look how much you need to have a simple "hello, world" there). You think preparing an image is hard? give a new programer a maven script and ask him to build an application with that. Or worst, ask him to add a new dependency... Industry uses those languages and not Smalltalk for many-many reasons... but this is not one of them. (Also... there is a lot of big industries still developing on COBOL. sadly) best, Esteban El 21/02/2012, a las 2:16p.m., Krishsmalltalk escribió: > > The choice is ours to make and define. > > Yes enterprise is boring for those wanting life on the edge: tech or anything > alike... I would love to jump over to the other side... > > Its like the freedom of being Picasso vs being a commercial artist in a > studio. > > Enterprise typically will use software that is stable and capable of being > easily usable by newbies. It cares less for the edge of technology, which can > be achieved by just a minimal subset of the developer community. Yes no new > larger enterprise stuff will happen in COBOL or ilk... But java and c# have > proven to be easier to train in freshers, capable of adapting and calling any > of the new technology if required etc. The very facts we tout as major > winners in smalltalk is actually dimly viewed by the bulk of managers in > enterprise: dynamic typing to begin with. They love the fact that the junior > dev cannot commit many blunders that smalltalk can carry. Image based > runtime, packaging , source code mgmt in st, etc are amongst stuff few > comprehend well. Also we lack any decent libraries to for many a task, > including reporting, DBMS , soap and many other stuff which when required > only the ingenous smalltalker can cobble it, not our general developer base. > > I can be specific with tons of example, that we need to push a clean rock > stable kernel and winning platform like rails, that make it hugely possible > for a small firm to push out completed apps in 2 to 6 weeks. It's like the > construction industry, be able to pick all components of the software: > authentication, DBMS / ORM , reporting, UI components, messaging, interfaces > to outside world viz soap, FFI , Remote , batch modules, ... One can push in > a long list... > > All this is important only if we want to succeed statistically and that > enriches the community to then indulge even more in research, it's symbiotic > in that way. The more success you get in the industry the more funding there > will be to do fundamental research eventually, the more happier all levels of > smalltalkers from the expert to the beginners will be. > > Modified Quote from Kung Fu panda: master oogway "enterprise .. No enterprise > .. Who cares", what we do care for is the eventual adoption of smalltalk as > an equal partner in the landscape of languages, platforms in the world, gives > enough money for everyone around. Unequal if it must eventually.. > > > > On Feb 21, 2012, at 1:02 PM, Marcus Denker <[email protected]> wrote: > >> >> On Feb 21, 2012, at 3:11 AM, Krishsmalltalk wrote: >> >>> Yes, >>> >>> Do not emphasize on one or few keywords. Malleable is better than plastic >>> (can be off putting for any environment conscious) >>> >>> Adopt the Pharo motto: >>> >>> "Pharo shall be one of the best enterprise platform in 3 years." >> >> >> Isn't "Enterprise Plattform" another word for "boring and complicated" ?? >> >> Marcus >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >
