Date: prev next · Thread: first prev next last
2010 Archives by date, by thread · List index

Re: [tdf-discuss] Re: Java dependency


On Wed, 2010-11-03 at 09:19 -0400, Kohei Yoshida wrote:
On Wed, 2010-11-03 at 12:50 +0000, Ian wrote:
On Wed, 2010-11-03 at 07:09 -0400, Michael Meeks wrote:

At least then it would run on any platform with a JVM eg cell phone

  Sure any cell-phone with a vast amount of RAM, and a CPU twice as fast
as those we have currently in desktops might give reasonable
performance.

Ok, perhaps a daft suggestion but the principle is that all cell phones
will have a vast amount of RAM and fast CPUs in the next 2 to 3 years. A
gig of RAM is normal now, it would have been unthinkable 10 years ago.

Personally, a mindset such as "RAM is cheap these days, so let's waste
it" troubles me as a developer.

Oh I agree, but the point I was making was that whether it is because
RAM gets cheaper or code gets more efficient, at some point all general
productivity tools are going to be available on cell phone technology.
That means ARM and probably Android.

BTW, I used to have an Acorn Archimedes computer running a full drag and
drop GUI with outline fonts with sub-pixel anti-aliasing back in 1989. I
ran a document publisher that was hand coded in ARM assembler. It ran
from a floppy disk in 1 meg of RAM - an upgrade to 4 meg was Wow! Real
time rotation of graphics in frames irregular shape frames for text
formatting etc. So I appreciate the value of efficient coding. I'm
rather depressed that I could do this 20 years ago and we seem to need
100 times the processing power and 1000 times the RAM to get similar
results.

  It's true that RAM is cheaper, but we
are not yet to the point where we no longer have to worry about runtime
RAM usage - far from it.

Just like consumers have managed to find ways to fill ever-so-increasing
hard disk space,

Actually I don't think many do. I have masses of unused disc space.
Unless you are storing video libraries a 250 Gig hard drive is not very
likely to get even half full. Writing software that forces machine
upgrades has logic if you get a new OS sale for every new machine
shipped. Even if not deliberate, the incentives are all in the wrong
direction.

developers will find ways to use up ever-so-increasing
memory space (and I've seen enough evidence of it).  So, we should
always be encouraging ourselves to reduce memory footprint, instead of
wasting it.

BTW, I love C++, which is standardized enough, is not tied to any single
vendor, and can generate native code, not byte code.

That is best as long as the compilers produce efficient code for the
target CPUs most likely to be in the highest volume in the not too
distant future. The principle of RISC technology is to focus on the 20%
of instructions that get used 80% of the time. Maybe that should be an
apps development philosophy too. 

Just my opinion.

Very valid :-)

-- 
Ian
Ofqual Accredited IT Qualifications
A new approach to assessment for learning
www.theINGOTs.org - 01827 305940

You have received this email from the following company: The Learning
Machine Limited, Reg Office, 36 Ashby Road, Tamworth, Staffordshire, B79
8AQ. Reg No: 05560797, Registered in England and Wales. 


-- 
Unsubscribe instructions: Email to discuss+help@documentfoundation.org
Posting guidelines: http://netmeister.org/news/learn2quote.html
Archive: http://www.documentfoundation.org/lists/discuss/
*** All posts to this list are publicly archived ***

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.