On Wed, 14 Jan 2015 22:26:37 -0800 (PST), "M.M." <m...@g...com>
wrote:
> nie rozumiem po co? Nie można bawić się przy robieniu czegoś potrze=
> bnego?

Grecy wymyślili że nie. Że rzeczy potrzebne mają robić niewolnicy. A
ludzie wolni bawią się rzeczami niepotrzebnymi. Na przykład filozofią
i takimi tam.

Innymi słowy: świat nie jest dla ciebie, różni ludzie robią różne
rzeczy. I jest mało prawdopodobne że będzie ich bawić robienie tobie
dobrze.

do góry

On Wed, 14 Jan 2015 22:26:37 -0800 (PST), "M.M." <m...@g...com>
wrote:
> Dobre aplikacje powstają w bólu.

Jakaš trauma z dzieciństwa?

do góry

On Thursday, January 15, 2015 at 5:38:11 PM UTC+1, slawek wrote:
> Grecy wymyślili że nie. Że rzeczy potrzebne mają robić niewolnicy. A
> ludzie wolni bawią się rzeczami niepotrzebnymi. Na przykład filozofią
> i takimi tam.
Może dlatego nie stworzyli języków programowania? :D


> > Dobre aplikacje powstają w bólu.
>
> Jakaš trauma z dzieciństwa?
No coś Ty, programiści nigdy się nie męczą i robią
wszystko bezwysiłkowo ;-)

do góry

On Wed, 14 Jan 2015 22:26:37 -0800 (PST), "M.M." <m...@g...com>
wrote:
> Jednym słowem, kolejny raz nie powiodła się próba nadmiernego uła=
> twienia
> życia programiście. Może tutaj powinieneś użyć określenia lif=

Ale dlaczego? Powiodła się... Python ma się wcale dobrze, lepiej niż
Pascal.

do góry

On Wednesday, January 14, 2015 at 1:33:04 AM UTC+1, slawek wrote:
> Równie dobrze można w trybie nakazowo-rozdzielczym domagać się aby np. nie
> było ruchów tektonicznych - no, bo po co nowe góry czy jakieś nowe wyspy?

Popieram ten postulat, jest nie tylko słuszny, ale i potrzebny
w naszym zobojętniałym społeczeństwie.

> Odnośnie samego Pythona. [...]
>
> 1. Za wolno działa (nawet 1000x wolniej niż program napisany w C).

To jest język interpretowany i będzie wolny. Trzeba z tym żyć.

> 2. Bałagan z wersjami. Wersje 3.* mają problemy z Cythonem.

Wersja 3 jest rozwijana na gałęzi cythona, jakie masz problemy?

> 3. Biblioteki "matematyczne" Numpy/Scipy nie są 100% bezbłędne.

Ale to nie jest biblioteka standardowa pythona.

> 4. Koszmarnie źle zrobione wątki.

Co z nimi jest nie tak?

> 5. Brak tablic.

A [1,2,3,4] to czym jest? #define tablica


w.

do góry

On Thu, 15 Jan 2015 08:48:15 -0800 (PST), "M.M." <m...@g...com>
wrote:
> Może dlatego nie stworzyli języków programowania? :D

Algorytmy jakieś wymyślili. ;)


> No coś Ty, programiści nigdy się nie męczą i robią

Zmęczenie to nie to samo co ból. Jeżeli boli programowanie, to może
lepiej abyś tego nie robił? To jak z wbijaniem gwoździ. Można to
robić zaciśniętą pięścią, ale boli. Fachowiec robi to młotkiem.

do góry

W dniu czwartek, 15 stycznia 2015 21:13:51 UTC+1 użytkownik Wojciech Muła napisał:
>
> To jest język interpretowany i będzie wolny. Trzeba z tym żyć.
>
nie jestem pewien czy to ze python jest wolny wynika z tego ze jest interpretowany,
najprawdopodobniej mozna by go kompilowac (?,nie jestem tego co prawda pewien) i
calkiem mozliwe ze kompilowany tez bedzie wolny (?,tego tez nie jestem calkiem
pewien)
[pewnie bylby szybszy niz obecny ale i tak wolniejszy niz c]
- wydaje mi sie ze moze to byc w sumie sluszna dorga, kompilowane jezyki
wysokopoziomowe, nieststy by cos wiecej o tym powiedziec chyba trzebby sie tym zajac,
znac procedury kompilacji takich
wysokopoziomowych jezykow jak to dziala,
co jest problemem itp

do góry

W dniu czwartek, 15 stycznia 2015 21:50:26 UTC+1 użytkownik firr napisał:

> > To jest język interpretowany i będzie wolny. Trzeba z tym żyć.
> >
> nie jestem pewien czy to ze python jest wolny wynika z tego ze jest interpretowany,
najprawdopodobniej mozna by go kompilowac (?,nie jestem tego co prawda pewien) i
calkiem mozliwe ze kompilowany tez bedzie wolny (?,tego tez nie jestem calkiem
pewien)

Stwierdzenie, ze "jezyk jest wolny", to najzwyczajniejszy w swiecie blad
kategorialny. Pythona oczywiscie mozna kompilowac.

> - wydaje mi sie ze moze to byc w sumie sluszna dorga, kompilowane jezyki
wysokopoziomowe, nieststy by cos wiecej o tym powiedziec chyba trzebby sie tym zajac,
znac procedury kompilacji takich
> wysokopoziomowych jezykow jak to dziala,
> co jest problemem itp

Dla jezyka Scheme istnieje kompilator, ktory podobno optymalizuje na tyle
dobrze, ze osiagalna wydajnosc jest porownywalna z C.
Jego autor napisal nawet (niezbyt doglebny, ale przyjemny w czytaniu)
tekst dotczacy tego, w jaki sposob rozwinal ten kompilator:
http://www.cs.indiana.edu/~dyb/pubs/hocs.pdf

Poza tym zdaje sie, ze istnieja bardzo dobre kompilatory dla OCamla.
Tutaj mozna znalezc porownanie wydajnosci raytracera napisanego w C++
z napisanym w OCamlu:

http://www.ffconsultancy.com/languages/ray_tracer/co
mparison.html

Widac, ze roznice w wydajnosci sa niewielkie (albo prezentacja wynikow
jest dobrze zmanipulowana ;]), natomiast korzysci wynikajace z uzycia
OCamla wydaja sie znaczace

do góry

W dniu czwartek, 15 stycznia 2015 22:12:12 UTC+1 użytkownik g...@g...com
napisał:

> Stwierdzenie, ze "jezyk jest wolny", to najzwyczajniejszy w swiecie blad
> kategorialny. Pythona oczywiscie mozna kompilowac.


I, co ciekawe, nadal bywa wtedy wolny (uściślając: program
w nim napisany działa wyraźnie wolniej).

Co jest dziwne, bo czy JAVA, czy Julia radzą sobie
znacznie lepiej.


'Bywa', bo to mocno zależy od zastosowania. Jeśli
odpalasz nieszczęsne 'mnozenie dużych macierzy',
tylko dookoła tym zarządzając, dostaniesz
to samo co w innych językach. Większość pracy
i tak robi podpięta bibliotaka napisana w FORTRANie;-].
Jeśli jednak bawisz się pojedynczymi zmiennymi,
jest wyraźnie wolniej.


Trochę wątpię, by przez tyle lat i tyle różnych prób
nikt nie napisał dobrego JIT czy kompilatora.

pzdr
bartekltg

do góry

W dniu piątek, 16 stycznia 2015 03:46:10 UTC+1 użytkownik bartekltg napisał:
> W dniu czwartek, 15 stycznia 2015 22:12:12 UTC+1 użytkownik g...@g...com
napisał:
>
> > Stwierdzenie, ze "jezyk jest wolny", to najzwyczajniejszy w swiecie blad
> > kategorialny. Pythona oczywiscie mozna kompilowac.
>
>
> I, co ciekawe, nadal bywa wtedy wolny (uściślając: program
> w nim napisany działa wyraźnie wolniej).

Program napisany w C tez bedzie dzialal wolno, jak sie go odpali
w dostatecznie slamazarnym interpreterze ;]

> Co jest dziwne, bo czy JAVA, czy Julia radzą sobie
> znacznie lepiej.

Nie jest dziwne. Python jest duzo bardziej elastyczny, w takim
sensie, ze bardzo duzo rzeczy w jezyku mozna zmieniac "na goraco",
w runtimie (vide monkey patching). Oczywiscie wiele programow z
tego nie korzysta, ale taka elastycznosc utrudnia wnioskowanie
o zachowaniu programu, a tym samym blokuje mozliwosc latwego
przeprowadzenia wielu optymalizacji.
Choc pewnie gdyby ktos poswiecil temu np. swoje zycie, to moglby
napisac dobry optymalizator, zeby Python dzialal rownie wydajnie,
co C (no ale potem i tak zmienilyby sie pewie core'owe ficzery
jezyka z kolejnym wydaniem, i trzeba by bylo glowkowac od nowa ;])

Warto pamietac, ze pierwotnym przeznaczeniem Pythona bylo stworzenie
alternatywy dla skryptow powloki

do góry