🚀 go-pugleaf

> > 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/CodeCompilation.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-Mathematica-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