Re: Maximum String size in Java?
From: Programmer Dude (Chris_at_Sonnack.com)
Date: 03/15/05
- Next message: Programmer Dude: "Re: .NET vs J2EE papers"
- Previous message: blmblm_at_myrealbox.com: "Re: A unique number for every "person" - can it be done?"
- In reply to: gswork_at_mailcity.com: "Re: Maximum String size in Java?"
- Next in thread: CBFalconer: "Re: Maximum String size in Java?"
- Reply: CBFalconer: "Re: Maximum String size in Java?"
- Reply: gswork_at_mailcity.com: "Re: Maximum String size in Java?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 15 Mar 2005 13:03:53 -0600
gswork@mailcity.com writes:
> 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."
The above are your closing paragraphs, but I thought they were worth
starting off with, because what they say is important to keep in mind.
>> 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
At that point in our history, we were mostly mini or mainframe from
a number of vendors. We had a lot of Vaxen and HP3000s onsite and
IBM big iron behind well-locked doors. A few locations has Suns of
one flavor or another.
There was never--IME--any requirement (or even thoughts of) having
applications from one environment work in another. The services
provided were specific and mapped to the business environment.
> MS-DOS : roughly mid-late 80's (a bit of Win16 later)
We glommed onto IBM PCs pretty early, so there was a lot of Lotus 123
and WordStar and Word Perfect in the corporate environment. (Our
service division even did 3rd party service for them for a while--at
one point I did some instructor work training field techs.)
> Windows 32bit: roughly mid-late 90's
By the time Windows came around, our desktop environment was largely
Microsoft. Some of the R&D labs used Macs, and there were a lot of
unix workstations in the CAD/CAM groups (Suns migrating to HP-UX boxen).
Eventually corporate dropped support for Macs and most unix platforms
(the unix fairly recently). We're hugely a Microsoft shop these days.
A thing to understand is that when you control the environment it
makes good economic sense to be unified. In the olden days, each
division had their own email system, and exchanging data was a major
problem--if it was possible at all. Now--for better or worse--we have
one that--despite its flaws--allows message and data exchange with
very little thought.
This is a *huge* win from the corporate point of view. Easier to
maintain and administer AND it allows your people to get on with their
work.
The bottom line is that cross-platform portability is vital in some
arenas, but is pretty much a non-issue in others. And, as you indicate,
the changes of *requirements* is vastly more a driver of change than
the need to migrate from one Windows version to another.
(My apps made the jump from Win95 to NT to Win2K seamlessly, and I
fully expect they'll continue to work in XP and beyond.)
> Windows 64bit: it's looking like late 00's.
I think some of the servers are starting to migrate that way, but
I'm not involved in that division, so I can't really say.
> 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.
Exactly so.
> 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!
Yep. And for all the Microsoft bashing that goes on, this is a capability
that nothing else--to my knowledge--provides in anything approaching the
seamlessness or ease that MS does. And both of those--seamlessness and
ease--are vital qualities at the corporate level.
When I think back to how it used to be I shudder. We expended so much
effort on *technique* rather than on *task* it was sad--a testiment to
the infant stage of corporate user computing. Now we don't waste time
on *how*...we waste time on "What color? What font?" :-)
But seriously,... I may have personal feelings about Bill Gates' tactics
or the Microsoft Monopoly, but I gotta respect the heck out of their
products. They do the job and pretty damn well.
- Next message: Programmer Dude: "Re: .NET vs J2EE papers"
- Previous message: blmblm_at_myrealbox.com: "Re: A unique number for every "person" - can it be done?"
- In reply to: gswork_at_mailcity.com: "Re: Maximum String size in Java?"
- Next in thread: CBFalconer: "Re: Maximum String size in Java?"
- Reply: CBFalconer: "Re: Maximum String size in Java?"
- Reply: gswork_at_mailcity.com: "Re: Maximum String size in Java?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
