Sat 25 Jun 2005
Hubert,
I don’t see how it is helpful to knock Python before we can get some real world data on it. In my opinion EOG is largly irrelevant these days which makes it a perfect test case. If Python allows it to become a useful application then that is better than having a useless application written in C. If there are memory problems I belive there are many ways we may be able to trim down the PyGTK modules so that only those parts that are used are ever loaded into memory. I for one want to get through these issues, get some real data and have people stop being affraid from using higher level languages for application development.
[read this post in: ar de es fr it ja ko pt ru zh-CN ]
June 25th, 2005 at 5:40 am
The only reason for the existance of EoG is that it is lean and fast. I would suggest that instead of rewriting it in an interpreted language, you simply leave it as it is. There is no point in adding any new functionality to EoG so I don’t see why someone would want to go through the trouble of rewriting it.
June 25th, 2005 at 7:06 am
So be a brave boy then and start rewriting your own programs in Python. I am happy to see the amount of people afterwards who may use a Python version of DBUS for example. I doubt anyone will ever touch it. I for my own believe that it’s better to have one language being used throughly inside GNOME rather than 5 different ones. Python is by far to overhyped and it’s getting much more attention than neccesary. Rewriting apps in python offers yet again a solution for a problem that doesn’t exist.
June 25th, 2005 at 8:21 am
Gnome will have a very hard time surviving if we only allow applications written in c. If don’t embrase higer-level languages like python and java we’ll end up losing a lot of developers. IMHO we should write our core libararies and functionality in c, but leave end-user applications to languages like python.
EoG is a perfecly good test case. If we rewrote it in python we would have a app that is easy to develop and maintain, that uses a c-written libarary for the imaging-tasks. It would be the same, just different
June 25th, 2005 at 9:08 am
language issues aside, please improve the image viewer in nautilus instead. it is far more usefull.
apart from that, i wonder if a useless app in python might not be a bad example instead of a good one. lets come up with a better idea
June 25th, 2005 at 2:50 pm
This is a big mistake. Check torrent clients for the best example. None of based Python, Java or any higher level language of torrent clients have manage to get low overhead, use less CPU and RAM. Any C/C++ based of torrent clients have whoops on based Python and other higher level language very far in no question.
C/C++ can be easy maintain if you write it cleaner and not make it complicate. Think simple and write it simple. If you want EOG in python, you are supposed to have one in C core and other one that is Python binding (EOG-python). C is very easy to have very many other languages binding.
June 25th, 2005 at 5:47 pm
ingo I thought Eog was the Image Viewer in Nautilus? Did something change?
Also I thought Python could be compiled instead of interpreted to help improve performance in certain circumstances?
June 26th, 2005 at 1:18 pm
Tony, the best bit torrent client I have found is called Azureus: http://azureus.sourceforge.net/
It is written in Java.
June 26th, 2005 at 5:10 pm
I agree with Alan - why is EoG considered irrelevant? Is there some other image viewer included with Gnome that I’m not aware of?
June 27th, 2005 at 1:58 am
JC Jones, you have to be kidding? Azureus is worst, it uses a lot of memory.
July 1st, 2005 at 10:58 am
Tony: in times where supermarket computers come with 1 gb ram, most people prefer features over a low memory footprint. that’s why azureus is always on sourceforge’s top10 list
July 4th, 2005 at 6:22 am
cs: That doesn’t mean that Azureus is more popular than BitComet, as BC is not hosted on SF. Generally speaking, the majority is using BitComet, Check your peer list when you BT. In terms of performance it outperforms the other clients a lot. In terms of functionality it has what most users need.
When the data rate is high enough (e.g. 600kByte/s), BC affects performance of foreground applications (e.g. IE, VS, etc.) far less than Azureus.