[squeak-dev] [Pharo-dev] Unicode Support
Ben Coman
btc at openinworld.com
Sun Dec 13 07:58:12 UTC 2015
On Sun, Dec 13, 2015 at 3:57 AM, Louis LaBrunda
<Lou at keystone-software.com> wrote:
> Hi Eliot,
>
>>Hi Louis,
>>_,,,^..^,,,_ (phone)
>>> On Dec 12, 2015, at 5:19 AM, Louis LaBrunda <Lou at Keystone-Software.com> wrote:
>>>
>>> Hi Guys,
>>>
>>> +0.95 I certainly agree we shouldn't write code now that we may need in
>>> the future but it doesn't hurt to look a little ahead and plan a bit. If
>>> the people defining database tables thought a little ahead and didn't try
>>> to save two characters per date by leaving off the century there never
>>> would have been a Y2K scare.
>>>
>>> Lou
>>
>>I am /not/ saying one shouldn't look forward; I am /not/ saying cut corners or do weak design.
>
> I'm sure you not. And I didn't mean to imply otherwise. And I don't
> disagree with anything you've said. I just wanted to be sure everyone
> understood there is a difference between not implementing what isn't needed
> now and looking ahead enough to allow easy changes in the future. Your
> example designing in support for 64-bits from the start is spot on.
>
>>I am saying don't implement what you're not necessarily going to use.
>
>>The y2k bug is either bad design or a space optimisation, depending on your point of view, but it isn't an example of requirements driving design. The requirement is to represent dates; the step to use 2 digits for the year is a subsequent step.
>
> Just a little history because I'm old enough to remember when disk space
> was limited and at a premium (I think IBM 3330 were about 200MB). The
> choice to leave off the century (back then dates and times were often
> stored as strings) was a space saving effort. It was a bad choice, if it
> was a conscious one. I'm not sure it was a conscious choice, as many
> programmers didn't look very far ahead even to see the approaching century.
Obligatory...
http://www.businessinsider.com.au/picture-of-ibm-hard-drive-on-airplane-2014-1
now get off my lawn... ;)
cheers -ben
More information about the Squeak-dev
mailing list
|