|
|
Re: I think I am Python Challenged
|
Posted: Aug 24, 2005 8:25 PM
|
|
> > > but
> > > in splitting the system in two parts where one part
> is
> > > adapting the other is abstracting.
> >
> > This is where Jini excels. You can use it as a front
> end
> > to place a new network centric (the network is the
> > computer) view of your computing environment. This is
> the
> > integration point!
>
> I don't see how to talk to C applications with Jini
> without using JNI but I know how to talk to C applications
> with Python without writing a line of C-Python API code.
>
> >
> > > Allthough the latter
> > > part may be evaluated on a virtual machine that is
> > > available for almost all OSes it is not system
> > independent
> > > because it interfaces to native code without an
> > additional
> > > layer in the middle ( say an XML based one ).
> >
> > I'm afraid I don't understand? The Java platform
> consists
> > of a set of APIs. The implementation of those APIs has
> to
> > meet the specs. It may or may not happen from
> interfacing
> > with native code. The aJile line of processors execute
> > Java bytecode natively at up to 100mhz. There is no
> JNI
> > or native layer there. Yet, the J2ME CLDC code that I
> run
> > on my cellphone will run on that processor just as
> well.
> >
> > I don't to see how XML fits into this. Can you
> clarify?
>
> I thought about the XML webservice thing ( which I
> consider for loosely coupled distributed apps only ) as an
> example, but since you mentioned Jini you might already
> had a competing approach in mind. I concede that you are
> right in describing a reasonable development process
> involving different, independent vendors to implement
> applications against specs but languages like Python and
> Ruby are open source and most of the time no one prevents
> anyone to change the code to fullfill personal
> requirements. Stabilizing interfaces is a requirement for
> a library that is post alpha. But I think that
> standardizing prevents innovation in some respects. I
> recognize this particularly in telecommunication industry
> ( ETSI ) where applications are still specified on the
> binary level and not on the API level. But those are
> software engineering objections which again only represent
> one aspect of the whole system.
>
> >
> > > Micro-productivity is just easy to demonstrate. An
> > overall
> > > micro-productivity helps to clarify ideas and do not
> > > obscure them by boiler-plate code.
> Micro-productivity,
> > a
> > > fast interactive feedback, a simplistic syntax and
> good
> > > extension capabilities may be the major issues why
> > Python
> > > is popular. At least I think so and try to consider a
> > > language as a whole and not just a bunch of features
> > > filling a feature matrix.
> >
> > Well, this is the question. Are all the minutes you
> are
> > saving in testing code saving you time/money in how
> much
> > work you have to do to really create the solution now,
> and
> > will it work in the future for the other needs you
> might
> > have?
>
> I don't know. Needs are out of control. They are a kind of
> free variable. That's why so many languages, tools,
> operating systems, platforms, libraries, application
> framworks etc. exist. Looking for Jini also makes me
> consider XML webservices or JXTA.
>
>
> > > I think few architectural concerns are situated on
> the
> > > language level. How to decompose a system, which use
> > cases
> > > should be applied, what are the guiding metaphors and
> > how
> > > can all the different concerns be mapped onto both
> new
> > and
> > > existing tools, machines and processes? The answer to
> > all
> > > those questions is surely not building huge class
> > > hierarchies and deploying platform independent code.
> >
> > I sense some sort of focus on the classic image of J2EE
> > applications. Large collections of boiler plate code
> > lumped into large containers of multi layered class
> > hierarchies.
> >
> > That is not Java!
> > That is only an attribute of one of the
> > more unfortunate directions that the industry decided
> to
> > take. There are perhaps 10,000 to 100,000 people that
> can
> > take advantage of J2EE tools. There are more than a
> > 1,000,000,000 that can take advantage of J2SE desktop
> > apps.
>
> Hmmm... I have to admit that I don't have J2SE desktop
> apps on my computer. They might be written in C/C++,
> Delphi or Visual Basic. Some Perl scripts, some pieces of
> Python. But Java? I always thought that Javas strength is
> on the server?
>
> > Somehow the market is being missed...
> >
> > The majority of my Java applications use the Jini tools
> > and are comprised of a handful of classes.
>
> Yes, what is the market share of Jini compared to J2EE?
>
> [...]
>
> > Okay, we're on the same page here regarding tools not
> > creating designs. But, I still contend that choosing
> the
> > right tools, including language/platform can add value
> to
> > the system you are building.
>
> I don't suggest to fall back into the pre VM/CLR age of
> course. But I think the most important result of this
> discussion if any was some agreement about tuning
> abstraction, that involves a different kind of
> conceptualisation than platform neutrality. This concern
> won't even vanish if you fix a platform say MS and declare
> Internet Explorer and MS Office to company standards.
>
> Kay
> I don't see how to talk to C applications with Jini
> without using JNI but I know how to talk to C applications
> with Python without writing a line of C-Python API code.
Most people who've used Java long enough know that the way to communicate with other languages is the network! The network is the computer! If operationally, or performance doesn't allow such integration, then it probably wasn't meant to be. With Jini, you can use any wire protocol you want to marry the RMI programming model into the integration context.
When you are just worried about making some piece of code into a library that another piece of code can use, then cross language barriers can be a big issue. But, I am not looking for those kinds of integrations. For me, that's just not productive.
In some causes, the facade pattern is a better choice where you put a new face on an old application with your language/platform of choice, and then over time, rewrite that application in the new language so that you can take advantage of all the language level performance optmizations and library like integrations that are then possible.
There may not be a good performance or cost return on such steps, so you have to figure out what works best to allow you to have a single language platform. Look at how people are treating XML as the ultimate integration language. It looks like the cats meow of solutions. What it is really doing is making it very obvious how much power and simplicity there is in a single language platform. The problem is that its focusing all the time and effort then on conversions between native types and XML.
> But I think that
> standardizing prevents innovation in some respects. I
> recognize this particularly in telecommunication industry
> ( ETSI ) where applications are still specified on the
> binary level and not on the API level. But those are
> software engineering objections which again only represent
> one aspect of the whole system.
I worked for AT&T in the 5ESS switching development center for 9 years. Believe me, I know how RBOC standards stifled innovation there, and has essentially sunk the whole fleet due to the Labs in ability to convince management that these RBOC things were not going to be profitable.
Please, please, someone name me one RBOC standard that is profitable! Bellcore told AT&T that wireless telephones would not amount to anything significant!
> > Are all the minutes you are
> > saving in testing code saving you time/money in how much
> > work you have to do to really create the solution now, and
> > will it work in the future for the other needs you might
> > have?
>
> I don't know. Needs are out of control. They are a kind of
> free variable. That's why so many languages, tools,
> operating systems, platforms, libraries, application
> framworks etc. exist. Looking for Jini also makes me
> consider XML webservices or JXTA.
XML web services are the cry for a single language platform solution. It's just that everyone has a different argument for why we can't just pick a language and move on. Politically its impossible. Technically it wouldbe challenging. Practically, there would be significant value.
> > There are perhaps 10,000 to 100,000 people that can
> > take advantage of J2EE tools. There are more than a
> > 1,000,000,000 that can take advantage of J2SE desktop
> > apps.
>
> Hmmm... I have to admit that I don't have J2SE desktop
> apps on my computer. They might be written in C/C++,
> Delphi or Visual Basic. Some Perl scripts, some pieces of
> Python. But Java? I always thought that Javas strength is
> on the server?
Javas strengths are dynamic class loading, network centric computing, and built in security.
Currently, those are hot server side topics. The RMI programming model, and Jini's use of RMI allow a service to deliver a dynamically binding UI and remote interface to your desktop. I know that a lot of people tried applets, and hate them. I am not excited by them anymore myself, really. Primarily because they are still second class citizens in the browser. Look at JavaScript. It's a first class citizen. It throws up popups, can mascarade dialogs and do all the ugly things that Java applets were guarded against doing. The world like Java Script for AJAX applications in the browser, such as maps.google.com.
With Jini's serviceUI mechanism, I can augment any application with a UI from a remote service that can be discovered and downloaded dynamically.
Jini's optimal place on the network is in near proximity to the services of interest so that the multicast range is not limiting contact with desired services.
What Jini provides as value added, to me is:
o An applet in any application with serviceUI.
o A remake of the BitBlit/DMD5620/630/730 terminal
environment where you ask for an application/service
and it comes your way for local effective use.
o Dynamic service discovery by allowing new services
to appear arbitrarily on the network for clients to
find and use.
o A completely Java focused example of how a single
language feature set, combined with the right
technologies such as dynamic code loading and
a security system can empower the developer to
fully capitalize on and exploit the network and
systems connected to it.
The big issue is that you have to believe in Java and you have to be ready to commit to learning some new concepts.
Solving problems with only a single language can create
some interesting problems to solve.
But, I have yet to be met with something that was so dramatic that I couldn't solve it with Java. The solution
might not scale in the manner that I wanted, but once I have a distributed programming environment that actually works as well as Jini does, I can proceed with problem solving instead of infrastructure creation.
> > Somehow the market is being missed...
> >
> > The majority of my Java applications use the Jini tools
> > and are comprised of a handful of classes.
>
> Yes, what is the market share of Jini compared to J2EE?
Small, but only because it doesn't have a marketing force near like J2EE does. Unfortunately, the initial licensing for Jini shut the door for most vendors. The second phase of licensing wasn't as nice for tool vendors as the apache license is now. But, it wasn't until Jini 2.0 that we had a plugable RMI programming stack that now lets Jini applications talk any transport protocol over any media supported by the computer it's running on.
> > Okay, we're on the same page here regarding tools not
> > creating designs. But, I still contend that choosing
> the
> > right tools, including language/platform can add value
> to
> > the system you are building.
>
> I don't suggest to fall back into the pre VM/CLR age of
> course. But I think the most important result of this
> discussion if any was some agreement about tuning
> abstraction, that involves a different kind of
> conceptualisation than platform neutrality. This concern
> won't even vanish if you fix a platform say MS and declare
> Internet Explorer and MS Office to company standards.
Look at what microsoft is doing with CLR. They are making sure that all languages compile to a single binary platform that allows binary interworking between languages without any programmer or tool work. That is the value added.
The Java platform also includes a VM spec that allows multiple languages to be created and run in the VM. JSR 233 will put JavaScript into Java SE 6.0. There really is value in that proposition. Little scripts and other productivity tools may not ever benefit from being written in Java or C# or whatever perse, but look at the Unix shell example.
By having the stdin to stdout connection via the pipe as a standard of interface, all those simple tools can be put together into a great big tool/application. The PBM graphics tools are a great example of exploitation of the pipe system.
If that system had instead been a monolythic application that kept needing addon code, it would have never been popular. The choice of piping the tools together was a great abstraction for those tools.
I am simply arguing that with Java and Jini in particular that there is a similar value as we've seen with pipes between applications. Both ends have a simple interface and get the data in a format already for use.
With XML web services, everyone has to convert to/from XML. If the document is broken, the application suffers. If I want to change the document structure I have to get agreement everywhere, and then carefully make changes.
With Java/Jini the contract is a compile time fact. If I change the interface, you can't find my service, or use it because your VM will say "Hey, that's not right". This is a very powerful mechanism to let things be changed fast, with less devastating impact that processing bad data can cause.
With XML web services, garbage in provide garbage out for unvalidated documents. If you're validating your documents then why not use a staticly compiled language and do that once and not worry about doing it over and over?
Okay, now I'm just ranting about my issues with XML web services. I'll save that for another blog.
|
|
Previous Topic
