> > Because it's proprietary.
> >
> > To dobrze? To niedobrze? Bo nie wiem.
>
> Z tego co widać, ma raczej hamujący wpływ na rozpowszechnianie się systemu.

Miliardy użytkowników Windowsa, Androida oraz iOSa się z Tobą nie zgadzają.

> Więc jeżeli komuś zależałoby na rozpowszechnieniu systemu, to raczej niedobrze.

Nadal się te miliardy nie zgadzają.

> Z drugiej strony, jeżeli ktoś ma klientów którzy płacą mu dostatecznie dużo, to
pewnie dobrze (dla tego kogoś)

Myślę, że dla tych co płacą też dobrze. Bo to daje podstawy sądzić, że będzie
zachowana ciągłość wysiłku inżynierskiego wokół danego produktu.
W tym celu niektórzy są gotowi płacić nawet za open source. Patrz np. RedHat vs.
Fedora. Albo EnterpriseDB vs. PostgreSQL. Albo itd.

Warto w tej dyskusji dodać taki drobiazg, że dla tych, co nie chcą płacić, Wolfram
jest... darmowy:

www.wolfram.com/engine/

> > To trochę tak, jak ze stwierdzeniem, że coś jest np. niemieckie.
>
> Nie rozumuem.

No, że proprietary. Tak jakby to było jakimś stygmatem. Może dla niektórych jest -
ale, patrz RedHat/itd., dla niektórych właśnie tak jest lepiej.

Patrz też (z tego roku!):

https://blog.wolfram.com/2019/04/02/why-wolfram-tech
-isnt-open-source-a-dozen-reasons/

> > 700.000x wolniejsze? Od czego? Podał link do Google Groups, do posta sprzed... 10
lat.
>
> Od MLa.
> Kody źródłowe chyba umieścił.

No, umieścił. Nie znam się na ray-tracingu, ale mam kilka spostrzeżeń.

1. Kod nie wygląda jak typowy Wolfram. Tzn. przykłady Wolframa wyglądają na oko
inaczej. To sugeruje, że podmiot liryczny po prostu przeklepał kod z innego systemu
obliczeniowego linia w linię. To nie jest dobry sporób na benchmark, bo pokazuje co
najwyżej, że Wolfram słabo wykonuje kod w MLu. Należałoby raczej skorzystać z idiomów
i funkcji Wolframa. Powtórzę jednak, że nie znam się na RT, więc nie podejmuję się
tego poprawiać.

2. Wolfram jest przede wszystkim systemem do przetwarzania symbolicznego, gdzie mamy:

In[1]:= Sin[Pi/6]

Out[1]= 1/2

Natomiast obliczenia/symulacje fizyczne lepiej robić nie symbolicznie, tylko
numerycznie. Wolfram też to umie, wtedy mamy:

In[2]:= Sin[Pi/6.]

Out[2]= 0.5

Ta druga wersja potrafi być kilka rzędów wielkości szybsza (bo używa FPU zamiast
podstawiać symbole jak w szkole), ale jak widzisz, trzeba być uważnym, żeby to
uzyskać.
Czy autor tego kodu był uważny, żeby to uzyskać? Nie widzę tego w jego kodzie. Więc
nie wiem.

3. Wolfram potrafi wygenerować kod w C, skompilować go i włączyć z powrotem do
systemu:

https://reference.wolfram.com/language/guide/CodeCom
pilation.html

To się idealnie nadaje właśnie do obliczeń numerycznych, właśnie takich na
machine-precision.
Czy autor z tego skorzystał? No nie widać, żeby skorzystał.

4. To było 9 lat temu.

5. Się zdecyduj. Wcześniej argument był taki, żeby uczyć się Pythona. Teraz jest
taki, że 9 lat temu komuś wydawało się, że ML jest szybszy. To jak w końcu? Mam się
uczyć Pythona zamiast Wolframa, czy MLa zamiast Wolframa, czy może MLa zamiast
Pythona?
Bo już teraz nie wiem.

> Harrop swego czasu pracował u Wolframa.

I dlaczego przestał? Nie chciał poprawiać bugów? Czy może wyszło na jaw, że to jego
bugi?
Ok, nabijam się.

> Źeby nie było, że tylko źle:
> https://www.quora.com/From-a-developer-point-of-view
-what-are-the-biggest-pros-and-cons-of-Wolfram-Mathe
matica-and-the-Wolfram-Language/answer/Jon-Harrop-2

To w końcu mam się uczyć Pythona?
Bo nie wiem.

--
Maciej Sobczak * http://www.inspirel.com