🚀 go-pugleaf

W dniu 2011-08-05 10:16, slawek pisze:
[...]
> Biznes prowadzi się tak, że: 1. pisanie innych programów, niż te
> sprzedawane w USA to obciach; 2. pokazywanie klientowi kodu źródłowego
> to głupota; 3. jeżeli klient rozumiałby co robi program nie byłoby
> dobrze, więc jeżeli można, trzeba pisać w takim języku
> (programowania/naturalnym) który zapewni maksymalny poziom ściemy. ;)

Po tym co napisałeś przyszła mi do głowy niezła analogia. Umowy
w biznesie pisze się w specjalistycznym języku prawniczym. Ma to powód:
chodzi o ścisłość (wbrew pozorom) i spójność z "zewnętrznym systemem"
(systemem prawnym). Tak - umowy są często trudne do czytania dla laików,
tak jak kod. Tak - czasem prawnicy celowo robią ściemy, podobnie jak
programiści. Ale ten aspekt zostawmy na boku.

W obrocie międzynarodowym umowy są zwykle po angielsku, bo to zwykle
jedyny wspólny język. Fakt, że lepiej je zapisać z użyciem UNICODE, żeby
choć nazwy lokalne były nieprzekłamane. Ale - z naszego punktu widzenia
- to nie jest "mięsko", tylko element "prezentacji". Nazwy stron np.
często używa się tylko w jednym miejscu pisząc coś w rodzaju "firma
Żółw Żółty zwana dalej Zleceniodawcą". Reszta treści umowy operuje tylko
na takich "aliasach" zapisanych już po angielsku. Czyli - patrząc przez
analogię - UNICODE w "mięsku"/kodzie nie jest potrzebny. Tu załamuje się
analogia - tekst umowy jest zwykle przetwarzany przez systemy
akceptujące UNICODE, narzędzia operujące na kodzie - nie koniecznie.

I tu powtórzę - z biznesowego punktu widzenia nie ma potrzeby używania
polskich znaków w identyfikatorach (szczególnie w programach, nad
którymi może pracować zespół międzynarodowy, a prawie zawsze tak się
może zdarzyć). Z technicznego punktu widzenia - lepiej tego nie robić,
bo współczesne systemy nie w pełni obsługują UNICODE w *kodzie*. A że
biznesowej potrzeby nie ma, to kółko się zamyka - nikomu nie zależy
na przystosowaniu kompilatora, linkera i profilera do obsługi
pl-identyfikatorów.

-- 
     Paweł Kierski
     news@pkierski.net