The Artima Developer Community
Sponsored Link

Weblogs Forum
What's in a Programming Language

16 replies on 2 pages. Most recent reply: Feb 6, 2004 7:19 PM by Gregg Wonderly

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 16 replies on 2 pages [ 1 2 | » ]
Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

What's in a Programming Language (View in Weblogs)
Posted: Jan 12, 2004 4:41 PM
Reply to this message Reply
Summary
I've blogged here before about how I'm a Java convert, never going back. Some recent comments by Frank Sommer about developing idioms in prgramming solutions sparked some other thoughts that I've had about this whole "Let's write a new programming language" party scene.
Advertisement
Frank Sommers wrote:
> I agree with Ward that a lot of what we consider great
> design is often a product of evolution, rather than
> someone sitting down and figuring everything out up-front.
...
> In lieu of a grand design, what I often find useful,
> though, are idioms.

This is exactly what I use. I have particular patterns of overall system architecture that I utilize in particular situations.

I often cast these patterns into classes at some point and provide enough augmentation via abstract interfaces to make them a general solution to a particular class or problem.

I did this with JDBC access and AWT layout very early in my use of java. Now, I always use those two classes when I write programs using those parts of Java.

This type of programming creates an application oriented language for how I architect a solution in programming constructs. It is extremely powerful. Patterns have been pressed hard over the years. What makes them difficult in practice is that everyone gets to recreate them in different languages.

As I've stated before, I've stopped switching languages. I adopted the Application Oriented Language paradigm of programming because I tired of not having the same tools everywhere. If the Java language APIs don't work the way I need, I recast them into something that is more familiar. If I am used to using the bourne shell to script a particular class of problem, and I have to do it in Java, I'll create some programming API tools to do that project and then I have them in my tool kit.

I strongly believe that this kind of programming is what will allow us to move on to faster solutions to larger or at least really different programming problems. In the end, computers can calculate numbers. We've managed to make everything look like a number, and then wrap all of our language based programming proceses around processing these numbers (but calling them somthing else). When we have finally solved all problems that need to be solved with numbers, then it will be time to invent a new base programming language.

Think about it... Every new language that is written today is written in another programming language that came before it. So, we have only recast the programming model.

Java finally closed the gap on memory management in a way that is powerful and effective (but not completely efficient, it needs a counting collector). What is left?

Many people say that they need lots of different languages, because the features of one language make them more productive in a particular environment. What I am thinking about is the whole tool verses canvas issue. If you have a nail, and your canvas is paper, you can use the nail to do but a few things to the paper. If you have a piece of thread as your tool and your canvas is a fire, what can you do with that thread?

What I have been doing with Java over the years, is picking my canvases, instead of finding a canvas and then picking a tool. What I see happening is that more canvases that are JVMs are popping up in more places. I can now use java 'anywhere'. There are litterly millions of smart cards that use the smartcard jvm. There are small processors like the aJile AJ-100, the systronix.com use of that chip in 'stamp' like packages. There are JVMs for many PDAs. There are JVMs for desktop and server class computers.

So, I can be a Java software Artisan in just about any place I go for just about any type of application domain.

There are of course FPGAs, DSPs and other specialized processors that still have their own programming languages and platforms and tools. I suspect that they will linger for some time to come. But, I also know that we've learned a lot about many of these application domains, and there are many solutions that don't need programability anymore. The solution spaces are known, and are being recast into hardware or libraries.

This is how application software developers need to think. Using domain centric patterns and casting them to code once will greatly improve where software evolves to. What we have to get over is creating a new programming language that invalidates all the tools we've already built for so many domains.

I consider the move from C to Java to be a worthwhile move. In Java, we have an interface from Java back to C/C++ if we need to tie some old tools together. We can script with Python, TCL and who knows what else using libraries that people have built for Java.

If you find that Java feels like Marble, then perhaps you are using the wrong canvas! Use a programming environment that allows you to mold your Java software more readily. I try my hardest to include delayed/late/runtime binding into software whereever that doesn't impact the application. This allows the software to be molded more readily and allows me to change how interfaces work. I can get the benefits of more dynamic programming languages just by changing how I architect my software.

When you write software, write it using an Application Oriented Language API that lets you say what you want done, not how to do it. Then, implement the how to do it part for your specific application. Later, you can change the how to part if you need to, and you'll feel a lot more like you are working with clay rather than Marble.


Peter Hickman

Posts: 41
Nickname: peterhi
Registered: Mar, 2003

Re: What's in a Programming Language Posted: Jan 12, 2004 6:34 PM
Reply to this message Reply
Think about it... Every new language that is written today is written in another programming language that came before it. So, we have only recast the programming model.

It's alot less evolutionary than you think. Almost every new language since the introduction of C has been written in C! Sure they have incorporated features from other languages, but they have all been implemented in C.

Or if they get really modern, they write it in C++.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: What's in a Programming Language Posted: Jan 12, 2004 6:48 PM
Reply to this message Reply
> Think about it... Every new language that is written
> today is written in another programming language that came
> before it. So, we have only recast the programming
> model.

>
> It's alot less evolutionary than you think. Almost every
> new language since the introduction of C has been written
> in C! Sure they have incorporated features from other
> languages, but they have all been implemented in C.
>
> Or if they get really modern, they write it in C++.

I didn't mean to suggest that there were lots of levels of evolution. I studied compiler design in college, and have writen many a tokenizer and/or parser using the lex and yacc tools, as well as written simple recursive descent parsers and FSM based tokenizers. This is all well known and well developed science. These powerful tools often are the lure to use C to create a new programming language.

Programming language design is such a seldomly visible part of COMSC that I fear people continue to use it for all the wrong reasons. We don't have examples visible in the form of useful APIs or in the practice of software development.

Libraries are thrown around as 'tools'. Library API design is really about language design. An API works in a particular domain when the 'language of use' that it presents as the API is similar to the language of the problem domain's common solution steps.

I don't want to have to create more lines of code than necessary. Reduction of programming hassel is what makes people more productive.

Keith Ray

Posts: 658
Nickname: keithray
Registered: May, 2003

Re: What's in a Programming Language Posted: Jan 12, 2004 9:25 PM
Reply to this message Reply
I think the language "Dylan" was written in Lisp...

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: What's in a Programming Language Posted: Jan 13, 2004 8:07 PM
Reply to this message Reply
> I don't want to have to create more lines of code than necessary.

Then Java certainly shouldn't be your language of choice!

Frank Wilhoit

Posts: 21
Nickname: wilhoit
Registered: Oct, 2003

Re: What's in a Programming Language Posted: Jan 15, 2004 9:59 AM
Reply to this message Reply
I cannot forgive Java--or its forebears, or its progeny--the notion of garbage collection, which in turn compels refcounts and the hierarchy rooted at Object.

How can anyone fail to see that the end of an object's lifespan requires exactly the same degree of control as the beginning? Safe programming in C/C++ depends upon this. A lot of C/C++ was [allowed to be] written and released by people who only half knew the language, but that doesn't mean that the remedy is to try to make the world safe for programmers who only half know their languages. Memo to management: it can't be done.

Joe Cheng

Posts: 65
Nickname: jcheng
Registered: Oct, 2002

Re: What's in a Programming Language Posted: Jan 16, 2004 7:21 PM
Reply to this message Reply
How can anyone fail to see that the end of an object's lifespan requires exactly the same degree of control as the beginning? Safe programming in C/C++ depends upon this.

Correct me if I'm wrong, Frank, but the only reason this is true is because the RAII idiom is so pervasive in C/C++. Java libraries are simply not written this way; unmanaged resources always need to be explicitly released (usually in finally blocks, or "using" in C#).

Also, garbage collection in no way compels refcounts or the hierarchy rooted at Object. Most modern collection algorithms do not use refcounts (AFAIK) and many scripting and functional languages do not have hierarchies rooted at Object.

I also object to your implication that Java is designed for people who aren't smart enough to grok C/C++. Java is designed for people who want to write safe, portable, object-oriented code--without constantly worrying about memory leaks or buffer overflow attacks.

Or if your assertion is that only dumb or inexperienced programmers use GC languages in general, well, that is just nonsense. Some of the smartest people in the world code in Lisp.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: What's in a Programming Language Posted: Jan 16, 2004 10:07 PM
Reply to this message Reply
> > 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.

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 more languages, making use of the 'methods' or 'operators' directly for the problem at hand.

The whole attitude of if it ain't done for me I need a new language is costing the software industry way too much...

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"

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...

There are countless things that Java doesn't do yet... But that list is getting shorter each day. And the things that Java doesn't do are more and more specific to very vertical markets. Thus, there are plenty of opportunities for small software companies and individuals to jump into profitable markets and have at it.

What's the mobile code security model in Ruby, Perl, Python or whatever your favorite language is. Does that model include Authentication, Authorization and Integrity for the mobile code? Does it provide method level access control?

Jini does! If your language doesn't then maybe you should switch to Java so you can use Jini :-)

Jim Burnes

Posts: 1
Nickname: blankreg
Registered: Jan, 2004

Re: What's in a Programming Language Posted: Jan 22, 2004 12:28 AM
Reply to this message Reply
Greg,

Interesting post. I wish I had the time to comment on the whole post, but I would like to comment on part of it. Your mention of Application Specific APIs and sculpting your tools to fit the application rang some bells in my brain.

Specifically AS APIs are nearly the same thing as an application specific vocabulary. I first encounterd that concept back when I learned FORTH in the late seventies. I've always had a love/hate relationship with FORTH -- a language that is spectacular at some tasks and then nearly falls apart in others.

In FORTH you develop your vocabulary word-by-word; bottom-up, top-down, fun-first or whatever strikes your development fancy. Whatever gets things done first. Whatever sheds light on the undiscovered country of your application space -- the limited noosphere of the project before you. Eventually your vocabulary is complex enough to elegantly express your problem solution. A short and perhaps too canonical example....

(programmer monkeying around on terminal)
42 emit <CR> * OK

(hmmm -- thats interesting)
: star 42 emit ; <CR> OK
star <CR> * OK
star star star <CR> *** OK

(hmmm - thats kind of fun)
: stars 0 do star loop ; <CR> OK
10 stars <CR> ********** OK

(okay, that gives me an idea)
: arch <CR> 
>> cr <CR>
>> -7 7 do <CR>
>>>> i dup * stars <CR>
>>>> cr <CR>
>>>> loop <CR>
>>; <CR> OK
OK
arch <CR>
*************************************************
****************** ******************
*************************
****************
*********
****
*

*
****
*********
****************
*************************
******************** ****************
*************************************************
OK

( ok -- that was pretty cool )

That's the great thing about FORTH. It's more like playing a piano than working hard. Of course some people might say that playing a piano is hard work, but that's a different story.

If you really concentrated on good FORTH expressions, building applications specific APIs became something of a Zen practice. Sometimes it also took about the same amount of time to become a Zen monk.

I really miss FORTH, but I don't miss having to worry about whether that last swap I did in the calling routine was a 2swap or dup and, well, you get the picture. The other thing is that a properly constructed vocabulary made the application a joy to read -- assuming you read from the definitions outward. The other edge to that sword was that a bad programmer could write code that neither they nor anyone else could maintain. Code that looked like an explosion in an HP calculator factory.

If some language could recreate the elegance of the FORTH vocabulary with the power of Python, well I just might be tempted.

POST ARTIMA SAVE <CR> msg.id:48545, 5k OK
TIME CHECK <CR>
The time is 10:43pm CST OK
MELATONIN H20 MIX INJEST <CR> 750ug, buffered OK
'6:45am '99.7FM SET-ALARM <CR> Radio enabled at 6:45am OK
NOW "Dune" READ <CR> Proceeding, using speex codec, 15 min. OK
SLEEP <CR> Sorry, resource busy. OK
"Bombay" GIN LOAD <CR> . .. . .. . .. Loaded OK
SLEEP <CR> zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

|-)
OK

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: What's in a Programming Language Posted: Jan 22, 2004 3:11 PM
Reply to this message Reply
> > > 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. 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.

> 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 know and regularly use many different languages and very proud of the fact that I can do that. I wouldn't ever think of writing a C++ program to generate useable C++ header files for me when I can do the same thing with a 15 line python script. I guess I could go out and buy or download a code generator for this sort of thing, but why? I get what I want and a whole lot more control over being able to script the thing myself. Heck, we had to put together a word count for all of our language resource files to see what it would cost to outsource translation a while ago. 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? I figured it just would show I had too much free time. 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.

> 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? And who approaches any problem like that? If you know of a better way to do it, how is using a more archaic, harder to manage, harder to build and harder to maintain method cheaper? And that attitude of it ain't done for me I need a new language is exactly what pushes progress. The quest for a better solution is rarely a bad thing. I'm not sure what the cost of finding a better solution is. Perhaps you could spell that one out for us. I've observed a lot of attitudes that cost the software industry a lot. The quest for a better way hasn't been one of them in my experience.

> 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.

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.

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. That line of thought doesn't make any sense to me. Progress is usually brought about by change, especially by change in thinking and the use of certain languages makes certain thought processes more likely, as any linguist will tell you. 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. 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!

> 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"? Or are you one 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.

> There are countless things that Java doesn't do yet...
> But that list is getting shorter each day. And the
> e things that Java doesn't do are more and more specific
> to very vertical markets. Thus, there are plenty of
> opportunities for small software companies and individuals
> to jump into profitable markets and have at it.

Yes. But I'm not sure what this has to do with the other points you are making.

> What's the mobile code security model in Ruby, Perl,
> Python or whatever your favorite language is. Does that
> model include Authentication, Authorization and Integrity
> for the mobile code? Does it provide method level access
> control?
>
> Jini does! If your language doesn't then maybe you should
> switch to Java so you can use Jini :-)

As I said above, this would make perfect sense to do. Two of the points I got out of the original post in this thread, which I try to do myself, are 1) is to create your own toolkit that will make you more productive in your language of choice. I got that from

"As I've stated before, I've stopped switching languages. I adopted the Application Oriented Language paradigm of programming because I tired of not having the same tools everywhere. If the Java language APIs don't work the way I need, I recast them into something that is more familiar. If I am used to using the bourne shell to script a particular class of problem, and I have to do it in Java, I'll create some programming API tools to do that project and then I have them in my tool kit.

"

2) Pick your 'canvas' so as to leverage the strength of your toolkit, which I got from

"What I have been doing with Java over the years, is picking my canvases, instead of finding a canvas and then picking a tool."

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. If you need a fast performing 3D graphics library are you going to try and tell me that you can implement that in Java? Most people use a combination of C/C++ and assembler because you need to be close to the hardware. 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.

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. 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.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: What's in a Programming Language Posted: Jan 25, 2004 8:02 PM
Reply to this message Reply
>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.

keep my options open. Boy is that a bad typo!

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: What's in a Programming Language Posted: Jan 25, 2004 11:08 PM
Reply to this message Reply
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...

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: What's in a Programming Language Posted: Jan 25, 2004 11:43 PM
Reply to this message Reply
http://java.sun.com/features/2003/05/steele_qa.html is another place that I just wondered across where the issue of making a language have more verses do more is discussed.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: What's in a Programming Language Posted: Jan 27, 2004 11:57 AM
Reply to this message Reply
I won't bother quoting the original because, well, between your post and my post it would be horribly long. So I'll pick the couple of points that either were missing from the original post that I was talking about that cast in a different light or, where, I guess we'll politely have to agree to disagree :-)

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.


This radically narrows the blanket assertion you yourself made. I wholeheartedly agree with this and try to do so in the languages I use regularly (C/C++, VB, Python). I think in general languages become targeted for certain problems, I don't think in general they are born that way. Or at least the good ones may initially be targetted toward certain problems but are designed well enough that they are used in ways the authors didn't intend to solve different problems. I think Java is a great example of that.

I use 'wc -w' to count words in documents

Not to pick nits, but the problem was slightly more complex than just counting words. We had to find the translatable part in files of various formats. There are a bunch of ways I could have just blindly counted words, as you point out, without doing extra work :-)

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.


I think whether the effort to create the tool depends on the size and scope of the problem. It's a tradeoff.

...The GC issue though was the primary problem to solve...
People were just fighting and fighting with managing
memory allocation.


They still are, even in Java, Python, etc. Bad use of objects such as string, while likely not leaking memory all over the place, is a terrible performance drag. It's another memory allocation problem and, depending on your application space/canvas, performance may be a more critical factor than the occasional leak, so you need a language that will perform better and you need to actually do some work and figure out how to manage your memory. Until machines are fast enough and have enough memory to make is almost a non-issue, people will be fighting with it one way or another. You've just moved the location of the fight.

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.


That's not true. The libraries available and the facilities available in a language have little to do with the language the compiler parses. This is why I like working with Python when I can.

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.

I couldn't agree with this more and this paragraph casts your other posts in a whole new light. Like I said, a lot of your original post rang true with me. In the follow-up, it seemed that in places you were either contradicting yourself or saying that Java was the be all and end all of programming. I believe that what you say about what solution spaces programming languages enable is critically important and it is exactly the reason why I like more than on tool in my toolkit. Add all the attachments you want to a hammer, but it'll never make a very good drill.

Humm, application stability, application security and the
ability to integrate it with network based management
technologies.


So now you've provided a reason for running around recreating things whereas before you were saying that this is bad practice. I'm not saying these are bad reasons to do anything. It's just that, sometimes, you have to recreate things. I think you've as much as acknowledged this.

That is a canvas that I stay away from. (referring to Office)

I envy you. :-) Alas, it's part of our companies product suite and for good or ill, I have a lot of experience with it. Pity me, but please don't think less of me. My wife likes our house and I would like to continue to make the mortgage payments on it.

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.


And here we are back to "reinventing the wheel" There are several very good libraries out there that would need to be rewritten for Java. The tradoff for these developers is that they would have (at least, in their opinion) a better time managing the memory the existing libraries use than to rearchitect the library to run in the JVM. I don't know if this is true or not. I would guess not since many people are gravitating toward Python for at least parts of game development. Java has many of the same perfomance issues as Java, only more so. I'm sure if somebody was motivated to take the time, a very useable Java 3d api that could be used for the apps you mention is workable.

Whether some of these things could be realistically tied to a language where everything has to be an object I don't know, as I'm no game developer. Some idioms allowed in procedural code might preclude Java from some applications. Or at least make the object overhead more trouble than it is worth if there is a viable alternative. Not being a game developer, I can only guess at these sorts of things.

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?


I disagree to some extent. I understand what you are saying. The stuff under the covers is still material, although less so, as shown by the port of Quake II to .NET http://www.vertigosoftware.com/Quake2.htm. For games this may no longer be an issue. For complex CAD tools, simulations, Movie animation, etc. I believe it is still very much an issue. Sometimes, performance matters.

There are many other spaces where performance matters enough that some pieces can't be written in an interpreted/byte code compiled language.

One of the dependability facilities of Java that I count on is checked exceptions.

I would depend on checked exceptions as much as I count on a language initializing variables for me. That is, not at all. You sound like you actually know what you are doing with them, which is more than I can say for some of the terrible examples of them I've read about and seen. I see them as an unnecessary constraint. Exceptions are nice where they are nice. To foist them on one unnecessarily, which isn't hard to do with a poor language design, causes more problems than it solves.

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 see the difference between 'artificially restrict' and 'purposefully choose'. For the sound programming advances that Java provides, the necessity of everything to be in a class and no operator overloading to name two, there are some places where Java either took a step back or boxes you into certain corners that make certain problems harder to solve than they need to be.

If you think Java is on its way out, then you've missed
the train you should have got on.


I don't have the foresight to see which languages will be in or out in X years. I'm sure similar things could have been said about many different languages over the years. COBOL is the one that comes to mind immediately because of the vast number of systems that were written in it.

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.


Popularity changes over time. It wasn't that long ago that you would be talking about some C/C++ library instead of Java. In several years there will likely be some other flavor of the month. Popularity and Cocktail party conversation topics is a poor indicator of the worth of a language or its level of use. It also depends where you spend most of your time.

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.


Alas, I have to admit that I'm in this group. And I've not had the time to take another look, as my career and my interests have taken me in another direction. Don't get me wrong, I do believe that Java has a lot to offer as you plainly point out and there are plenty of reasons to use it, I don't think it, or any language, is a holy grail of software design. Until they come up with the computer I can plug into my brain that will just output what I want done in a reproduceable, error free manor, I'll be more than happy to continue looking at other languages and other paradigms.

Heck, if I keep hammering away on my Linux box at home long enough, I may decide I want to look at using Apache and something like Tomcat and then, if I'm not mistaken, I won't be able to help but be exposed to the nirvana that is Java, right?

The hairs on my neck reflexively stand on end when anybody touts Language X as the be all and end all in programming. It's not much different than Bruce Eckel claiming he gained a 10x boost in performance when he started using Python and now he is practically a Python salesman. Maybe he did. I didn't. Certain problems and applications for me, maybe, but not in general. I respect the man and always listen to what he has to say, I just have to tune out the overly Pythonic parts and dig for the deeper meaning. I guess, worst case, you'll have to go into the same boat. Which, at least according to the way I view the world, isn't a bad boat to be in.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: What's in a Programming Language Posted: Jan 27, 2004 12:01 PM
Reply to this message Reply
> http://java.sun.com/features/2003/05/steele_qa.html is
> another place that I just wondered across where the issue
> of making a language have more verses do more is discussed.

Overloaded operators are still a subject of controversy. They are almost indispensable for certain kinds of mathematical work, but people who oppose adding them to the Java language point out, quite rightly, that the feature was badly abused in C++ for nonmathematical purposes, making code much harder to read than necessary.

The same thing about people badly abusing overloaded operators in C++ can be said about checked exceptions in Java.

Flat View: This topic has 16 replies on 2 pages [ 1  2 | » ]
Topic: Sun, bullets, and feet Previous Topic   Next Topic Topic: Introducing Artima Weblogs


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us