🚀 go-pugleaf

On 03/08/11 10:13, slawek wrote:
>> Używanie Unicode w identyfikatorach nie rozwiązuje żadnych istotnych
>> problemów, natomiast powoduje nowe: od zwiększenia skomplikowania samego
>
> Nie chodzi o używanie w indentyfikatorach, bo nikt nie zmusi programistę
> aby nie pisał id001, id002, itd. albo i, j, ii, ij, a, b, x, y, z.
>
> Chodzi o to, aby po prostu pisać w Unicode bez myślenia jakie literki
> wolno w jakim miejscu pisać. Czyli jeżeli wolno pisać ąę w literałach,
> to wolno i w komentarzach, a jeżeli wolno w komentarzach, to musi być
> wolno w identyfikatorach. Proste i logiczne.

Z uporem maniaka powtórzę pytanie: jaki realny problem ma rozwiązać 
postulowane przez Ciebie rozszerzenie? Bo na razie czytamy tylko "bo ja 
bym tak chciał" w różnych wariantach.

> Zabrzmi nacjonalistycznie - ale być może dobrze byłoby, aby czasami kod
> źródłowy nie był czytelny dla przypadkowych ludzi, takich właśnie jak
> niedouczeni (tj. nie znający polskiego) Hindusi? Zresztą, jak chcesz aby
> Hindusi pracowali nad programem - to pisz w hindi - ja ci nie bronię.

Nie chcę z góry. Ale chcę, by było to możliwe, jeśli kiedyś względy 
biznesowe wskażą, że warto. Albo żeby dało się wynająć 
konsultanta-uberguru z USA do rozbudowy lub optymalizacji. Albo żeby 
przy automatycznym generowaniu diagramów architektury móc wybierać z 
całego rynku, a nie dwóch produktów, które na razie jako jedyne 
obsługują ogonki w nazwach metod. To się nazywa niezamykanie sobie opcji 
bez potrzeby.

>> Poza tym, język to nie tylko kompilator. Jeśli chcesz sensownie używać
>> unicode'owych identyfikatorów, Unicode musi być wspierany przez
>> linker, debugger, profilery, wszystkie narzędzia typu nm... nie
>> wspominając o
>
> A samochód musi mieć cztery koła do jazdy, zapasowe, silnik, hamulce i
> wycieraczki. I co? Jaki morał z tych wyliczeń?!

Że moje stanowią część argumentu, a Twoje są nie na temat?...

>> samym systemie i jądrze (wynalazki typu dtrace). Aha, a jeśli program
>> ma być przenośny, to wsparcie musi dotyczyć wszystkich docelowych
>> systemów.
>
> Co dużo łatwiej zrobić w Unicode niż w 7-bitowym ASCII.

Nieprawda. Dlatego, że wsparcie dla 7-bitowego ASCII już jest, a dla 
Unicode trzeba by dopiero wprowadzić.

Twoje przekonywanie miałoby sens, gdyby nie istniała jeszcze żadna 
infrastruktura i tworzylibyśmy właśnie pierwszy projekt. Ale ona już 
istnieje i oczywiste pytanie brzmi "jakie będa korzyści tej zmiany, a 
jakie koszty". Na razie te pierwsze są niewielkie, a te drugie olbrzymie.

>> Pewnie, że teoretycznie to możliwe, ale motywacja jest niewielka, więc
>> ja bym z zapartym tchem nie czekał...
>
> Dla nas pikuś. Dla PRC to już mniej pikuś - miliard programistów nie
> może się mylić (pisząc w jakimś języku naturalnym, który nie ma nawet 3
> tysięcy liter).

W Chinach po angielsku mówi więcej osób niż w USA. Jak myślisz, o czym 
to świadczy?

W książce "Projektowanie i rozwój języka C++" Bjarne fajnie opisuje 
funkcjonowanie Komitetu Standaryzacyjnego i podaje kryteria stawiane 
proponowanym rozszerzenium Standardu oraz sporo przykładów rozszerzeń 
zaakceptowanych i odrzuconych. Jeśli masz wolny wieczór, warto sobie 
przeczytać - zobaczysz, jak bardzo pomysł typu "Unicode w całym kodzie" 
jest z kosmosu.