On Thursday, January 2, 2020 at 9:46:39 AM UTC+1, slawek wrote:
> Jest wiele mitów:
>
> 1. "Python to język skryptowy" - mit - podział na języki skryptowe
> i nie-skryptowe wymagałby zdefiniowania "skryptowości" - jak
> dotąd nikomu nie udało się tego dobrze zrobić. Czy Lua to język
> skryptowy? A Basic? Czym różni się semantycznie for z Javy, C++ i
> AWK? A taki Postscript to jest jaki?!

Hmmm w sumie tak na szybko z rękawa nie umiem rzucić takiej definicji, aby
nikt się nie przyczepił. Może chodzi o to, że do 'języków skryptowych' nie
warto pisać kompilatora który zamieniałby go na kod maszynowy, bo wymagałoby
to wkompilowania interpretera? Każdy specyficzny element języka skryptowego
wymagałby call do interpretera, albo wstawienia ogromnej ilości kodu inline.

> 2. "Nie ma sensu robić programów z GUI w Pythonie" - mit - bo
> takie programy jest łatwiej zrobić niż w C++.

Nie przepadam za Pyhonem, ani nie mam doświadczenia w pisaniu aplikacji w
Pythonie, ale zgadzam się, że interfejs GUI w językach typu Python robi się
łatwiej, szybciej i w ogóle lepiej się do tego nadają. Po co w C++ się uganiać
za wskaźnikami i martwić czy domyślny konstruktor wywoła się szybciej i
przydzieli pamięć pod listę z danymi do wyświetlenia w GUI... Ale nie
popadajmy w skrajność, dla kogoś kto ma wprawę takie uganianie w C++ jest
nawet przyjemne i też robi się szybko. Podobno główną zaletą Pythona jest
to, że po zaledwie małym kursie można szybko pisać duże aplikacje. W C++
bez solidnego kursu i praktyki programować się zdecydowanie nie da. Czasami tu i
ówdzie można przeczytać, że Python jest dla naukowców. Jeśli chodzi o to, że
naukowiec żyje w swoim świecie, a od czasu do czasu musi szybko napisać
jakiś programik sprawdzający jego teorię w praktyce - to się zgadzam. Po co
naukowiec miałby część swojej intelektualnej twórczości marnować na opanowywanie
ogromnej ilości szczegółów języka takiego jak C++? Natomiast gdy już naukowiec
zwraca się do programisty ze swoim problemem, to bardziej normalne
wydaje się, że programista zaproponuje naukowcowi rozwiązanie uszyte na miarę
problemu i na miarę dostępnego sprzętu właśnie w C++ a nie w jakimś skrypciaku.

> Choćby w tym sensie
> że biblioteka Qt wymaga w przypadku C++ gimnastyki z
> metakompilatorem,

Jeden podpity do drugiego:
- na rynku zrobili taką dziurę, wkłada się tam głowę i samo goli twarz.
- no ale przecież każdy ma inną gębę!
- ale tylko za pierwszym razem ;-)

Więc ta gimnastyka jest tylko za pierwszym razem gdy ktoś nie opanował
metakompilera, kompilera zasobów, itd. Poza tym istnieje IDE o nazwie
QTCreator w którym (dziś, bo kiedyś się wywalało co rusz) można zbudować
naprawdę dużą aplikację i duże GUI nie rozumiejąc jak działa metakompiler a
nawet kompiler c++... w regularnym kodzie produkcyjnym nastawionym na
stosunek funkcjonalności do nakładu pracy nawet nie jest wskazane rozumienie
szczegółów z qmake. Oczywiście gdy ktoś chce wycisnąć maksimum możliwości z
tych narzędzi to musi rozumieć jak one działają, ale taka konieczność
zachodzi tylko w specyficznych aplikacjach.

> a Python tego nie potrzebuje. Osobną sprawą
> jest kwestia czy każdy program powinien mieć GUI ? - ale
> odpowiedź na to nie zależy od języka.

No nie zależy od języka.


> 3. "Python nie kompiluje się" - mit - są kompilatory Pythona.

Słyszałem że jak się podaje typy i pisze w odpowiedni sposób to
można Pythona skompilować do C i potem do kodu maszynowego. Ale
to pisanie w odpowiedni sposób chyba oznacza rezygnację z wygód
jakie niosą kacze interpretowane języki ?

> Ponadto podział języków na interpretowane (translatory) i
> kompilowane (kompilatory) jest dziś głupotą - mamy JIT i podobne
> techniki. A DLL dla Pythona są w natywnym.

Tak, ale nawet (bez sarkazmu) w wydajnej Javie JIT nie może wiele
zrobić gdy jest wirtualny call po nazwie i overloading na podstawie
dynamicznych typów - w przypadku każdego wywołania.


Pozdrawiam