🚀 go-pugleaf

Marcin 'Qrczak' Kowalczyk wrote:

>>I bardzo dobrze! O to właśnie chodzi, dokładnie tak samo jak z
>>reinterpret_cast, static_cast, itd. - one też się nie "skalują" do
>>większych przykładów. To *ma* wystawać z kodu i być widoczne.
> 
> Po co język ma do tego zniechęcać? Do reinterpret_cast rozumiem,
> niech zniechęca, ale do lokalnych funkcji - nie.
> 
> Wyróżniać się powinny przede wszystkim operacje, które mają zachowanie
> niezdefiniowane albo bardzo trudno przewidywalne, kiedy się ich źle
> użyje. Tyle że w C++ jest ich za dużo, żeby to było praktyczne.

Praktyczne? W Adzie jest tego znacznie więcej. Nawet rzutowanie pomiędzy 
dwoma strukturalnie identycznymi typami musi być jawne:


procedure Hello is

    type My_Int1 is new Integer;
    type My_Int2 is new Integer;

    A : My_Int1 := 5;
    B : My_Int2;

begin

-- compile-time error:
--   B := A;

-- OK, rzutowanie:
    B := My_Int2(A);

end Hello;


Idź teraz przekonaj ludzi od Ady, że Twoje tricki z trzema 
zagnieżdżonymi lambdami, które używają siedmiu zmiennych lokalnych, są 
"fajne". Z pewnością uznaliby to za prowokację.


> Jasne, jeździjmy po ulicach z włączonym ręcznym. Hamulec - niech
> będzie, ale tylko kiedy robię coś niestosownego, a nie cały czas.

I tu jest właśnie różnica pomiędzy "teoretycznie" a "praktycznie" 
(pisałem o niej parę postów temu). Różnica wyraża się w tym, czy w 
realnym projekcie, prowadzonym z użyciem realnych standardów i procesów 
i w realnym zespole, ktoś pozwoliłby Ci takie rzeczy pisać. Różnica 
wyraża się w tym, czy np. mój szef pozwoliłby mi na to albo czy np. ja 
pozwoliłbym na to swoim podwładnym.

Różnica wyraża się też w tym, jaki jest cel tworzenia jakiegoś języka. 
Czy tworzy się go po to żeby go stworzyć (w celu np. zrobienia doktoratu 
- co jest akurat dobrym pomysłem), czy po to, żeby w nim pisać docelowe 
systemy informatyczne. I jakie.
Zestaw dostępnych/potrzebnych/dozwolonych ficzerów albo pojęcie tego, co 
jest wygodne a co jest wskazane w znacznym stopniu właśnie od tego zależy.

>>wiele
>>kompilatorów i translatorów było pisanych w C++ (i w czymkolwiek
>>innym) i nikt takiej sieczki tam nie napisał
> 
> Wypraszam sobie, oryginalny kod w moim języku nie był sieczką.

Sieczkę zrobiłeś próbując to przetłumaczyć na C++. Co do Twojego języka 
się nie wypowiem, bo i tak nie rozumiem tego przykładu. To, że jest 
znacznie krótszy, nie musi oznaczać, że byłby dozwolony w realnym 
projekcie, nawet gdyby był legalny w C++.


> Oczywiście że można całość wyrazić całkiem inaczej. Ale dlaczego
> miałbym być do tego zmuszony przez ograniczenia języka? Uważam mój
> schemat za zgrabny, tylko C++ nie pozwala mi go sensownie zapisać.

Taki styl. Ja uważam za zgrabne to, że obiekty lokalne mają czas życia 
sterowany zakresem i nie sprzedałbym tego za możliwość używania Twoich 
zgrabnych zapisów. Taki styl.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/