Weblogs Forum - What Are Your Java Pain Points, Really?

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
What Are Your Java Pain Points, Really?

264 replies on 18 pages. Most recent reply: Jan 17, 2008 7:07 AM by GJ sonke

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 264 replies on 18 pages [ « | 1 ... 14 15 16 17 18 | » ]

Jonathan Lehr

Posts: 18
Nickname: jlehr
Registered: Jan, 2004

Re: Lack of extension

Posted: Mar 1, 2007 4:36 PM

> I'm not suggesting that we all program in Lisp, but the
> Lisp inspired languages like Smalltalk, Ruby etc do seem
> to point the way forward. Static typing is the last
> argument for languages like Java and C#. But this can be
> added to Smalltalk/Ruby/Python etc without affecting their
> dynamic runtime nature.

Actually, I think Objective C offers a better solution -- static typing with dynamic binding. Essentially Obj C allows you to type an object reference as (void *), in which case the compiler doesn't attempt to resolve any method references for that object. All method invocations are resolved dynamically, even for statically typed object references. That opens the door to additional flexibility, such as adding methods to an existing class at compile time, as discussed earlier in this thread.

Various optimizations (such as caching method selectors) can be done to reduce a lot of the overhead of dynamic lookups. NeXT claimed to have reduced it below 15%, which seems a reasonable price to pay for the added flexibility. (Plus, in performance critical sections of code, you could always get a pointer to the actual method implementation and invoke it directly.)

Paul Beckford

Posts: 51
Nickname: phaedrus
Registered: Feb, 2007

Re: Lack of extension

Posted: Mar 1, 2007 6:09 PM

> > For desktop personal computers which is what Alan Kay
> is
> > refering to, the processing power available today is
> > ample. The comparison with software has to do with how
> > well that hardware is being exploited. The hardware
> guys
> > have exploited semi-conductors to a massive degree and
> > have exceeded moores law - yet we are still building
> > Software the same way we always have. In fact if you
> > compare Java to Lisp, we have in effect gone backwards.
>
> I've actually decided to teach myself Lisp as a result of
> reading these comments. I once decided to learn a
> dynamically typed language for the same reason and it
> opened my eyes a great deal so I hope to have the same
> thing happen with Lisp. I also have a sneaking suspicion
> that Scala would make more sense to me if I knew Lisp but
> I could be wrong.
>
> To whet my appetite could one of you try to explain what
> makes Lisp so much better in your opinion. If you can
> prove it, that's great, but I don't request any proof.
>
> If it's just too much to explain here, that's fine.

http://www.gigamonkeys.com/book/

Enjoy!

P.

Paul Beckford

Posts: 51
Nickname: phaedrus
Registered: Feb, 2007

Re: Lack of extension

Posted: Mar 2, 2007 5:30 AM

> > I'm not suggesting that we all program in Lisp, but the
> > Lisp inspired languages like Smalltalk, Ruby etc do
> seem
> > to point the way forward. Static typing is the last
> > argument for languages like Java and C#. But this can
> be
> > added to Smalltalk/Ruby/Python etc without affecting
> their
> > dynamic runtime nature.
>
> Actually, I think Objective C offers a better solution --
> static typing with dynamic binding. Essentially Obj C
> allows you to type an object reference as (void *), in
> which case the compiler doesn't attempt to resolve any
> method references for that object. All method invocations
> are resolved dynamically, even for statically typed object
> references. That opens the door to additional flexibility,
> such as adding methods to an existing class at compile
> time, as discussed earlier in this thread.
>
> Various optimizations (such as caching method selectors)
> can be done to reduce a lot of the overhead of dynamic
> lookups. NeXT claimed to have reduced it below 15%, which
> seems a reasonable price to pay for the added flexibility.
> (Plus, in performance critical sections of code, you could
> always get a pointer to the actual method implementation
> and invoke it directly.)

Objective C is a move in the right direction. Mac OS X Cocoa GUI is built using it and the Mac GUI is definately sexy! The big vendors chose to back C++ instead of Objective C and the rest is history.

Personally, my take is that Objective C was a good compromise back in the day when 64M was a lot of memory on a PC. As I understand it, it is not VM based (so no mobile code) and it lacks Garbage collection.

With the machines of today why not go one better, like Smalltalk? :^)

Paul.

Chuck Simpson

Posts: 1
Nickname: chuckls
Registered: Mar, 2007

Re: What Are Your Java Pain Points, Really?

Posted: Mar 3, 2007 4:05 PM

My top pain point is that the JVM is a single fragile and monolithic process. This puts any Java programmer in the role of a systems programmer and causes more wasted time, effort and money from crashes, hangs and limited scalability than any other facet of Java.

Adding bi-level system and user heaps and giving objects within a java/javax/system package tree the ability to manage heaps for user threads (objects from other packages) would be a welcome addition. System objects would execute from the main heap and have no control over it and user objects would have no control over their heap but, system objects would have the ability to destroy a user heap with no consequence to the VM.

The coupling of the JVM and the java/javax package trees provide this kind of separation currently but no one but Sun can add to those packages. The proposed system package distinction extends that model providing Java programmers more capability for separating and managing risks.

Having a VM with a bi-level safety distinction would allow organizations to put potentially dangerous but recoverable processes in non-system package and monitor them from the system package. If problems are detected the manager objects in the system package could schedule a GC on or even destroy the offending user heap protecting the overall stability of the VM. At the same time objects in the system heap pose no greater threat to the VM than any object does in the current VM model.

Any reasonable multi-tasking OS provides this capability so it is a proven model. The VM would have to change but the changes could be made backward compatible. The VM would be a little more complex but, the system vs user process distinction has been in Unix for 30 years so it is not new and unknown.

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: Lack of extension

Posted: Mar 4, 2007 12:38 AM

> Type safety -really means program correctness.
That is not the main advantage for me.
The main advantage is readability. I want to click on a variable or method and see what interface/implementation it belongs to.

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: What Are Your Java Pain Points, Really?

Posted: Mar 4, 2007 12:59 AM

> Please forgive the curtness of my previous response. I
> should have just waited until today as I was ill this last
> weekend.
I wasn't offended :)

> I think you are not understanding. I am not talking about
> an abstraction layer over the database. I am talking
> about an abstract layer over the logic.
What is the difference? Can you give an example?

(I skipped the above comments, because this seems to be the part I'm not getting)

> The application
> should not retrieve the data. It should receive it or
> request it but avoid retrieving it explicitly. A lot of
> the usefulness of this approach necessitates a dynamic
> data approach.
What exactly is a "dynamic data" approach?

> I believe using fairly
> simple tools to create designs with an appropriate level
> of complexity rather than using complex tools to create
> simplistic designs.
Even better would be a complex tool that makes your problem really easy for most cases - such as a garbage collector.

> I just want to add that I don't want my statements to be
> interpreted as an attempt to state universal truths.
I hadn't thought that.

> I am
> only speaking from my own personal experience and the
> kinds of systems and projects I have worked with.
I probably wouldn't defend the approaches where you were having problems with - I'm just wondering if I would come to the same conclusions as you did.

> I'm pretty sure they go against much of
> the common-wisdom of developers and designers.
I actually thought that Linq goes against common wisdom :)

> Whether my concerns
> are warranted will not be known for a number of years.
Until we read the disaster stories of Linq ;-)
But then I could argue that it's not Linq's fault - it will just have been used in the wrong way... :)

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: What Are Your Java Pain Points, Really?

Posted: Mar 4, 2007 10:47 AM

> The coupling of the JVM and the java/javax package trees
> provide this kind of separation currently but no one but
> Sun can add to those packages. The proposed system package
> distinction extends that model providing Java programmers
> more capability for separating and managing risks.

Technically, this is what the Java Community Process covers. If you have an idea of something to do different, you should submit a JSR. Is that a painless process? I don't think so. It's what happens when people can "vote".

Also, now that Java is open sourced under GPL, I suspect that there will be many different forks of this technology into new languages that will try and address some of the personal complaints of those that have the most drive to do this kind of thing.

It's not possible to build what has been open sourced yet, but Sun is apparently trying to make that happen sooner rather than later so that people can make changes and do things that they want.

I'm really curious to see what happens on that front...

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: What Are Your Java Pain Points, Really?

Posted: Mar 4, 2007 2:05 PM

> Trivially; variables should use underscores, not
> StudlyCaps. It makes it easier for int'l developers.
>
Can you elaborate? How would underscores be easier for international developers?

Jonathan Lehr

Posts: 18
Nickname: jlehr
Registered: Jan, 2004

Re: Lack of extension

Posted: Mar 5, 2007 6:36 AM

> Objective C is a move in the right direction. Mac OS X
> Cocoa GUI is built using it and the Mac GUI is definately
> sexy! The big vendors chose to back C++ instead of
> Objective C and the rest is history.

Right. And now Apple is running rings around them by leveraging the advantages of the language and the libraries they (actually NeXT, mostly) developed.

> Personally, my take is that Objective C was a good
> compromise back in the day when 64M was a lot of memory on
> a PC. As I understand it, it is not VM based (so no mobile
> code) and it lacks Garbage collection.

Optional garbage collection has been added in Objective C 2.0, which will be available as part of the Leopard release.

> With the machines of today why not go one better, like
> Smalltalk? :^)

In what way is Smalltalk a better choice than Objective C?

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Learning Lisp

Posted: Mar 5, 2007 7:45 AM

>http://www.gigamonkeys.com/book/

Excellent place to start, but I think in order to really appreciate Lisp you have to see it used in an area where it really shines.

http://norvig.com/paip.html

I haven't even worked that far through it and it's alread changed the way I think about code, including Java.

As an aside, one of my biggest "difficulties" with this book (and many other material on "dynamic" languages) is that the code never seems to validate its input. I think when I was a child someone played "Thou shalt validate input in all of thy programs. Thy program shall not crash, loop infinitely, or yield invalid results on any input that thy user may produce, be it through terminal, file, socket, or API call."

So I get this sick feeling in my stomach as I imagine all the ways the user could crash the program by passing in a list with that doesn't conform to the non-specified input specification.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Learning Lisp

Posted: Mar 5, 2007 10:21 AM

> >http://www.gigamonkeys.com/book/
>
> Excellent place to start, but I think in order to really
> appreciate Lisp you have to see it used in an area where
> it really shines.
>
> http://norvig.com/paip.html
>
> I haven't even worked that far through it and it's alread
> changed the way I think about code, including Java.

Thanks for the reference. I'll try to get a look at it.

On a side note, can someone please give me one example of something you can Lisp but you can't do in Python? I'm trying to get through that gigamonkeys book but I find it terribly slow and boring so far. Maybe I'll try skipping a few chapters ahead.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Learning Lisp

Posted: Mar 5, 2007 10:51 AM

"On a side note, can someone please give me one example of something you can Lisp but you can't do in Python? I'm trying to get through that gigamonkeys book but I find it terribly slow and boring so far. Maybe I'll try skipping a few chapters ahead."

Most Lisp compilers support tail recursion optimization.

And there's another thing, with many Lisp compilers you can compile to native code. In certain domains, you can write Lisp that will perform as well as optimized C (not that I've done it).

I haven't done it, but you can add type information and have the compiler perform checks and optimizations based on it.

And of course you have macros, the ultimate black magic, and true closures and lambdas.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Learning Lisp

Posted: Mar 5, 2007 11:04 AM

> "On a side note, can someone please give me one example of
> something you can Lisp but you can't do in Python? I'm
> trying to get through that gigamonkeys book but I find it
> terribly slow and boring so far. Maybe I'll try skipping a
> few chapters ahead."
>
> Most Lisp compilers support tail recursion optimization.
>
> And there's another thing, with many Lisp compilers you
> can compile to native code. In certain domains, you can
> write Lisp that will perform as well as optimized C (not
> that I've done it).
>
> I haven't done it, but you can add type information and
> have the compiler perform checks and optimizations based
> on it.

That's all well and good but that's all about the compiler which isn't really what I am concerned with. It can be as fast as C is not a reason to choose a language in my opinion. If I want something as fast as C I could just use C.

> And of course you have macros, the ultimate black magic,
> and true closures and lambdas.

Do you not consider Python lambdas to be true lambdas?
What's a 'true' closure in the sense of what Python does not provide?

It's not yet clear to me what macros provide and whether I'd want to use them. I guess I'll have to work my way through the book with a forced march to get there.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Learning Lisp

Posted: Mar 5, 2007 1:05 PM

Re: "True" Lambdas

Python lambdas are limited to a single expression, while Lisp lambdas can be arbitrarily long.

re: "True" closures

Python doesn't have closures. When you use a lambda in Python, the parameters are explicit, and the lambda can only access it's parameters. With a closure, it has access to the variables in the surrounding context in addition to it's parameters.

re: Macros

My personal preference usually runs against macros. Macros seem to be mostly an optmization technique to me.

re: Lisp in general

I don't think I would use Lisp for a new production system. I think it's (I'm refering to Common Lisp) standard library is both antiquated and polluted with stuff tossed in to unify the multitude of Lisp variants that exist. Also, a lot of Lisp code feels almost as low-level as C. Instead of twiddling bits you twiddle cons cells.

As an educational endeavor learning Lisp is worth it. It will improve the way you think. If you're doing AI work, it's worth it, because you need to be able to understand the existing body of code. But for most information systems work all you'll get is a new way of thinking. It's not like Python where you probably find opportunities to use it on a regular basis.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Learning Lisp

Posted: Mar 5, 2007 4:56 PM

> re: Lisp in general
>
> I don't think I would use Lisp for a new production
> system. I think it's (I'm refering to Common Lisp)
> standard library is both antiquated and polluted with
> stuff tossed in to unify the multitude of Lisp variants
> that exist. Also, a lot of Lisp code feels almost as
> low-level as C. Instead of twiddling bits you twiddle
> cons cells.

Thanks for elaborating. I can see the value in these features (still not sure about macros) and I am wondering, what contemporary language that incorporates these features fully? (assuming there are some.)

Flat View: This topic has 264 replies on 18 pages [ « | 14 15 16 17 18 | » ]

Previous Topic

Next Topic