|
|
Re: What's in a Programming Language
|
Posted: Jan 25, 2004 8:08 PM
|
|
This is a bit lengthy, but there are many good issues in
here.
> > > > I don't want to have to create more lines of code
> > than
> > > necessary.
> > >
> > > Then Java certainly shouldn't be your language of
> > choice!
> >
> > This is exactly the kind of attitude that I was
> refering
> > to. Blind programers want the 'language' to do
> everything
> > for them. Insightful programmers see what the language
> > already does for them and use the features of the
> language
> > to provide the remaining infrastructure to solve the
> > problem at hand.
>
> I'm glad there were enough Blind programmers in the early
> days to get us beyond machine code. Best case there has
> been no point in moving beyond C, as there hasn't been
> much that is revolutionary in language design since then.
I made a general reference to 'language' when I was more
specifically thinking about Java. Granted, Java doesn't
provide an more language constructs than C, but adding a
complete GC facility to C is what I consider a powerful
feature given how I've seen programmers just not get
pointers and memory allocation.
> Unfortunately many cases many language constructs make
> certain problems much easier to solve, as you ably point
> out by your Jini observation below. If I had a need for
> the features of Jini, I would definitely give Java a look.
> It sounds like you're determined to put your large square
> peg into a very small round hole because, dagnabbit, you
> got the purdiest shiniest square peg in existence. If
> that's insight, I would rather be blind.
Recall that I am picking my canvases, and using your
example, the canvases all have square holes that my shiny
square peg fits into.
> > If you believe that Java requires too many lines of
> code
> > then you haven't learned how to engineer software yet.
> > You have perhaps used your programming skills in one or
> > r more languages, making use of the 'methods' or
> > 'operators' directly for the problem at hand.
>
> I don't see how mastery of Java equates to learning how to
> engineer software. No language is good at every task.
I was specifically refering to this sweeping statement that
Java was not a good choice if I wanted to write fewer lines
of code. This statement, to me, says that this person
thinks that a language is all about what you can do with
the language provided constructs. It seems to ignore the
whole issue of how fast and easy can you build the tools
and constructs that you need to solve the class of problem
that you are trying to solve. Note that I said class of
problem. Programming languages are largely targeted at
classes of solutions in my view. Assembly language would
provide the ability to solve any problem. But the speed
of constructing the tools you need is the issue. And, the
solutions are specific to a particular processor/machine
and this portability (another key aspect of Java) becomes
an issue.
> I know and regularly use many different languages and very
> proud of the fact that I can do that.
...
> Are you seriously going to tell me that writing
> that little utility in Java instead of the almost
> mindless, efficient and very easy to update Python would
> prove that I was a better software engineer?
Scripting is something that have done on a regular basis
too. But, I don't always have a wide range of problems,
that I continuously need to use scripting to solve. I
use 'wc -w' to count words in documents. That's been
available to me for my entire school and professional
career. I ftp (another handy tool) files to 'UN*X'
machines to use those tools when I need to.
I've also found it handy to be able to
integrate different bits of software in somewhat adhoc
manners to quickly leverage tools and expertise that
you've developed to solve particular problems. If I've
got a large application written in Java and I need
portability across multiple OSes, then I'm probably
going to extend that application using Java to continue
to have the ability to easily take it to other OSes.
> That 20 minute
> Python program saved weeks of work doing it manually and
> probably hours doing it in a more structured, compiled
> language that doesn't have the readily available tools to
> do the sort of file manipulation I needed. Maybe I'm a
> terrible software engineer because of it, but that little
> utility saved time, money and was good enough that all the
> other teams in our company used it too. Not bad for a
> blind guy.
Again, you are talking about the tools that the language
provides directly, not what tools could exist in the language
and how you might use those tools to more readily solve
problems in a particular domain. Clearly if noone ever
creates the tools, they'll never exist. This is what has
been happening for many years. Because a particular class
of problem can't be solved with language constructs doesn't
mean that a language is incapable or inappropriate in that
domain.
Java's key components are Object oriented programming,
the GC mechanism, and dynamic code downloading. These are
very much enabling technologies. If you don't recognize
how to exploit these to make your software development
easier, I am not sure how to help you see the picture
that I am trying to paint.
> > The whole attitude of if it ain't done for me I need a
> new
> > language is costing the software industry way too
> much...
>
> Costing way too much what exactly?
Well, what happens is that we have a whole set of things
happening that I think matters.
1. Users have to learn the new language. Thus, if it
doesn't provide a measureable change in productivity or
stability of applications, there is little benefit.
2. Users have to find bugs in reimplementations of facilities
that already exist in other languages. Memory allocation
bugs in C implemented languages are the predominant issue
for me. People keep picking the C toolset and keep creating
language implementations with bugs. Even Java has this
problem in the native code such as the GC implementation,
native graphics interfaces etc.
3. A whole collection of new media is published and we have
to spend money and time (which is money of sorts) on consuming
and finding the relevent media to understand the core of
the new language and relevent changes as it is upgraded.
4. There is no interworking interface for all languages except
for I/O techniques such as sockets or pipes. Thus, as soon
as a new language appears, the first gripe and related set
of changes will probably be related to making the language
interwork with some environment that a large number of
users already use. The JNI changes for the JDK are a
great example of this. The core details of the JVM
implementation are quite visible in the JNI api's. Any
such language would have similar issues with making its
integration mechanism as painless as possible.
> > Software will never make any revolutionary steps if we
> all
> > change languages everytime we are challenged by a
> > language's features. What is happening is that the
> most
> > productive software developers are running around
> > recreating things that we already have in new languages
> > instead of solving problems that haven't be solved yet.
> > Thus, we're just all playing "keep up with the
> Joneses"
>
> I'm assuming you don't consider Java a revolutionary step
> then, even if it is most obviously your language of
> choice. There was nothing revolutionary in it. You mention
> memory management, but the algorithms it uses for that
> have been around for decades. I think Java made it popular
> because it was in the right place at the right time.
For many procedural thinkers, one of the revolutionary things
was that it wasn't LISP. It was just C expressions with an
Object implementation that removed all the pitfalls of C++.
Everyone that wants to program is not a software engineer.
C++ makes it trivally possible for really bad programming
practices to prevail. James Gosling and company saw this
in software they'd encountered in various contexts. It was
important to change something to get passed those issues.
The other very important concept in Java is downloaded code.
Mobile code enables all kinds of interesting possibilities.
That is the type of canvas that I have the most interest in.
I want to see software environments that can be easily fixed
and modified throughout their life. We do all kind of
scripting and all kinds of text processing because we don't
have real objects and real mobile code. We have to deal
with the text and create tools that deal with the text.
Languages that are text centric, and software development
using these languages and which continues to promote text
centric programming perpetuates the need for the languages.
I saw this happening in a prior job and I have blogged
about that. Things we just continuing to get uglier and
uglier in the software, its performance of duties. So, I
did define a completely new language, using lex and yacc
that created a 'api language' that embodied all the
concepts that were trying to be done with scripting and
I/O based interworking. We had no other languages on
the platform, we needed something different. It wasn't
Java. It was before Java and I encorporated the C
expression syntax, and GC in it. I did some other things
like make lists and hashmaps be a native part of the
language because collections of things and lists were
part of what the target class of programs needed.
The GC issue though was the primary problem to solve...
People were just fighting and fighting with managing
memory allocation.
> And who are these most productive software developers
> running around recreating things? I haven't met them. Or I
> just work with a lot of unproductive software developers
> who are busy creating new stuff but are quite happy
> leveraging the best tool they have at hand for the job
> they need to get done.
Most programming languages that make significant headway
are useable by those that choose to use them. People who
thrive on being the one to implement something, or thrive
on being able to contribute, get involved. These people
are the ones that are the 'most productive'. Given a
carrot or other enticement these people get involved.
> And the point I really don't get is how you think software
> can make revolutionary steps if everybody does the same
> thing all the time using the same tools.
...
> You think in a language which has structure and context.
> Thoughts are not these amorphous blobs running around in
> your head. Thus, what you think and how you think is
> influenced in no small part by the language you use.
You are still thinking in terms of the language that the
compiler parses as being the only solution space then.
I am trying to get you to think way beyond that. The
syntax of the C language does not provide FFTs,
Networking, I/O.
> This
> is as true for solving problems on a computer as it is for
> trying to figure out what to eat for dinner tonight. Some
> languages are just not good for solving some problems. Why
> ever go beyond assembler, or better yet microcode, then?
> So what if writing secure mobile code in x86 or m68k
> assembler is hard? It's obviously possible. Stop wasting
> your time with Java and get out your 'How to Program Web
> Services in Assember in 21 days' book. WOOHOO!
What you are failing to recognize is what solution spaces
programming languages enable. For me, this is the critical
issue. Assembler creates a solution space for easy hardware
access. That is important for some types of applications,
but not many as a general purpose solution provision. There
are certainly asm libraries and drivers that are generally useful
by a wide range of applications. But, we've learned that we
can write a library to provide such things, and stop doing it over
and over.
Each time a new language is created, we either recreate
many such things (look how many different GUI toolkits
there are for Linux as an example of repetitive development),
or we try and device an integration mechanism (using I/O
mechanisms for example) to make it possible for this new
language to use thing in other languages.
> > Java doesn't have a class that does MODBUS in the J2SE
> or
> > J2EE or J2ME. Does that mean I should switch languages
> > because I'd have to find or write such a thing before I
> > could use Java to communicate with a MODBUS speaking
> > device? I don't think so...
>
> That depends on whether you are writing a brand new app or
> if you have a need for a current Java app to do MODBUS. If
> it's a brand new app and there is a language already out
> there that does this, why would you bother "running
> around recreating things that we already have"?
Humm, application stability, application security and the
ability to integrate it with network based management
technologies.
> Or are you one
> e of the most productive software developers so you can
> afford to waste time rewriting something in a new
> language? If you need the capability in a Java app and
> there is no good way to hook it in from another
> language/toolkit, then you write the Java version. If you
> it's not specifically a Java app, or there is a way to
> very easily hook in the work somebody else has done, then
> you are simply wasting time reinventing the wheel if you
> roll your own, which I think is more blind than looking
> for the best tool for the job.
What I am suggesting is that we have to, at some point come
to a realization that it is possible to make any programing
language to anything. Classes of solutions are the problem
spaces. If we all are picking different languages that
don't have integration capabilities then we are spending
time doing things that are not where the value is added.
Look at XML based solutions. XML wraps data using an
an extensible structure that can be mutated easily by
adding more structure. Removing parts of the DTD requires
everyone to agree that that part can be removed. Everywhere
the document goes, there has to be code that extracts
the meaning of the text in the document and converts it
to something that the local software can utilize.
Mobile code in Java has the ability to be extended in
ways that are compatible with earlier versions. If you
want to remove functionality from the code, everyone has
to agree. However, noone has to implement code to extract
the data and turn it into program useable elements. It
already is! So, while XML lets everyone exchange
information freely, it requires that everyone know how
to do that. Thus we have replicated development.
> Unfortunately, some of us don't have the luxury of picking
> our canvases all the time. If you are automating a
> Microsoft Office application for a client, how exactly do
> you propose to use Java to do that in an efficient manner?
> I would say you would be better off learning VB and VBA,
> but that's just me.
That is a canvas that I stay away from. What I've learned
about that whole environment is that it is a trap. It provides
functionality that is enticing, but in the end, you have
to spend so much effort to do the automation that it's
probably best to just avoid it. In many cases, it might
be cheaper and more affective to write a completely new
application that did what you needed.
If the application itself is the minority of the automation
then do you need the automation or do you need a new application
that does what you need, can be extended to do more of what
you need and keeps you from being dependent on another
vendors whims about user interface, pricing and compatibility.
> If you need a fast performing 3D
> graphics library are you going to try and tell me that you
> can implement that in Java?
Java has a 3D API that is useable. There are bugs and
limitations that make it not excellent. But, if people don't
help with the resolution of the bugs then we get the issue
that I am talking about.
Everyone is going out an writing 3D libraries for Gaming,
Geospacial etc. apps. They think that it would be much
better to burden yourself with the memory management,
OS dependent graphics I/O etc., than to help Java become
what is needed so that there is no longer a reason to not
use Java.
Java has native interface capabilities. In can provide
the same speed as a native application! Really! What is
needed is a programming API that satisfies the solution
space of the application at hand. If everyone goes off
and writes application specific 3D libraries, we'll never
have what we need to take a step forward. We'll all
just be dancing around the fire showing off our fancy,
very focused and highly expensive (in terms of code
reuse) development projects.
> Most people use a combination
> of C/C++ and assembler because you need to be close to the
> hardware.
You think this because you are not focusing on the language
of the solution space. If you are doing geospacial
applications, you need to draw textures in polygons for
topographic rendering. You need to draw vectors for
roads and county, state etc borders. You need to be able
to do some icon drawing etc. These are the verbage
of the programming language you need. All the other stuff
that is under the covers is immaterial. Being able to
write it, having knowledge of how the intefaces for textures
work with the hardware are not valuable to solving the
problem of a mapping application. Why would you care to
be meddling with them?
> If you need a quick and dirty administrative
> utility to back up some directories, are you going to
> write a shell/perl/python script, or are going to fire up
> your Java Development Environment of choice and write a
> full blown java program to do it? I would go the scripting
> route, but this blind programmer would rather get the job
> done and move on than waste time on a version of the same
> thing that will take at least 3 times as long to write, is
> more prone to bugs and hey, you can copy and reuse your
> scripts just like you would a java class. Nobody died and
> made java the king of code reuse.
As James Gosling said in one of his Blogs... I use java not
because I can create throwaway application fast. I use
java because I can create dependable, extensible applications
faster here than in those other applications. One of
the dependability facilities of Java that I count on is
checked exceptions.
> I don't see how artificially restricting your toolkit
> makes you a better engineer. I'm of the mind that
> constantly expanding your knowledge base and thereby
> increasing the methods at your disposal for solving
> problems will get you a lot further than restricting your
> toolset and becoming an expert in one small corner of the
> known computing univers.
I don't artificially restrict myself. I purposefully chose
to use Java because I recognize all the fundamentally
sound programming advances that it provides. I don't
care about all the details under the covers. I don't
want to have to deal with those day in and out. Someone
is already doing that for me by implementing the JVM.
Now I (and others) can move on to the solutions that I
need to create.
I am programming applications that utilize the network
and mobile code to provide distributed applications. These
applications allow me to work from anywhere in the world
to solve problems anywhere that the network goes. I don't
think this is a small, restricted universe. It is a
profound notion.
"The network is the computer"!
> If you can afford to become
> proficient in one language and only one language, be my
> guest. I prefer to keep learning and keep my options over.
> When Java goes the way of Algol, ADA, Simula, COBOL and
> Fortran, what are you going to do then? You'll be master
> of the buggywhip in a world where few people ride in
> horsedrawn carraiges and most everybody is driving
> vehicles powered by internal combustion engines.
If you think Java is on its way out, then you've missed
the train you should have got on. It's alive and well.
The promises of Java woke up microsoft. They took it
and renamed it and then attached it firmly to their
platform in ways that would make sure that there was
platform lockin.
Microsoft completely changed the fundamentals of their
whole business. The 'safe code' notion in the Common
Language Runtime seem to have made them excited enough
to bet the whole boat.
The power and ideals of the Java platform provide a
very exciting new opportunity for many different
application solution spaces to pivot off of a common
platform.
Which is more popular?
o J2ME phones or Windows CE phones?
o Java Smart Cards or magnetic stripe cards?
o J2EE or .NET?
o Java as a general programming language or
C?
o Java based administration or C?
I guess that I see more publicly visible discussion
of Java based applications and solutions than other
languages.
Certainly .NET is getting more and more press. But,
it's also under the same level of critism that Java
was under when it first came out.
There are a large number of projects visible on the
internet that are based on extending Java to do
something more. People were entrigued with the base
of Java, but thought that they needed it to do more.
Many of these projects tried to add some feature of
C++, or C such as operating overloading,
preprocessing etc. The creators of Java have talked
about why these things were not included.
The people trying to add these things are focused on
solving problems in a particular way. They are not
able to reshape their thought processes to solve
problems using different tools and paradigms.
Many of these projects took the simple 1.0 JVM and
extended it to do things that they wanted to
experiment with. I have no issues with this. There
are later investigations that happened with the 1.1,
1.2 and later JVMs. There are some projects
attempting to create a JVM and an implementation
of the Java clases. What's going on in some of
these groups is a competative spirit. Which,
is interesting and beneficial in many cases.
But, I also see a lot of people that have not spent
any significant time working with Java so that they
actually know the values that the platform provides.
It seems that many people tried JDK1.0 or the really
buggy JDK1.2 and just gave up because it did not meet
their needs. While I can understand the frustration
that comes when you spend time working on something
and then hit a brick wall.
Ignoring capable technologies is what has kept us from
moving on to dealing with software development at a
new level where we can just implement the solutions
we need and take advantage of previously created
solutions for underlying infrastructure that enable
application oriented APIs that greatly simplify
particular classes of programming.
Assembly did this to get us past machine code.
C did this to get us past assembly. Java provide
a further simplification of long running applications
needing advanced memory management as well as many
other capabilities that are prevalent in the world
of network and distributed computing, as well as
many other domains that are from smart cards to
embedded systems (look at J2ME in depth, including
things such as the embedlets project on sourceforge)
to desktop apps to high availability servers.
Heck, Nasa developers saw the benefits of Java in
create more robust and highly portable system management
applications and thus are managing many aspects of
the Mars rover using Java technologies. This lets
them share the management around the world and provide
the public with applets to experience parts of the
mission operation details to see what they are
doing.
If developers pick 'canvases' that perpetuate old,
outdated arts, then we will always have to see
that art and live with it.
If developers pick 'canvases' that allow new arts
to be developed, then we'll get to try something
new and diffent and change the way we work.
But, in the end, we all of free choice...
|
|
Previous Topic
