pytanie o wydajność
Marek Kozlowski
Czytałem o wadach i zaletach różnych IDE do Pythona. Wielokrotnie wśród
różnych "przeciw" znajdowałem: "stosunkowo wolny, ponieważ napisany w
Pythonie".
Hm... "Wydajność" to szerokie pojęcie -- jakbym umiał zdefiniować to bym
też umiał zmierzyć. Programowanie znajduje się na peryferiach moich
zawodowych zainteresowań. Jednakże inżynieria oprogramowanie jest
dziedziną dość "dysertabilną" -- na pewno ktoś zaproponował jakieś
zestawy standardowych testów dla oceny wydajności danego języka.
Bawię się w pisanie programu (łatwo i wygodnie w Pythonie), który w
pewnym fragmencie operuje na dość skomplikowanych strukturach danych.
Można się umordować bardzo złożonymi wskaźnikami i zrobić misternie to w
C. Trochę prościej można w C++. W Pythonie kod na złożonych słownikach,
zbiorach i listach będzie duuużo prostszy. Można też napisać kod w
Pythonie bardziej subtelny, ale zapewne wydajniejszy -- czy warto?
Pytanie: czy pisząc program w Pythonie warto dla optymalizacji wykonania
robić pewne fragmenty w C? Kiedy warto (chociaż jakieś ogólne wskazówki)
mieszać kod w Pythonie z kodem niskiego poziomu? Czy pisząc tylko w
Pythonie warto zawracać sobie głowę optymalizacją kodu? Czy istnieją
jakieś zgrubne oszacowania co warto pisać w Pythonie, a czego się nie
opłaca (np. na jakich klasach algorytmów Python najbardziej odstaje od
implementacji C/C++ a dla jakich wydajnościowo wyjdzie podobnie)? Czy
może jednak jak w opisie z pierwszego akapitu należy przyjąć, że jak w
Pythonie, to wolny...
Dla ustalenie uwagi przyjmijmy python 2.4.4 i gcc 4.1.2
Dzięki za wszelkie sugestie.
Pozdrawiam,
/M
Sulsa
Marek Kozlowski <kozl...@mini.pw.edu.pl> wrote:
> [ciach]
Z wydajnoscia to jest tak ze jesli cos dziala wystarzajaco szybko to
znaczy ze nie ma sie co mordowac. Dopiero jak cos dziala zbyt wolno
wtedy sie kombinuje, pierwsze od czego bym zaczal gdy brakuje predkosci
to zainteresowanie sie psyco -- daje ogromnego kopa.
>
> Dla ustalenie uwagi przyjmijmy python 2.4.4 i gcc 4.1.2
>
2.5 wedlug tego co pisali na python.org bardzo przyspieszyl w stosunku
do poprzednika.
--
Seweryn Habdank-Wojewódzki
Sulsa wrote:
> pierwsze od czego bym zaczal gdy brakuje predkosci
> to zainteresowanie sie psyco -- daje ogromnego kopa.
i nie wszędzie działa, ale jak to się w przemyśle mówi "Who cares?!".
Pozdrawiam.
--
|\/\/| Seweryn Habdank-Wojewódzki
\/\/
ACCU - Professionalism in programming - http://www.accu.org/
Sulsa
Seweryn Habdank-Wojewódzki <shw_...@wp.pl> wrote:
> Witam
>
> Sulsa wrote:
>
> > pierwsze od czego bym zaczal gdy brakuje predkosci
> > to zainteresowanie sie psyco -- daje ogromnego kopa.
>
> i nie wszędzie działa, ale jak to się w przemyśle mówi "Who cares?!".
W obliczeniech zmienoprzecinkowych, w moim przypadku najlepiej
przetestowalem na sieciach neuronowych i innych metodach klasyfikacji,
wzrost jest *ogromy*. Python niestety nie jest zbyt mocny w takich
obliczeniach "sam z siebie".
Seweryn Habdank-Wojewódzki
Sulsa wrote:
> W obliczeniech zmienoprzecinkowych, w moim przypadku najlepiej
> przetestowalem na sieciach neuronowych i innych metodach klasyfikacji,
Oczywiście, ale ja nie o tym :-).
> wzrost jest *ogromy*.
Tak. Czasem nawet do 20 razy. Psyco używam w kilku projektach.
> Python niestety nie jest zbyt mocny w takich
> obliczeniach "sam z siebie".
Tak.
Ale chodzi mi o system operacyjny i sprzęt :-D. A dokładniej uczulam, aby
dokładnie przeczytać gdzie Psyco NIE działa.
Sulsa
Seweryn Habdank-Wojewódzki <shw_...@wp.pl> wrote:
> Witam
>
> Sulsa wrote:
>
> > W obliczeniech zmienoprzecinkowych, w moim przypadku najlepiej
> > przetestowalem na sieciach neuronowych i innych metodach klasyfikacji,
>
> Oczywiście, ale ja nie o tym :-).
>
> > wzrost jest *ogromy*.
>
> Tak. Czasem nawet do 20 razy. Psyco używam w kilku projektach.
>
> > Python niestety nie jest zbyt mocny w takich
> > obliczeniach "sam z siebie".
>
> Tak.
>
> Ale chodzi mi o system operacyjny i sprzęt :-D. A dokładniej uczulam, aby
> dokładnie przeczytać gdzie Psyco NIE działa.
niestety tylko x86, nadzieje na eksploracje innych architektur niesie
PyPy, który dostał niemały grant od UE, jednak narazie efektów nie
widać poza paroma specyficznymi kawałkami kodu gdzie jest nieznacznie
szybszy od CPythona. Podobno Stackless jest tez szybszy od CPythona
szczególnie w momęcie wywoływania funkcji, jednak nie wiem czy na
stacklesie da sie odpalic psyco i nie jest on raczej poza paroma grami
MMORPG wykorzystywany.
--
Adam Karpierz
'Jednym slowem' i ogolnie (czyli absolutnie nie tylko w Pythonie)
o tzw 'optymalizacji' w programowaniu.
Kilka kardynalnych zasad ktore stosuje i doradzam innym:
1. Przykazanie glowne swiete i podstawowe:
'Nie ma nic gorszego niz przedwczesna optymalizacja'
2. Optymalizuje sie _tylko i wylacznie_ wyrazne konkretne
bootlenecks.
Co do innych wnioskow do Twoich pytan (z tej zasady wynikajacych):
> W Pythonie kod na złożonych słownikach, zbiorach i listach będzie duuużo
> prostszy. Można też napisać kod w Pythonie bardziej subtelny, ale zapewne
> wydajniejszy -- czy warto?
_Napewno_ nie warto. Ale... (bardzo malutkie ale..)
> Pytanie: czy pisząc program w Pythonie warto dla optymalizacji
> wykonania robić pewne fragmenty w C?
_Napewno_ nie warto. Ale... (bardzo malutkie ale..)
> Czy pisząc tylko w Pythonie warto zawracać sobie głowę optymalizacją kodu?
_Napewno_ nie warto. Ale... (bardzo malutkie ale..)
> Czy istnieją jakieś zgrubne oszacowania co warto pisać w Pythonie, a czego
> się nie opłaca
Niby istnieja ale _napwno_ nei naezy ich brac powaznie pod
uwage _zawczasu_, gdyz optymalizacja tyczy bardzo konkretnej
niepowtarzalnej sytuacji i tzw bootlenecks to nei pojecie ogolne
ale szczegolne (konkretne warunki sprzetowo softwareowo...
polityczno mentalne:)
Ale... (bardzo malutkie ale..)
> (np. na jakich klasach algorytmów Python najbardziej odstaje od
> implementacji C/C++ a dla jakich wydajnościowo wyjdzie podobnie)?
Np OSowe drivery kart graficznych :)
Ale.. nawet w tak niskopoziomowych zastosowaniach
Python nie moze byc generalnei odrzucony bo..
wiekszosc bilbliotek w Pythonie to tylko wrapper do
niskoposiomowych optymalizowanych Cowych bibliotek
wie.. no taki driver klawiatury spokojnie moglby byc napisany
w Pythonie bo naewt znana Pani Jasia co pisze 11.5 znaku na
sekunde nie nadazy .
Ale... (bardzo malutkie ale..)
No wlasnie.
Ale.. gdy sie jednak okaze ze w konkretnej sprawie/warunkach
istnieje bootleneck: nalezy:
1. Sprobowac zoptymalizowac samemu kod Pythona
gdy nie pomoze to:
2. Poszukac gotowych Pythonowych rozwiazan problemu
gdy nie pomoze to:
4. Poszukac gotowych Pythonowo/C/C++owych rozwiazan problemu
gdy nie pomoze to:
5. Poszukac gotowych np C/C++-owych komponentowych (COM. .NET CORBA)
(jesli mozna tych technologii ich uzyc w danym srodowisku) rozwiazan
problemu i uzyskac ad hoc 'wrapping' do Py poprzez uzycie
binderowania do tych ttechnologi (PythonWin, pythonCOM, omniORB itp)
zwlaszac jesli i tak www tech.komp sie w projekcie uzywa.
gdy nie pomoze - lub nie mozna/nie nalezy uzywac w/w technologi to:
6. Poszukac gotowych niekomponentowych C/C++-owych rozwiazan problemu
i probowac uzyskac wraper do dll/so - za pomoca np ctypes itp
gdy nie pomoze to:
7. Poszukac gotowych niekomponentowych C/C++-owych rozwiazan problemu
i probowac uzyskac wraper do Py np SWIGiem albo innym SIPem
gdy nie pomoze (nie do obejscia problemy z wrappingiem automatycznym) to:
8. Poszukac gotowych C/C++-owych rozwiazan problemu i probowac
napisac wrapper recznie.
gdy nie pomoze (nie do obejscia problemy z wrappingiem automatycznym) to:
9. Poszukac gotowych C/C++-owych rozwiazan problemu i probowac
napisac wrapper recznie.
gdy nie pomoze to:
10. Samemu napisac w C/C++ probujac uzyc ew technologii
komponentowej (jeli jest i moze byc uzywana w projekcie)
gdy nie pomoze to:
11. Samemu napisac w C/C++ robiac so/dll a potem ctypes itp
gdy nie pomoze to:
12. Samemu napisac w C/C++ robiac lib a potem
SIWG SIP itp
gdy nie pomoze to:
13. Samemu napisac w C/C++ robiac lib a potem
wrapper pisac recznie.
gdy nie pomoze to:
...
14. Olac ten projekt.
Swiat nie jest dla Pstrowskich
gdy nie da rady to (a jest duuuza kasa):
....
67. Napisac wszytsko w C udajac geeka :)
gdy nie pomoze to:
321. Napisac wszytsko w ASM udajac Greka :)
gdy nie pomoze to:
999. kill -9 pechowy_developer
gdy sie nie chce to:
1000. Ozenic sie.
Ten 'sakrament' ustala wlasciwe proporcje
miedzy praca/ambicjami a ehh... ;)
AK (programista od 30 lat, malzonek 'nieco' krocej:)
Adam Karpierz
> Z wydajnoscia to jest tak ze jesli cos dziala wystarzajaco szybko to
> znaczy ze nie ma sie co mordowac. Dopiero jak cos dziala zbyt wolno
Brawo ! :)
> wtedy sie kombinuje, pierwsze od czego bym zaczal gdy brakuje predkosci
> to zainteresowanie sie psyco -- daje ogromnego kopa.
No wlaasnie !
Swietne ze przypomniales.
Psyco przeoczylem :(
AK
Adam Karpierz
> nadzieje na eksploracje innych architektur niesie PyPy, który dostał
> niemały grant od UE, jednak narazie efektów nie
> widać poza paroma specyficznymi kawałkami kodu gdzie jest nieznacznie
> szybszy od CPythona.
Grant sie skonczyl juz chwile temu.
Towarzysto w wzielo kase i sie rozjechalo.
Kilku zapewne zrobi doktorat itp.
Czyli klasyka !
Obsmiewalem sposob finansowania/tworzenia PyPy chyba 2 lata temu.
Sprawdzilo sie w 100%.
Jak kazde stricte socjalistyczne podejscie :(.
PS: Nadzieje poza glownym Pythonem (3000) niesie glownie
IronPython pod rzadmi MS-a oraz Jython pod rzadami Suna
Moze tez Google z GvR z czyms 'wyskocza' ?
Moze na bazie wlasnie PyPy (zalozenia nie sa zle - np wydajna
maszyna wirtulna itp)
AK
Bart Ogryczak
>:-)
>
> Czytałem o wadach i zaletach różnych IDE do Pythona. Wielokrotnie wśród
> różnych "przeciw" znajdowałem: "stosunkowo wolny, ponieważ napisany w
> Pythonie".
>
> Hm... "Wydajność" to szerokie pojęcie -- jakbym umiał zdefiniować to bym
> też umiał zmierzyć. Programowanie znajduje się na peryferiach moich
> zawodowych zainteresowań. Jednakże inżynieria oprogramowanie jest
> dziedziną dość "dysertabilną" -- na pewno ktoś zaproponował jakieś
> zestawy standardowych testów dla oceny wydajności danego języka.
>
> Bawię się w pisanie programu (łatwo i wygodnie w Pythonie), który w
> pewnym fragmencie operuje na dość skomplikowanych strukturach danych.
> Można się umordować bardzo złożonymi wskaźnikami i zrobić misternie to w
> C. Trochę prościej można w C++. W Pythonie kod na złożonych słownikach,
> zbiorach i listach będzie duuużo prostszy. Można też napisać kod w
> Pythonie bardziej subtelny, ale zapewne wydajniejszy -- czy warto?
> Pytanie: czy pisząc program w Pythonie warto dla optymalizacji wykonania
> robić pewne fragmenty w C?
Dla słowników na pewno nie warto. Słowniki to hashtable zaimplementowane
w C, są wyjątkow szybkie. Podobnie rzecz ma się z for itd.
To co działa *bardzo* wolno w Pythonie, to wywołania funkcji i metod.
ATSD, generalna zasada jest taka, że za optymalizacje, to się trzeba
wziąć tylko, jeśli działa za wolno.
bart
--
"kiedy rozum śpi, włącza się automatyczna sekretarka"
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
Bart Ogryczak
Bo takie rzeczy się przerabia na algebrę liniową i używa SciPy/NumPy.
bart
--
"Music?" "Yeah, use Wagner. Scares hell out of gooks, my boys love it"
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
Jacek Popławski
> Pytanie: czy pisząc program w Pythonie warto dla optymalizacji wykonania
> robić pewne fragmenty w C?
Jest trochę fajnych rzeczy, które można przyśpieszyć. Ja piszę coś, co
operuje na grafice złożonej z kilkunastu/kilkudziesięciu tysięcy
odcinków rysowanych w czasie rzeczywistym i działa to w 100% czystym
Pythonie. Zobacz archiwa.
Rob Wolfe
Adam Karpierz napisał(a):
> Uzytkownik "Sulsa" <su...@dontmail.me> napisal:
>
> > nadzieje na eksploracje innych architektur niesie PyPy, ktory dostal
> > niemaly grant od UE, jednak narazie efektow nie
> > widac poza paroma specyficznymi kawalkami kodu gdzie jest nieznacznie
> > szybszy od CPythona.
Efekty sa jak najbardziej.
Chlopaki od zera stworzyli JIT-a. To jest jednak nieco inna zabawa niz
generowanie
bajtkodu dla istniejacej maszyny wirtualnej.
To ze na razie nie moze konkurowac z CPythonem, to nie znaczy ze prace
nie przyniosly zadnych efektow.
> Grant sie skonczyl juz chwile temu.
> Towarzysto w wzielo kase i sie rozjechalo.
> Kilku zapewne zrobi doktorat itp.
> Czyli klasyka !
Nikt sie nie rozjechal. Prace caly czas trwaja. Portowane sa coraz to
nowe
biblioteki: ctypes, pyglet, bittorrent itp. Dodawane sa tez nowe
backendy
do innych maszyn wirtualnych, np. CLI.
Moze i zespol core deweloperow nie jest zbyt duzy (stad moze niezbyt
duze tempo prac), ale postepy sa systematyczne.
Gdyby ten projekt mogl liczyc na takie wsparcie ze strony spolecznosci
jak CPython, to pewnie juz dawno osiagnalby moc produkcyjna.
> Obsmiewalem sposob finansowania/tworzenia PyPy chyba 2 lata temu.
> Sprawdzilo sie w 100%.
> Jak kazde stricte socjalistyczne podejscie :(.
W czym to finansowanie bylo gorsze od finansowania CPythona?
RW
Tomek Paczkowski
> U¿ytkownik "Sulsa" <su...@dontmail.me> napisa³:
>
>> nadzieje na eksploracje innych architektur niesie PyPy, który dosta³
>> niema³y grant od UE, jednak narazie efektów nie
>> widaæ poza paroma specyficznymi kawa³kami kodu gdzie jest nieznacznie
>> szybszy od CPythona.
>
> Grant sie skonczyl juz chwile temu.
> Towarzysto w wzielo kase i sie rozjechalo.
> Kilku zapewne zrobi doktorat itp.
> Czyli klasyka !
>
> Obsmiewalem sposob finansowania/tworzenia PyPy chyba 2 lata temu.
> Sprawdzilo sie w 100%.
> Jak kazde stricte socjalistyczne podejscie :(.
>
> PS: Nadzieje poza glownym Pythonem (3000) niesie glownie
> IronPython pod rzadmi MS-a oraz Jython pod rzadami Suna
> Moze tez Google z GvR z czyms 'wyskocza' ?
> Moze na bazie wlasnie PyPy (zalozenia nie sa zle - np wydajna
> maszyna wirtulna itp)
Przede wszystkim PyPy to projekt badawczy, dlatego finansowanie PyPy
przez UE jest tak samo sensowne, jak finansowanie uniwersyteckich
projektów badawczych. Towarzystwo się nie rozjechało i pewnie przed
zrobieniem magisterek się nie rozjedzie.
To co do tej pory zrobili, to na prawdę świetne i ciekawe rzeczy. Tam
nie ma JITa. Tam jest generator JITów na podstawie interpreterów.
Polecam zapoznanie się z ich stronką.
Pozdrawiam
--
Oinopion
Adam Mikuta
[...]
> gdy sie nie chce to:
>
> 1000. Ozenic sie.
>
> Ten 'sakrament' ustala wlasciwe proporcje
> miedzy praca/ambicjami a ehh... ;)
>
> AK (programista od 30 lat, malzonek 'nieco' krocej:)
Czego nie dałeś rady zoptymalizować? ;)
--
Adam "Prawda jest prosta - gdyby było inaczej
każdy głupiec mógłby ją zrozumieć".
Seweryn Habdank-Wojewódzki
Adam Karpierz wrote:
...
> gdy sie nie chce to:
>
> 1000. Ozenic sie.
>
> Ten 'sakrament' ustala wlasciwe proporcje
> miedzy praca/ambicjami a ehh... ;)
1001 - 100x. Inwestycja we własne dzieciaki umiejące programować (i dla
każdego goto 1.)
Sulsa
Rob Wolfe <r...@smsnet.pl> wrote:
>
> Efekty sa jak najbardziej.
> Chlopaki od zera stworzyli JIT-a. To jest jednak nieco inna zabawa niz
> generowanie
> bajtkodu dla istniejacej maszyny wirtualnej.
> To ze na razie nie moze konkurowac z CPythonem, to nie znaczy ze prace
> nie przyniosly zadnych efektow.
No to ja mam kilka pytań, jakie efekty przynioslo stworzenie PyPy?
> W czym to finansowanie bylo gorsze od finansowania CPythona?
Przez kogo byl finansowany cpython(tylko nie mowcie ze przez google!)
I czemu nie wykorzystać np parrota, ktory podobno ma byc taka super
hiper maszyna wirtualna?
--
Rob Wolfe
Sulsa napisał(a):
> On Mon, 14 Apr 2008 05:55:18 -0700 (PDT)
> Rob Wolfe <r...@smsnet.pl> wrote:
>
> >
> > Efekty sa jak najbardziej.
> > Chlopaki od zera stworzyli JIT-a. To jest jednak nieco inna zabawa niz
> > generowanie
> > bajtkodu dla istniejacej maszyny wirtualnej.
> > To ze na razie nie moze konkurowac z CPythonem, to nie znaczy ze prace
> > nie przyniosly zadnych efektow.
>
> No to ja mam kilka pytan, jakie efekty przynioslo stworzenie PyPy?
1. Mozliwosc kompilacji Pythona (no ok, RPythona) do kodu maszynowego
w locie.
2. Mozliowsc implementacji GC w Pythonie
3. Stworzenie _modularnej_ bazy dla tworzenia interpreterow innych
jezykow dynamicznych.
4. Wykrycie i usuniecie niezliczonej ilosci bugow w wielu pythonowych
bibliotekach (w tym w samym CPythonie).
Poza tym jak juz mowilem PyPy *jest* uzywalny. Portowane sa coraz
to nowe biblioteki i one *dzialaja*. To, ze komus taka platforma jak
PyPy
nie jest potrzebna do szczescia, to moge zrozumiec, ale nie moge
zrozumiec
niedostrzegania wkladu tego projektu w rozwoj Pythona jako takiego.
Pamietam jak pojawily sie wzmianki o tym, ze jest taki projekt jak
Psyco.
Jak zwykle wielu marudzilo: "Co? To sie nie moze udac." Teraz Armin
Rigo
pracuje nad PyPy i znowu musi sluchac tych samych malkontentow.
> > W czym to finansowanie bylo gorsze od finansowania CPythona?
>
> Przez kogo byl finansowany cpython(tylko nie mowcie ze przez google!)
Byl i jest finansowany przez fundacje non-profit PSF. Co oznacza, ze
pieniadze
nie pochodza z dzialalnosci komercyjnej, a z datkow sponsorow.
> I czemu nie wykorzystac np parrota, ktory podobno ma byc taka super
> hiper maszyna wirtualna?
Bo jest napisany w C, a nie w Pythonie?
RW
Bart Ogryczak
> Użytkownik "Sulsa" <su...@dontmail.me> napisał:
>
>> nadzieje na eksploracje innych architektur niesie PyPy, który dostał
>> niemały grant od UE, jednak narazie efektów nie
>> widać poza paroma specyficznymi kawałkami kodu gdzie jest nieznacznie
>> szybszy od CPythona.
>
> Grant sie skonczyl juz chwile temu.
> Towarzysto w wzielo kase i sie rozjechalo.
> Kilku zapewne zrobi doktorat itp.
> Czyli klasyka !
Po pierwsze, jeśli kilku zrobi doktorat, to to jest sukces, bo temu miał
służyć grant *naukowy*[1]. Po drugie nie zauważyłem, żeby się "rozjechali",
PyPy jest nadal rozwijane. To nie jest projekt komercyjny, który miał na
celu stworzenie PyPy Ltd. sprzedający licencje na PyPy pod 10K euro per
site. Pomijam już to, że poziom finansowania to ma taki, że pewnie Sun
to więcej wydaje na kawę dla ludzi pracujących nad Da Vinci Machine.
> Obsmiewalem sposob finansowania/tworzenia PyPy chyba 2 lata temu.
> Sprawdzilo sie w 100%.
> Jak kazde stricte socjalistyczne podejscie :(.
Sprawdziło się, że nie bardzo masz pojęcie o tym, czym są badania naukowe.
No, ale zawsze możesz użyć MS IronPythona, z tego nikt doktoratu nie
zrobił ;-P
[1] STReP - Specific Targeted *Research* Projects.
bart
--
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
Bart Ogryczak
> On Mon, 14 Apr 2008 05:55:18 -0700 (PDT)
> Rob Wolfe <r...@smsnet.pl> wrote:
>
>>
>> Efekty sa jak najbardziej.
>> Chlopaki od zera stworzyli JIT-a. To jest jednak nieco inna zabawa niz
>> generowanie
>> bajtkodu dla istniejacej maszyny wirtualnej.
>> To ze na razie nie moze konkurowac z CPythonem, to nie znaczy ze prace
>> nie przyniosly zadnych efektow.
>
> No to ja mam kilka pytań, jakie efekty przynioslo stworzenie PyPy?
Pokazali co da się z Pythonem zrobić, nawet jeśli PyPy nigdy nie osiągnie
dorosłości jako samodzielny produkt, to na pewno wiele stworzonych przez
nich rozwiązań wcześniej czy później trafi do CPythona i Jythona.
>> W czym to finansowanie bylo gorsze od finansowania CPythona?
>
> Przez kogo byl finansowany cpython(tylko nie mowcie ze przez google!)
Pierwsza wersja, to przez holenderski Narodowy Instytyt Rozwoju
Matematyki i Informatyki, czyli jakby powiedział Adam Karpierz,
czysty socjalizm! ;-)
bart
--
Ten się śmieje ostatni, kto myśli najwolniej.
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
Lewy
> On 2008-04-15, citizen Sulsa testified:
>> On Mon, 14 Apr 2008 05:55:18 -0700 (PDT)
>> Rob Wolfe <r...@smsnet.pl> wrote:
>>
>>> Efekty sa jak najbardziej.
>>> Chlopaki od zera stworzyli JIT-a. To jest jednak nieco inna zabawa niz
>>> generowanie
>>> bajtkodu dla istniejacej maszyny wirtualnej.
>>> To ze na razie nie moze konkurowac z CPythonem, to nie znaczy ze prace
>>> nie przyniosly zadnych efektow.
>> No to ja mam kilka pytań, jakie efekty przynioslo stworzenie PyPy?
>
> Pokazali co da się z Pythonem zrobić, nawet jeśli PyPy nigdy nie osiągnie
> dorosłości jako samodzielny produkt, to na pewno wiele stworzonych przez
> nich rozwiązań wcześniej czy później trafi do CPythona i Jythona.
>
>>> W czym to finansowanie bylo gorsze od finansowania CPythona?
>> Przez kogo byl finansowany cpython(tylko nie mowcie ze przez google!)
>
> Pierwsza wersja, to przez holenderski Narodowy Instytyt Rozwoju
> Matematyki i Informatyki, czyli jakby powiedział Adam Karpierz,
> czysty socjalizm! ;-)
>
> bart
Jeśli ktoś łączy wydajność i holenderskie instytuty to od razu
przychodzi mi na myśl jeden link:
http://monetdb.cwi.nl/
Polecam potestować wydajność tego monstrum :]
Paweł
Sulsa
Rob Wolfe <r...@smsnet.pl> wrote:
> Bo jest napisany w C, a nie w Pythonie?
Co za różnica jeśli pozowli zaimplementować lepszą maszynę wirtualną
pythona?
Rob Wolfe
Sulsa napisał(a):
> On Tue, 15 Apr 2008 23:47:26 -0700 (PDT)
> Rob Wolfe <r...@smsnet.pl> wrote:
>
> > Bo jest napisany w C, a nie w Pythonie?
>
> Co za ronica jesli pozowli zaimplementowac lepsza maszyne wirtualna
> pythona?
Idea projektu PyPy bylo zaimplementowanie maszyny wirtualnej
w jezyku _wysokiego_ poziomu. Pomysl ten pojawil sie nie przypadkowo.
Majac taka implementacja mozna w duzo latwiejszy sposob
eksperymentowac z nowymi rozwiazaniami i generalnie rozwijac
taki soft.
Przykladowo trudno mi sobie wyobrazic, aby kiedykolwiek w CPythonie
doszlo do zmiany GC opartego na zliczaniu referencji. W PyPy
GC jest jednym z klockow, ktory mozna wymieniac. Mozna probowac
roznych rozwiazan i o to w tym wszystkim chodzilo.
Poza tym rozwijanie CPythona staje sie coraz trudniejsze ze wzgledu
na zlozonosc roznych optymalizacji. Gdyby nie bylo GIL-a ta zlozonosc
wzroslaby jeszcze bardziej, co jest jedna z przyczyn dla ktorych GIL
tez pewnie nigdy nie zostanie usuniety.
RW
Sulsa
Teraz rozumiem, jednak powinienes wiedziec ze C *jest* jezykiem
wysokiego poziomu.
--
Rob Wolfe
> Teraz rozumiem, jednak powinienes wiedziec ze C *jest* jezykiem
> wysokiego poziomu.
W latach 70-tych poprzedniego stulecia miałbyś rację, ale niestety
od tamtego czasu kilka drobiazgów uległo zmianie.
http://en.wikipedia.org/wiki/High-level_programming_language
RW
Bart Ogryczak
C++ jest językiem wysokiego poziomu. Co do C to nie jest takie
znów oczywiste.
http://en.wikipedia.org/wiki/High-level_programming_language#Relative_meaning
bart
--
"Panowie, żarty się skończyły!" (c) JMD
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
Adam Karpierz
> Teraz rozumiem, jednak powinienes wiedziec ze C *jest* jezykiem
> wysokiego poziomu.
Ty powinienes raczej wiedziec ze C to jezyk niskiego poziomu.
To zaledwie nieco wiecej niz assembler.
AK
Adam Karpierz
> W latach 70-tych poprzedniego stulecia mialbys racje, ale niestety
> od tamtego czasu kilka drobiazgów uleglo zmianie.
Nieprawda.
Tez nie mialby racji.
Powiem wiecej. Mialby mniej racji niz dzisiaj.
To slabiutkie PC-ty 'wywindowaly' rownie slabiutkie C.
AK
Adam Karpierz
> C++ jest językiem wysokiego poziomu. Co do C to nie jest takie
> znów oczywiste.
C++ _tez nie jest _ jezykiem wysokiego poziomu.
Nie dorownuje w wysokosci poziomu nawet Simuli z 67 roku,
ze o jakichs Smalltalkach, Prologach, Eifflach czy nawet Pythonach
nie wspomne.
AK
Seweryn Habdank-Wojewódzki
Adam Karpierz wrote:
> C++ _tez nie jest _ jezykiem wysokiego poziomu.
A jakiś dowód, najlepiej matematyczny (logiczny), tego faktu, może by się
pojawił, co?
Czy znowu jakaś forma frustracji dokucza niczym reumatyzm?
Sulsa
Wiecie jakby spojrzez z perspektywy programisty SQL to python tez jest
jezykiem niskiego poziomu, punkt widzenia zalezy od punktu siedzenia.
Grzegorz Staniak
>> > Teraz rozumiem, jednak powinienes wiedziec ze C *jest* jezykiem
>> > wysokiego poziomu.
>>
>> W latach 70-tych poprzedniego stulecia miałbyś rację, ale niestety
>> od tamtego czasu kilka drobiazgów uległo zmianie.
>>
>> http://en.wikipedia.org/wiki/High-level_programming_language
>>
> Wiecie jakby spojrzez z perspektywy programisty SQL to python tez jest
> jezykiem niskiego poziomu, punkt widzenia zalezy od punktu siedzenia.
Ale określenie "przenośny asembler" nie jest wynalazkiem XXI wieku.
GS
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Bart Ogryczak
> "Bart Ogryczak" <B.Ogr...@addr.in.reply-to.invalid> wrote:
>
>> C++ jest językiem wysokiego poziomu. Co do C to nie jest takie
>> znów oczywiste.
>
> C++ _tez nie jest _ jezykiem wysokiego poziomu.
Oczywiście, że jest. Nie ma żadnego ręcznego zarządzania pamięcią,
operacji artymetycznych na wskaźnikach ani żadnych innych tego
typu wynalazków rodem z asemblera.
bart
--
"PLEASE DO *NOT* EDIT or poldek will hate you." - packages.dir (PLD)
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
Artur M. Piwko
Bart Ogryczak <B.Ogr...@addr.in.reply-to.invalid> screamed:
>>> C++ jest językiem wysokiego poziomu. Co do C to nie jest takie
>>> znów oczywiste.
>>
>> C++ _tez nie jest _ jezykiem wysokiego poziomu.
>
> Oczywiście, że jest. Nie ma żadnego ręcznego zarządzania pamięcią,
> operacji artymetycznych na wskaźnikach ani żadnych innych tego
> typu wynalazków rodem z asemblera.
>
char * p = 0;
p++;
--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:216B ]
[ 10:41:11 user up 11680 days, 22:36, 1 user, load average: 0.05, 0.89, 0.31 ]
The shortest bedtime story: No.
Seweryn Habdank-Wojewódzki
Artur M. Piwko wrote:
> char * p = 0;
> p++;
Ale ciekawie jest tu:
double * d = NULL;
d++;
O ile bajtów pamięci przesunie się p, a o ile d?
Jeśli o tyle samo to faktycznie mamy niski poziom, jesli nie, to ...
zbliżamy się do pojęcia iteratora, który do niskopoziomowych nie należy.
Bart Ogryczak
> In the darkest hour on Thu, 17 Apr 2008 08:17:32 +0000 (UTC),
> Bart Ogryczak <B.Ogr...@addr.in.reply-to.invalid> screamed:
>>>> C++ jest językiem wysokiego poziomu. Co do C to nie jest takie
>>>> znów oczywiste.
>>>
>>> C++ _tez nie jest _ jezykiem wysokiego poziomu.
>>
>> Oczywiście, że jest. Nie ma żadnego ręcznego zarządzania pamięcią,
>> operacji artymetycznych na wskaźnikach ani żadnych innych tego
>> typu wynalazków rodem z asemblera.
>>
>
> char * p = 0;
> p++;
To jest C, nie C++. W C++ to nie char* tylko klasa String.
bart
--
"Security issues are not discussed in this memo, but then again, no
other issues of any importance are discussed in this memo either." [RFC1438]
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
Adam Karpierz
> O ile bajtów pamięci przesunie się p, a o ile d?
>
> Jeśli o tyle samo to faktycznie mamy niski poziom, jesli nie, to ...
> zbliżamy się do pojęcia iteratora, który do niskopoziomowych nie należy.
Panie Wojewodzki
Co to za 'iterator' ktory nie wie.. kiedy skonczyc :)
Niech Pan raczy nie zartowac z wysokopoziomowoscia C++
bo to temat oklepany i z C++trupa nie zrobi Pan nowozenca.
AK
Adam Karpierz
>> char * p = 0;
>> p++;
>
> To jest C, nie C++. W C++ to nie char* tylko klasa String.
Panie Bart
Niech Pan sobie wezmie raport _C++_ i poczyta.
AK
Sulsa
"Adam Karpierz" <karpierz@_NOSPAM_python.pl> wrote:
> Co to za 'iterator' ktory nie wie.. kiedy skonczyc :)
> Niech Pan raczy nie zartowac z wysokopoziomowoscia C++
> bo to temat oklepany i z C++trupa nie zrobi Pan nowozenca.
>
Lepiej popatrz ile programow jest pisanych w tym trupie zanim objawisz
nam swe swiete prawdy.
Artur M. Piwko
Seweryn Habdank-Wojewódzki <shw_...@wp.pl> screamed:
>> char * p = 0;
>> p++;
>
> Ale ciekawie jest tu:
>
> double * d = NULL;
> d++;
>
> O ile bajtów pamięci przesunie się p, a o ile d?
>
p o sizeof(char), d o sizeof(double), co akurat w przypadku tych
dwóch typów da ściśle określoną ilość bajtów.
> Jeśli o tyle samo to faktycznie mamy niski poziom, jesli nie, to ...
> zbliżamy się do pojęcia iteratora, który do niskopoziomowych nie należy.
>
Prawie jak iterator. ;)
--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:227B ]
[ 15:52:07 user up 11680 days, 3:47, 1 user, load average: 0.05, 0.89, 0.31 ]
Wszyscy chcą iść do nieba, ale nikt nie chce umierać.
Artur M. Piwko
Bart Ogryczak <B.Ogr...@addr.in.reply-to.invalid> screamed:
>> char * p = 0;
>> p++;
>
> To jest C, nie C++. W C++ to nie char* tylko klasa String.
>
double foo[] = {1.0, 2.0};
double * bar = foo;
bar++;
Teraz jak rozumiem mam przejść na referencje,
bo wyłuskiwanie jest z C nie z C++? ;)
--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:211B ]
[ 15:53:56 user up 11680 days, 3:48, 1 user, load average: 0.05, 0.89, 0.31 ]
Co by tu napisać? ;^)
Adam Karpierz
> Lepiej popatrz ile programow jest pisanych w tym trupie zanim
> objawisz nam swe swiete prawdy.
Lepiej sie naucz myslec o czym dyskutujesz.
Mowa byla o _niskopoziomowosci_ C/C++ a nie
o ilosci programow w nich napisanych.
AK
Sulsa
Lepiej naucz sie czytac wlasnie wypowiedzi zanim przejdziesz do
dyskusji, nazwales c++ trupem, rozumiem ze trupem jest jezyk, w ktorym
sie nie pisze badz pisze nie wiele, a jednak c++ jest szeroko
wykorzystywanym jezykiem.
Bart Ogryczak
Jako żywo w specyfikacji C++ widzę, że używa się std::string, a nie char*.
To, że C++ pozwala używać pewnych konstrukcji z C, to nie znaczy, że jest
to właściwy styl pisania w C++.
bart
--
"This is an information document and does not specify any level of standard."
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
Seweryn Habdank-Wojewódzki
Adam Karpierz wrote:
> Panie Wojewodzki
>
> Co to za 'iterator' ktory nie wie.. kiedy skonczyc :)
Bezstanowy?
> Niech Pan raczy nie zartowac z wysokopoziomowoscia C++
> bo to temat oklepany i z C++trupa nie zrobi Pan nowozenca.
Panie Karpierz, dowodzik logiczny poproszę, bo tego faktu nie widzę.
Wie Pan znajomi spece od Prologa śmieją się ze wszystkich "wysoko
poziomopwych" języków więc idąc za ich wnioskowaniem musiałbym pisać
*tylko* w Prologu.
Seweryn Habdank-Wojewódzki
Artur M. Piwko wrote:
> p o sizeof(char), d o sizeof(double), co akurat w przypadku tych
> dwóch typów da ściśle określoną ilość bajtów.
Bo to akurat było z C. To samo wzięte w prawdziwym C++ np. w kontekście:
std::list<MyObject>::iterator p = mylist.begi();
p++;
Już nie jest tak bardzo określone :-).
>> Jeśli o tyle samo to faktycznie mamy niski poziom, jesli nie, to ...
>> zbliżamy się do pojęcia iteratora, który do niskopoziomowych nie należy.
>>
>
> Prawie jak iterator. ;)
Wskaźnik jest prawzorcem (protowzorcem) iteratora, dlatego słusznie jest
prawie jak iterator.
Adam Karpierz
> Jako żywo w specyfikacji C++ widzę, że używa się std::string, a nie char*.
> To, że C++ pozwala używać pewnych konstrukcji z C, to nie znaczy, że jest
> to wła¶ciwy styl pisania w C++.
Panie Bart
_Raport_ ! Prosze wziac raport i pokazac mi gdzie pisze ze nalezy
uzywac std::string a char * nie wolno ?.
char * mozna by od biedy przebolec, ale ptr++ to juz nie.
Natomiast uzywania char * nie uswiadczy Pan w takich
jezykach ja;: Algol, Simula, Eiffel, Prolog, Modula, Java, C# (oprocz
specjalnie wydzielonej strefy zwanej wyraznie 'unsafe'), Python, Lisp,
VB itp itd. Czyli w wiekszosci jezykow.
Prosze wiec nie wmawiac mi o wysokopoziomowosci C++ bo
pisze w nim juz 20 lat , a zanim w nim pisalem pisalem w innych
jezykach, wiec mnie Pan nie przekona.
Prosze natomiast nie wprowadzac innych w blad w sensie
'wysokopoziomowosci' C++.
Mowiac o 'wysokopoziomowosci' zaprzecza Pan samemu jego
tworcy czyli Bjarne Stoustrupowi.
AK
Adam Karpierz
>> Co to za 'iterator' ktory nie wie.. kiedy skonczyc :)
>
> Bezstanowy?
Bezsensowny po prostu.
>> Niech Pan raczy nie zartowac z wysokopoziomowoscia C++
>> bo to temat oklepany i z C++trupa nie zrobi Pan nowozenca.
>
> Panie Karpierz, dowodzik logiczny poproszę, bo tego faktu nie widzę.
Jelsi Pan do tego czasu nie wie co to sa jezyki wysokopoziomowe a co
to ustruktarylizowane assemblery typu C czy C++ to ja Pan uczyc
nie zamierzam.
Polecam literature ("Informatyka" z lat 80 nawet jelsi z ksiazkami ciezko)
> Wie Pan znajomi spece od Prologa śmieją się ze wszystkich "wysoko
> poziomopwych" języków więc idąc za ich wnioskowaniem musiałbym pisać
> *tylko* w Prologu.
Otoz nie Panie Wojewodzki.
Prolog jest naprawde wysokopoziomowy w jednym z paradygmatow
programowania natomiast w innych jest 'normalny' a nawet kiepski wiec
prosze nie gloryfikowac Prologu ponad miare.
AK
Wit Jakuczun
"Adam Karpierz" <karpierz@_NOSPAM_python.pl> napisał(a):
> > Wie Pan znajomi spece od Prologa śmieją się ze wszystkich "wysoko
> > poziomopwych" języków więc idąc za ich wnioskowaniem musiałbym pisać
> > *tylko* w Prologu.
>
> Otoz nie Panie Wojewodzki.
> Prolog jest naprawde wysokopoziomowy w jednym z paradygmatow
> programowania natomiast w innych jest 'normalny' a nawet kiepski wiec
> prosze nie gloryfikowac Prologu ponad miare.
>
Eeee tam. W prologu można wszystko i GUI i HTTP server i... ;)
Pozdrawiam
--
[ Wit Jakuczun <W.Jakuczun [at] wlogsolutions.com> ]
[ WLOG Solutions http://www.wlogsolutions.com ]
Seweryn Habdank-Wojewódzki
Adam Karpierz wrote:
>>> Co to za 'iterator' ktory nie wie.. kiedy skonczyc :)
>>
>> Bezstanowy?
>
> Bezsensowny po prostu.
To zależy od kontekstu. W szczególności, kiedy ma pracować na nieskończonym
kontenerze, to może być nieskończony.
>>> Niech Pan raczy nie zartowac z wysokopoziomowoscia C++
>>> bo to temat oklepany i z C++trupa nie zrobi Pan nowozenca.
>>
>> Panie Karpierz, dowodzik logiczny poproszę, bo tego faktu nie widzę.
>
> Jelsi Pan do tego czasu nie wie co to sa jezyki wysokopoziomowe a co
> to ustruktarylizowane assemblery typu C czy C++ to ja Pan uczyc
> nie zamierzam.
Pan mnie nie musi uczyć. Kłopot polega na tym, że Pan sam definicji nie
potrafi podać. Najpierw Pan pisze że w latach 70 C był wysokopoziomowy,
teraz każe mi Pan czytać literaturę z lat 80, czy z niej nie dowiem się
tego samego?
> Polecam literature ("Informatyka" z lat 80 nawet jelsi z ksiazkami ciezko)
Rozumiem, że Pan nie potrafi podać definicji.
>> Wie Pan znajomi spece od Prologa śmieją się ze wszystkich "wysoko
>> poziomopwych" języków więc idąc za ich wnioskowaniem musiałbym pisać
>> *tylko* w Prologu.
>
> Otoz nie Panie Wojewodzki.
> Prolog jest naprawde wysokopoziomowy w jednym z paradygmatow
Super. W jakim?
> programowania natomiast w innych jest 'normalny' a nawet kiepski wiec
> prosze nie gloryfikowac Prologu ponad miare.
Zatem jest wysokopoziomowy czy nie? Jeśli nie, to czy określenie
wysokopozimowości związane jest z jakąś hiperprzestrzenią cech języka, to
proszę podać te cechy w sposób ścisły i dyskusja zacznie być ciekawa.
Póki co jest jałowa, bo nie padają żadne konkrety.
SQL też jest podobno wysokopoziomowy, a predyktory w nim się pisze tak
paskudnie, że czuję jakby gdzieś "wysokipoziom" się schował i drwił z
koderów. A może nie jest wysokopoziomowy?
A Haskell jest wysokopoziomowy czy nie?
Seweryn Habdank-Wojewódzki
Adam Karpierz wrote:
> Natomiast uzywania char * nie uswiadczy Pan w takich
> jezykach ja;: Algol, Simula, Eiffel, Prolog, Modula, Java, C# (oprocz
> specjalnie wydzielonej strefy zwanej wyraznie 'unsafe'), Python, Lisp,
> VB itp itd. Czyli w wiekszosci jezykow.
A co to ma do wysokiego czy niskiego poziomu?
char * to jest wskaźnik na zmienną typu char.
Bardzo abstrakcyjne pojęcie.
> Prosze wiec nie wmawiac mi o wysokopoziomowosci C++
Ależ nikt nie wmawia. Wszyscy pytają o definicję. Bo póki co jest to
definicja A.K:
Jeżyk wysokopoziomowy to takie, który nie jest C lub C++.
> bo pisze w nim juz 20 lat
A ja 13 i co z tego?
> , a zanim w nim pisalem pisalem w innych jezykach, wiec mnie Pan nie
> przekona.
Panie Karpierz. Do czego mamy Pana przekonywać? Definicji Pan podać nie
potrafi, a innych do książek odsyła, toż to przecież antyprzykład.
> Prosze natomiast nie wprowadzac innych w blad w sensie
> 'wysokopoziomowosci' C++.
Właśnie Pan to robi. Potem na sieci będą krążyć opinie:
"Język P nie jest wysokopoziomowy ..., bo Pan Karpierz tak rzekł."
> Mowiac o 'wysokopoziomowosci' zaprzecza Pan samemu jego
> tworcy czyli Bjarne Stoustrupowi.
Czyli? Twórca ma dużo do powiedzenia, ale aktualnie nie jest jedynym twórcą,
więc jego dawne opinie mogą być nie są całkiem aktualne.
Proszę swojej frustracji nie rozsiewać na innych użytkowników języków
programowania. I to nie chodzi o sam C++, po prostu Pana definicja
wysokopoziomowości jest mętna i póki co sprowadza się do wyliczania Pana
ulubionych języków. W szczególności czy Smalltalk jest wysokopoziomowy? I
dlaczego VB miałby pretendować do bycia wysokopoziomowym, czym jest lepszy
np. od Object Pascala?
Piotr Sawicki
> Adam Karpierz wrote:
>
>> Natomiast uzywania char * nie uswiadczy Pan w takich
>> jezykach ja;: Algol, Simula, Eiffel, Prolog, Modula, Java, C# (oprocz
>> specjalnie wydzielonej strefy zwanej wyraznie 'unsafe'), Python, Lisp,
>> VB itp itd. Czyli w wiekszosci jezykow.
>
> A co to ma do wysokiego czy niskiego poziomu?
>
> char * to jest wskaźnik na zmienną typu char.
>
> Bardzo abstrakcyjne pojęcie.
No przecież char* to tak naprawdę adres komórki pamięci.
Pojęcie na poziomie abstrakcji kodu maszynowego.
>> Prosze wiec nie wmawiac mi o wysokopoziomowosci C++
>
> Ależ nikt nie wmawia. Wszyscy pytają o definicję.
> Bo póki co jest to definicja A.K:
>
> Jeżyk wysokopoziomowy to takie, który nie jest C lub C++.
No dobra, pojęcie nie jest ścisłe: nawet jak ktoś się
pokusi o arbitralne sformułowanie konkretnej definicji,
to choćby był, ho ho, Autorem Książki - to zawsze znajdzie
się język na podstawie którego będzie można wykazać
bezużyteczność definicji. W sumie podobnie jest np.
z pojęciem inteligencji, ale to nie znaczy przecież
że nie da się z grubsza zarysować sensu. No więc moim
zdaniem, wysokopoziomowość języka oznacza możliwość
przetwarzania nie tylko danych, ale również programu
- oczywiście poprzez mechanizmy języka, a nie dłubaniem
w pamięci czy ręcznym implementowaniem kompilatora.
Języki mają to w różnym stopniu: w Lispie można z kodem
zrobić wszysto, w innych językach funkcyjnych można w biegu
definiować funkcje, przekazywać je i stosować częściową
ewaluację, w Algolu jest call by name, niektóre języki
obiektowe mają refleksję. W takim sensie C ma wyłącznie
parametryzowanie statycznych procedur danymi. C++ jest
teoretycznie bogatsze o templaty, ale... wiadomo.
> W szczególności czy Smalltalk jest wysokopoziomowy?
> I dlaczego VB miałby pretendować do bycia wysokopoziomowym,
> czym jest lepszy np. od Object Pascala?
VB nie tykam nawet kijem, ale IMHO Smalltalk wysokopoziomowy
jest: klasa bloków kodu, metaklasy, perform, doesNotUnderstand.
Piotr Sawicki
Seweryn Habdank-Wojewódzki
Piotr Sawicki wrote:
>> char * to jest wska�nik na zmienn� typu char.
>>
>> Bardzo abstrakcyjne poj�cie.
>
> No przecie� char* to tak naprawd� adres kom�rki pami�ci.
> Poj�cie na poziomie abstrakcji kodu maszynowego.
x = 10
Czym jest x jak nie adresem w pami�ci? Mo�e jest spinem elektronu w 12*10^7
atomie wodoru z 100 l wody?
> No dobra, poj�cie nie jest �cis�e:
Nie �cis�e? Nie widz� �adnego.
> No wi�c moim
> zdaniem, wysokopoziomowo�� j�zyka oznacza mo�liwo��
> przetwarzania nie tylko danych, ale r�wnie� programu
> - oczywi�cie poprzez mechanizmy j�zyka, a nie d�ubaniem
> w pami�ci czy r�cznym implementowaniem kompilatora.
> J�zyki maj� to w r�nym stopniu: w Lispie mo�na z kodem
> zrobi� wszysto, w innych j�zykach funkcyjnych mo�na w biegu
> definiowa� funkcje, przekazywa� je i stosowa� cz�ciow�
> ewaluacj�, w Algolu jest call by name, niekt�re j�zyki
> obiektowe majďż˝ refleksjďż˝.
Haskell odpada i wszystkie kompilowane j�zyki r�wnie� razem z nim.
Natomiast nagle bardzo wysokopoziomowy staje sie Lua i TCL, a co ciekawe
Bash r�wnie�. Zatem mo�e zaczniemy wypunktowywa� cechy j�zyka wysobiego
poziomu?
BTW nie widzďż˝ aby SQL miaďż˝ te ficzery, a podobno jest wysokiego poziomu.
> W takim sensie C ma wy��cznie
> parametryzowanie statycznych procedur danymi. C++ jest
> teoretycznie bogatsze o templaty, ale... wiadomo.
Co wiadomo? P�ki co poda�e� definicj� na tyle lakoniczn�, �e bardzo du�o
j�zyk�w jest wysokopoziomowych nie bardzo wiadomo czemu (Bash), a Haskell
odpadďż˝, bo ma kompilator.
>> W szczeg�lno�ci czy Smalltalk jest wysokopoziomowy?
>> I dlaczego VB mia�by pretendowa� do bycia wysokopoziomowym,
>> czym jest lepszy np. od Object Pascala?
>
> VB nie tykam nawet kijem, ale IMHO Smalltalk wysokopoziomowy
> jest: klasa blok�w kodu, metaklasy, perform, doesNotUnderstand.
VB Pan Karpierz poda� w swojej li�cie idea��w. Zatem czy jest
wysokopoziomowy czy nie?
Pozdrawiam.
--
|\/\/| Seweryn Habdank-Wojew�dzki
Piotr Sawicki
>
>>> char * to jest wskaźnik na zmienną typu char.
>>>
>>> Bardzo abstrakcyjne pojęcie.
>>
>> No przecież char* to tak naprawdę adres komórki pamięci.
>
> x = 10
>
> Czym jest x jak nie adresem w pamięci?
W pythonie nie jest. A w języku kompilowanym może być miejscem w ramce
aktywacji na stosie (ok, to też jest gdzieś w pamięci, ale w zależności
od platformy może być odseparowane od segmentu danych lub pod nieznanym
adresem), może być też przez optymalizator przekształcone w stałą albo
w ogóle nie pamiętane - jeśli to nie jest zmienna żywa w danym bloku.
W drugą stronę te argumenty się nie stosują, bo chodziło mi o to,
że _wartość_ zmiennej typu char* to po prostu adres (a nie żadne
bardzo abstrakcyjne pojęcie). Tu wartością zmiennej x jest zwykły
integer - też nie twierdzę jakoby był to wysoki poziom abstrakcji.
> Może jest spinem elektronu w 12*10^7 atomie wodoru z 100 l wody?
Zależnie od poziomu analizy: jest leksemem identyfikator,
lub elementem przestrzeni nazw.
>> w Lispie można z kodem zrobić wszysto, w innych językach
>> funkcyjnych można w biegu definiować funkcje, przekazywać
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> je i stosować częściową ewaluację, w Algolu jest call by
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> name, niektóre języki obiektowe mają refleksję.
>
> Haskell odpada
Jak najbardziej posiada funkcje wyższych rzędów definiowane w locie.
> i wszystkie kompilowane języki również razem z nim.
To już zabrali kompilatory do Lispa, Algola i SML-a?
> Natomiast nagle bardzo wysokopoziomowy staje sie Lua i TCL,
> a co ciekawe Bash również.
Jakie cechy tych języków masz na myśli? BTW nie wiem czemu basha
traktujesz jako kuriozum, ten język ma bardzo ciekawe featury
funkcyjne, tyle że wygodny jest tylko w wąskiej dziedzinie zastosowań.
> Zatem może zaczniemy wypunktowywać cechy
> języka wysobiego poziomu?
Ja swoje propozycje wyliczyłem, ciekaw jestem Twoich.
> BTW nie widzę aby SQL miał te ficzery, a podobno jest wysokiego poziomu.
OK, miałem dopisać zastrzeżenie a w końcu zapomniałem (i tak posting
był długi i nudny): to kryterium dotyczyło jedynie języków imperatywnych.
>> C++ jest teoretycznie bogatsze o templaty, ale... wiadomo.
>
> Co wiadomo?
Że templaty w C++ są do bani z wielu powodów. W szczególności
nie umywają się do polimorfizmu z haskella/ocamla/smla.
> Póki co podałeś definicję na tyle lakoniczną,
Jakbym podawał definicję, to bym nie załączał przydługiego
disclaimera, że nie wierzę w możliwość podania definicji.
> VB Pan Karpierz podał w swojej liście ideałów.
> Zatem czy jest wysokopoziomowy czy nie?
Z bejzików znam tylko Atari Basic - nie jest wysokopoziomowy.
Piotr Sawicki
Seweryn Habdank-Wojewódzki
Piotr Sawicki wrote:
>> x = 10
>>
>> Czym jest x jak nie adresem w pamięci?
>
> W pythonie nie jest.
>
> A w języku kompilowanym
x::Int = 10
Jezyk kompilowany nic do tego nie ma.
> może być miejscem w ramce
> aktywacji na stosie (ok, to też jest gdzieś w pamięci, ale w zależności
> od platformy może być odseparowane od segmentu danych lub pod nieznanym
> adresem), może być też przez optymalizator przekształcone w stałą albo
> w ogóle nie pamiętane - jeśli to nie jest zmienna żywa w danym bloku.
A w C? Nie wiesz jaki to segment, jaki offset, która strona, czy zmienna
jest w cache, czy nie.
>> Haskell odpada
>
> Jak najbardziej posiada funkcje wyższych rzędów definiowane w locie.
Wymaga kompilacji. Nic "w biegu" nie zdefiniujesz.
>> i wszystkie kompilowane języki również razem z nim.
>
> To już zabrali kompilatory do Lispa, Algola i SML-a?
To nie ja sugeruję, że języki kompilowane nie są wysokopoziomowe.
>> Natomiast nagle bardzo wysokopoziomowy staje sie Lua i TCL,
>> a co ciekawe Bash również.
>
> Jakie cechy tych języków masz na myśli?
Generacja czegokolwiek "w biegu". Zreszta to nie jest moja klasyfikacja.
> BTW nie wiem czemu basha
> traktujesz jako kuriozum, ten język ma bardzo ciekawe featury
> funkcyjne, tyle że wygodny jest tylko w wąskiej dziedzinie zastosowań.
Nic do niego nie mam, po prostu jakby nagle nabył wysokości poziomu.
>> Zatem może zaczniemy wypunktowywać cechy
>> języka wysobiego poziomu?
>
> Ja swoje propozycje wyliczyłem, ciekaw jestem Twoich.
Przykładowa cecha to łatwość zamiany abstrakcji matematycznej na kod.
Przykład z C++:
Mass m = 10 * kilo();
Acceleration a = 9.81;
Force f = m * a;
// Force f = m / a; // kompilator rzuca błędem,
// bo język pozwala w czasie kompilacji sprawdzić,
// czy zgadzają się jednostki SI.
Kiedy pisze programy związane z fizyką takie cos jest mega ficzerem.
Nie mam dokładnego opisu co jest językiem niskiego, czy wysokiego poziomu,
bo IMHO to jest o tyle bez sensu o ile każdy język w swojej domenie bedzie
wysokopoziomowym a nie w swojej domenie bedzie niskopoziomowym.
Natomiast nie posługuję sie kategorycznymi okresleniami, że któryś język
jest lub nie jest wysokopoziomowy.
Jak już pisałem np. pisanie algorytmów dataminingowych w SQL jest fatalne,
chociaż nic nie ma bardziej zwięzłego niż "select * from mytable".
>> BTW nie widzę aby SQL miał te ficzery, a podobno jest wysokiego poziomu.
>
> OK, miałem dopisać zastrzeżenie a w końcu zapomniałem (i tak posting
> był długi i nudny): to kryterium dotyczyło jedynie języków imperatywnych.
A co to ma do rzeczy imperatywny czy nie?
Haskell jest funkcyjny, ale ma też możliwość pisania imperatywnego, czy to
obniża jego poziom? BTW algorytmy sekwensynje zapisane w Haskellu sa
bardziej niskopoziomowe inż w kazdym imperatwnym języku.
>>> C++ jest teoretycznie bogatsze o templaty, ale... wiadomo.
>>
>> Co wiadomo?
>
> Że templaty w C++ są do bani z wielu powodów.
Tak? A co dokładnie i jaki to ma wpływ na wysokość poziomu języka?
> W szczególności
> nie umywają się do polimorfizmu z haskella/ocamla/smla.
Bzdura. Te języki poprostu są funkcyjne i w swojej klasie wyglądają
elegancko.
Pseudo-kod przykładowego metaprogramiku szablonowego wygląda tak:
class < IF < isIntergral <Type>, IntegralPower, RealPower > > MatrixPower;
Klasa w zalezności od typu wybiera specjalizację potegowania i ją umieszcza
w kompilacie. Pomyśl sobie masz bibliotekę do obliczeń na macierzach i
podnosisz macierze do potęgi. Jeśli potęga jest całkowita stoujesz
określony dedykowany ze względu na prędkość algorytm, jesli jest potęga
rzeczywista, to stosujesz inny algorytm. Jak myślisz ile języków ta decyzje
potrafi podjąc w czasie kompilacji? I jaki to ma wpływ na wydajność?
Zrób to w Haskellu -- tak aby na poziomie kompilacji potrafił dopasować
procedurę do typu.
> Jakbym podawał definicję, to bym nie załączał przydługiego
> disclaimera, że nie wierzę w możliwość podania definicji.
No więc jeśli nie ma definicji, to nie można kategorycznie stwierdzić który
język jest wysokopoziomowy, a który nie. A Pan Karpierz ot tak sobie rzuca
jakieś okreslenia bez pokrycia.
W prawdziwym lispie pętla for jest paskudna. Czy to oznacza, że jest
niskopoziomowy? Bo z punktu widzenia pętli for jest.
Dla mnie prawdziwy lisp jest tak samo "niskopozimowy" jak dla wielu C, bo
algorytmy dataminingowe pisze się w nim paskudnie -- rzadko kiedy istnieją
ich wersje rekurencyjne i za każdym razem by coś napisać w lispie trzeba
byłoby przerabiac procedurę z wersji normalnej na "lispowego" fora.
W szczególności to ``elegancko'' wygląda kiedy pracuje sie na grafach nie
bedących drzewami.
Pozdrawiam.
--
|\/\/| Seweryn Habdank-Wojewódzki
Sulsa
Piotr Sawicki <ps17...@students.mimuw.edu.pl> wrote:
> W drugą stronę te argumenty się nie stosują, bo chodziło mi o to,
> że _wartość_ zmiennej typu char* to po prostu adres (a nie żadne
> bardzo abstrakcyjne pojęcie). Tu wartością zmiennej x jest zwykły
> integer - też nie twierdzę jakoby był to wysoki poziom abstrakcji.
Brawo! referencje w pythonie tez przetrzymuja adres w pamieci, wiec
python jak najbardziej jest jezykiem niskiego poziomu!
Ktos na grupe pl.comp.lang.c utryzmywal ze definicja standardu c +
+ pozwala aby pamiec adresowana byla nawet stringami, czy takie
adresowanie jest dla ciebie "niskopoziomowe" bo jak dla mnie jest
bardziej wysokopoziomowe niz adres w pamieci(tak jak to ma miejsce w
pythonie).
--
Piotr Sawicki
>
>> _wartość_ zmiennej typu char* to po prostu adres (a nie żadne
>> bardzo abstrakcyjne pojęcie). Tu wartością zmiennej x jest zwykły
>> integer - też nie twierdzę jakoby był to wysoki poziom abstrakcji.
>
> Brawo! referencje w pythonie tez przetrzymuja adres w pamieci,
To rzeczywiście odkrywcze, że odwzorowanie przestrzeni nazw
na miejsca w pamięci da się zrealizować prostym mapowaniem,
i gdzieś adresy będą w końcu zapisane. To jednak kwestia
implementacyjna schowana w silniku, w C wskaźnik jest
dostępny na wierzchu jako liczba jak każda inna.
> wiec python jak najbardziej jest jezykiem niskiego poziomu!
Na podstawie jakiego/czyjego znaczenia wysokopoziomowości wnioskujesz?
> Ktos na grupe pl.comp.lang.c utryzmywal ze definicja standardu c +
> + pozwala aby pamiec adresowana byla nawet stringami, czy takie
> adresowanie jest dla ciebie "niskopoziomowe" bo jak dla mnie jest
> bardziej wysokopoziomowe
W ogóle dostęp programisty normalnymi mechanizmami języka
(pomijam specjalne furtki) do adresów w pamięci maszyny,
jak by nie były zapisane, uważam za niskopoziomowy.
> niz adres w pamieci (tak jak to ma miejsce w pythonie).
Nie ma. Czegoś takiego jak stały adres w pamięci
wyznaczony do przechowywania wartości iksa.
Piotr Sawicki
Piotr Sawicki
>
>>> x = 10
>>>
>>> Czym jest x jak nie adresem w pamięci?
>>
>> W pythonie nie jest.
>>
>> A w języku kompilowanym
>
> x::Int = 10
W pythonie x nie jest adresem w pamięci. W takim sensie, jak
jest nim wartość zmiennej typu char*. To tylko etykietka, która
może pokazywać różne obiekty. Jakoś je oczywiście pokazuje wewnątrz
enginu, ale można napisać interpreter pythona trzymający wartości
zmiennych np. na dysku, z pełnym zachowaniem semantyki języka.
> Jezyk kompilowany nic do tego nie ma.
Wiesz, napis ,,x = 10'' nie mówi jaki język miałeś na myśli.
> A w C? Nie wiesz jaki to segment, jaki offset, która
> strona, czy zmienna jest w cache, czy nie.
Zawsze jakiś postęp w stosunku do kodu zerojedynkowego :>.
>>> Haskell odpada
>>
>> Jak najbardziej posiada funkcje wyższych rzędów definiowane w locie.
>
> Wymaga kompilacji. Nic "w biegu" nie zdefiniujesz.
Jednym palcem lewej ręki mogę zdefiniować treść funkcji
w trakcie działania programu. Choćby poprzez partial evaluation.
>>> i wszystkie kompilowane języki również razem z nim.
>>
>> To już zabrali kompilatory do Lispa, Algola i SML-a?
>
> To nie ja sugeruję, że języki kompilowane nie są wysokopoziomowe.
Ale jeśli chcesz żebym się odniósł do zarzutów, to najpierw
sprecyzuj swoje niejawne założenia, bo akurat te języki
podałem jako wysokopoziomowe enumeratywnie.
>>> Natomiast nagle bardzo wysokopoziomowy staje sie Lua i TCL,
>>> a co ciekawe Bash również.
>>
>> Jakie cechy tych języków masz na myśli?
>
> Generacja czegokolwiek "w biegu".
A konkretnie którym mechanizmem języka?
> [...]
> // Force f = m / a; // kompilator rzuca błędem,
> // bo język pozwala w czasie kompilacji sprawdzić,
> // czy zgadzają się jednostki SI.
>
> Kiedy pisze programy związane z fizyką takie cos jest mega ficzerem.
OK, fajne, ale ta cecha ma już swoją nazwę: strong typing.
> Nie mam dokładnego opisu co jest językiem niskiego, czy wysokiego
> poziomu, bo IMHO to jest o tyle bez sensu o ile każdy język w swojej
> domenie bedzie wysokopoziomowym a nie w swojej domenie bedzie
> niskopoziomowym.
Mam wrażenie, że przez poziom języka rozumiesz wygodę jego użytkowania.
>> OK, miałem dopisać zastrzeżenie a w końcu zapomniałem (i tak posting
>> był długi i nudny): to kryterium dotyczyło jedynie języków imperatywnych.
>
> A co to ma do rzeczy imperatywny czy nie?
>
> Haskell jest funkcyjny,
Miałem na myśli przeciwieństwo deklaratywnego, niezależnie
czy jest strukturalny, obiektowy czy funkcyjny (imperatywny
to może rzeczywiście niejasne określenie). Znaczenie ma
o tyle, że tekst w takim języku stanowi opis działania programu.
Podczas gdy w czysto deklaratywnych jest to rozbudowany, ale
opis problemu, program już istnieje i jest nim np. silnik algebry
relacji (SQL) albo prover metodą SLD-rezolucji (Prolog).
>> Że templaty w C++ są do bani z wielu powodów.
>
> Tak? A co dokładnie i jaki to ma wpływ na wysokość poziomu języka?
Ale poważnie jesteś nimi zachwycony czy tylko w nastroju polemicznym?
> class < IF < isIntergral <Type>, IntegralPower, RealPower > > MatrixPower;
>
> Klasa w zalezności od typu wybiera specjalizację potegowania i ją
> umieszcza w kompilacie. Pomyśl sobie masz bibliotekę do obliczeń na
> macierzach i podnosisz macierze do potęgi. Jeśli potęga jest całkowita
> stoujesz określony dedykowany ze względu na prędkość algorytm, jesli
> jest potęga rzeczywista, to stosujesz inny algorytm. Jak myślisz ile
> języków ta decyzje potrafi podjąc w czasie kompilacji?
Języki funkcyjne - funktorem.
> No więc jeśli nie ma definicji, to nie można kategorycznie
> stwierdzić który język jest wysokopoziomowy, a który nie.
> A Pan Karpierz ot tak sobie rzuca jakieś okreslenia bez pokrycia.
Jakoś można stwierdzić, że Albert Einstein był inteligentny,
a ślimak na jego trawniku nie. Rzecz jasna istnieją przypadki
pośrednie, ale akurat C do nich nie należy.
> W prawdziwym lispie pętla for jest paskudna.
> Czy to oznacza, że jest niskopoziomowy?
Że jest niewygodny i nieczytelny.
Piotr Sawicki
Piotr Sawicki
>
>>> x = 10
>>>
>>> Czym jest x jak nie adresem w pamięci?
>>
>> W pythonie nie jest.
>>
>> A w języku kompilowanym
>
> x::Int = 10
W pythonie x nie jest adresem w pamięci. W takim sensie, jak
jest nim wartość zmiennej typu char*. To tylko etykietka, która
może wyznaczać różne obiekty. Jakoś je oczywiście pokazuje wewnątrz
enginu, ale można napisać interpreter pythona trzymający wartości
zmiennych np. na dysku, z pełnym zachowaniem semantyki języka.
> Jezyk kompilowany nic do tego nie ma.
Wiesz, napis ,,x = 10'' nie mówi jaki język miałeś na myśli.
> A w C? Nie wiesz jaki to segment, jaki offset, która
> strona, czy zmienna jest w cache, czy nie.
Zawsze jakiś postęp w stosunku do kodu zerojedynkowego :>.
>>> Haskell odpada
>>
>> Jak najbardziej posiada funkcje wyższych rzędów definiowane w locie.
>
> Wymaga kompilacji. Nic "w biegu" nie zdefiniujesz.
Jednym palcem lewej ręki mogę zdefiniować treść funkcji
w trakcie działania programu. Choćby poprzez partial evaluation.
>>> i wszystkie kompilowane języki również razem z nim.
>>
>> To już zabrali kompilatory do Lispa, Algola i SML-a?
>
> To nie ja sugeruję, że języki kompilowane nie są wysokopoziomowe.
Ale jeśli chcesz żebym się odniósł do zarzutów, to najpierw
sprecyzuj swoje niejawne założenia, bo akurat te języki
podałem jako wysokopoziomowe enumeratywnie.
>>> Natomiast nagle bardzo wysokopoziomowy staje sie Lua i TCL,
>>> a co ciekawe Bash również.
>>
>> Jakie cechy tych języków masz na myśli?
>
> Generacja czegokolwiek "w biegu".
A konkretnie którym mechanizmem języka?
> [...]
> // Force f = m / a; // kompilator rzuca błędem,
> // bo język pozwala w czasie kompilacji sprawdzić,
> // czy zgadzają się jednostki SI.
>
> Kiedy pisze programy związane z fizyką takie cos jest mega ficzerem.
OK, fajne, ale ta cecha ma już swoją nazwę: strong typing.
> Nie mam dokładnego opisu co jest językiem niskiego, czy wysokiego
> poziomu, bo IMHO to jest o tyle bez sensu o ile każdy język w swojej
> domenie bedzie wysokopoziomowym a nie w swojej domenie bedzie
> niskopoziomowym.
Mam wrażenie, że przez poziom języka rozumiesz wygodę jego użytkowania.
>> OK, miałem dopisać zastrzeżenie a w końcu zapomniałem (i tak posting
>> był długi i nudny): to kryterium dotyczyło jedynie języków imperatywnych.
>
> A co to ma do rzeczy imperatywny czy nie?
>
> Haskell jest funkcyjny,
Miałem na myśli przeciwieństwo deklaratywnego, niezależnie
czy jest strukturalny, obiektowy czy funkcyjny (imperatywny
to może rzeczywiście niejasne określenie). Znaczenie ma
o tyle, że tekst w takim języku stanowi opis działania programu.
Podczas gdy w czysto deklaratywnych jest to rozbudowany, ale
opis problemu, program już istnieje i jest nim np. silnik algebry
relacji (SQL) albo prover metodą SLD-rezolucji (Prolog).
>> Że templaty w C++ są do bani z wielu powodów.
>
> Tak? A co dokładnie i jaki to ma wpływ na wysokość poziomu języka?
Ale poważnie jesteś nimi zachwycony czy tylko w nastroju polemicznym?
> class < IF < isIntergral <Type>, IntegralPower, RealPower > > MatrixPower;
>
> Klasa w zalezności od typu wybiera specjalizację potegowania i ją
> umieszcza w kompilacie. Pomyśl sobie masz bibliotekę do obliczeń na
> macierzach i podnosisz macierze do potęgi. Jeśli potęga jest całkowita
> stoujesz określony dedykowany ze względu na prędkość algorytm, jesli
> jest potęga rzeczywista, to stosujesz inny algorytm. Jak myślisz ile
> języków ta decyzje potrafi podjąc w czasie kompilacji?
Języki funkcyjne - funktorem.
> No więc jeśli nie ma definicji, to nie można kategorycznie
> stwierdzić który język jest wysokopoziomowy, a który nie.
> A Pan Karpierz ot tak sobie rzuca jakieś okreslenia bez pokrycia.
Jakoś można stwierdzić, że Albert Einstein był inteligentny,
a ślimak na jego trawniku nie. Rzecz jasna istnieją przypadki
pośrednie, ale akurat C do nich nie należy.
> W prawdziwym lispie pętla for jest paskudna.
> Czy to oznacza, że jest niskopoziomowy?
Że jest niewygodny i nieczytelny.
Piotr Sawicki
Seweryn Habdank-Wojewódzki
Piotr Sawicki wrote:
>> niz adres w pamieci (tak jak to ma miejsce w pythonie).
>
> Nie ma. Czegoś takiego jak stały adres w pamięci
> wyznaczony do przechowywania wartości iksa.
Jest stały do póki do GC nie zmieni.
I tak obawiam się, że to często nie następuje.
BTW ewentualna stałość może być wynikiem optymalizacji.
Są algorytmy, które tak tasują dane w strukturze pamięci, że dostęp do
często uzywanych elementów znajduje się pod stałymi adresami w bliskim
rejonie w szczególności w pamięci cache procesora.
Czy języki korzystające z tego ficzeru są niskopoziomowe?
A może własnie są wysokopoziomowe, bo oferują całą gamę szybkości dostępu do
danych?
Pozdrawiam.
--
|\/\/| Seweryn Habdank-Wojewódzki
Seweryn Habdank-Wojewódzki
Piotr Sawicki wrote:
>>>> Haskell odpada
>>>
>>> Jak najbardziej posiada funkcje wyższych rzędów definiowane w locie.
>>
>> Wymaga kompilacji. Nic "w biegu" nie zdefiniujesz.
>
> Jednym palcem lewej ręki mogę zdefiniować treść funkcji
> w trakcie działania programu. Choćby poprzez partial evaluation.
Nie wszystko tak zrobisz w Haskellu -- klasy nie dodasz "w biegu".
> Ale jeśli chcesz żebym się odniósł do zarzutów, to najpierw
> sprecyzuj swoje niejawne założenia, bo akurat te języki
> podałem jako wysokopoziomowe enumeratywnie.
Ja nie neguję ich wysokopoziomowości. Wskazuję jedynie na relatywizm
definicji.
Dla mnie osobiście niskopoziomowe są asemblery, ponieważ one są nie
przenośne ze względu na platformę.
Średniopoziomowe są przenośne języki sprzętu: VHDL, STL (dla PLC), C dla
procesorów ogólnego zastosowania. Nie nazywam ich niskim poziomem, bo kod
napisany w C dla procesora DSP w dużej mierze przechodzi na x86. STL użyty
na maszynach Siemensa można w dużej mierze przenieść na Fanuca. VHDL
podobnie.
Wysokopoziomowe są języki potrafiące w łatwy sposób odwzorować myślenie
ludzkie na kod. Nie ustawiam ich w sensie bardziej lub mniej
wysokopoziomowe.
One są dla mnie równolegle wysokopoziomowe, dlaczego?
Mam bardzo proste przykłady: język Matlab w tej chwili imperatywny obiektowy
język do pracy na macierzach. Jedna komenda pozwala odzyskać krawędzie z
obrazu. Język R funkcyjny język do statystycznego patrzenia na dane. Jedna
komenda pozwala wybudować model predyktora ARMA. Python ma bardzo dobre
narządzia do pracy z tekstem (wątek o generatorach to potwierdza). C++ jak
dla mnie to jest bardzo wydajny język do implementacji skomplikowanej
matematyki i fizyki (prosty przykład już podałem wcześniej). W pracy takie
zabawki używałem już nie raz. Języki funkcyjne rewelacyjne jeśli
implementowane algorytmy są rekurencyjne. I tak dalej i tak dalej.
Każdy z tych języków użyty nie w swojej domenie staje się niskopoziomowy lub
tez nie możliwy do uzycia. Przykład w SQL nie da się robić połączeń via
socket chociaż SQL tez jest językiem wysokiego rzędu.
>> // Force f = m / a; // kompilator rzuca błędem,
>> // bo język pozwala w czasie kompilacji sprawdzić,
>> // czy zgadzają się jednostki SI.
>>
>> Kiedy pisze programy związane z fizyką takie cos jest mega ficzerem.
>
> OK, fajne, ale ta cecha ma już swoją nazwę: strong typing.
Nie. Strong typing tu jest połączony z operator overloading i z faktem, że
język ma kompilator. Już się robią trzy cechy.
Które u mnie nie określają wysokopoziomowości w sensie takim, że jedynym
językiem wysokopoziomowym jest ten, który ma silne typowanie, przeładowanie
opratorów i kompilator. C++ jest dla mnie tak samo wysokopoziomowy jak
Python, Haskell czy R i Matlab. Są rzeczy proste do zakodowania i są
trudne.
>> Nie mam dokładnego opisu co jest językiem niskiego, czy wysokiego
>> poziomu, bo IMHO to jest o tyle bez sensu o ile każdy język w swojej
>> domenie bedzie wysokopoziomowym a nie w swojej domenie bedzie
>> niskopoziomowym.
>
> Mam wrażenie, że przez poziom języka rozumiesz wygodę jego użytkowania.
Według definicji ogólnych poziom języka to oddalenie kodu programu
odspecyfiki maszyny na rzecz myślenia człowieka. Teraz w zależności od
zadania myślenie jest inne i zatem inny język w kontekście tego zadania
bedzie najlepszy, dla F = m * a IMHO C++ jest świetny, dla pracy z tekstem
obstawiam na Pythona (chociaż są dedykowane języki do pracy z tekstem). Do
pracy na bazach danych SQL. Do skrytpów w Excelu VB itd.
> Znaczenie ma
> o tyle, że tekst w takim języku stanowi opis działania programu.
> Podczas gdy w czysto deklaratywnych jest to rozbudowany, ale
> opis problemu, program już istnieje i jest nim np. silnik algebry
> relacji (SQL) albo prover metodą SLD-rezolucji (Prolog).
No tak, ale czemu nie ma do tej pory języka rozmawiającego z człowiekiem?
Każdy język "wysokiego poziomu" ma zaszyty w sobie jakiś dedykowany engine.
Jesli go nie ma w jakiejś działce, to jest nagle językiem niskiego rzędu.
Polacam napisanie procedury budującej model ARMA w Haskellu. Jak
powiedziałem w funkcyjnym R to jest jedna linia kodu.
>>> Że templaty w C++ są do bani z wielu powodów.
>>
>> Tak? A co dokładnie i jaki to ma wpływ na wysokość poziomu języka?
>
> Ale poważnie jesteś nimi zachwycony czy tylko w nastroju polemicznym?
Zachwycony to zadużo powiedziane. Natomiast myślę, że potrafię się nimi
posługiwać i tam gdzie to daje korzyść zwracają mi z nawiązką.
Mam napisany w C++ kod solwera ARK-4,5 do równań różniczkowych, który po
kompilacji zajmuje mniej niż równoważny kod w C i jest szybszy niż kod
napisany w C. Po prostu szablony zostały one użyte optymalnie.
>> class < IF < isIntergral <Type>, IntegralPower, RealPower > >
>> MatrixPower;
>>
[...]
>
> Języki funkcyjne - funktorem.
Ogólnie. A szczegółowo ile to bedzie kodu?
> Jakoś można stwierdzić, że Albert Einstein był inteligentny,
> a ślimak na jego trawniku nie. Rzecz jasna istnieją przypadki
> pośrednie, ale akurat C do nich nie należy.
Pan Karpierz pisał o C++ i do tego się odnoszę -- twierdzę, że to
nieuzasadniona opinia.
>> W prawdziwym lispie pętla for jest paskudna.
>> Czy to oznacza, że jest niskopoziomowy?
>
> Że jest niewygodny i nieczytelny.
Co zatem oznacza, że jest niskopoziomowy? Jest blisko sprzętu?
A jeśli sprzęt rozumie Javę to znaczy, że Java jest niskopoziomowa?
Czy zatem Groovy jest też niskopoziomowy, czy średniopoziomowy?
Seweryn Habdank-Wojewódzki
Sulsa wrote:
> Ktos na grupe pl.comp.lang.c utryzmywal ze definicja standardu c +
> + pozwala aby pamiec adresowana byla nawet stringami, czy takie
> adresowanie jest dla ciebie "niskopoziomowe" bo jak dla mnie jest
> bardziej wysokopoziomowe niz adres w pamieci(tak jak to ma miejsce w
> pythonie).
Dobrze, że o tym wspomniałeś.
Jest to ciekawe w kontekście programowania systemów rozproszonych, kiedy np.
odwołanie się do obiektu wygląda nietypowo, czyli na wysokim poziomie
odwołanie może iść property serwera (name servera), a property serwer
uwidacznia cechy nazwy takie jak adres IP, port i właściwą nazwę obiektu.
Albo można posługiwać się zdalną obiektową bazą danych, przy dzisiejszej
wydajności sieci i baz danych może się takie coś jest szybkim i dobrym
rozwiązaniem, bo separuje dane i obiekty od algorytmów. To można ładnie
poktyś wysokopoziomowym intefejsem np. w C++ można użyć semantyki
smart_ptr.
Ciekawe jak takie adresowanie realizowane jest w innych językach "wysokiego
poziomu"?
Pozdrawiam.
--
|\/\/| Seweryn Habdank-Wojewódzki
Adam Karpierz
> Brawo! referencje w pythonie tez przetrzymuja adres w pamieci, wiec
> python jak najbardziej jest jezykiem niskiego poziomu!
1. Nie ma w Pythonie zadnych referencji.
To o czym myslisz to sa metki.
Metki to sa chwilowe (czyli w scope) nazwy obiektow.
Z pamiecia obiektow maja dokladnei 0 wspolnego.
2. Nieprawda ze przetrzymuja adres w pamieci
O tym jezyk milczy (i slusznie) a taki ZODB
jawnie temu przeczy i przetrzymuje metki na dysku.
No i ?
> Ktos na grupe pl.comp.lang.c utryzmywal ze definicja standardu
> c++ pozwala aby pamiec adresowana byla nawet stringami
No to pokaz mi pamiec adresowana stringiem w C++ :)
Chcialbym zobaczyc zanim umre: pamiec[string]
AK
Adam Karpierz
> W ogóle dostęp programisty normalnymi mechanizmami języka
> (pomijam specjalne furtki) do adresów w pamięci maszyny,
> jak by nie były zapisane, uważam za niskopoziomowy.
Oczywiscie.
Swieta racja.
Taki dostep to byl jest i bedzie po prostu glownym fjutczerem
assemblerow == jezykow maszynowych.
AK
Wojciech Muła
> No to pokaz mi pamiec adresowana stringiem w C++ :)
> Chcialbym zobaczyc zanim umre: pamiec[string]
Jeszcze trochę cierpliwości. To będzie zaraz po tym jak zostanie wydany
Duke Nukem Forever, ukończą GNU/Hurd i powstanie kompilator C++ w pełni
zgodny ze standardem. :)
w.
Adam Karpierz
> W pythonie x nie jest adresem w pamięci. W takim sensie, jak
> jest nim wartość zmiennej typu char*. To tylko etykietka, która
> może wyznaczać różne obiekty. Jakoś je oczywiście pokazuje wewnątrz
> enginu, ale można napisać interpreter pythona trzymający wartości
> zmiennych np. na dysku, z pełnym zachowaniem semantyki języka.
Dokladnie.
ZODB , shelve, bcddb itp o tym swiadcza.
AK
Adam Karpierz
>> Nie ma. Czegoś takiego jak stały adres w pamięci
>> wyznaczony do przechowywania wartości iksa.
>
> Jest stały do póki do GC nie zmieni.
> I tak obawiam się, że to często nie następuje.
Panie Wojewodzki
Niech Pan sobie _raz na zawsze_ wbije do ukrzyzykowanej glowy:
Python _nic nie mowi_ gdzie znajduje sie obiekt do ktorego ma Pan metke.
Moze to byc pamiec, moze to byc dysk a moze to byc odlegly serwer.
W ogole _nie wie Pan_ gdzie jest ten obiekt i wszelkie zalozenia
o tym gdzie (fizycznie) sie znajduje sa sprzeczne z raportem i natura
Pythona.
AK
Adam Karpierz
> Ciekawe jak takie adresowanie realizowane jest w innych językach
> "wysokiego
> poziomu"?
Panie Wojewodzki
Niech sie z laski swojej nie blamuje doszczetnie.
Ta Pan super semantyka shared_ptr w normalnych jezykach realizowana
jest 'sama z siebie'.
W Javie, Pythonie, VB, Simuli (dynamiczne przydzielanie), C#
'semantylke' shared ptr ma kazdy obiekt _z natury_ bez zadnych dodatkowych
smiesznych zabiegow !
shared_ptr w C++ to.. nieudolne nasladowanie powyzszych jezykow .
Rozumie juz Pan ?
Co to tych cech distribiutionrozproszonych/zdalnych itp to..
w Pythonie realizacja wyglada tal ze.. nawet Pan nie wie
gdzie ten obiekt siedzi.
Po prostu uzywa sie metki obiektu i.. juz !
AK
Adam Karpierz
napisał:
> No to pokaz mi pamiec adresowana stringiem w C++ :)
> Chcialbym zobaczyc zanim umre: pamiec[string]
> Jeszcze trochę cierpliwości.
> 1. To będzie zaraz po tym jak zostanie wydany Duke Nukem Forever
To nie jest bez szans ;)
> 2. ukończą GNU/Hurd
No tak.... pierwszy gwozdz wbiles bolesnie...
> 3. i powstanie kompilator C++ w pełni zgodny ze standardem. :)
Wieko zaspawales tytanem i to bez cienia litosci :(
AK
Seweryn Habdank-Wojewódzki
Adam Karpierz wrote:
> Niech sie z laski swojej nie blamuje doszczetnie.
Narazie To Pan się wygłupia. Już nie raz zapędziłem Pan w kozi róg więc nie
boję się Pańskich "mądrości". Póki co jedynie co Pan potrafi to przytakiwać
lokalnym guru, bez obrazy dla nich.
> Ta Pan super semantyka shared_ptr w normalnych jezykach realizowana
> jest 'sama z siebie'.
Nawet czytać nie umie, a gardłuje.
Pisałem o semantyce SMART_PTR!!! Czytać, czytać i czytać. A nie opowiadać
bzdur.
> shared_ptr w C++ to.. nieudolne nasladowanie powyzszych jezykow .
> Rozumie juz Pan ?
Panie Karpierz nie mówiłem o shared_ptr.
Mam do Pan pytanie, bo o definicję wysokopoziomowego języka się
niedowiedziałem.
Niech mi Pan pokaże, którym z wymienionych przez Pana języków transakcje
rozproszone są transparentne? Oraz druga rzecz. Który wysokopozomowiec sam
tworzy algorytmy równoległe (sam sobie ustala co i gdzie nalezy blokować).
To byłby dla mnie wysoki poziom. Wszystko cotego nie ma tak naprawdę jest
dla mnie tylko trochę powyżej asemblera, bo i tak samemu o wszystko trzeba
dbać. W szczególności trzeba sobie samemu pisać namiastki rozproszonych GC
i innych rzeczy.
Parafrazując Pana kulturę wypowiedzi.
Zamim Pan zaczniesz dalej stulać niech Pan powie jakie języki realizują
żądany przezemnie wysoki poziom.
> Co to tych cech distribiutionrozproszonych/zdalnych itp to..
> w Pythonie realizacja wyglada tal ze.. nawet Pan nie wie
> gdzie ten obiekt siedzi.
> Po prostu uzywa sie metki obiektu i.. juz !
Och i ach. Jeszcze nie widziałem aby mieć dwie maszyny uruchomione w sieci i
aby Python sam mi rozłozył obietky i kod i najlepije jeszcze aby stosowne
kawałki algorytmów obapalały się same w odpowiednije liczbie watków i aby
sam Python wiedział co nalezy blokować.
Seweryn Habdank-Wojewódzki
Adam Karpierz wrote:
> Niech Pan sobie _raz na zawsze_ wbije do ukrzyzykowanej glowy:
> Python _nic nie mowi_ gdzie znajduje sie obiekt do ktorego ma Pan metke.
A gdzie ja pisałem że mówi?
> Moze to byc pamiec, moze to byc dysk a moze to byc odlegly serwer.
Może być ale w praktyce nie jest nic dalej niż dysk i to nie odległy.
> W ogole _nie wie Pan_ gdzie jest ten obiekt i wszelkie zalozenia
> o tym gdzie (fizycznie) sie znajduje sa sprzeczne z raportem i natura
> Pythona.
Cieszę się, że Python ma w sobie rozproszone GC.
Panie Karpierz, dla ustalenia uwagi, bo widzę, że Pan nie umie czytać ze
zrozumieniem.
Dla mnie Python jest takim samym wysokopoziomowcem jak C++, Java, C#,
Matlab, R czy Haskell.
Jeśli którykolwiek z nich jest wysokopozomy to wszystkie pozostałe też.
Jeżeli któryś nie jest to pozostałe też nie są.
Nie widziałem języka z wbudowaną sztuczną inteligencją, który sam potrafi
sobie pisać stosowny kod.
Ja piszę:
krawędź <- get_krawędzie(obraz)
a program sam uzupełnia to czym uważa za stosowne. Nawet Matlab, ktory ma
procedury do krawędzi obrazu nie jest inteligentny na tyle, aby wybrać dla
zadanego obrazu najlepszą.
Nie ma takich wysokopoziomowych języków więc te co są określam mianem
wysokopoziomowych.
A Pan nawet nie potrafi podać definicji a na to na co Pana stać to tępe
przytakiwanie, bo Pan własny zasób wiedzy się już skończył wraz z
samosprzecznym określeniem, że książki z lat 80 mają definicje, ale one
fałszywie określają C wysokopoziomowym.
Napisz Pan coś mądrego, bo póki co to tylko zamęt Pan szerzy.
Sulsa
Seweryn Habdank-Wojewódzki <shw_...@wp.pl> wrote:
> Każdy z tych języków użyty nie w swojej domenie staje się niskopoziomowy lub
> tez nie możliwy do uzycia. Przykład w SQL nie da się robić połączeń via
> socket chociaż SQL tez jest językiem wysokiego rzędu.
SQL jest jezykiem 4. rzędu(deklaratywnym), a podzial na jezyki
wysokiego i niskiego poziomu dla takich jezykow jest troche bezsensu.
Pozatym jest jezykiem domenowym wiec wynajdywanie dla niego zadan dla
których nie został stworzony tez jest troche bezsensu.
Tak pozatym mysle ze ta dyskusja by nie byla tak żywiołowa gdybysmy na
jezyki wysokiego/niskiego poziomu nie patrzyli jak dzieci, w czarno
bialych barwach, tylko wyroznili kilka odcieni szarosci(np. logike
rozmyta) i ukategoryzowali np tak:
poziom kodu maszynowego = 0
poziom kodu maszynowego < poziom assemblera < poziom c < poziom pythona
wbrew pozora assembler tez jest w pewnym stopniu przenosny i dziala w
pewnym oderwaniu od sprzetu bo np.: instrukcja(program)
mov zmienna1, zmienna2
bedzie przenosna miedzy platformami, na których wystepuje ta instrukcja
mimo tego ze moga one posiadac rozne kody operacji dla tej instrukcji.
Seweryn Habdank-Wojewódzki
Sulsa wrote:
> SQL jest jezykiem 4. rzędu(deklaratywnym), a podzial na jezyki
> wysokiego i niskiego poziomu dla takich jezykow jest troche bezsensu.
No tak, ale zawsze jakiś jezyk do czegoś się lepiej lub gorzej nadaje.
Jak wspomniałem do pisania algorytmów dataminingowych SQL się "nadaje", ale
to jest gehenna w nim pisać coś takiego.
Oracle dostarcza w swojej bazie *specjalne* funkcje, bo napisanie tego w
dowolnym SQL jest poronionym pomysłem, ale da się.
I tu zaczniemy się zastanawiać czy coś się da w okreslonym języku napisać,
czy nie. Też potrzeba wielu odcieni szarości w wielu wymiarach
odpowiadających zagadnieniom.
Ale ogólnie masz rację.
> Pozatym jest jezykiem domenowym wiec wynajdywanie dla niego zadan dla
> których nie został stworzony tez jest troche bezsensu.
O nie bo można znajdować stany pośrednie jak wpomniane algorytmy. Da się je
napisać, ale to jest koszmar.
> Tak pozatym mysle ze ta dyskusja by nie byla tak żywiołowa gdybysmy na
> jezyki wysokiego/niskiego poziomu nie patrzyli jak dzieci, w czarno
> bialych barwach, tylko wyroznili kilka odcieni szarosci(np. logike
> rozmyta) i ukategoryzowali np tak:
W jednym swoim poście to napisałem. Podałem podział i przykłady.
Dla mnie istnieje jakby pseudo oś:
Myślenie człowieka <----> Kod maszyny.
Dla róznych zadań i dla różnych wymagań w obrębie tych zadań można
spoktać "asemblery" i języki zbliżone do ludzkiego myślenia.
Przykładowa obróbka obrazu (wykrywanie krawędzi) w kazdym języku poza
Matlabem ta procedura jest wykonywana w zasadzie jak w asemblerze (modulo
przenośność kodu). Trzeba przeiteorwać obraz piksel po pikselu nalezy
policzyć stosowne gradienty (lub gradienty uogólnione). Te gradienty trzeba
zaimplementować od zera itd. Czyli dla tego zadania wszelakie języki poza
Matlabem są niskopoziomowe. Bo nie można myślenia "łatwo" zamienić na kod.
Są ciekawe acz dosc ograniczone w zakresie uzycia narzedzia firmy IBM
odpowiadajace MDD. Czlowiek *rysuje* modele, a potem kod Javy jest
generowany. Ale uwaga nie kazdy model mozna narysowac. Generalnie biznesowe
modele relacyjne mozna rysowac, ale modele matematyki dyskretnej juz nie,
np. modele ARMA. Tak wiec znowu graficzny jezyk wysokiego poziomu jest
tylko czesciowo wysokiego poziomu.
Kupę piany idzie w pod wątek skupiający się na pojedynczym detalu
programistycznym dot. "char*". Tam skupia się czołowy zadymiarz, który
merytorycznie nic nie powiedział i dlatego częściowo dyskusja jest
przegadana.
Proszę zaproponuj coś konstruktywnego bedziemy dyskutować i podawać
przykłady.
Sulsa
Seweryn Habdank-Wojewódzki <shw_...@wp.pl> wrote:
> Przykładowa obróbka obrazu (wykrywanie krawędzi) w kazdym języku poza
> Matlabem ta procedura jest wykonywana w zasadzie jak w asemblerze (modulo
> przenośność kodu). Trzeba przeiteorwać obraz piksel po pikselu nalezy
> policzyć stosowne gradienty (lub gradienty uogólnione). Te gradienty trzeba
> zaimplementować od zera itd. Czyli dla tego zadania wszelakie języki poza
> Matlabem są niskopoziomowe. Bo nie można myślenia "łatwo" zamienić na kod.
Mysle ze podejscie, w ktorym wysoki poziom to taki jezyk, w ktorym da
sie latwo opisac algorytm jest bledne(wysoki poziom jezyka
przedewszystkim bylby subiektywny). Wysoki poziom to cecha, ktora
uniezaleznia jezyk od szczegolow sprzetowych, tak jest np w pythonie
(nie znam zadnej konstrukcji zaleznej od sprzetu), ale np. w wielu
przypadkach nie jest to prawdziwe w c/c++ np. little/big endian
oczywiscie da sie takie konstrukcje ominac, ale nie zmienia to faktu ze
one wystepuja w tym jezyku i dlatego jest to nizszy poziom niz python,
ale zupelnie sie nie zgadzam nawet przyjumujac bledny czarno bialy
podzial ze jest to jezyk niskiego poziomu. Nie jest moze on tak
abstrakcyjny jak python czy java(chociaz tu niezaleznosc od sprzetu
jest momentami zludna) ale nie czyni go to jezykiem niskiego poziomu.
Jest taki fajny żart, że c++ jest najlepszym z assemblerów, jak w
kazdym żarcie jest w nim odrobina prawdy, ale tylko odrobina.
--
Seweryn Habdank-Wojewódzki
Sulsa wrote:
> Mysle ze podejscie, w ktorym wysoki poziom to taki jezyk, w ktorym da
> sie latwo opisac algorytm jest bledne
Póki co nikt nie podał definicji.
> (wysoki poziom jezyka
> przedewszystkim bylby subiektywny).
A nie jest. Na stronach wikipedii zarówno Python jak i C++ są uznane za
wysokopoziomowe.
> Wysoki poziom to cecha, ktora
> uniezaleznia jezyk od szczegolow sprzetowych, tak jest np w pythonie
> (nie znam zadnej konstrukcji zaleznej od sprzetu)
Hmm... żadnej?
Dlaczego pisząc program wielowątkowy muszę się matrwić o jakieś tam bariery
muteksy i inne sekcje krytyczne?
> , ale np. w wielu
> przypadkach nie jest to prawdziwe w c/c++ np. little/big endian
Co proszę? Gdzie masz doczynienia z big i little endian w C++?
Jeśli nie chcesz tego dotykać to nie dotykasz.
> oczywiscie da sie takie konstrukcje ominac
Raczej odwrotnie da się w nie wdepnąć jak ktoś prosi się o kłopoty.
Dla ustalenia uwagi w Pythonie też się da w to wdepnąć, tylko że zamiast
rzutowania nalezy trochę pomieszać.
> , ale nie zmienia to faktu ze
> one wystepuja w tym jezyku i dlatego jest to nizszy poziom niz python,
To zalezy od definicji, która jeszcze nie padła.
> ale zupelnie sie nie zgadzam nawet przyjumujac bledny czarno bialy
> podzial ze jest to jezyk niskiego poziomu.
To już jest coś.
> Nie jest moze on tak
> abstrakcyjny jak python czy java
Hmmm... ciekawe że C++ szablony uchodzą za bardzo abstrakcyjne. A np.
boost.mpl za astronautykę.
> Jest taki fajny żart, że c++ jest najlepszym z assemblerów, jak w
> kazdym żarcie jest w nim odrobina prawdy, ale tylko odrobina.
Asemblerem bym go nie nazwał, za dużo programowałem w asm dla małych
procków. Polecam Ci oderwanie się od świata PC. Zerknij na VHDL, STL to
bedziesz miał języki -- przenośne, znacznie powyzej asemblera a jednak
języki sprzętu. Jednak C++ jest jakby wyżej, ale ocenę pozostawię jako
ćwiczenie dla czytelnika.
Cały czas oczekuję na ścisłą definicję pojęcia poziomu języka.
Może być wypowiedziana w języku logiki logice rozmytej, przy pełnym podaniu
opisu.
Piotr Sawicki
>>> Wymaga kompilacji. Nic "w biegu" nie zdefiniujesz.
>>
>> Jednym palcem lewej ręki mogę zdefiniować treść funkcji
>> w trakcie działania programu. Choćby poprzez partial evaluation.
>
> Nie wszystko tak zrobisz w Haskellu -- klasy nie dodasz "w biegu".
Z niczego zrobiło się wszystko oprócz klasy. Nad nią nie boleję
specjalnie - zauważ, że type class w Haskellu to zupełnie co
innego niż klasa w sensie OOP, jeden stopien abstrakcji wyżej.
Faktycznie, w żadnym języku nie ma poziomu meta-meta, to już
byłby przerost techniki nad zdrowym rozsądkiem.
> Ja nie neguję ich wysokopoziomowości.
> Wskazuję jedynie na relatywizm definicji.
No to nie wiem z czym się spierasz, o różnym stopniu
wysokopoziomowości w różnych językach napisałem explicite.
> Wysokopoziomowe są języki potrafiące w łatwy sposób
> odwzorować myślenie ludzkie na kod.
Chałowa taka definicja, uniemożliwia jakąkolwiek falsyfikację,
weryfikację i whateveryzację, o wzorze ludzkiego myślenia to
można sobie nawzajem opowiadać dowolne bajki z mchu i paproci,
przynajmniej na obecnym poziomie kognitywistyki AFAIK.
> Każdy z tych języków użyty nie w swojej domenie staje
> się niskopoziomowy lub tez nie możliwy do uzycia.
Przypadków spoza dziedziny się nie rozpatruje, elementarne.
>> OK, fajne, ale ta cecha ma już swoją nazwę: strong typing.
>
> Nie. Strong typing tu jest połączony z operator overloading
> i z faktem, że język ma kompilator. Już się robią trzy cechy.
Trzy cechy systemu typów, a nie całego języka.
> Według definicji ogólnych poziom języka to oddalenie
> kodu programu odspecyfiki maszyny
Z takim ujęciem niskopoziomowości się spotkałem...
> na rzecz myślenia człowieka.
... ale z tym nigdy. Jakieś źródło?
> dla F = m * a IMHO C++ jest świetny,
Tylko wymaga wprowadzania jakichś idiotycznych pseudofunkcji w rodzaju
kilo(), żeby typechecker mógł zatrybić. Typami algebraicznymi
(choćby z Haskella) można zrobić to samo, tylko zgrabniej.
> No tak, ale czemu nie ma do tej pory języka rozmawiającego z człowiekiem?
Automatyczne rozwiązywanie problemów algorytmicznych nie jest możliwe.
> Każdy język "wysokiego poziomu" ma zaszyty w sobie jakiś
> dedykowany engine. Jesli go nie ma w jakiejś działce,
> to jest nagle językiem niskiego rzędu.
Musisz mieć bardzo dziwne rozumienie tego zaszytego engine'u
skoro ten sam język raz go ma a raz nie, zależnie od działki.
> Polacam napisanie procedury budującej model ARMA w Haskellu. Jak
> powiedziałem w funkcyjnym R to jest jedna linia kodu.
A możesz pokazać?
>>>> Że templaty w C++ są do bani z wielu powodów.
>>>
>>> Tak? A co dokładnie i jaki to ma wpływ na wysokość poziomu języka?
>>
>> Ale poważnie jesteś nimi zachwycony czy tylko w nastroju polemicznym?
>
> Zachwycony to zadużo powiedziane. Natomiast myślę,
> że potrafię się nimi posługiwać
No to dobry jesteś, biorąc pod uwagę że nawet kompilator
c++ potrafi je sam rozwikłać tylko w trywialnych przypadkach.
>>> class < IF < isIntergral <Type>, IntegralPower, RealPower > >
>>> MatrixPower;
>>
>> Języki funkcyjne - funktorem.
>
> Ogólnie. A szczegółowo ile to bedzie kodu?
Tyle samo z dokładnością do czytelnego zapisu.
> Pan Karpierz pisał o C++ i do tego się odnoszę
> -- twierdzę, że to nieuzasadniona opinia.
A ja twierdzę, że (skoro też wolisz opis relatywny) c++ jest
na niższym poziomie niż python, smalltalk albo haskell.
>>> Czy to oznacza, że jest niskopoziomowy?
>>
>> Że jest niewygodny i nieczytelny.
>
> Co zatem oznacza, że jest niskopoziomowy? Jest blisko sprzętu?
Wg mojego kryterium wysokopoziomości jest co najwyżej niewygodny.
> A jeśli sprzęt rozumie Javę to znaczy, że Java jest niskopoziomowa?
Słyszałem coś o takim projekcie, ale IMHO jak program jvm
wdrukują w scalaki to po prostu sprzęt będzie wysokopoziomowy.
> Czy zatem Groovy jest też niskopoziomowy, czy średniopoziomowy
Mnie nie pytaj - to Twoje kryterium.
Rzeczywiście w tym świetle brzmi niemądrze.
Piotr Sawicki
Piotr Sawicki
>>
>> Nie ma. Czegoś takiego jak stały adres w pamięci
>> wyznaczony do przechowywania wartości iksa.
>
> Jest stały do póki do GC nie zmieni.
Pomyliłeś zmienną z obiektem stanowiącym jej aktualną wartość.
> I tak obawiam się, że to często nie następuje.
>
> BTW ewentualna stałość może być wynikiem optymalizacji.
> Są algorytmy, które tak tasują dane w strukturze pamięci, że dostęp do
> często uzywanych elementów znajduje się pod stałymi adresami w bliskim
> rejonie w szczególności w pamięci cache procesora.
> Czy języki korzystające z tego ficzeru są niskopoziomowe?
To nie cecha języka, tylko kompilatora/jit-u/vm-u.
I zwykło się ją nazywać zoptymalizowaniem.
Piotr Sawicki
Piotr Sawicki
>
> Jest to ciekawe w kontekście programowania systemów rozproszonych, kiedy np.
> odwołanie się do obiektu wygląda nietypowo, czyli na wysokim poziomie
> odwołanie może iść property serwera (name servera), a property serwer
> uwidacznia cechy nazwy takie jak adres IP, port i właściwą nazwę obiektu.
> Albo można posługiwać się zdalną obiektową bazą danych, przy dzisiejszej
> wydajności sieci i baz danych może się takie coś jest szybkim i dobrym
> rozwiązaniem, bo separuje dane i obiekty od algorytmów. To można ładnie
> poktyś wysokopoziomowym intefejsem np. w C++ można użyć semantyki
> smart_ptr.
>
> Ciekawe jak takie adresowanie realizowane jest w innych językach
> "wysokiego poziomu"?
Nie do końca chwytam o co Ci chodzi, location transparency?
Jest w erlangu domyślnie, bez żadnych dodatkowych interfejsów.
Piotr Sawicki
Seweryn Habdank-Wojewódzki
Piotr Sawicki wrote:
> Z niczego zrobiło się wszystko oprócz klasy. Nad nią nie boleję
> specjalnie - zauważ, że type class w Haskellu to zupełnie co
> innego niż klasa w sensie OOP, jeden stopien abstrakcji wyżej.
Nie widzę tego. Tak jak generyki Haskelowe według niektórych są powyżej
wszelkich generyków a dla nie one nie wyskakują powyżej referencji na
okreslony interfejs. Ale może kwestia spojrzenia.
> No to nie wiem z czym się spierasz, o różnym stopniu
> wysokopoziomowości w różnych językach napisałem explicite.
Spieram się z *bezpodstawnym* stwierdzeniem, że C++ nie jest wysokopozimowy.
Bezpodstawny dla mnie jest ponieważ nikt nie podał definicji poziomu języka.
>> Wysokopoziomowe są języki potrafiące w łatwy sposób
>> odwzorować myślenie ludzkie na kod.
>
> Chałowa taka definicja
Lespza według Ciebie jest taka w której Pan Kaprpierz lstuje według jego
widzimi się jest wyskopoziomowe a co nie? Czy poda dla każdego języka taka
ocenę?
BTW za wikipedią [1]
"
"high-level language" refers to the higher level of abstraction from machine
language.
"
Nie ma w tym nic prezyzyjniejszego niż w moje "definicji".
Tam tez jest napisane dość wyraźnie nt. "Relative meaning", co również
koresponduje z moja opinią.
> , uniemożliwia jakąkolwiek falsyfikację,
> weryfikację i whateveryzację, o wzorze ludzkiego myślenia to
> można sobie nawzajem opowiadać dowolne bajki z mchu i paproci,
> przynajmniej na obecnym poziomie kognitywistyki AFAIK.
Wystrczy poniżej ludzkiego swobodnego myślenia wstawić matematykę, która
jest ścisła, a żaden język programowania nie wypełnił jej wszystkich
abstrakcyjnych pojęć.
Zatem jeżeli nawet granicę ustalimy na matematyce to też będzie to rozsądne.
>> Każdy z tych języków użyty nie w swojej domenie staje
>> się niskopoziomowy lub tez nie możliwy do uzycia.
>
> Przypadków spoza dziedziny się nie rozpatruje, elementarne.
Są przypadki graniczne już podawałem.
>>> OK, fajne, ale ta cecha ma już swoją nazwę: strong typing.
>>
>> Nie. Strong typing tu jest połączony z operator overloading
>> i z faktem, że język ma kompilator. Już się robią trzy cechy.
>
> Trzy cechy systemu typów, a nie całego języka.
Kompilacja nie jest cechą żadnego typu. To tez dotyczy Haskella, Ady itd.
>> Według definicji ogólnych poziom języka to oddalenie
>> kodu programu odspecyfiki maszyny
>
> Z takim ujęciem niskopoziomowości się spotkałem...
A ja tak.
>> na rzecz myślenia człowieka.
>
> ... ale z tym nigdy. Jakieś źródło?
Wikipedia póki co nie mam lepszego.
>> dla F = m * a IMHO C++ jest świetny,
>
> Tylko wymaga wprowadzania jakichś idiotycznych pseudofunkcji w rodzaju
> kilo(), żeby typechecker mógł zatrybić. Typami algebraicznymi
> (choćby z Haskella) można zrobić to samo, tylko zgrabniej.
Zgrabniej czyli? Kodzku nie widzę.
>> Każdy język "wysokiego poziomu" ma zaszyty w sobie jakiś
>> dedykowany engine. Jesli go nie ma w jakiejś działce,
>> to jest nagle językiem niskiego rzędu.
>
> Musisz mieć bardzo dziwne rozumienie tego zaszytego engine'u
> skoro ten sam język raz go ma a raz nie, zależnie od działki.
Znam wiele dziwnych rzeczywistych przykładów i to mnie skutecznie izoluje od
filozofowania.
Oracle + SQL: komenda "insert" sama dba o spójność bazy sama blokuje co
trzeba, same rozdaje dane gdzie trzeba.
Kiedy wstawianie sie nie powidzie w pełni. baza sama robi roll back.
Języki wysokopoziomowe:
insert do kolekcji + wątki: "figa z makiem" jak user sam nie założy sekcji
krytycznej to nie ma blokowania. Kiedy cały insert się nie powiedzie malezy
sobie samemu posprząta wadliwe wpisy.
>> Polacam napisanie procedury budującej model ARMA w Haskellu. Jak
>> powiedziałem w funkcyjnym R to jest jedna linia kodu.
>
> A możesz pokazać?
Co? Model ARMA? Czy język R?
>> Zachwycony to zadużo powiedziane. Natomiast myślę,
>> że potrafię się nimi posługiwać
>
> No to dobry jesteś, biorąc pod uwagę że nawet kompilator
> c++ potrafi je sam rozwikłać tylko w trywialnych przypadkach.
Hmmm...? Który kompilator i co to jest trywialny przypadek?
>>>> class < IF < isIntergral <Type>, IntegralPower, RealPower > >
>>>> MatrixPower;
[...]
> Tyle samo z dokładnością do czytelnego zapisu.
Czytelność to kwestia przyzwyczajenia -- patrz Lisp i jego ().
>> Pan Karpierz pisał o C++ i do tego się odnoszę
>> -- twierdzę, że to nieuzasadniona opinia.
>
> A ja twierdzę, że (skoro też wolisz opis relatywny) c++ jest
> na niższym poziomie niż python, smalltalk albo haskell.
Może i na niższym, ale nadal jest w tej kaście. Trzeba byłoby mieć konkretne
przykłady referencyjne.
Pozdrawiam.
[1] http://en.wikipedia.org/wiki/High-level_programming_language
Seweryn Habdank-Wojewódzki
Piotr Sawicki wrote:
>> BTW ewentualna stałość może być wynikiem optymalizacji.
>> Są algorytmy, które tak tasują dane w strukturze pamięci, że dostęp do
>> często uzywanych elementów znajduje się pod stałymi adresami w bliskim
>> rejonie w szczególności w pamięci cache procesora.
>> Czy języki korzystające z tego ficzeru są niskopoziomowe?
>
> To nie cecha języka, tylko kompilatora/jit-u/vm-u.
> I zwykło się ją nazywać zoptymalizowaniem.
A mnie się wydawało, że obecność, np. GC jest cechą języka a nie vm itp.?
Widziałeś Javę bez GC? Specyfikacja tego *języka* zakłda obecność GC.
Seweryn Habdank-Wojewódzki
Piotr Sawicki wrote:
> Nie do końca chwytam o co Ci chodzi, location transparency?
> Jest w erlangu domyślnie, bez żadnych dodatkowych interfejsów.
Ale to już kolejny język. Który zresztą nie ma wielu innych cennych
ficzerów, które np. są w Pythonie. Gdyby miał, to już dawno wszyscy by w
nim pisali nie uważasz?
Dla każdego ficzeru języka istnieje język, który go spełnia. Natomiast nie
prawda jest, że istnieje jezyk mający każdy ficzer.
Jeden ficzer nie czyni języka rewelacyjnym, co najwyżej specjalizowanym.
Artur M. Piwko
Sulsa <su...@dontmail.me> screamed:
> wbrew pozora assembler tez jest w pewnym stopniu przenosny i dziala w
> pewnym oderwaniu od sprzetu bo np.: instrukcja(program)
>
> mov zmienna1, zmienna2
>
> bedzie przenosna miedzy platformami, na których wystepuje ta instrukcja
> mimo tego ze moga one posiadac rozne kody operacji dla tej instrukcji.
I to też nie do końca.
W jednych będzie to
MOVE src, dst
w drugich
MOV dst, src
Do tego dochodzą jeszcze problemy z różnym zachowaniem się dosyć
istotnej rzeczy, jakim jest rejestr statusu.
Jedne ustawiają (np. LDA $01 w 6502), inne nie (LD A, B w Z80).
--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:236B ]
[ 12:52:58 user up 11683 days, 0:47, 1 user, load average: 0.36, 0.99, 0.59 ]
Everybody wants to go to heaven, but nobody wants to die. -- Joe Louis
Wojciech Muła
> wbrew pozora assembler tez jest w pewnym stopniu przenosny i dziala w
> pewnym oderwaniu od sprzetu
Dawno nie słyszałem równie nonsensownego stwierdzenia.
w.
Piotr Sawicki
>
>> zauważ, że type class w Haskellu to zupełnie co
>> innego niż klasa w sensie OOP, jeden stopien abstrakcji wyżej.
>
> Nie widzę tego.
Definiuje klasy abstrakcji na typach (a nie na wartościach/obiektach,
jak oop-klasa). To mniej więcej jak interfejs w javie.
> Tak jak generyki Haskelowe według niektórych są powyżej
> wszelkich generyków a dla nie one nie wyskakują powyżej referencji
> na okreslony interfejs. Ale może kwestia spojrzenia.
Zupełnie nie chwytam.
>>> Wysokopoziomowe są języki potrafiące w łatwy sposób
>>> odwzorować myślenie ludzkie na kod.
>>
>> Chałowa taka definicja
>
> Lespza według Ciebie jest taka w której Pan Kaprpierz
> lstuje według jego widzimi się jest wyskopoziomowe a co nie?
Jakby mi się podobała, to bym się nie wtrącał ze swoją.
Tylko że definicja oparta na subiektywnym pojmowaniu wzoru
ludzkiego myślenia też pośrednio odwołuje się do widzimisia.
[przesortowałem]
>>> Według definicji ogólnych poziom języka to oddalenie
>>> kodu programu odspecyfiki maszyny
>>
>> Z takim ujęciem niskopoziomowości się spotkałem...
>
> A ja tak.
:)... Toż piszę że się spotkałem.
>>> na rzecz myślenia człowieka.
>>
>> ... ale z tym nigdy. Jakieś źródło?
>
> Wikipedia póki co nie mam lepszego.
> [myk]
> "high-level language" refers to the higher level
> of abstraction from machine language.
Tu nie ma mowy o myśleniu człowieka, jest o wyższym poziomie
abstrakcji. Co ja rozumiem w ten sposób, że na zerowym piętrze
są gołe dane, na pierwszym przekształcenia danych (program),
a wyżej - przekształcenia również samego programu.
> Nie ma w tym nic prezyzyjniejszego niż w moje "definicji".
Nie zarzucam jej nieprecyzyjności, wydaje mi sie ona nieunikniona.
> Wystrczy poniżej ludzkiego swobodnego myślenia wstawić matematykę,
To już zupełnie inna rozmowa. Ale matematyka dostarcza jedynie
języku opisu, jakość trzeba tę własność sformułować.
>>> Nie. Strong typing tu jest połączony z operator overloading
>>> i z faktem, że język ma kompilator. Już się robią trzy cechy.
>>
>> Trzy cechy systemu typów, a nie całego języka.
>
> Kompilacja nie jest cechą żadnego typu.
> To tez dotyczy Haskella, Ady itd.
Przecież chodzi o static typing, czyli możliwość wyłapania błędów
jeszcze przed zapuszczeniem programu, a nie kompilowanie samo
w sobie. Do haskella jest i kompilator i interpreter, przy tym samym
statycznym systemie typów (modulo eksperymentalne rozszerzenia).
>>> dla F = m * a IMHO C++ jest świetny,
>>
>> Tylko wymaga wprowadzania jakichś idiotycznych pseudofunkcji w rodzaju
>> kilo(), żeby typechecker mógł zatrybić. Typami algebraicznymi
>> (choćby z Haskella) można zrobić to samo, tylko zgrabniej.
>
> Zgrabniej czyli? Kodzku nie widzę.
data Measurable = Mass Float | Acceleration Float | Force Float
deriving (Eq, Show)
instance Num Measurable where
(Mass m) * (Acceleration a) = Force (m*a)
(Acceleration a) * (Mass m) = Force (a*m)
m = Mass 10
a = Acceleration 9.81
f = m*a
-- f = m/a lub m = f*a : error
Wszystko. Oczywiście można dorobić możliwe różne jednostki,
bez zaprzęgania do tego nic nie robiących pseudofunkcji.
>>> Każdy język "wysokiego poziomu" ma zaszyty w sobie jakiś
>>> dedykowany engine. Jesli go nie ma w jakiejś działce,
>>> to jest nagle językiem niskiego rzędu.
>>
>> Musisz mieć bardzo dziwne rozumienie tego zaszytego engine'u
>> skoro ten sam język raz go ma a raz nie, zależnie od działki.
>
> Znam wiele dziwnych rzeczywistych przykładów i to mnie
> skutecznie izoluje od filozofowania.
A ja nie dość że zastanawiam się co mogłeś mieć na myśli
używając terminu engine, to jeszcze mówię prozą.
> Oracle + SQL: komenda "insert" sama dba o spójność bazy sama
> blokuje co trzeba, same rozdaje dane gdzie trzeba. Kiedy
> wstawianie sie nie powidzie w pełni. baza sama robi roll back.
>
> Języki wysokopoziomowe:
> insert do kolekcji + wątki: "figa z makiem" jak user sam nie założy
> sekcji krytycznej to nie ma blokowania. Kiedy cały insert się nie
> powiedzie malezy sobie samemu posprząta wadliwe wpisy.
Zmyliła mnie niespójność między jednym enginem a wielością działek.
No dobra, jak zwał tak zwał. Sęk w tym, że języki o wysokim poziomie
abstrakcji dużo brakujących cech potrafią nadrobić biblioteką,
przezroczyście dla używającego jej programisty.
>>> Polacam napisanie procedury budującej model ARMA w Haskellu. Jak
>>> powiedziałem w funkcyjnym R to jest jedna linia kodu.
>>
>> A możesz pokazać?
>
> Co? Model ARMA? Czy język R?
Tę linijkę w R z procedurą budującą model ARMA.
>> nawet kompilator c++ potrafi je sam rozwikłać
>> tylko w trywialnych przypadkach.
>
> Hmmm...? Który kompilator i co to jest trywialny przypadek?
Każdy kompilator. To raport opisuje typowanie pomieszane
z parsowaniem i nieliniowe pozapętływane konkretyzowanie
szablonów. A już rozdział o disambiguities to horror.
Trywialne są te, gdzie nie ma wielokrotnych współzależności.
>> Tyle samo z dokładnością do czytelnego zapisu. [funktora]
>
> Czytelność to kwestia przyzwyczajenia -- patrz Lisp i jego ().
functor f(parametr : sygnatura) = struct (*...*) end
Piotr Sawicki
Piotr Sawicki
>
>>> BTW ewentualna stałość może być wynikiem optymalizacji.
>>> Są algorytmy, które tak tasują dane w strukturze pamięci, że dostęp do
>>> często uzywanych elementów znajduje się pod stałymi adresami w bliskim
>>> rejonie w szczególności w pamięci cache procesora.
>>> Czy języki korzystające z tego ficzeru są niskopoziomowe?
>>
>> To nie cecha języka, tylko kompilatora/jit-u/vm-u.
>> I zwykło się ją nazywać zoptymalizowaniem.
>
> A mnie się wydawało, że obecność, np. GC jest cechą języka a nie vm itp.?
> Widziałeś Javę bez GC? Specyfikacja tego *języka* zakłda obecność GC.
Istnienie GC lub nie radykalnie zmienia postać tekstu programu w danym
języku, natomiast to czy w implementacji zmienne są trzymane na stosie,
na stercie, w keszu, w sposób zoptymalizowany czy naiwny - nie odbija
się na źródle programu (chyba że jest niskopoziomowy i sam tam grzebie).
Ten sam język można interpretować albo różnie kompilować. Absurdalna
wydaje mi się taka definicja wysokopoziomowości, w której język
przestawałby być wysokopoziomowy po napisaniu lepszego kompilatora.
Piotr Sawicki
Piotr Sawicki
>
>> Nie do końca chwytam o co Ci chodzi, location transparency?
>> Jest w erlangu domyślnie, bez żadnych dodatkowych interfejsów.
>
> Ale to już kolejny język.
Same w sobie smart pointers robią to, co wszędzie z GC jest
za darmo. A to co da się dodać biblioteką w C++, da się też
gdzie indziej, tylko wyjdzie ładniej. Poza niskopoziomową obsługą
sprzętu, ale do tego w zupełności wystarczy biblioteka w C.
> Który zresztą nie ma wielu
> innych cennych ficzerów, które np. są w Pythonie.
Wielu? Jakich konkretnie Ci brakuje?
Dla mnie jest przede wszystkim mniej czytelny od Pythona, za mało
tylko syntactic sugar (no ale ja nie wszystko uważam za przydatne).
> Gdyby miał, to już dawno wszyscy by w nim pisali nie uważasz?
Nie uważam. W popularności języków programowania kluczową
rolę odgrywają czynniki zupełnie różne od bogactwa ficzerów.
> Dla każdego ficzeru języka istnieje język, który go spełnia.
Tautologia.
> Jeden ficzer nie czyni języka rewelacyjnym, co najwyżej specjalizowanym.
Akurat Erlang to język obładowany ficzerami jak wielbłąd.
Piotr Sawicki
Seweryn Habdank-Wojewódzki
Piotr Sawicki wrote:
>>> zauważ, że type class w Haskellu to zupełnie co
>>> innego niż klasa w sensie OOP, jeden stopien abstrakcji wyżej.
>>
>> Nie widzę tego.
>
> Definiuje klasy abstrakcji na typach (a nie na wartościach/obiektach,
> jak oop-klasa). To mniej więcej jak interfejs w javie.
Myśle, że to nie jest jeden poziom abstrakcji wyżej. Był już o tym dyskusja
na grupie o C.
Np. klasa Double czy też typ double jest podobny do Integer czy int. np. w
sensie dodawanie itd.
Szablony w C++ pozwalają na ocenę np. isIntegral, bez wnikania czy klasa/typ
ma jakieś swoje metody. W każdym razie nie zawsze interfejs "omawia" cechy
klasy/typu.
Ale to jest NTG i nie będę kontynuował tego tematu, bo był omawiany na
grupie o C.
>> Tak jak generyki Haskelowe według niektórych są powyżej
>> wszelkich generyków a dla nie one nie wyskakują powyżej referencji
>> na okreslony interfejs. Ale może kwestia spojrzenia.
>
> Zupełnie nie chwytam.
Poszukaj wspomnianego wątku na grupie o C.
>> Nie ma w tym nic prezyzyjniejszego niż w moje "definicji".
>
> Nie zarzucam jej nieprecyzyjności, wydaje mi sie ona nieunikniona.
Mi chodzi, że jakaś JEST :-). Pan Karpierz nie dysponuje żadną i na
podstawie braku definicji podaje twierdzenia istne kuriozum wnioskowania.
>> Wystrczy poniżej ludzkiego swobodnego myślenia wstawić matematykę,
>
> To już zupełnie inna rozmowa. Ale matematyka dostarcza jedynie
> języku opisu, jakość trzeba tę własność sformułować.
Hmmm... nie całkiem mi o to chodzi. Chodzi o formalność zapisu i kolejnych
definicji. W szczególności, że matematyka od liczb naturalnych doszła do
teorii modeli.
> data Measurable = Mass Float | Acceleration Float | Force Float
> deriving (Eq, Show)
>
> instance Num Measurable where
> (Mass m) * (Acceleration a) = Force (m*a)
> (Acceleration a) * (Mass m) = Force (a*m)
>
> m = Mass 10
> a = Acceleration 9.81
> f = m*a
> -- f = m/a lub m = f*a : error
>
> Wszystko.
Super, podoba mi się. Ale czemu to jest zgrabniej?
> Tę linijkę w R z procedurą budującą model ARMA.
Przykładzik
Budowa modelu ARMA:
lm(y[-c(1:5)] ~ y[-c((n-4):n)])
Koniec :-).
Poprostu R zawiera engine do takich rzeczy i potrafi to wykonać. R jest
funkcyjny, Matlab jest (od niedawna) obiektowy i imperatywny i też to
potrafi -- kwestia tego co język zawiera w sobie.
Pozdrawiam.
Seweryn Habdank-Wojewódzki
Piotr Sawicki wrote:
>> Który zresztą nie ma wielu
>> innych cennych ficzerów, które np. są w Pythonie.
>
> Wielu? Jakich konkretnie Ci brakuje?
> Dla mnie jest przede wszystkim mniej czytelny od Pythona, za mało
> tylko syntactic sugar (no ale ja nie wszystko uważam za przydatne).
Ot tak z rękawa (nie jestem specem od Erlanga), nie widze dekoratorów czy
metaklas.
>> Jeden ficzer nie czyni języka rewelacyjnym, co najwyżej specjalizowanym.
>
> Akurat Erlang to język obładowany ficzerami jak wielbłąd.
Hmmm... może ma mały marketing :-).
Seweryn Habdank-Wojewódzki
Piotr Sawicki wrote:
> Istnienie GC lub nie radykalnie zmienia postać tekstu programu w danym
> języku, natomiast to czy w implementacji zmienne są trzymane na stosie,
> na stercie, w keszu, w sposób zoptymalizowany czy naiwny - nie odbija
> się na źródle programu (chyba że jest niskopoziomowy i sam tam grzebie).
Oczywiście. To powinno byc nie widoczne.
> Ten sam język można interpretować albo różnie kompilować. Absurdalna
> wydaje mi się taka definicja wysokopoziomowości, w której język
> przestawałby być wysokopoziomowy po napisaniu lepszego kompilatora.
Tak.
Sulsa
To udowodnij to Panie wszechwiedzaca wyrocznio tytulujaca sie
ostateczna objawiona prawda. Jakies fakty czy tylko twoje niezwykle
autorytatywne poparte znanym na calym swiecie nazwiskiem zdanie
wnoszace jakze wiele bezcennej, czczonej przez pokolenia prawdy(wrecz
wiary!) do tej dyskusji?
Sulsa
"Artur M. Piwko" <milusi.p...@buziaczek.pl> wrote:
> > bedzie przenosna miedzy platformami, na których wystepuje ta instrukcja
> > mimo tego ze moga one posiadac rozne kody operacji dla tej instrukcji.
>
> I to też nie do końca.
> W jednych będzie to
> MOVE src, dst
> w drugich
> MOV dst, src
Tu mówisz o dwóch róznych jezykach, jednen to assebler wedlug intela
drugie wedlug... no coz nie pamietam.
> Do tego dochodzą jeszcze problemy z różnym zachowaniem się dosyć
> istotnej rzeczy, jakim jest rejestr statusu.
> Jedne ustawiają (np. LDA $01 w 6502), inne nie (LD A, B w Z80).
No coż o czyms takim jak rejestr statusu nigdy nie slyszalem, ale to
jest przenosne do pewnego stopnia tak samo jak kod w c:
int *ptr2 = inicjalizuj();
int ptr1 = ptr2;
na jednych platformach bedzie poprawne na innym obetnie pare bitów.
Artur M. Piwko
Sulsa <su...@dontmail.me> screamed:
>> > bedzie przenosna miedzy platformami, na których wystepuje ta instrukcja
>> > mimo tego ze moga one posiadac rozne kody operacji dla tej instrukcji.
>>
>> I to też nie do końca.
>> W jednych będzie to
>> MOVE src, dst
>> w drugich
>> MOV dst, src
>
> Tu mówisz o dwóch róznych jezykach, jednen to assebler wedlug intela
> drugie wedlug... no coz nie pamietam.
>
AT&T?
>> Do tego dochodzą jeszcze problemy z różnym zachowaniem się dosyć
>> istotnej rzeczy, jakim jest rejestr statusu.
>> Jedne ustawiają (np. LDA $01 w 6502), inne nie (LD A, B w Z80).
>
> No coż o czyms takim jak rejestr statusu nigdy nie slyszalem, ale to
> jest przenosne do pewnego stopnia
Przenośny do pewnego stopnia - tak. Ale do małego. W praktyce sprowadza
się do przepisania kodu.
> tak samo jak kod w c:
>
> int *ptr2 = inicjalizuj();
> int ptr1 = ptr2;
>
> na jednych platformach bedzie poprawne na innym obetnie pare bitów.
>
Problem, że w jednym przypadku masz np. NV-BDIZC a w drugim SZ-H-VAC.
Wiem, że to przykłady z dosyć starych architektur, ale na tym
przykładzie najprościej pokazać, że przenośność asemblera == przepisanie
całego kodu...
--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:226B ]
[ 07:49:21 user up 11684 days, 19:44, 1 user, load average: 0.50, 0.98, 0.68 ]
Nothing ever becomes real until it is experienced.
Wojciech Muła
> To udowodnij to Panie wszechwiedzaca wyrocznio tytulujaca sie
> ostateczna objawiona prawda. Jakies fakty czy tylko twoje niezwykle
> autorytatywne poparte znanym na calym swiecie nazwiskiem zdanie
> wnoszace jakze wiele bezcennej, czczonej przez pokolenia prawdy(wrecz
> wiary!) do tej dyskusji?
Napij się melisy.
w.
Piotr Sawicki
>> data Measurable = Mass Float | Acceleration Float | Force Float
>> deriving (Eq, Show)
>>
>> instance Num Measurable where
>> (Mass m) * (Acceleration a) = Force (m*a)
>> (Acceleration a) * (Mass m) = Force (a*m)
>>
>> m = Mass 10
>> a = Acceleration 9.81
>> f = m*a
>> -- f = m/a lub m = f*a : error
>>
>> Wszystko.
>
> Super, podoba mi się. Ale czemu to jest zgrabniej?
Znacznie krótsze i czytelniejsze definicje, brak potrzeby
używania wszędzie w obliczeniach pustych funkcji takich jak
kilo(), język sam domyśla się typów tam gdzie to tylko możliwe
(tutaj masa i przyspieszenie były jawnie skonstruowane, ale
siła już ma wydedukowany typ). A przede wszystkim, program
jest znacznie bliższy modelu - zależności między wielkościami
fizycznymi opisuje algebra i Haskell ma od tego algebraiczne
typy danych. Paradygmat obiektowy skupia się na operacjach
wewnątrz klasy i trzeba cudować z friendami. Działa, ale
tak jak w dowcipie o testowaniu milicjantów dziecięcą
zabawką od wkładania do sześcianu klocków o różnym
kształcie: 99% wykazało się wybitną siłą.
> Budowa modelu ARMA:
>
> lm(y[-c(1:5)] ~ y[-c((n-4):n)])
>
> Koniec :-).
> Poprostu R zawiera engine do takich rzeczy i potrafi to wykonać.
> R jest funkcyjny, Matlab jest (od niedawna) obiektowy i imperatywny
> i też to potrafi -- kwestia tego co język zawiera w sobie.
Schowałeś kod za procedurą biblioteczną do tworzenia modeli liniowych.
Biblioteki naukowe (bo to nie kwestia silnika) są przecież i do Haskella
i do Pythona (GSL czy SciPy), tak samo sekwencje i indeksy. Brakuje tylko
takiego jak w R wsparcia składniowego dla formuły modelu, więc zmieni się
tyle, że jej konstruktory nie będą infiksowe i bardziej rozwlekle nazwane.
Piotr Sawicki
Piotr Sawicki
>>
>> Wielu? Jakich konkretnie Ci brakuje?
>> Dla mnie jest przede wszystkim mniej czytelny od Pythona, za mało
>> tylko syntactic sugar (no ale ja nie wszystko uważam za przydatne).
>
> Ot tak z rękawa (nie jestem specem od Erlanga),
> nie widze dekoratorów czy metaklas.
A są klasy?
Bo dekoratory to głównie ozdobik składniowy, a funkcje
wysokiego rzędu są przecież dla siebie metafunkcjami.
>>> Jeden ficzer nie czyni języka rewelacyjnym,
>>> co najwyżej specjalizowanym.
>>
>> Akurat Erlang to język obładowany ficzerami jak wielbłąd.
>
> Hmmm... może ma mały marketing :-).
Mam (być może mylne) wrażenie, że w wielkoskalowych systemach
rozproszonych jest nie do pobicia, ale poza nimi nie ma
właściwie zalet nad innymi dobrymi językami, a wad sporo.
Piotr Sawicki
Wit Jakuczun
Seweryn Habdank-Wojewódzki <shw_...@wp.pl> napisał(a):
> Poprostu R zawiera engine do takich rzeczy i potrafi to wykonać. R jest
> funkcyjny, Matlab jest (od niedawna) obiektowy i imperatywny i też to
> potrafi -- kwestia tego co język zawiera w sobie.
>
R jest nie tylko funkcyjny ale także obiektowy a jego
dynamiczność jest na poziomie pythona. Nie jest
deklaratywny, chociaż dzięki przejrzystej składni i
bogatych bibliotekach wygląda jak język deklaratywny
dla użytkownika.
I sprawdza się w zastosowaniach produkcyjnych
na dość dużą skalę.
Pozdrawiam
--
[ Wit Jakuczun <W.Jakuczun [at] wlogsolutions.com> ]
[ WLOG Solutions http://www.wlogsolutions.com ]
Wit Jakuczun
Seweryn Habdank-Wojewódzki <shw_...@wp.pl> napisał(a):
>
> Budowa modelu ARMA:
>
> lm(y[-c(1:5)] ~ y[-c((n-4):n)])
>
Albo lepiej skorzystać z funkcji
model <- arima( szereg, order=(p,d,q), seasonal=list( period=N, order=(P,D,Q), xvar=X)
która buduje model SARIMAX. W szczególności arima tworzy model
arma korzystając z estymatorów MLE.
Adam Karpierz
>> Do tego dochodzą jeszcze problemy z różnym zachowaniem się dosyć
>> istotnej rzeczy, jakim jest rejestr statusu.
>> Jedne ustawiają (np. LDA $01 w 6502), inne nie (LD A, B w Z80).
> No coż o czyms takim jak rejestr statusu nigdy nie slyszalem, ale to
> jest przenosne do pewnego stopnia tak samo jak kod w c:
Jesli nie slyszales w assemblerze o czyms takim jak:
status operacji, flaga czy tp, to juz lepiej nie mow ani slowa
o zadnym assemblerze ani czymkolwiek jego tyczacym.
AK
Seweryn Habdank-Wojewódzki
Piotr Sawicki wrote:
> Znacznie krótsze i czytelniejsze definicje, brak potrzeby
> używania wszędzie w obliczeniach pustych funkcji takich jak
> kilo()
Kilo top jest synonim 10^3, i nic więcej ani mniej. Więc nie jest ona pusta
i ma za zadanie SŁOWNIE podkreślić, że aktualnie wartośc jest liczona jako
kilo. Tak więc jest to przejżystość kodu, a nie bezsensowna funkcja.
> , język sam domyśla się typów tam gdzie to tylko możliwe
> (tutaj masa i przyspieszenie były jawnie skonstruowane, ale
> siła już ma wydedukowany typ).
Nie wydaje mi się. Bo jak przed f = m * a postawisz wpis błędny, to siła
będzie miała błędnie ustalony (indukowany) typ, a właściwy zostanie
okreslony jako błędny.
> A przede wszystkim, program
> jest znacznie bliższy modelu - zależności między wielkościami
> fizycznymi opisuje algebra i Haskell ma od tego algebraiczne
> typy danych.
Co to jest algebraiczny typ danych?
> Paradygmat obiektowy skupia się na operacjach
> wewnątrz klasy i trzeba cudować z friendami.
Nie mam żadnych friendów.
> Schowałeś kod za procedurą biblioteczną do tworzenia modeli liniowych.
Nie prawda. To jest właśnie język R i jego wysokopoziomowość!
> Biblioteki naukowe (bo to nie kwestia silnika) są przecież i do Haskella
> i do Pythona (GSL czy SciPy), tak samo sekwencje i indeksy. Brakuje tylko
> takiego jak w R wsparcia składniowego dla formuły modelu, więc zmieni się
> tyle, że jej konstruktory nie będą infiksowe i bardziej rozwlekle nazwane.
Nie prawda! Żaden z tych języków nie ma wsparcia do modeli ARMA, do tego są
płatne biblioteki. Żadna GSL, czy SciPy nie dorasta do R, gdyby dorastała
to nie używałbym R. To jest osobny język funkcyjny, dynamicznie typowany.
Poprostu wtej materii jest on bardzo wysokopozimowy. Zapisujesz dokładnie
to co masz na myśli -- "tworzę model liniowy o okreslonej strukturze" -- i
tyle.
Piotr Sawicki
>
>> brak potrzeby używania wszędzie w obliczeniach
>> pustych funkcji takich jak kilo()
>
> Kilo top jest synonim 10^3, i nic więcej ani mniej.
> Więc nie jest ona pusta i ma za zadanie SŁOWNIE podkreślić,
> że aktualnie wartośc jest liczona jako kilo. Tak więc jest
> to przejżystość kodu, a nie bezsensowna funkcja.
Więc bez sensu żeby to była funkcja
(pusta bo nie ma kodu), wystarczy symbol.
>> , język sam domyśla się typów tam gdzie to tylko możliwe
>> (tutaj masa i przyspieszenie były jawnie skonstruowane, ale
>> siła już ma wydedukowany typ).
>
> Nie wydaje mi się. Bo jak przed f = m * a postawisz wpis
> błędny, to siła będzie miała błędnie ustalony (indukowany)
> typ, a właściwy zostanie okreslony jako błędny.
Źle Ci się wydaje, po to w typie Measurable zdefiniowana
była algebra działań na masie, przyspieszeniu i sile,
żeby Haskell sam się domyślał typów wyrażeń.
>> A przede wszystkim, program jest znacznie bliższy modelu
>> - zależności między wielkościami fizycznymi opisuje
>> algebra i Haskell ma od tego algebraiczne typy danych.
>
> Co to jest algebraiczny typ danych?
W skrócie : te konstruowane przez programistę
w językach funkcyjnych. Np:
data Tree a = Leaf a | Branch (Tree a) (Tree a)
Język potrafi potem sam sprawdzać zgodność wyrażeń
i pozwala na pattern matching w definicjach.
>> Paradygmat obiektowy skupia się na operacjach
>> wewnątrz klasy i trzeba cudować z friendami.
>
> Nie mam żadnych friendów.
A pokażesz jakie w takim razie miałeś definicje
typów/klas w tym przykładzie fizycznym dla C++?
>> Schowałeś kod za procedurą biblioteczną do tworzenia modeli liniowych.
>
> Nie prawda. To jest właśnie język R i jego wysokopoziomowość!
To lm nie jest funkcją do budowania modeli liniowych dla podanej
formuły ? Zdaje się że w matlabie trzeba to zrobić na dwa razy:
polyfit pierwszego stopnia a potem polyval?
>> Biblioteki naukowe (bo to nie kwestia silnika) są przecież i do Haskella
>> i do Pythona (GSL czy SciPy), tak samo sekwencje i indeksy. Brakuje tylko
>> takiego jak w R wsparcia składniowego dla formuły modelu, więc zmieni się
>> tyle, że jej konstruktory nie będą infiksowe i bardziej rozwlekle nazwane.
>
> Nie prawda!
Że funkcje obliczalne da się zaprogramować w językach Turing-kompletnych?
> Żaden z tych języków nie ma wsparcia do modeli ARMA,
> do tego są płatne biblioteki.
Może nie zrozumiałem kryptycznego zapisu, ale mam wrażenie,
że sam przedstawiłeś dość proste rozwiązanie metodą najmniejszych
kwadratów. Przy czym model łączący średnią ruchomą z autoregresją
to nie są jakieś znowu nieprzekraczalne wyżyny abstrakcji.
> Żadna GSL, czy SciPy nie dorasta do R, gdyby dorastała
> to nie używałbym R. To jest osobny język funkcyjny, dynamicznie typowany.
OK, wiem że to wysokopoziomowy język, i wierzę na słowo, że jego
wbudowana biblioteka naukowa jest znacznie szersza niż w innych.
Tyle że wszystkomających bibliotek można używać nawet w asemblerze.
> Poprostu wtej materii jest on bardzo wysokopozimowy.
> Zapisujesz dokładnie to co masz na myśli --
> "tworzę model liniowy o okreslonej strukturze" -- i tyle.
E tam, nikt nie myśli ,,y[-c(1:5)] ~ y[-c((n-4):n)]''. Po prostu
nauczyłeś się zapisywać modele w składni R. Która jest - przyznaję
- wygodna. Ale możliwa do podobnego zapisania w innym języku.
Piotr Sawicki