Re: I think I am Python Challenged
Posted: Jun 22, 2005 9:41 AM
> But unfortunately there are not so many successfull
> projects that support your claim at least not in my
> experience where huge redesign-efforts that were not
> carefully wrapping / substituting legacy code but starting
> on greenfields with Java burned > 100 Mio $ for nothing
> but hype, ideology and wrong expectations.
Is that a fault of the platform, or is it mismanaged projects or incorrect assignment of responsibility? There are lots of factors to consider for the failure of any project.
> > The .NET platform sports multiple languages, as does my
> > choice platform, Java.
> Do they also support COBOL and PL1 and several machine
> languages on old IBM mainframes?
It seems that you are talking about maintaining and/or extending an existing application. If you want to move your cobol or pl1 application off of a mainframe, then you probably are going to have to make some changes, no matter what. So, the question becomes is it a better choice to start over, or to continue to feed the fire.
> One can also reverse the direction and create translations
> for several backends. PyPy adopts this approach ( e.g. for
> CLISP, Java, CPython, LLVM ... ). That's the way a
> hopefull and usable extension language should work that is
> able to glue systems together and enable soft migration -
> not forcing each to run on the same platform with more or
> less efficient language implementations.
I think you and I are talking about different levels of development. Extension languages are about automating certain APIs already in a software architecture. That's only part of the problem.
Explain how you take an application running on one machine and then distribute piece parts to multiple machines and then integrate those pieces into a new distributed system. That's the kind of thing that I'm talking about with integration.
It might also be that there are already disparate applications on different machines that need to talk to each other. There are a wide range of choices for how to do it. The question is, which choice provides the most powerful position for growing your new system.
I'm saying that the Java platform (J2SE) is a great way to do this because of its OS neutrality. Java applications running on PowerPC MACs are going to work just as well on Intel MACs. Native code won't.
There are of course additional tools, such as the Jini platform, that provide some great tools for distributed system building.
If you choose to use an extension language to paste your new world together, then you'll have to keep applying glue everywhere to hold it together because a real architecture will be difficult to create within a bunch of adhoc programming structures.
When you put a new wrapper around something, I think there is a lot of value in making the commitment to that being the base of a new SOA/Corporate/Enterprise architecture that will allow new systems to be easily deployed, and fully isolate the legacy environment from view.
This is in essense starting over. However, the initial layer is much cheaper to build than a complete rewrite of the legacy apps. But, it is a very firm foundation with a lot of opportunity to exploit some very powerful features of the Java platform.
I don't want to point any fingers and any particular response, but there is still a lot of feedback in this thread about micro-productivity gains from being able to sit at a prompt and do things. For me, that seems like a complete lack of architecture. I worry that this kind of approach will make sure that an architecture will never really appear.
If you are talking about doing this in some kind of design or investigative phase, then perhaps so. But, I'm not convinced that this is the case. It sure sounds like you want to be able to just sit down and invent a small function to do something and then throw it into the codebase, adhoc.