W dniu wtorek, 6 stycznia 2015 23:05:00 UTC+1 użytkownik M.M. napisał:

> Nie lepiej zrobić 3 języki, począwszy od 'niskopoziomowych' z wskaźnikami,

C++, tylko nie dotykaj sensownych zabawek.

> skończywszy na czymś jak C++ bez wskaźników i z tablicami z automatycznym
> sprawdzaniem zakresów tablic ?

Znów C++. Znów jedynie ograniczony wywieską
na ścianie 'koduj tak a tak'.

Pośrodku, niech zgadnę, będzie c++.

Dość lubię ten język, no i omne trinum perfectum,
ale tu chyba nieco przesadzasz.
;-)


> Przecież Python pochłonął masę pracy, nie
> lepiej było tę pracę zainwestować inaczej?

Pobudki masz może słuszne, ale to, co proponujesz,
to na dobrą sprawę zahamowanie jakiegokolwiek postępu.
"Główne języki" nie będą się tak szybko rozwijać, jeśli
nie będą czuły na karku oddechu konkurencji.
Do tego nowinki są pewnym poligonem doświadczalnym.
Nie wszytko jest sens testować jako odnogi gcc.

pzdr
bartekltg

do góry

W dniu wtorek, 6 stycznia 2015 23:52:46 UTC+1 użytkownik M.M. napisał:
> On Tuesday, January 6, 2015 11:28:55 PM UTC+1, firr wrote:
> > nie wiem, ale moge powiedziec ze podobienstwo jezykow moze byc zludne, tak
> > naprawde jezyki niby podobne do siebie moga byc jednak w spory sposob rozne bo
> > sa to dosyc abstrakcyjne twory
> > - tak ze nie koniecznie musi byc tak ze 350ty jezyk nic juz nie wnosi
> Zależy czy rozmawiamy o językach ogólnego przeznaczenia czy o językach
> specjalistycznych. W przypadku zastosowań specjalistycznych warto:
> 1) pogłówkować nad statystycznie wygodną/zwartą składnią
> 2) poświęcić czas na opanowanie tejże składni.
> W przypadku języków ogólnego przeznaczenia, zwłaszcza w świetle tego faktu
> że istnieją biblioteki programistyczne, moim zdaniem czwarty język już nic
> nie wnosi, nie wspominając o 350tym. Kolejny język to tylko zamęt, tak samo
> jak kolejna biblioteka do GUI, albo kolejny XString w C++.
>
> Na jakie pytania trzeba znać odpowiedzi, aby wybrać odpowiedni język
> ogólnego przeznaczenia? Może zacznijmy tę rozmowę od takich pytań.
> Wtedy się okaże, czy kolejny język jest potrzebny.
>
eozne jezyki (nawet tylko te ogolnego przeznaczenia) maja jednak rozne cechy..

w pewnej 'ogolnej mierze' spora czesc znich wymaga wiedzy jakby z 'jednego obszaru'
ale tez te cechy je roznicują i ludzie raczej
beda je chcieli dobierac sopbie roznie i po swojemu

mozliwe ze w 'obrocie' tych jezykow nie musialobybyc duzo ale przydaloby sie
zorientowac ktore te cechy sa dobre i w
czym i dlaczego itp

do góry

W dniu wtorek, 6 stycznia 2015 23:59:56 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
> [...]
> > (python bywa niekiedy
> > okreslany mianem "wykonujacego sie pseudokodu")
>
> ...co jest bzdurą, bo pseudokod z definicji omija nieistotne dla danej
> sprawy rzeczy, a Python jednak wymaga kompletnego programu. Zresztą
> o tym pierwszy raz czytam u ciebie, więc twoje "niekiedy" chyba się
> sprowadza do "ja tak robię".

https://www.youtube.com/watch?v=zJOS0sV2a24
20:45 - 21:10
misiu
(hint: ten pan na filmie to nie jestem ja)

> > najwiekszymi wadami wydaja mi sie dziwny model obiektowy (do ktorego jednak
> > mozna sie przyzwyczaic) oraz balagan panujacy w wersjach pythona.
>
> Nie wiem co masz do modelu obiektowego w Pythonie, bo jest mniej więcej
> typowy dla współczesnych języków obiektowych.

poza tym, ze np. nie wspiera enkapsulacji, misiu.

> A w wersjach jest porządek. Liniowy porządek w
> obrębie danego wydania (2.x, 3.x).

porzadek jest. co nie zmienia faktu, ze jest strasznie duzo
"wersji jezyka" i to niczemu nie pomaga. to tylko nalecialosci
historyczne, misiu

> > powaznym problemem jest tez brak systemu typow
>
> OK, po tym widać że nie wiesz o czym mówisz, więc przestań. Typów to nie
> ma w rachunku lambda, a nie w Pythonie.

skoro przeszkadza ci, ze mowie, to moze dodaj mnie do swojego killfile'a,
misiu

> > irytujace wydaje sie rowniez to, ze autor pythona, Guido van Rossum,
> > sprawia wrazenie kompletnego ignoranta w kwestii jezykow programowania
>
> I mówi to ktoś, kto nie odróżnia braku systemu typów od dynamicznego
> systemu typów.

odroznia tam, gdzie to rozroznienie ma sens, misiu

do góry

ktos (co tam ostatnio cztalem nazwal pythona interpretowanym c - nie do konca ale w
ajkims
sensie to me sens, tak na to spojrzwszy chyba glowna roznica w tej interpretowalnosci
polega w podejsciu do kontenerów 9i 2ga ew w podejsciu do bibliotek), c ma nieststy
bardzo skostniele podejscie do kontenerow, - w c trzebaby je napisac a nawet wtedy
trzabby pilnowac czy sa dobrzeuzywane co i tak prowadziloby do rozleglej jak nie
skostnialosci to czegos nieco podobnego (o ile wogole udaloby sie je poprawnie w
duchu c napisac), W pytonie jest podobno inaczej choc nie mam tego praktycznie
przetrenowanego,
druga sprawa to wlasnie podejscie do bibliotek, w c tez jest ono chyba skostniale ze
wzgledu moze na wlasnie skostnialosc
argumentów (jakie jest w pytonie to nie wiem),
byc moze jest tez jakies trzecie pole istotnych roznic

do góry

On 2015-01-07, g...@g...com <g...@g...com> wrote:
>> > najwiekszymi wadami wydaja mi sie dziwny model obiektowy (do ktorego jednak
>> > mozna sie przyzwyczaic) oraz balagan panujacy w wersjach pythona.
>>
>> Nie wiem co masz do modelu obiektowego w Pythonie, bo jest mniej więcej
>> typowy dla współczesnych języków obiektowych.
>
> poza tym, ze np. nie wspiera enkapsulacji, misiu.

Ach, enkapsulacji. Czyli upakowania funkcji operujących na danych i tych
danych w jeden element. Rozumiem. Ty po prostu nie widziałeś kodu
pythonowego na oczy.

>> > powaznym problemem jest tez brak systemu typow
>>
>> OK, po tym widać że nie wiesz o czym mówisz, więc przestań. Typów to nie
>> ma w rachunku lambda, a nie w Pythonie.
>
> skoro przeszkadza ci, ze mowie, to moze dodaj mnie do swojego killfile'a,
> misiu
>
>> > irytujace wydaje sie rowniez to, ze autor pythona, Guido van Rossum,
>> > sprawia wrazenie kompletnego ignoranta w kwestii jezykow programowania
>>
>> I mówi to ktoś, kto nie odróżnia braku systemu typów od dynamicznego
>> systemu typów.
>
> odroznia tam, gdzie to rozroznienie ma sens, misiu

A w Pythonie to nie ma sensu, bo Python nie ma systemu typów, co jest
jego poważnym problemem? Czy może z innego powodu?

I możesz przestać używać mojego zwrotu, zwłaszcza w każdym jednym
akapicie. Chyba stać cię na minimum pomysłowości?

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu środa, 7 stycznia 2015 02:24:53 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:

> Ach, enkapsulacji. Czyli upakowania funkcji operujących na danych i tych
> danych w jeden element. Rozumiem. Ty po prostu nie widziałeś kodu
> pythonowego na oczy.

Nie to słowo.
Enkapsulacja to "bardziej angielski" synonim hermetyzacji.
Ukrycia części kodu/danych przed użytkownikiem obiektu.

To, co opisujesz, upakowanie danych i operacji w jeden
logiczny obiekt, to... po prostu programowanie obiektowe ;-)

pzdr
bartekltg

do góry

W dniu środa, 7 stycznia 2015 02:24:53 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
> >> Nie wiem co masz do modelu obiektowego w Pythonie, bo jest mniej więcej
> >> typowy dla współczesnych języków obiektowych.
> >
> > poza tym, ze np. nie wspiera enkapsulacji, misiu.
>
> Ach, enkapsulacji. Czyli upakowania funkcji operujących na danych i tych
> danych w jeden element. Rozumiem. Ty po prostu nie widziałeś kodu
> pythonowego na oczy.

Oczywiscie sposrod slow obiektowej nowomowy mialem na mysli hermetyzacje,
a nie enkapsulacje. (Mysle jednak, ze kazdy bystry czytelnik zdolal wylapac
ten blad)

> >> > irytujace wydaje sie rowniez to, ze autor pythona, Guido van Rossum,
> >> > sprawia wrazenie kompletnego ignoranta w kwestii jezykow programowania
> >>
> >> I mówi to ktoś, kto nie odróżnia braku systemu typów od dynamicznego
> >> systemu typów.
> >
> > odroznia tam, gdzie to rozroznienie ma sens, misiu
>
> A w Pythonie to nie ma sensu, bo Python nie ma systemu typów, co jest
> jego poważnym problemem? Czy może z innego powodu?

Problem z rozmowa z Toba jest taki, ze jestes do mnie wrogo nastawiony,
misiu, a Twoje "argumenty" maja forme "ad personam" ("widac, ze nie wiesz,
o czym mowisz", "i to mowi ktos, kto...") i sa niemerytoryczne.
Wybacz, ale nie mam teraz czasu na bezowocne przekomarzanki, misiu.

do góry

On Wednesday, January 7, 2015 12:00:55 AM UTC+1, Kviat wrote:
> To tak jak "wszystkie światowe potrzeby" załatwiłyby 3 rodzaje silników.
Dobre porównanie, użycie silnika do tworzenia oprogramowania daje
podobny efekt jak języka programowania.

do góry

W dniu środa, 7 stycznia 2015 06:07:21 UTC+1 użytkownik bartekltg napisał:
>
> To, co opisujesz, upakowanie danych i operacji w jeden
> logiczny obiekt, to... po prostu programowanie obiektowe ;-)
>
dobrze by było ;-CCC zarowno 'łaczenie' jak i 'operacje' jak i 'dane' to podstawowe
pojecia
ze swiata programowania i w jezykach i kodach
mozna i nalezy tego uzywac na wielce rozne sposoby
to co oferuje c++ albo java jako cos co sie zwyczajowo nazywa programowaniem
obiektowym to rodzaj dosyc paskudnej protezy majacej nie
wiele wspolnego z 'ogolnie' łaczeniem operacji
i danych
(dlatego je jesli mowie programowanie
obiektowe odnosze sie do znanego syfu a nie do
ogólnie 'przeswitujacej' koncepcji łaczenia
danych i operacji
odnopsnie tegoco jest w pythonie, to nie przyjrzalem sietemu jeszcze zbyt dokladnie
ale
to co w javie czt c++ bylo oopem w wydaniu javy czy c++ tutaj wydaje sie jest czyms
innym i chyba ma o wiele wiecej sensu (ze wzgledu na dynamiczny charakter pythona
mozna tu uzywac takich 'polaczen' na wiele (?) bardziej doraznych i dynamicznych
sposobów - a to mniej dzieki powinowactwu z oopem a bardziej pewnie dzieki specyfice
i przebudowywalnosci pythonowych kontenerów (1. laczenie nie jest oopem (wciskacze
kitu get out) wlasciwie dpiero jego czesc mozna by uznac za pewne szlachetne
uogolnienie oop (prawdopodobnie),
to co ja np pewnie moglbym wywiesc z koncepcji laczenia struktur z funkcjami (s+f)
nie bardzo pewnie mogloby przypominac tzw oop
2. to co python ma jest w jakiejs czesci oop-em (tym co jest historycznie wciskane
jako oop) ale nie tylko i nie tak do konca i mozliwe ze ma wiecej sensu (nalezalo by
zbadac sprawe, moeze sie zainteresuje)

do góry

W dniu wtorek, 6 stycznia 2015 23:23:41 UTC+1 użytkownik firr napisał:
> > irytujace wydaje sie rowniez to, ze autor pythona, Guido van Rossum,
> > sprawia wrazenie kompletnego ignoranta w kwestii jezykow programowania
>
> a mozesz przyblizyc po czym dokladniej sprawia takie wrazenie? sam nie czytalem
chyab zadnych wypowiedzi i nie kojarze (Kiedys w "koders at work" chyba czytalem
wypowiedzi tworcy javaskryptu i ten 'autor' o ile pamietam mowil z sensem - dlatego
poniekad jakos od pewnego czasu interesuje sie zestwaieniem javascript vs python ale
ledwo znam i ten i ten)

Jest taka ksiazka "Wielkie umysly programowania" (naprawde fatalnie
przetlumaczona na jezyk polski, o czym moze napisze w osobnym watku),
i w niej mozna przeczytac wywiad z Guido.

Tym, co mnie zrazilo, bylo m.in. przytaczane chyba na tej grupie stwierdzenie:
"Prymitywne operacje konieczne do zaimplementowania [pojec z jezykow funkcyjnych] sa
wbudowane w pythonie, natomiast w jezykach funkcyjnych
pojecia te wystepuja jako operacje prymitywne. Operacje 'reduce()' mozna
napisac za pomoca kilku linijek kodu w Pythonie. W jezyku funkcyjnym
jest zupelnie inaczej"

> > (podobne -- ale duzo gorsze -- wrazenia sprawial tworca PHP Rasmus Lerdorf.
>
> nie znam php ni w zab

znasz, tylko o tym nie wiesz
PHP to skladnia C (z tym ograniczeniem, ze wszystkie zmienne musza sie
zaczynac od dolara) i dynamiczne typowanie z lispu (czyli z grubasza taka
jak w Pythonie. W innych modnych jezykach jak Perl czy Ruby znajdziesz
to samo)

> > Z drugiej strony, Larry Wall sprawial lepsze wrazenie, a jednak jezyk
> > Perl -- z tej samej polki co Python czy PHP, tzn. jezykow, ktorych nazwa
> > zaczyna sie na litere "P" -- robi wrazenie groteskowego, pomimo ze bardzo
> > pchnal do przodu kwestie stosowania wyrazen regularnych)
> >

> dla mnie to nie jest + bo raczej szczerze niecierpie wyrazen regularnych (wyaja mi
sie chyab gorsze niz dziwne deklaracje typow w c)
> perla tez nie znam

Wiele problemow zwiazanych z przetwarzaniem tekstu daje sie najzwiezlej
i najwygodniej wyrazic przy pomocy wyrazen regularnych

> 3P mowisz? ostatnio ukulem nazwe 4c - na cztery klony jezyka c tzn java, cs, obj-c
i c++ - bo sa to tak naprawde klony

mowiac szczerze, to nie za bardzo znam jave, c# i objective-c, ale
nie wydaje mi sie, zeby slowo "klon" tutaj dobrze pasowalo. chyba
lepszym slowem bylby "mutant" :)

do góry