Home > Archive > Smalltalk > December 2007 > Recommendation Migration from Smalltalk to JAVA
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Recommendation Migration from Smalltalk to JAVA
|
|
| aknighley@gmail.com 2007-11-02, 7:14 pm |
| Hello,
Although we have enjoyed the Smalltalk environment for years, we come
to a point were we have to consider migrating to JAVA.
Our environment is VSE.
Now, we really thanks and welcome any recommendation in this project,
including:
- specialized service companies having track records in such
migrations.
- recommended tools to do so
- recommendations on the migration process.
Thanks in advance for any advice and help.
We are open to study migration to other environment such as
- .NET
- or other environment (other smalltalk ?) provided we get the
insurance such other environment will be commercially maintained for
years.
However, strong argument are required since the global strategy for us
is J2EE.
Thank you to Smalltalk advocates and fans to avoid to post messages
argueing Smalltalk it is far better and powerfull than JAVA since we
know this for sure as we have enjoyed for years Smalltalk advantages.
Now, very practically and pragmatically, we have a project were we
have to migrate.
Again, Thanks in advance for any advice and help.
Regards
| |
| Janko Mivšek 2007-11-02, 7:14 pm |
| I would strongly reconsider to migrate rather to other Smalltalk than
Java or even .NET. There is Cincom VisualWorks and ObjectStudio and
Cincom is a company which has a proven record to never abandon its
customers. Just consider that they are still maintaining a Total
database from 70s!
And there is also Gemstone, which is not only a database but Smalltalk
too and it has also a proven record of stability and very big and loyal
customers.
Consider also, what a pain will this migration actually be and how many
failures there were. Actually, did we here any migration success story
so far?
Best regards
Janko
aknighley@gmail.com wrote:
> Hello,
>
> Although we have enjoyed the Smalltalk environment for years, we come
> to a point were we have to consider migrating to JAVA.
>
> Our environment is VSE.
>
> Now, we really thanks and welcome any recommendation in this project,
> including:
> - specialized service companies having track records in such
> migrations.
> - recommended tools to do so
> - recommendations on the migration process.
>
> Thanks in advance for any advice and help.
>
> We are open to study migration to other environment such as
> - .NET
> - or other environment (other smalltalk ?) provided we get the
> insurance such other environment will be commercially maintained for
> years.
> However, strong argument are required since the global strategy for us
> is J2EE.
>
> Thank you to Smalltalk advocates and fans to avoid to post messages
> argueing Smalltalk it is far better and powerfull than JAVA since we
> know this for sure as we have enjoyed for years Smalltalk advantages.
>
> Now, very practically and pragmatically, we have a project were we
> have to migrate.
>
> Again, Thanks in advance for any advice and help.
>
> Regards
>
--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
| |
| Frank Lesser [LSW] 2007-11-02, 10:10 pm |
| Hi,
you should look at the VSE list (
http://www.listserv.dfn.de/archives/vswe-l.html in english ). There is a
recent discussion about migration to our Smalltalk ( LSWVST ).
LSWVST is not published yet but due to some real interest we are researching
a publishing of LSWVST in 2008.
LSWVST has a Bytecode & Primitive number compatible migration mode and
allows loading SLLs & starting with a VSE Image.
With LSWVST you get a multithreaded unicode-based compiled modern Windows
Smalltalk. The virtual-machine is about 110 KB executable including the JIT
compiler & multithreading-support written in Assembly.
We claim that we reach the speed of C. There are still a few serious
applications written in VSE and if we can collect enough new business
customers we will publish LSWVST.
with best regards, Frank Lesser, www.lesser-software.com
<aknighley@gmail.com> schrieb im Newsbeitrag
news:1194028194.223200.261060@z9g2000hsf.googlegroups.com...
> Hello,
>
> Although we have enjoyed the Smalltalk environment for years, we come
> to a point were we have to consider migrating to JAVA.
>
> Our environment is VSE.
>
> Now, we really thanks and welcome any recommendation in this project,
> including:
> - specialized service companies having track records in such
> migrations.
> - recommended tools to do so
> - recommendations on the migration process.
>
> Thanks in advance for any advice and help.
>
> We are open to study migration to other environment such as
> - .NET
> - or other environment (other smalltalk ?) provided we get the
> insurance such other environment will be commercially maintained for
> years.
> However, strong argument are required since the global strategy for us
> is J2EE.
>
> Thank you to Smalltalk advocates and fans to avoid to post messages
> argueing Smalltalk it is far better and powerfull than JAVA since we
> know this for sure as we have enjoyed for years Smalltalk advantages.
>
> Now, very practically and pragmatically, we have a project were we
> have to migrate.
>
> Again, Thanks in advance for any advice and help.
>
> Regards
>
| |
| Guido Stepken 2007-11-03, 8:11 am |
| aknighley@gmail.com schrieb:
> Hello,
>
> Although we have enjoyed the Smalltalk environment for years, we come
> to a point were we have to consider migrating to JAVA.
You must be crazy. You will need 3 times more programmers with JAVA
compared to smalltalk.
> Our environment is VSE.
>
> Now, we really thanks and welcome any recommendation in this project,
> including:
> - specialized service companies having track records in such
> migrations.
> - recommended tools to do so
> - recommendations on the migration process.
>
> Thanks in advance for any advice and help.
>
> We are open to study migration to other environment such as
> - .NET
Ask Frank. With Frank's Smalltalk you even can program for .NET, write
DLL for XP and so on. (Still .NET 1.1 if i remember right Frank's
descriptions, hope this will change soon ;-)
> - or other environment (other smalltalk ?) provided we get the
> insurance such other environment will be commercially maintained for
> years.
Sign a NDA with Frank and you get SOURCE (sure, not for free)
> However, strong argument are required since the global strategy for us
> is J2EE.
J2EE is expecially designed for very small amounts of data, put together
with code into containers, dashing through the network looking out for
free CPU and MEMORY to be calculated.
Do you really think, this design fits your needs? I have seen more giant
projects dying after having changed to java J2EE, than you can imagine.
Last project was 1.000.000.000€ for german tax office (the former fiscus
GmbH, Bonn). They burned all money for nothing, just a few input/output
sheets... The other was IBM at FAG Kugelfischer, INA. They burned
500.000€/month over 3 years for a simple project: writing a warehousing
program and connecting it to SAP.
Never ever mention J2EE in comp.lang.smalltalk, ok?
> Thank you to Smalltalk advocates and fans to avoid to post messages
> argueing Smalltalk it is far better and powerfull than JAVA since we
> know this for sure as we have enjoyed for years Smalltalk advantages.
Ok. Why then such nonsense with J2EE?
> Now, very practically and pragmatically, we have a project were we
> have to migrate.
No. There is nothing what you can't do e.g. with Franks Smalltalk, even
write DLL, for .NET and so on. And you do not have any intermediate crap
code like MSIL. Franks Smalltalk directly generates 32 bit assembler
code, blindingly fast. 64-bit pointes for better use of memory is in
preparation, pure 64 bit code ... i fear 250.000 lines of code in his
assembler (writtten in assembler) aren't changed easily.
> Again, Thanks in advance for any advice and help.
Have fun, Guido Stepken
| |
| Marten 2007-11-03, 8:11 am |
| I've been using VSE in the last decade until 1997 and then I switched
to VASmalltalk
around that time - one of the main arguments were the existance of
WindowBuilderPro,
which I was used to use at that time. I was and still are very
satisfied with that
product.
If you really consider a migration your only chance is a change to
another Smalltalk
dialect and actually there are only two choices out there: Cincom and
Instantiations.
If you switch to JAVA or .NET you are not doing a migration, but a
rewrite - actually,
that's what I found out, when doing such a project (we switched
to .NET).
Actually when doing that switch one must be very honest with oneself -
there
are wishes of the management, which have to be considered - but in my
experience there
are nearly no real economical reason (even if management tells so) to
switch away from
Smalltalk.
We went to .NET (using VS2005) - reasons were political ones and
perhaps the wishes
from the developers to be in mainstream again (perhaps to be in a
better situation to
get new jobs).
The result ? Unsure - it was NOT the big win. Developing in C# (or
perhaps Java) is not
nicer than in Smalltalk. Less freedom and lots of technical things
I've forgotten over
the years developing with Smalltalk. There are also problems with .NET
and
VS2005 and all that stuff. Its getting larger and larger, difficult
and more difficult
....
The most interesting stuff is: in comparision to .NET Smalltalk is a
lean system. Needs
less memory and it has still a much better interactivity - the larger
your system get,
the more interactivity you have with Smalltalk.
| |
| Friedrich Dominicus 2007-11-03, 7:12 pm |
| Marten <marten@toppoint.de> writes:
>
> If you switch to JAVA or .NET you are not doing a migration, but a
> rewrite - actually,
> that's what I found out, when doing such a project (we switched
> to .NET).
I could not agree more. But I before bashing the OP, it would be a
good idea from him to explain why he thinks moving to Java will help
in anyway.
>
> Actually when doing that switch one must be very honest with oneself -
> there
> are wishes of the management, which have to be considered - but in my
> experience there
> are nearly no real economical reason (even if management tells so) to
> switch away from
> Smalltalk.
One can rewrite software and maybe sometimes it's really
necessary. However that must be terrible serious reasons. One of it is
that the vendor of the tools used for building has simply gone. But
even that does not make the code fully useless.
>
> The result ? Unsure - it was NOT the big win. Developing in C# (or
> perhaps Java) is not
> nicer than in Smalltalk. Less freedom and lots of technical things
> I've forgotten over
> the years developing with Smalltalk. There are also problems with .NET
> and
> VS2005 and all that stuff. Its getting larger and larger, difficult
> and more difficult
> ...
I can not reall name it but I have the idea that the stuff gets too
complicated and that there are so many layers of abstraction that it's
getting more counterproductive...
>
> The most interesting stuff is: in comparision to .NET Smalltalk is a
> lean system. Needs
> less memory and it has still a much better interactivity - the larger
> your system get,
> the more interactivity you have with Smalltalk.
And if one uses a cross-platform Smalltalk the chance of getting
something run on other platforms are higher. Maybe unimportant for a
windows shob but still a reason to be a bit more cautious.
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
| |
|
| Words to the wise, aknighley@gmail.com wrote:
>Hello,
>
>Although we have enjoyed the Smalltalk environment for years, we come
>to a point were we have to consider migrating to JAVA.
At the company I am working we have "migrated" a server application
from Smalltalk (VS) to Java. However, it was not a migration, it was a
complete rewrite.
If you are looking for a Java IDE, I would strongly recommend having a
look at IntelliJ, it beats Eclipse hands down.
The migration process was as follows: Look at what we have, remodel
the object hierarchy to get rid of a few annoyances, and then
implement it in Java.
As for tools:
If you are using UML to do modelling in Smalltalk, you should be able
to use the same UML to get a class structure (Object model) in Java,
but that is about all you can do.
If you are in need of an application sever, look closely, for there
are quite a few differences. We are using Glassfish.
Hope this helps a bit.
--
Claus Dragon <clauskick@mpsahotmail.com>
=(UDIC)=
d++ e++ T--
K1!2!3!456!7!S a27
"Coffee is a mocker. So, I am going to mock."
- Me, lately.
| |
| Reinout Heeck 2007-11-05, 4:29 am |
| aknighley@gmail.com wrote:
>
> Now, we really thanks and welcome any recommendation in this project,
> including:
> - specialized service companies having track records in such
> migrations.
> - recommended tools to do so
Synchrony Systems offers St->St and St->Java migration services.
They use their own in-house tool to transform the code.
I don't know about their track record ;-)
http://www.sync-sys.com/solutions/index.html#migration
HTH,
Reinout
-------
| |
| zorin.slavik@gmail.com 2007-11-05, 7:24 pm |
| On Nov 2, 1:29 pm, aknigh...@gmail.com wrote:
> Hello,
>
> Although we have enjoyed the Smalltalk environment for years, we come
> to a point were we have to consider migrating to JAVA.
>
> Our environment is VSE.
>
> Now, we really thanks and welcome any recommendation in this project,
> including:
> - specialized service companies having track records in such
> migrations.
> - recommended tools to do so
> - recommendations on the migration process.
>
> Thanks in advance for any advice and help.
>
> We are open to study migration to other environment such as
> - .NET
> - or other environment (other smalltalk ?) provided we get the
> insurance such other environment will be commercially maintained for
> years.
> However, strong argument are required since the global strategy for us
> is J2EE.
>
> Thank you to Smalltalk advocates and fans to avoid to post messages
> argueing Smalltalk it is far better and powerfull than JAVA since we
> know this for sure as we have enjoyed for years Smalltalk advantages.
>
> Now, very practically and pragmatically, we have a project were we
> have to migrate.
>
> Again, Thanks in advance for any advice and help.
>
> Regards
Hello,
Please, contact Synchrony Systems - http://www.sync-sys.com for
information on our solutions, products and services.
Synchrony is known worldwide as the migration company of mission-
critical Smalltalk applications across Smalltalk platforms and to
other platforms such as Java and C#. We've just completed a major
migration of 3 VSE applications for a major Bank in Amsterdam/
Netherlands. We'll be publishing a customer experience report this
w . The 3 applications were migrated in 9 months and put in
production 2 months later. We are known for our comprehensive
migration and modernization technology called SMT.
My name is Slavik Zorin and you can contact me directly at
914-703-6610 to discuss how to move forward.
Regards...
| |
| zorin.slavik@gmail.com 2007-11-06, 7:19 pm |
| On Nov 5, 4:01 am, Reinout Heeck <rein...@soops.nl> wrote:
> aknigh...@gmail.com wrote:
>
>
> Synchrony Systems offers St->St and St->Java migration services.
> They use their own in-house tool to transform the code.
>
> I don't know about their track record ;-)
>
> http://www.sync-sys.com/solutions/index.html#migration
>
> HTH,
>
> Reinout
> -------
Reinout, please check out our reference page
http://www.sync-sys.com/customers/index.html#stories.
Thank you for pointing the gentlemen to our site.
I also want to take this opportunity and note that Smalltalk
migrations is only one of three Synchrony offerings.
The others focus on management and modernization of existing Smalltalk
systems in Smalltalk.
We also have capabilities to use our technology to upgrade
applications from earlier versions of VisualWorks with Envy to the
latest version of VisualWorks and Store. Similarly, we can migrate VSE
not only to Java but to VisualWorks.
Regards,
Slavik
| |
| Fernando Rodriguez 2007-11-08, 8:11 am |
| Hello zorin.slavik@gmail.com,
> My name is Slavik Zorin and you can contact me directly at
> 914-703-6610 to discuss how to move forward.
> Regards...
Is the Smalltalk -> Java path moving forward or backwards?
| |
| jarober 2007-11-08, 8:11 am |
| Any such migration is a rewrite, so it's more of a "stand still"
option. Ask yourself: It will take you N months to redo the
application, during which time you'll have no new capabilities. If
you instead spent that time enhancing the existing application, what
new capabilities would you have?
IMHO, such migrations rarely make sense.
On Nov 8, 5:49 am, Fernando Rodriguez
<fernandoREMOVE_T...@easyjob.net> wrote:
> Hello zorin.sla...@gmail.com,
>
>
> Is the Smalltalk -> Java path moving forward or backwards?
| |
| zorin.slavik@gmail.com 2007-11-11, 7:17 pm |
| On Nov 8, 5:49 am, Fernando Rodriguez
<fernandoREMOVE_T...@easyjob.net> wrote:
> Hello zorin.sla...@gmail.com,
>
>
> Is the Smalltalk -> Java path moving forward or backwards?
Are asking if we can migrate Java back to Smalltalk? The answer is
yes.
| |
| zorin.slavik@gmail.com 2007-11-11, 7:17 pm |
| On Nov 8, 7:02 am, jarober <jaro...@gmail.com> wrote:
> Any such migration is a rewrite, so it's more of a "stand still"
> option. Ask yourself: It will take you N months to redo the
> application, during which time you'll have no new capabilities. If
> you instead spent that time enhancing the existing application, what
> new capabilities would you have?
>
> IMHO, such migrations rarely make sense.
One of the key distinctions with Synchrony's SMT technology is that it
enables ongoing development during migration. SMT is complete
modernization platform that supports merges and replayability. This is
the reasons customers have chosen us over competition. Read our recent
success story from Fortis Bank. We are also about to publish another
massive migration of a system of nearly 200K methods, 8K classes and
2200 screens from VAST to Java/Eclipse/SWT.
Make no mistake about it. A rewrite is the only path doomed to
failure. The reason is because inevitably it takes a lot longer then
anyone projects since in most places original engineers are long gone.
Without advanced technology support and experience with
transformations, a rewrite has been recorded to take 10x compared to
migrations. Additionally, migration at least ensures that you get a
similar performing system without any loss of functionality. Any
rewrites (from any environment not just Smalltalk) end up taking
almost as much time as it took to develop the original application and
sometimes more. The reason for this is that the knowledge of a new
language and platform is lacking.
Of course, there are always reasons to start anew. However, even in
such cases, having a system already working on the target platform is
a whole lot easier to improve than to start from scratch. Some of our
customers use Synchrony and SMT just to get some of the key software
assets to the target platform so that they get a kick-start.
I would love to have a discussion and answer any questions which
arise. We have really good specific case studies and can talk about
some real details such as how to deal with interfaces which are
implicit in Smalltalk but explicit in Java just as the rest of the
static type system in Java. There's the topic about blocks and other
Smalltalk metaphors such as resumable exceptions, object mutation,
richer meta programming model, etc.
It's hard enough to give up the elegance of Smalltalk and replace it
with this arcane C syntax and the rest of Java/C# noise. Rest assured
if your company decided to leave Smalltalk, you're much better of
starting with a technology like SMT to get a leg up. Remember, these
so-called mainstream languages are a whole lot more verbose. You have
lots of work to do from scratch so please, be very careful in your
rewrite recommendations, especially if it is just your humble
opinion :)
Regards,
Slavik
| |
| jarober 2007-11-11, 7:17 pm |
| IMHO, it's a rewrite regardless of the quality of the migration
tools. As such, I stand by my assertion that migrations are almost
always a "stand still while the competition moves forward" option.
On Nov 11, 3:44 pm, zorin.sla...@gmail.com wrote:
> On Nov 8, 7:02 am, jarober <jaro...@gmail.com> wrote:
>
>
>
> One of the key distinctions with Synchrony's SMT technology is that it
> enables ongoing development during migration. SMT is complete
> modernization platform that supports merges and replayability. This is
> the reasons customers have chosen us over competition. Read our recent
> success story from Fortis Bank. We are also about to publish another
> massive migration of a system of nearly 200K methods, 8K classes and
> 2200 screens from VAST to Java/Eclipse/SWT.
>
> Make no mistake about it. A rewrite is the only path doomed to
> failure. The reason is because inevitably it takes a lot longer then
> anyone projects since in most places original engineers are long gone.
> Without advanced technology support and experience with
> transformations, a rewrite has been recorded to take 10x compared to
> migrations. Additionally, migration at least ensures that you get a
> similar performing system without any loss of functionality. Any
> rewrites (from any environment not just Smalltalk) end up taking
> almost as much time as it took to develop the original application and
> sometimes more. The reason for this is that the knowledge of a new
> language and platform is lacking.
>
> Of course, there are always reasons to start anew. However, even in
> such cases, having a system already working on the target platform is
> a whole lot easier to improve than to start from scratch. Some of our
> customers use Synchrony and SMT just to get some of the key software
> assets to the target platform so that they get a kick-start.
>
> I would love to have a discussion and answer any questions which
> arise. We have really good specific case studies and can talk about
> some real details such as how to deal with interfaces which are
> implicit in Smalltalk but explicit in Java just as the rest of the
> static type system in Java. There's the topic about blocks and other
> Smalltalk metaphors such as resumable exceptions, object mutation,
> richer meta programming model, etc.
>
> It's hard enough to give up the elegance of Smalltalk and replace it
> with this arcane C syntax and the rest of Java/C# noise. Rest assured
> if your company decided to leave Smalltalk, you're much better of
> starting with a technology like SMT to get a leg up. Remember, these
> so-called mainstream languages are a whole lot more verbose. You have
> lots of work to do from scratch so please, be very careful in your
> rewrite recommendations, especially if it is just your humble
> opinion :)
>
> Regards,
> Slavik
| |
| zorin.slavik@gmail.com 2007-11-12, 7:17 pm |
| On Nov 11, 6:11 pm, jarober <jaro...@gmail.com> wrote:
> IMHO, it's a rewrite regardless of the quality of the migration
> tools. As such, I stand by my assertion that migrations are almost
> always a "stand still while the competition moves forward" option.
>
Except for the fact that this is your assertion that empirically has
been proven wrong!
We have migrated 45 Smalltalk applications all of which were done
concurrently with active ongoing development.
Its not just about good technology; its about experience of migrating
working systems without ripping and replacing them.
Developing new software is a completely different skill compared to
taking an existing software and moving it to another platform.
The migration specialist needs to have deep knowledge of programming
languages in general, think in abstract terms about program structure,
composition, grammar, and have an ability to translate intelligently
the underlying software to alternate programming language and
platform. So, if you've never ported a complete system from one
platform to another, it is no surprise that you think it can only be
rewritten. This is precisely your skill - writing new software. Its a
whole different ball game trying to understand software written by
others and focus on transforming it with high quality to an
alternative programming environment while preserving its function,
performance and quality.
Cheers,
Slavik
| |
| Esteban A. Maringolo 2007-11-12, 7:17 pm |
| zorin.slavik@gmail.com escribió:
> On Nov 11, 6:11 pm, jarober <jaro...@gmail.com> wrote:
>
> Except for the fact that this is your assertion that empirically has
> been proven wrong!
> We have migrated 45 Smalltalk applications all of which were done
> concurrently with active ongoing development.
> Its not just about good technology; its about experience of migrating
> working systems without ripping and replacing them.
Can you share more date about that migrations?
What are Smalltalk dialects from where the companies flees most and what
are the main reason of migration?
<humor>
However... migrating to Java is future work assured for you, because all
the companies will then migrate to another platform :-D
</humor>
Regards,
--
Esteban.
| |
| Guido Stepken 2007-11-12, 7:17 pm |
| My experience is, that migration from a high-level language like
smalltalk to java/.NET ... only costs 1/3 of former development costs.
OpenSource has shown us, that e.g. J2EE -> JBOSS was 1/3, .NET-MONO even
less, PHP had a rewrite, PHPNuke, Linux Kernel from 1.3 to 2.x, e.g. ...
Even a rewrite in C can be very cheap. Have a look e.g. at the Novell
Filesystem code in Linux Kernel from former Timpanogas. Shows brillant
structured code. I even have seen OO code in "C" (YES, even that works,
though "C" is not explicit OO, but think about CFRONT from AT&T!)
We had migrated in India, China for about 6.000 bucks per manyear. And -
no, nobody of the former programmers had to be thrown out. They had to
learn new programming language, new framework ... they really had fun!
regards, Guido Stepken
| |
| Davide Grandi 2007-11-12, 7:17 pm |
| Guido Stepken <stepken@web.de> wrote:
> We had migrated in India, China for about 6.000 bucks per manyear
500 bucks/month.
Davide Grandi
--
Ing. Davide Grandi
davide.grandi@mclink.it
| |
| Bruce Badger 2007-11-13, 8:12 am |
| Guido Stepken wrote:
> My experience is, that migration from a high-level language like
> smalltalk to java/.NET ... only costs 1/3 of former development costs.
> OpenSource has shown us, that e.g. J2EE -> JBOSS was 1/3, .NET-MONO even
> less, PHP had a rewrite, PHPNuke, Linux Kernel from 1.3 to 2.x, e.g. ...
> Even a rewrite in C can be very cheap. Have a look e.g. at the Novell
> Filesystem code in Linux Kernel from former Timpanogas. Shows brillant
> structured code. I even have seen OO code in "C" (YES, even that works,
> though "C" is not explicit OO, but think about CFRONT from AT&T!)
I've done some of this kind of think too and I agree that once the
algorithm is sorted out it can be re-coded for less than one might
imagine a total rewrite would cost.
At least in theory.
In practice most in-house projects are trying to hit a moving target
because business moves on. So it's not a simple rewrite in most cases,
it's a simple re-write + "Oh, while you're doing that can we also ...".
Then there is the real win for Smalltalk: It is dynamic in a business
sense. A system remains mailable over time. This is much less the case
in statically typed languages where systems become brittle.
So take your dynamic Smalltalk system and convert it to a static Java
system. Then watch as your new system becomes brittle over time and can
only keep up with the business with more and more ugly hacks and
patches, and *then* you get to the point where the only way forward
really is a re-write.
So I think Jim is right. He just missed out some ugly bits in the middle.
| |
| Thomas Gagne 2007-11-13, 7:17 pm |
| Joel Spolski wrote a great essay on this subject, called "Things you
should never do, Part I."
<http://www.joelonsoftware.com/artic...0000000069.html>
jarober wrote:
> Any such migration is a rewrite, so it's more of a "stand still"
> option. Ask yourself: It will take you N months to redo the
> application, during which time you'll have no new capabilities. If
> you instead spent that time enhancing the existing application, what
> new capabilities would you have?
>
> IMHO, such migrations rarely make sense.
>
>
--
Visit <http://blogs.instreamco.com/anything.php> to read
my rants on technology and the finance industry. Visit
<http://tggagne.blogspot.com/> for politics, society and culture.
| |
| Guido Stepken 2007-11-13, 7:17 pm |
| Davide Grandi schrieb:
> Guido Stepken <stepken@web.de> wrote:
>
>
> 500 bucks/month.
Yes. There are companies with 35.000 employees, which for every solution
they have, they find a customer with such a problem.
Can you imagine their giant CVS tree of solutions or parts of it?
I asked for a solution, described my problem. Two days later they told
me, that the already had such a case, sent me a .exe
Thats was it. 3 days later we made the deal. We payed 20.000 bucks for
adaption of code, which would have cost us 6 manyears to code.
Thats my way of programming. Using synergies, ready made software.
My Law: "Given a perfect network of information exchange, you always
find a company which already has exactly the code you can need laying
around"
Have fun, Guido Stepken
| |
| Guido Stepken 2007-11-13, 7:17 pm |
| Bruce Badger schrieb:
> I've done some of this kind of think too and I agree that once the
> algorithm is sorted out it can be re-coded for less than one might
> imagine a total rewrite would cost.
>
> At least in theory.
>
> In practice most in-house projects are trying to hit a moving target
> because business moves on. So it's not a simple rewrite in most cases,
> it's a simple re-write + "Oh, while you're doing that can we also ...".
>
> Then there is the real win for Smalltalk: It is dynamic in a business
> sense.
yes!
> A system remains mailable over time. This is much less the case
> in statically typed languages where systems become brittle.
yes!
> So take your dynamic Smalltalk system and convert it to a static Java
> system. Then watch as your new system becomes brittle over time and can
> only keep up with the business with more and more ugly hacks and
> patches, and *then* you get to the point where the only way forward
> really is a re-write.
yes!
> So I think Jim is right. He just missed out some ugly bits in the middle.
Agreed. Maintenance costs much, much less in Smalltalk, refactoring is
much less often needed, as well as a complete rewrite, which i have seen
very often in C, C++, JAVA and seldom seen in Python, Ruby and Smalltalk
It's like people speaking to each other; One knows how to express
himself in smalltalk, others simply speak pidgin, and you always have to
ask what they meant. That lets the amount of needed communications
explode and so time and money goes by.
regards, Guido Stepken
| |
| Guido Stepken 2007-11-13, 7:17 pm |
| Thomas Gagne schrieb:
> Joel Spolski wrote a great essay on this subject, called "Things you
> should never do, Part I."
>
> <http://www.joelonsoftware.com/artic...0000000069.html>
"The reason that they think the old code is a mess is because of a
cardinal, fundamental law of programming:
It's harder to read code than to write it.
This is why code reuse is so hard."
In Smalltalk it's the other way round; Smalltalk is very near natural
language and so much easier to read and understand than every other
language.
Given a problem and you are able to formulate that in natural language,
you my be able to code that in smalltalk easily.
The other extreme is the programming language 'brainXXXX':
http://en.wikipedia.org/wiki/BrainXXXX
Would you like to maintain and refactor 100.000 lines of code?
No, really? So, such huge gap you sometimes can find between clean
smalltalk and java beginners crap, who still tend towards
procedural/imperative programming, instead of
objective/functional/processual
processual programming means expressing everything in chains of verbs,
not states and subjects even dont exist... an upcoming mainstream after
the alan kay age of OO.
regards, Guido Stepken
| |
| slavik.zorin@gmail.com 2007-11-13, 7:17 pm |
| > Can you share more date about that migrations?
> What are Smalltalk dialects from where the companies flees most and what
> are the main reason of migration?
>
> <humor>
> However... migrating to Java is future work assured for you, because all
> the companies will then migrate to another platform :-D
> </humor>
>
> Regards,
>
> --
> Esteban.
Smalltalk applications running on VSE or ObjectStudio, especially the
ones still running under OS/2 (believe it or not) are the first.
Companies only "flee" for the following reasons:
1. Corporate direction is Java or .NET
2. Smalltalk skill is no longer available to support existing mission-
critical Smalltalk systems
> <humor>
> However... migrating to Java is future work assured for you, because all
> the companies will then migrate to another platform :-D
> </humor>
I don't think this statement is about Smalltalk only. We already work
with customers who are "migrating" their Java legacy to the latest
JDK. Companies move from one persistence framework to another; one gui/
development platform to another; older version of JDK to the latest,
etc... This about what Microsoft has done with VB 6.0? Move from this
platform to VB.net is more complex than moving from Smalltalk to Java.
Regards,
Slavik
| |
| slavik.zorin@gmail.com 2007-11-13, 7:17 pm |
| > Then there is the real win for Smalltalk: It is dynamic in a business
> sense. A system remains mailable over time. This is much less the case
> in statically typed languages where systems become brittle.
>
> So take your dynamic Smalltalk system and convert it to a static Java
> system. Then watch as your new system becomes brittle over time and can
> only keep up with the business with more and more ugly hacks and
> patches, and *then* you get to the point where the only way forward
> really is a re-write.
We are working to extend our type inferencing technology to Java. This
is actually quite interesting. What we do today in SMT's typed
Smalltalk is (kind of like Strongtalk) is type inference your code as
you write it. This same technology will also work in Java. Think about
it, you get to write java code without thinking of static types...
On a different note, I have question. What do you think about using
Smalltalk grammar while programming against a JDK class library? For
example dict.put(key,'hello') would be written as dict put:
key :'hello'. A slightly extended Smalltalk grammar which allows a
single keyword with multiple argument delimiters (:). Since Java only
allows a single keyword, we'd also allow to have an arbitrary keyword
for better readability, which would allows you to type dict put: key
value: 'hello'. Our compiler simply ignores the second keyword during
parsing/compilation.
Regards,
Slavik
| |
| jarober 2007-11-13, 7:17 pm |
| ObjectStudio 8 was just released, so there's really no reason to
migrate off it. As to VSE, Cincom is more than happy to help anyone
migrate to Cincom Smaltalk. Any such migration, being Smalltalk to
Smalltalk, will be simpler.
As to the reasons below
(1) If that mattered, Cobol would not be in use anywhere
(2) Are you telling me that it's easier to find young Cobol developers
than it is to find young Smalltalkers? Have you sniffed around the
Squeak or Seaside mailing lists recently?
> Smalltalk applications running on VSE or ObjectStudio, especially the
> ones still running under OS/2 (believe it or not) are the first.
> Companies only "flee" for the following reasons:
> 1. Corporate direction is Java or .NET
> 2. Smalltalk skill is no longer available to support existing mission-
> critical Smalltalk systems
>
>
> I don't think this statement is about Smalltalk only. We already work
> with customers who are "migrating" their Java legacy to the latest
> JDK. Companies move from one persistence framework to another; one gui/
> development platform to another; older version of JDK to the latest,
> etc... This about what Microsoft has done with VB 6.0? Move from this
> platform to VB.net is more complex than moving from Smalltalk to Java.
>
> Regards,
> Slavik
| |
| Arne Dehli Halvorsen 2007-11-14, 4:30 am |
| slavik.zorin@gmail.com wrote:
>
> We are working to extend our type inferencing technology to Java. This
> is actually quite interesting. What we do today in SMT's typed
> Smalltalk is (kind of like Strongtalk) is type inference your code as
> you write it. This same technology will also work in Java. Think about
> it, you get to write java code without thinking of static types...
Ah. Lovely. I can just imagine code written without all that noise, and
the inference added (but hidden in the IDE, so you could hover over it
and see what it is inferenced or anchored at).
I hate all this:
Map<String, List<Person>> personsBySurname =
new HashMap<String, ArrayList<Person>>();
Typically takes up half of the code.
I have played around with Haskell, which inferences the types for you
unless you place them in the code, typically as a separate line echoing
the function name and parameters:
personlistForName:: (Map String [Person]) -> String -> [Person] --type
personlistForName personsBySurname name = personsBySurname !! name --def
>
> On a different note, I have question. What do you think about using
> Smalltalk grammar while programming against a JDK class library? For
> example dict.put(key,'hello') would be written as dict put:
> key :'hello'. A slightly extended Smalltalk grammar which allows a
> single keyword with multiple argument delimiters (:). Since Java only
> allows a single keyword, we'd also allow to have an arbitrary keyword
> for better readability, which would allows you to type dict put: key
> value: 'hello'. Our compiler simply ignores the second keyword during
> parsing/compilation.
I would like a smalltalk grammar for Java, thousands wouldn't. Smalltalk
syntax is scary to many, and is seen by many as a large factor in the
question of why Smalltalk has lost out in the market.
Ruby wins out with C-syntax people because of this, even if Smalltalk is
more complete and more internally consistent.
>
> Regards,
> Slavik
Regards, Arne D Halvorsen
>
>
>
>
>
| |
| Bruce Badger 2007-11-14, 4:30 am |
| slavik.zorin@gmail.com wrote:
> On a different note, I have question. What do you think about using
> Smalltalk grammar while programming against a JDK class library?
I think syntactic sugar may help make things feel a little better in the
short term, but it would be a cruel kind of help because the static
typing would still get you in the end.
All the best,
Bruce
| |
| Bruce Badger 2007-11-14, 4:30 am |
| In-Reply-To: <fhcouu$icf$02$1@news.t-online.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: < CZ6dnRAMnI9eVqfanZ2dnUVZ_tGonZ2d@totally
objects.com>
Lines: 23
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 81.86.102.62
X-Trace: sv3-m5evFfsOQhJzg8id0/ npLDLwYYGhvJ0opXlZ9C7iz1oMfzPVsruuyk8QaC
D3J/d4uUsSZUEexV2Mdfd!Yv+2OEIXC+zekGU/ OTMH7ZcuPHp9LuJwpd7XRIWGM2QJzcop1cJ2J65j
bhaDCnDUJm3iaQSsO89X!xmZBFaphT/2qzF3DsJOEEquCDhqIdQ==
X-Complaints-To: abuse@totallyobjects.com
X-DMCA-Complaints-To: abuse@totallyobjects.com
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.35
Bytes: 2377
Xref: number1.nntp.dca.giganews.com comp.lang.smalltalk:137768
Guido Stepken wrote:
> Thomas Gagne schrieb:
>
> "The reason that they think the old code is a mess is because of a
> cardinal, fundamental law of programming:
>
> It's harder to read code than to write it.
>
> This is why code reuse is so hard."
>
> In Smalltalk it's the other way round; Smalltalk is very near natural
> language and so much easier to read and understand than every other
> language.
I think the point is not that a given language is hard to read *if you
try to read it*, but rather that many programmers simply can not bring
themselves to read existing code. It's a social thing, not a lexical thing.
.... but I agree that Smalltalk makes a better read than Java :-)
| |
| Davide Grandi 2007-11-14, 7:16 pm |
| Guido Stepken <stepken@web.de> wrote:
> Davide Grandi schrieb:
>
.... snip ...
> We payed 20.000 bucks for adaption of code, which would have cost us
> 6 manyears to code.
Paying 20K bucks for a code adaption has a different mean (IMHO) than
paying _someone_ 500 bucks a _month_ to migrate a complex systems.
> Have fun
I'll try, harder.
Best regards,
Davide
--
Ing. Davide Grandi
davide.grandi@mclink.it
| |
| Christian.Haider@smalltalked-visuals.com 2007-11-15, 7:56 pm |
| For a VSE to Smalltalk migration my favorite was VisualWorks with
Widgetry (former Pollock), since the transition would have been rather
straight forward (see http://www.esug.org/data/ESUG2004/E...WithPollock.pdf).
But since Cincom dropped Widgetry, I cannot recommend VisualWorks as
target platform anymore. The VisualWorks UI model is very different
from the Pane and Form oriented approach of VSE, which would make a
rewrite of most of the UI necessary. VA Smalltalk is based on the
Motif UI model on native widgets and requires more than some rewrite
rules as well. I dont know anything about ObjectStudio and how well it
matches the VSE way of doing things.
If your application has many UIs, a migration to another Smalltalk
needs some effort. But this would still be much smaller than going to
a stiffly typed language.
On Nov 13, 10:50 pm, jarober <jaro...@gmail.com> wrote:
> ObjectStudio 8 was just released, so there's really no reason to
> migrate off it. As to VSE, Cincom is more than happy to help anyone
> migrate to Cincom Smaltalk. Any such migration, being Smalltalk to
> Smalltalk, will be simpler.
| |
| craigslist.jg@gmail.com 2007-11-19, 10:20 pm |
| On Nov 2, 1:29 pm, aknigh...@gmail.com wrote:
> Hello,
>
> Although we have enjoyed the Smalltalk environment for years, we come
> to a point were we have to consider migrating to JAVA.
>
> Our environment is VSE.
>
> Now, we really thanks and welcome any recommendation in this project,
> including:
> - specialized service companies having track records in such
> migrations.
> - recommended tools to do so
> - recommendations on the migration process.
>
> Thanks in advance for any advice and help.
>
> We are open to study migration to other environment such as
> - .NET
> - or other environment (other smalltalk ?) provided we get the
> insurance such other environment will be commercially maintained for
> years.
> However, strong argument are required since the global strategy for us
> is J2EE.
>
> Thank you to Smalltalk advocates and fans to avoid to post messages
> argueing Smalltalk it is far better and powerfull than JAVA since we
> know this for sure as we have enjoyed for years Smalltalk advantages.
>
> Now, very practically and pragmatically, we have a project were we
> have to migrate.
>
> Again, Thanks in advance for any advice and help.
>
> Regards
Since everyone is offering the "pros" and "cons" for migrating to
another platform, I'd like to offer some experiences from the
"business" perspective.
I actually am a programmer, but at the previous "gig" I got to sit in
sale pitches with clients.
The company I worked for sold Application Services in a number of
industries. We had a pure Smalltalk (VAST) App Server built upon a
custom framework (geared mainly towards ecommerce websites). Some
times clients wanted to know technical specs:
....Smalltalk... ?
What is that? Don't you use .NET? Java? PHP? etc...
Some clients wanted "ownership" of the code. This became a problem
because they would also need a VAST license. In other cases, they
wanted their people to maintain their application space themselves,
which required Smalltalk savvy personnel on their part.
In the end my boss ended up omitting the word "Smalltalk" from sales
meetings and he would just say we were using "IBM Development
tools" (this was back in 2005 or so). To be honest, I can only recall
one instance where a client didn't want to go with us due to Smalltalk
being used. The guy was adamant about going with .net and / or Java.
My boss was pretty good at touting the strenghts of the "IBM tools"
such as rapid development time and painless deployments.
The moral of the story is that Smalltalk is not going to win any PR /
Marketing battles, when compared to Java / .Net.
good luck!
| |
| yuriy.yatsyk@gmail.com 2007-11-21, 7:16 pm |
| On Nov 13, 1:05 pm, Guido Stepken <step...@web.de> wrote:
> Thomas Gagne schrieb:
>
.... snip ...
>
> It's harder to read code than to write it.
>
> This is why code reuse is so hard."
>
> In Smalltalk it's the other way round; Smalltalk is very near natural
> language and so much easier to read and understand than every other
> language.
> Given a problem and you are able to formulate that in natural language,
> you my be able to code that in smalltalk easily.
>
.... snip ...
I agree that Smalltalk is easier to read because of natural language-
like syntax.
However, if a Smalltalk system is large enough, what you end up with
is this:
1. Plenty of dead code - no one bothers to delete unused methods
because it's very hard to actually determine that it's dead. This is
the stuff that you should not even be reading.
2. Smalltalk projects tend to have elaborate frameworks, which require
you to implement a few methods here and there to fit within framework.
This is the code that is hard to understand - you'll see a method, but
without the knowledge of a framework you'll have no idea why it's
there. This is where (documented) Java interfaces really help.
So while understanding individual methods is easier in Smalltalk, to
get a grasp of how the system is put together, what are the moving
parts and how they interact with each other may actually be easier in
Java.
| |
|
| Hi yuriy.yatsyk@gmail.com,
> However, if a Smalltalk system is large enough, what you end up with
> is this:
> 1. Plenty of dead code - no one bothers to delete unused methods
> because it's very hard to actually determine that it's dead. This is
> the stuff that you should not even be reading.
That is a possible state to end up in, however I have also worked in large
java and c# projects were the same was equally true - the extra type information
did not encourage people to delete code. Having running tests does seem to
make a different - and this then applies to both typed and dynamic languages
- if your tests run then people are more comfortable deleting. Additionaly
I've found with well named methods, and the use of "senders of" that people
in Smalltalk seem to delete more code than their java counterparts - part
of this seems to be that Smalltalk programmers "care" more, or have a better
understanding of how their tools work, or are surrounded by much better code
in the first place.
> 2. Smalltalk projects tend to have elaborate frameworks, which require
> you to implement a few methods here and there to fit within framework.
> This is the code that is hard to understand - you'll see a method, but
> without the knowledge of a framework you'll have no idea why it's
> there. This is where (documented) Java interfaces really help.
Again - in theory Java should be easier - but I have to disagree - Java frameworks
that people use today are extremely complicated - Hibernate, Spring etc -
these things are wickedly hard to fathom with all kinds of gotcha's. There
are reams of books on them, and even my more experienced colleagues complain
how they keep getting caught out too.
I have found that coming back to Smalltalk I was much more quickly able to
understand frameworks than in Java. I put this down to people caring more,
the better examples in the image and possibly the power of extension methods
which seem to remove un-needed levels of architectural layering (but I'm
not an architect). I also think that the image and the ease which you can
find senders seems to make navigation much less cumbersome. Of course eclipse
and idea have copied the senders idea - but somehow even with the type information
that reduces accidental method detection (which you get in smalltalk - although
I find that the application bundling that most smalltalks have lets you quickly
discount methods that aren't related), I still find that all the extra layering
that typing seems to incurr makes it hard to work out what is going on.
The ruby guys often talk about how less is more - and I believe that they
have gained this from their smalltalk heritage of the language - less is
defintitely more and dramatically eases comprehension.
> So while understanding individual methods is easier in Smalltalk, to
> get a grasp of how the system is put together, what are the moving
> parts and how they interact with each other may actually be easier in
> Java.
Yes in theory - but as I have said above - reality doesn't seem to match.
Don't get me wrong - Java and C# are ok - I've programmed in them quite a
bit but Smalltalk seems to have a lightness and joy to it that is very hard
to recreate.
Still this thread is about porting, and if you are convinced you need to
port - then I guess go for it, there are lots of arguments for and against
all mentioned.
Tim
| |
| Niall Ross 2007-11-21, 7:16 pm |
| Dear Yuriy
> I agree that Smalltalk is easier to read because of natural language-
> like syntax.
> However, if a Smalltalk system is large enough, what you end up with
> is this:
> 1. Plenty of dead code - no one bothers to delete unused methods
> because it's very hard to actually determine that it's dead. This is
> the stuff that you should not even be reading.
This is not at all my experience: because refactoring is so easy in
Smalltalk, keeping a lean ratio of code to used functionality is easier.
(There are also static and dynamic frameworks one can use to track down
tricky dead code cases.) Some practices - cloning instead of refactoring,
CM management that obstructs deletion - will cause dead code to accumulate
in any language, but not more so in Smalltalk than elsewhere.
> 2. Smalltalk projects tend to have elaborate frameworks, which require
> you to implement a few methods here and there to fit within framework.
> This is the code that is hard to understand - you'll see a method, but
> without the knowledge of a framework you'll have no idea why it's
> there. This is where (documented) Java interfaces really help.
>
> So while understanding individual methods is easier in Smalltalk, to
> get a grasp of how the system is put together, what are the moving
> parts and how they interact with each other may actually be easier in
> Java.
Again, my experience (and my theoretical analysis: see my ESUG talk, at
ESUG99 in Ghent at http://www.esug.org/data/ReportsFromNiallRoss/) is that
the lack of typing makes it _easier_ to fit into an existing framework.
Hence less code must be written to do so and less code to read means easier
understanding. (And as above there are static and dynamic analysis
frameworks if you feel that type info would help your understanding, but I
find that stepping through an example in the debugger usually helps most.)
Yours faithfully
Niall Ross
| |
| jarober 2007-11-21, 7:16 pm |
| Small correction: Where you say "Smalltalk" below, you should say
"insert your favorite language here"
On Nov 21, 12:05 pm, yuriy.yat...@gmail.com wrote:
> On Nov 13, 1:05 pm, Guido Stepken <step...@web.de> wrote:> Thomas Gagne schrieb:
>
> ... snip ...
>
>
>
>
> ... snip ...
>
> I agree that Smalltalk is easier to read because of natural language-
> like syntax.
> However, if a Smalltalk system is large enough, what you end up with
> is this:
> 1. Plenty of dead code - no one bothers to delete unused methods
> because it's very hard to actually determine that it's dead. This is
> the stuff that you should not even be reading.
> 2. Smalltalk projects tend to have elaborate frameworks, which require
> you to implement a few methods here and there to fit within framework.
> This is the code that is hard to understand - you'll see a method, but
> without the knowledge of a framework you'll have no idea why it's
> there. This is where (documented) Java interfaces really help.
>
> So while understanding individual methods is easier in Smalltalk, to
> get a grasp of how the system is put together, what are the moving
> parts and how they interact with each other may actually be easier in
> Java.
| |
| Bruce Badger 2007-11-22, 7:14 pm |
| yuriy.yatsyk@gmail.com wrote:
> I agree that Smalltalk is easier to read because of natural language-
> like syntax.
> However, if a Smalltalk system is large enough, what you end up with
> is this:
<snipped examples>
Any poorly managed software project using any language can get into a mess.
Smalltalk helps more than most to avoid getting into such a mess, and if
you are in a mess then Smalltalk provides the tools to help you get out
of it. This is because of the dynamic and malleable nature of Smalltalk
and tools such as the refactoring browser.
> So while understanding individual methods is easier in Smalltalk, to
> get a grasp of how the system is put together, what are the moving
> parts and how they interact with each other may actually be easier in
> Java.
Not in my experience. In a Smalltalk system I can dive into the running
program and see it working. Image based development using Smalltalk
debuggers and inspectors gives us the absolutely the best way to learn
what a software system is doing, and is much more powerful than trying
to understand a system by just staring at the source code - even if you
do have powerful code analysis tools (which we have in Smalltalk too if
you insist on a static approach).
All the best,
Bruce
| |
| gavino 2007-11-24, 8:11 am |
| On Nov 3, 3:27 am, Guido Stepken <step...@web.de> wrote:
> aknigh...@gmail.com schrieb:
>
>
>
> You must be crazy. You will need 3 times more programmers with JAVA
> compared to smalltalk.
>
>
>
>
>
> Ask Frank. With Frank's Smalltalk you even can program for .NET, write
> DLL for XP and so on. (Still .NET 1.1 if i remember right Frank's
> descriptions, hope this will change soon ;-)
>
>
> Sign a NDA with Frank and you get SOURCE (sure, not for free)
>
>
> J2EE is expecially designed for very small amounts of data, put together
> with code into containers, dashing through the network looking out for
> free CPU and MEMORY to be calculated.
>
> Do you really think, this design fits your needs? I have seen more giant
> projects dying after having changed to java J2EE, than you can imagine.
> Last project was 1.000.000.000 EURO for german tax office (the former fiscus
> GmbH, Bonn). They burned all money for nothing, just a few input/output
> sheets... The other was IBM at FAG Kugelfischer, INA. They burned
> 500.000 EURO/month over 3 years for a simple project: writing a warehousing
> program and connecting it to SAP.
>
> Never ever mention J2EE in comp.lang.smalltalk, ok?
>
>
> Ok. Why then such nonsense with J2EE?
>
>
> No. There is nothing what you can't do e.g. with Franks Smalltalk, even
> write DLL, for .NET and so on. And you do not have any intermediate crap
> code like MSIL. Franks Smalltalk directly generates 32 bit assembler
> code, blindingly fast. 64-bit pointes for better use of memory is in
> preparation, pure 64 bit code ... i fear 250.000 lines of code in his
> assembler (writtten in assembler) aren't changed easily.
>
>
> Have fun, Guido Stepken
What is Franks smalltalk? What about squeak? why do people write
250.000 instead of 250,000?
| |
| Janko Mivšek 2007-11-24, 7:14 pm |
|
gavino wrote:
> What is Franks smalltalk? What about squeak? why do people write
> 250.000 instead of 250,000?
Because in our part of the world we use dot to separate 000 and comma
for decimals.
Janko
--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
| |
| Aleksej Saushev 2007-11-24, 7:14 pm |
| gavino <gavcomedy@gmail.com> writes:
> why do people write
> 250.000 instead of 250,000?
Because we mean 250 thousands, and not 250 with 0,5*10^(-4) deviation.
--
CKOPO CE3OH...
| |
| brian.vanderbijl@gmail.com 2007-11-26, 8:15 am |
| On 24 nov, 11:53, gavino <gavcom...@gmail.com> wrote:
> On Nov 3, 3:27 am, Guido Stepken <step...@web.de> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> What is Franks smalltalk? What about squeak? why do people write
> 250.000 instead of 250,000?
Will you American morons please quit mixing up comma's and dots? It's
bad enough with your crappy spelling!
The decimal system was invented in the old world, so better start
using old world style when using it!
| |
| Peter Kenny 2007-11-26, 7:22 pm |
|
<brian.vanderbijl@gmail.com> wrote...
>
> Will you American morons please quit mixing up comma's and dots? It's
> bad enough with your crappy spelling!
> The decimal system was invented in the old world, so better start
> using old world style when using it!
>
I suppose you will include us Brits in your category of 'morons', since we
punctuate numbers the same way as the Americans do. And how would you
describe those who separate the thousands groups with spaces - also here in
the 'old world'?
This discussion group has so far been pretty free of this sort of childish
abuse, thank goodness. I suggest you learn the local style, or go and play
with people who think like you.
Peter Kenny
| |
|
| Words to the wise, "Peter Kenny" <pkenny@globalnet.co.uk> wrote:
>
><brian.vanderbijl@gmail.com> wrote...
>I suppose you will include us Brits in your category of 'morons', since we
>punctuate numbers the same way as the Americans do. And how would you
>describe those who separate the thousands groups with spaces - also here in
>the 'old world'?
>
>This discussion group has so far been pretty free of this sort of childish
>abuse, thank goodness. I suggest you learn the local style, or go and play
>with people who think like you.
>
>Peter Kenny
Why is anyone even replying to the original post? Does it really
matter how you spell 10000, whether 10.000 or 10,000 in the discussion
context? No, so how about staying on topic for a change?
--
Claus Dragon <clauskick@mpsahotmail.com>
=(UDIC)=
d++ e++ T--
K1!2!3!456!7!S a27
"Coffee is a mocker. So, I am going to mock."
- Me, lately.
| |
| yuriy.yatsyk@gmail.com 2007-12-02, 4:41 am |
| On Nov 21, 4:01 pm, "Niall Ross" <n...@bigwig.net> wrote:
> Dear Yuriy
>
>
> This is not at all my experience: because refactoring is so easy in
> Smalltalk, keeping a lean ratio of code to used functionality is easier.
> (There are also static and dynamic frameworks one can use to track down
> tricky dead code cases.) Some practices - cloning instead of refactoring,
> CM management that obstructs deletion - will cause dead code to accumulate
> in any language, but not more so in Smalltalk than elsewhere.
>
Well, refactoring's easy in Java - Eclipse provides all of the
Refactoring browser's functionality (I believe, IntelliJ's not bad
either). But you're right, dead code accumulates in any language. My
only point was (and I may have made too wide of a statement) that
_some_ dead things in Java are easier to find, you don't even have to
think. For example, private method that has no senders - dead. Private
anything (variable, class, interface) without references - dead. In
Smalltalk you don't have any guarantees - all member variables are
"protected", i.e. visible by subclasses and could be accessed through
reflection, no limitations whatsoever. Any method can be called
through reflection as well.
>
>
> Again, my experience (and my theoretical analysis: see my ESUG talk, at
> ESUG99 in Ghent athttp://www.esug.org/data/ReportsFromNiallRoss/) is that
> the lack of typing makes it _easier_ to fit into an existing framework.
> Hence less code must be written to do so and less code to read means easier
> understanding. (And as above there are static and dynamic analysis
> frameworks if you feel that type info would help your understanding, but I
> find that stepping through an example in the debugger usually helps most.)
>
> Yours faithfully
> Niall Ross
Of course, stepping through debugger is a great help (and may be the
only way to understand what's going on, other then talking to the
author of the code, if s/he still remembers it). And yet, I find that
when interface is clearly defined, mental effort while reading the
code is so much smaller. So, while it may be easier to fit into
framework without static types, _reading_ and understanding the code
with static types is, in my opinion, easier. One of our developers who
recently had a chance to do some Java programming now routingly
includes static type declarations in Smalltalk in comments. His
explanation - "this way I don't have to remember".
All the best,
Yuriy Yatsyk
| |
| Stefan Schmiedl 2007-12-02, 4:41 am |
| On Sat, 1 Dec 2007 22:05:30 -0800 (PST)
yuriy.yatsyk@gmail.com wrote:
> Well, refactoring's easy in Java - Eclipse provides all of the
> Refactoring browser's functionality (I believe, IntelliJ's not bad
> either). But you're right, dead code accumulates in any language. My
> only point was (and I may have made too wide of a statement) that
> _some_ dead things in Java are easier to find, you don't even have to
> think. For example, private method that has no senders - dead. Private
> anything (variable, class, interface) without references - dead. In
> Smalltalk you don't have any guarantees - all member variables are
> "protected", i.e. visible by subclasses and could be accessed through
> reflection, no limitations whatsoever. Any method can be called
> through reflection as well.
Same goes for Java. I have once used a library which uses naming
conventions to find actions associated with events, i.e. I would
define
private void button1_actionPerformed(ActionEvent e) {...}
and this method would be called when the user clicked on button1.
Yet there were no statically visible references to this piece of
code.
I guess, you can trick any static (reading your code) control mechanisms
if you're using dynamic (doing stuff at runtime) methods.
s.
| |
|
| Hi yuriy,
> Well, refactoring's easy in Java - Eclipse provides all of the
> Refactoring browser's functionality (I believe, IntelliJ's not bad
> either).
Actually IntelliJ is very good - and I would possibly say that the refactorings
in the Java IDE's are now strong than the onces in Smalltalk - but thats
really only becuase all of the money that has been spent on them.
> think. For example, private method that has no senders - dead. Private
> anything (variable, class, interface) without references - dead. In
> Smalltalk you don't have any guarantees - all member variables are
> "protected", i.e. visible by subclasses and could be accessed through
> reflection, no limitations whatsoever. Any method can be called
> through reflection as well.
I can see what your getting - in fact a dead method in smalltalk (not referenced
by anything) is easy to find - I think you really mean a method like #remove:
which is implemented in many classes, and if a class in your application
gets rid of it, it wont appear as easily because of the senders in other
classes that are using #remove: in say Set.
That said, I was often scared of this but in practice I've found its not
too bad - particularly becuase many environments (I use Dolphin) have the
concept of Packages - doing senders shows me the methods categorized by Package,
if I sort the packages I can see if any of them are mine and make a reasonably
good decision (its also good if you can run your tests as well - but even
without them, that classification goes a long way).
So yes - storng typing can help in this case but overall its not a magic
win - its gets in the way a lot and often gets subverted. Without it - the
tools in Smalltalk give you quite a lot to see whats going on and make informed
decisions.
> Of course, stepping through debugger is a great help (and may be the
> only way to understand what's going on, other then talking to the
> author of the code, if s/he still remembers it). And yet, I find that
Its not just the debugger though - navigating Smalltalk code searching for
senders and implementers seems to get you more quickly to the results you
need. And yes, Eclipse and Idea have copied that Smalltalk idea - but in
practice it just doesn't seem so easy somehow - I think its possibly becuase
the typing and interfaces mean you have to write a lot more code and so when
you navigate around there is such a lot more to see and that clutters your
understanding (its not always the case, but trying to understand Dolphin
MVP compare to understanding Struts by browsing the code base is a night
and day difference).
It might also be that there are so many bad examples that were written very
quickly in Java - so there is a legacy of ways to do things, that Smalltalk
seemed to have avoided somehow (maybe all the years in Parc payed off) -
so the clutter is less. I notice that Blaine Buxton did a recent blog post
on class sizes, number of methods and parameters and the numbers in Java
were quite a bit higher than Smalltalk - and I think this is where understanding
gets limited.
> when interface is clearly defined, mental effort while reading the
> code is so much smaller. So, while it may be easier to fit into
> framework without static types, _reading_ and understanding the code
> with static types is, in my opinion, easier.
I definitely agree with this - however you may be suprised to find that Smalltalk
has the idea of interfaces - we call them protocols and you will see that
lots of classes adhere to a convention of method categorisation that indicates
the protocols like Collection, Streaming etc. In Dolphin they have a protocol
browser that shows you this information and what objects conform to what
protocols - its not perfect but it goes a long way
> recently had a chance to do some Java programming now routingly
> includes static type declarations in Smalltalk in comments. His
> explanation - "this way I don't have to remember".
It sounds like your colleague could be using categories for this - as this
is what they get used for.
Anyway - its not a cut and dry argument - for me, while Java and C# are ok,
they aren't as much fun to program in - there just seems to be so much junk
to navigate around (even though the type information is there). I think this
is why ruby is also popular now - it will be interesting to compare ruby
and smalltalk at some point - but they don't have the tools to really do
that comparison yet (of course they seem to think they don't need any).
Tim
| |
|
| There is one simple fact, using smalltalk and envy is far superior to
anything out there. Any arguments where one tries to fine tune that
statement with the conclusion that somehow some other language/environment
is better is not factual, but political.
IBM keeps track of function point counts for all their projects. At the end
of a project, the function point team sends e-mail to the project manager
detailing the FPs for their project and the spreadsheet includes other
languages for comparison. One can argue if a project is of one type or
another then it can really boost or cut the function point count. However,
these numbers are for a wide range of projects, not one or two projects.
Smalltalk, 50 function point per 100 man hours
Lotus Notes, 30 function points per 100 man hours
Java, 20 function points per 100 man hours
PL/1, 5 function points per 100 man hours
On the political side, a company like IBM goes into a situation, talks to
someone high up in the reporting chain, non-technical, but financial, and
talks numbers to them.
'If you switch to java, we will give you the language, 200 hours of
consulting, training, maybe PCs, etc. at a discount'.
The financial guy usually says yes and the burden is on the technical people
below him to justify it and make it seem like it was a good technical
decision as well.
All of that is political. So, if one wants to switch then do it for the
right reason, the boss wants it, the boss feels it is better in terms of
money, etc. but say the switch is done because, on a technical level, java
and <the environment of your choice> is better is simply not true.
A while back, some java people posted messages here trying make just such a
case, on a technical level, talking about smalltalk islands of code, etc.
It made me laugh.
--g
| |
|
| Words to the wise, "geoff" <nospam@nospam.com> wrote:
>There is one simple fact, using smalltalk and envy is far superior to
>anything out there.
Envy is good, but it could be better. For example: you have a class
defined in two different editions of a subapplication. You create one
edition of the class in each subapplication edition. It really should
be possible to release (and version of course) both class editions in
their corresponding subapplication (or application) edition without
Envy whining about already having a released class version which might
have a slightly newer time stamp, but is defined in another
subapplication edition and therefore not existant.
--
Claus Dragon <clauskick@mpsahotmail.com>
=(UDIC)=
d++ e++ T--
K1!2!3!456!7!S a27
"Coffee is a mocker. So, I am going to mock."
- Me, lately.
| |
| geoff 2007-12-05, 10:15 pm |
| There are always issues but those things are so minor compared to the other
stuff out there.
Also, having two editons of a (sub)-application and two editions of a class
where presumably two different people are working in each edition, and each
person releases their version, *IS NOT* how OTI nor Instantiations
recommends using Envy.
However, everyone thinks they know better how to use it then later complain
about it.
--g
| |
|
| aknighley@gmail.com wrote:
> Although we have enjoyed the Smalltalk environment for years, we come
> to a point were we have to consider migrating to JAVA.
>
> Our environment is VSE.
I've been through a project migrating a company's
main application from VSE to ... a set of components
running on different platforms.
The server-side of the application was translated
to Java. The GUI-side of the application was
transformed into a web-based interface using HTML
and JavaScript.
The GUI-framework was transformed mechanically,
by a program written (by me) in Smalltalk. The
generated framework allowed further GUI -parts
to be developed in HTML, Flash, JavaScript, Curl,
or what ever the developers available required.
On hindsight Java/J2EE was overkill. It worked,
but took a lot of effort to get working correctly,
and later to add new functionality to it. The
cost of adding new features to server side went
up, from what it had been with the Smalltalk
environment.
A better decision might have been to translate
the VSE server-side to a commercially stable
Smalltalk such as VA or VisualWorks, or an open-
source -dialect such as Squeak. Or rather:
just migrate the GUI first, while keeping the
server in Smalltalk.
Once you separate the client and server-side to
separate components which communicate over well-
defined protocols (HTTP, Rest, Ajax, XML) you
can independently choose the platform for each,
now and in the future.
-Panu Viljamaa
| |
|
| Words to the wise, "geoff" <nospam@nospam.com> wrote:
>There are always issues but those things are so minor compared to the other
>stuff out there.
True, it is not a big thing. But ...
>Also, having two editons of a (sub)-application and two editions of a class
>where presumably two different people are working in each edition, and each
>person releases their version, *IS NOT* how OTI nor Instantiations
>recommends using Envy.
so how else would you fork off from the main development branch?
Are you telling me that Envy was not thought to support branching
properly?
--
Claus Dragon <clauskick@mpsahotmail.com>
=(UDIC)=
d++ e++ T--
K1!2!3!456!7!S a27
"Coffee is a mocker. So, I am going to mock."
- Me, lately.
| |
|
| > so how else would you fork off from the main development branch?
> Are you telling me that Envy was not thought to support branching
> properly?
If you have it, read the manual. Envy started as project orwell at carleton
university and yes, all of that was thought out.
--g
| |
|
| Words to the wise, "geoff" <nospam@nospam.com> wrote:
>
>If you have it, read the manual. Envy started as project orwell at carleton
>university and yes, all of that was thought out.
Ok, so there must be some changes made to Envy which generate this
useless complaint. Good to know.
--
Claus Dragon <clauskick@mpsahotmail.com>
=(UDIC)=
d++ e++ T--
K1!2!3!456!7!S a27
"Coffee is a mocker. So, I am going to mock."
- Me, lately.
| |
|
| Useless complaint is a good way to describe it, most of what I saw was
useless or over-reactins to situations of the person's own making. If one
wants to use the product their own way that is fine but don't complain about
it afterwards.
--g
|
|
|
|
|