|
|
Re: What's in a Programming Language
|
Posted: Feb 6, 2004 4:19 PM
|
|
> 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.
What I see happening is that people who first adopt a particular language tend to build libraries and request new features that make that language appear stronger in a particular domain of solutions. I don't think there is any existing proof that assembler couldn't do everything, computationally, that you'd need to solve a problem. The initial problems of computers were strictly numeric, doing things like calculations for projectile trajectories. Calculations involving sin and cos are helpful for doing long range calculations (missle distances), so those kind of things appeared very early in mathematical libraries, and persist today. But most wide spread languages do not have a direct API to doing great circle calculations. But, you can find libraries for such.
> I think whether the effort to create the tool depends on
> the size and scope of the problem. It's a tradeoff.
But, the more times we choose not to, the more time we have chosen to let others recreate and repeat all the same mistakes. A reality that is everywhere, no doubt...
> 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.
But, what happens is that that application will likely stay running and not stop abrubtly because of the programming error. We are humans, imperfect and very capable of creating bugs. A language that helps keep others from being impacted by a programmers bugs is a benefit to all of us.
> 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.
The point is that any language that can perform numeric calculations can do an FFT. Any language with networking support can be used for network applications. Any language with I/O to files can be used for database applications. So, we can all go around writing anything anywhere because most modern languages have all three of these. My argument is that we should confine which languages we choose more than we have in the past because all we are doing is reducing the possibility of people using our software for something that we hadn't initially target it to do.
Java has made me write more thing that I'd probably written as programs, as Jini services which provide the infinite reuse capabilities. From my perspective, Jini provides the next generation UNIX pipe. We use pipes everywhere in UNIX to tie things together. You can write simple applications that do something really well with stdin and stdout. Then we can tie them together with pipes to build a much different application than perhaps the original tool had been designed for.
e.g. I use grep -n "" <infile> to number lines in a file. This is a useful thing, that makes it unnecessary to write a num or other application.
With Jini applications, we've switched from the inaccurate and problematic everything's a string model to the much more extensible and flexible everything's mobile code model. Now, we can actually send code to run inside of the VM where the user is. If I want an FFT service, I ask the lookup server for one, and I get an object back that provides that service. It might use RMI to talk to a super computer that can do my calculations quickly. It might also just be a serialized object that runs completely on my machine. But, I don't have to care or know to use it. Although, I might be intersted in a particular class of FFT solver, I don't have to be concerned up front, and can classify them later.
> 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.
Communicating with the typed word and without immediate reaction to misconceptions make it harder.
> 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.
I guess a more accurate statement of my perspective is that I do in fact uses other languages for throwaway or one off applications. But, if I think that I will ever need to take some software somewhere else, or that it might be generally useful, then I'll choose Java. Sometimes that means that I write a lot of code in Java that is throwaway just so that I can use a library that I wrote earlier.
> 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.
I think it is bad practice to continually recreate things. It will be necessary to recreate some things in Java that are already written in other languages that are distant from Java. Things written in C and C++ can often be stuck into Java with JNI. But the lack of a coherent threading model in these languages often makes such things non thread-safe in java and can thus be problematic to use.
> 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.
I think that the lack of integratability with Java speaks to the vastly different programming models. For me, Java makes it possible for me to just get the job done. I don't have to worry and muss with a lot of stuff that I used to in C and C++. The Java threading model and the JIT activities mean that you can't easily integrate C or C++ libraries, using JNI, that are not thread safe. The global variable name space in these languages make it possible to write truely attrocious code. Java's programming model makes it more likely that you'll scope your application data carefully to have the correct mix of parameters and inner classes/inner references.
> 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.
I guess the everything's an object mode is hard for you based on your repeated mention of this. Good OO programming practices allow you to use objects when you need objects and create functional code modules when you need them. The java.lang.Math class is an example of functional class. It doesn't hold any data for you to use. It just provides a namespace for related functional code. You can decided to do this with things that fit this kind of domain/class of problem.
> 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.
If, you have to get under the covers and create so much 'linkage' across modules in your software to make it work as needed, then you've probably picked a poor model for codifying your applications functionality. This is why I keep trying to push the design of the API as a language of the solution space. This is the vital issue. If we have the luxury of infinite time for perfect design, then we can do it 100% right. If we have limited time and budgets, then we have to make the best effort. For me, Java allows me to make the best effort in the least amount of time. It provides a foundation of APIs that remove all the bookkeeping chores from most modern programming activities so that all I need to do is write the code that codifies the solution language.
> There are many other spaces where performance matters
> enough that some pieces can't be written in an
> interpreted/byte code compiled language.
I think this is because we put the performance design too close the the application code. It needs to be far enough down that the API designed language feels more like scripting the solution then tickling the hardware.
> 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.
I'll throw out the standard argument about operator overloading. Overloaded method names provide the same confusion level. But, I don't think there is practically any performance difference in any language that has operator overloading, when one might code a function call instead of an operator based operation. What Java designers decided was that it was better to not have a feature that is so easily abused and can cause such large amount of confusion, even to the developer, who doesn't see a conversion that is implicitly happening to cause his operator overload to work. Numeric truncation and conversion are evil when they happen behind your back.
I've only seen highly mathematically intensive applications that could benefit from operators. Most of those need a more expressive system that would allow them to write math expressions similar to the TeX language or to see the results as TeX would render them.
|
|
Previous Topic
