Hi horrido,
I do not agree with most of yours arguments.
Here is what I picked :
...
"Indeed, many organizations have to use JVM, and yes, they probably
fall back
on Java because that's the "safe" choice."
Most CEO or IT managers think like that, but this is a false marketing
argument mostly sustained by the fact that the software is good enough
for the majority.
The Java license explicitly states that there is no warranty of
whatever. I remember in the past it was forbidden to use it for nuclear
systems, I don't know if this is still the case ;) .
The same as for several mainstream technologies, and big software vendors.
And when you are beaten by a bug (very rare yes, but it happens), it is
sometimes very hard to deal with it.
Being able to understand and master the system is a key advantage.
By dropping the vm you will depend on other and loose this advantage.
And I saw several systems choosen only on those criterias be very poor
choices for their users.
...
"If we can't convince these organizations that they'll be much more
productive using Smalltalk over Java, and save tons of money /in the long
run/, then how can we ever advance our agenda to the rest of the world??"
I do not see productivity as very important. It is just an (eventually)
good feature.
Productivity, and cost are the most flawed indicators in software
development and this is the argument I hate the most (I may be a bit
rude about that because I have to maintain some old legacy code and we
had quite some bugs last years).
Costs in the middle and long run are clearly related to code quality and
to bugs, not to productivity.
And sometimes, the cost of bugs is terrible when you think about how
many people are involved in the chain and what has to be done to solve
customer problems and revert the results of bugs. .. Awful.
For example, about the cost of null ... "I did it, just because it was
so easy"
http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare
"Strategically, it shows Smalltalk's versatility and that
it's not just a one-trick pony. Limiting ourselves to just desktop (or
Seaside) applications is rather short-sighted."
I do not understand how Smalltalk will be more versatile by using a jvm
? doing like others ?
IMHO innovation is related to change, this implies not following the
main path somewhere,
and some risks too.
A very good example here about wheels :)
http://blogs.ubc.ca/etec540sept12/2012/09/16/inventing-the-wheel/
Going on this way, one could ask why not use cloudstack or openstack and
plain java for server side , with an hypervisor-ready jvm (kenai?) ,
plain javascript for the client side and forget about the system.
It will be open to widespread frameworks library and tools, but at what
cost ? That will be safer, but would it still be interesting ?
Would you have fun using it ?
To end, I found your question a good revealer about one's expectations
about pharo, very interesting :).
--
Regards,
Alain
