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
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
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
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
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 :-)
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 email@example.com
Posting guidelines: http://netmeister.org/news/learn2quote.html
*** All posts to this list are publicly archived ***
Re: [tdf-discuss] Java dependency · RGB ES
Impressum (Legal Info)
: 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