Re: Maximum String size in Java?
gswork_at_mailcity.com
Date: 03/14/05
- Next message: Martin Dowie: "Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))"
- Previous message: rik: "Re: Found a neat article by Edsger W.Dijkstra"
- In reply to: infobahn: "Re: Maximum String size in Java?"
- Next in thread: infobahn: "Re: Maximum String size in Java?"
- Reply: infobahn: "Re: Maximum String size in Java?"
- Reply: Programmer Dude: "Re: Maximum String size in Java?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 14 Mar 2005 01:31:33 -0800
infobahn wrote:
> Randy Howard wrote:
> >
> > My work
> > has often (usually) involved supporting multiple (sometimes as many
> > as 8 or 9 quite often) OS and hardware platforms from the same code
> > base.
>
> It's always a pleasure to be able to know on which platforms your
> code will be running, even if there are 8 or 9 of them. It gets a
> bit scarier when you haven't a clue which platforms your code has
> to work on.
>
> I suppose that those who consider portability to be of vital
> importance are those for whom it's a daily reality. But it's
> of very little importance if your site is 100% CP/M-based,
> since obviously the company isn't going to throw out all that
> investment for the sake of... Sorry, let me start that again.
> But it's of very little importance if your site is 100% MS-DOS
> based, since obviousl... Excuse me. But it's of very little
> importance if your site is 100% Win32-bas... Win64-ba...
let's see....
year a business might adopt a new OS platform for the company
CP/M : circa 1980
MS-DOS : roughly mid-late 80's (a bit of Win16 later)
Windows 32bit: roughly mid-late 90's
Windows 64bit: it's looking like late 00's.
and keeping in mind that a major reason behind all this to do is PD's
experience of corporate programming we can acknowledge that the core
requirements of corp IT changes alot more often than the platform does
and that the core 'engine' code would also change often enough that
worrying about seperating portable from non-portable would just eat up
time for projects like these, without long term benefit.
In the meantime things like internet tech spring up and demand the kind
of code that would not have been accommodated anywhere in the original
1980 app.
And then there's all the "can we make Excel pick up that data, generate
the trend analysis then put it on our powerpoint charts and email the
team that they're ready..." type of stuff you get in organisations,
there's no point even trying to be portable then!
for general purpose code, either in PC applications or elsewhere, there
would indeed be a desire to keep the core portable, though in practice
even the core of a long lived application tends to be slowly replaced
by new code with a new interface with non portable elements of the
project.
two different angles on the same theme, two different perspectives from
two different backgrounds. Both the 'correct' approach in their
contexts.
i think we can apply standard programming answer #1 to the question
"should code always be portable?", namely: "it depends."
- Next message: Martin Dowie: "Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))"
- Previous message: rik: "Re: Found a neat article by Edsger W.Dijkstra"
- In reply to: infobahn: "Re: Maximum String size in Java?"
- Next in thread: infobahn: "Re: Maximum String size in Java?"
- Reply: infobahn: "Re: Maximum String size in Java?"
- Reply: Programmer Dude: "Re: Maximum String size in Java?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|