W dniu niedziela, 18 stycznia 2015 22:04:59 UTC+1 użytkownik Wojciech Muła napisał:

> > >> 5. Brak tablic.
> > >
> > > A [1,2,3,4] to czym jest? #define tablica
> >
> > Ok, uzupełnię - tablic równie wydajnych jak w Fortranie. Bo to co jest to
> > symulacja tablic na listach.
>
> W takim razie ten punkt to jedynie wariant pierwszego Twojego zastrzeżenia. :)

Do podstawowych liczbowych typów jest array,
ale nie da się tam nic własnego włożyć.

pzdr
bartekltg

do góry

Użytkownik "Wojciech Muła" <w...@g...com> napisał:

> Ok, mój błąd, myślałem, że chodzi Ci o cpythona.

Przyznam sie, ze ja tez identycznei sie pomylilem.
W sprawie Cythona slawek ma 100% racji.
Pomieszanie z poplataniem (wlacznie z delikatnie mowiac "falujaca" miedzy
(sub)wersjami stabilnoscia, a nawet kompilowalnoscia).

PS: Tyle tylko ze Cython to nie Python.

AK


---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe
Avast.
http://www.avast.com

do góry

W dniu sobota, 17 stycznia 2015 19:17:08 UTC+1 użytkownik AK napisał:
> > Na to ja przytoczylem dokladnie zrodlo,
> > z ktorego zaczerpnalem to stwierdzenie.
> > Ty zasugerowales wowczas (o ile dobrze Cie zrozumialem), ze to zrodlo jest
falszywe
>
> CO !? _Gdzie_ stwierdzilem ze jest falszywe ? :)

Nie powiedzialem, ze stwierdziles, ze jest falszywe.
Powiedzialem, ze to _zasugerowales_. Napisales:

"W/g Ciebie z tych (jakze prawdziwych) slow wynika [...]"

i wyrazenie w nawiasie ("jakze prawdziwych") jest sugestia,
ze przytoczone przeze mnie slowa nie sa prawdziwe (a jesli
nie, to w jakim celu je napisales?)

> Falszywe to sa Twoje wnioski z przytoczonych slow.
> Nie wiem skad wysnules/"wyimaginowales" wnioski ze "gap" pomiedzy C i shellem
> to jest alternatywa dla shella.

To moze przytocze ponownie cytowane juz zdanie:

"language to be used in cases where C was overkill
and shell scripts became too cumbersome"

idzie o to, ze ludzie pisali skrypty powloki dla coraz bardziej
zlozonych zastosowan, jednak powloka uniksa jest bardzo marna
jako jezyk programowania.

> Skroce Twoje cierpeinia interpretacyjne:
> Python nigdy nie mial byc alternatywa dla shellow dowolnych, ale mial na celu
> wlasnie zalatanie tej nadmeinionej "gap-y" (nie tylko w stosunku do C zreszta).
> Python juz w swych poczatkach (a potem to jzu w ogole) mial byc typowym
> "glue language" dla Unixa (z czasem stal sie nim rowniez dla innych platform).

Nie wiem, czy masz swiadomosc, ale powloka rowniez czesto sluzy
jako "glue language" dla unixa

> > i okresliles je mianem "czyichs imaginacji", ale ani nie powiedziales,
>
> _Twoje_ bajania okreslilem tym mianem, a nie slowa GvR.

A moglbys przytoczyc ten fragment z Twojej wypowiedzi, z ktorego
wynika, co konkretnie okresliles mianem "imaginacji"?

do góry

On Sunday, January 18, 2015 at 10:04:59 PM UTC+1, Wojciech Muła wrote:
> Zgoda, ale znowu: python nie był do tego projektowany i szczerze mówiąc
> wątpię, żeby dało się go elegancko "urównoleglić" bez całkowitego
> przeprojektowania i przepisania runtime. To już lepiej nowy język
> o zbliżonej składni zrobić. :)
Dlaczego składnia podobna do Pythona a nie do Javy?

do góry

On Monday, January 19, 2015 at 11:18:07 AM UTC+1, M.M. wrote:
> On Sunday, January 18, 2015 at 10:04:59 PM UTC+1, Wojciech Muła wrote:
> > Zgoda, ale znowu: python nie był do tego projektowany i szczerze mówiąc
> > wątpię, żeby dało się go elegancko "urównoleglić" bez całkowitego
> > przeprojektowania i przepisania runtime. To już lepiej nowy język
> > o zbliżonej składni zrobić. :)
> Dlaczego składnia podobna do Pythona a nie do Javy?

Żeby programiści pythona łatwo się wdrożyli. :)

w.

do góry

On Monday, January 19, 2015 at 1:54:14 PM UTC+1, Wojciech Muła wrote:
> On Monday, January 19, 2015 at 11:18:07 AM UTC+1, M.M. wrote:
> > On Sunday, January 18, 2015 at 10:04:59 PM UTC+1, Wojciech Muła wrote:
> > > Zgoda, ale znowu: python nie był do tego projektowany i szczerze mówiąc
> > > wątpię, żeby dało się go elegancko "urównoleglić" bez całkowitego
> > > przeprojektowania i przepisania runtime. To już lepiej nowy język
> > > o zbliżonej składni zrobić. :)
> > Dlaczego składnia podobna do Pythona a nie do Javy?
>
> Żeby programiści pythona łatwo się wdrożyli. :)

A tak poważnie, rozpoznawanie instrukcji blokowej (czy jak to się
zwie w Pythonie) po samych wcięciach, nie jest wystarczająco
upierdliwe, żeby tę składnie porzucić? W meta-kodzie zgadzam się
że tak jest czytelniej, ale tak? To się nie miesza w oczach?

do góry

On Sunday, January 18, 2015 at 10:04:59 PM UTC+1, Wojciech Muła wrote:
> > Zgoda - gdy zależy nam na prędkości omijajmy Python. A kiedy nie zależy nam
> > na prędkości?
>
> To używamy pythona :)
To gratuluję umiejętności oszacowania czy wydajność Pythona i wysokopoziomowych
bibliotek wystarczy.
Pozdrawiam

do góry

On Monday, January 19, 2015 at 2:51:09 PM UTC+1, M.M. wrote:
> > Żeby programiści pythona łatwo się wdrożyli. :)
>
> A tak poważnie, rozpoznawanie instrukcji blokowej (czy jak to się
> zwie w Pythonie) po samych wcięciach, nie jest wystarczająco
> upierdliwe, żeby tę składnie porzucić? W meta-kodzie zgadzam się
> że tak jest czytelniej, ale tak? To się nie miesza w oczach?

Mnie to nie przeszkadza, kwestia gustu.

Chociaż dla długich bloków i dużej liczby wcięć przestaje być
czytelnie - ale wtedy i tak znaczy, że coś jest nie tak z kodem,
niezależnie od języka.

w.

do góry

On Tuesday, January 20, 2015 at 1:21:28 PM UTC+1, M.M. wrote:
> On Sunday, January 18, 2015 at 10:04:59 PM UTC+1, Wojciech Muła wrote:
> > > Zgoda - gdy zależy nam na prędkości omijajmy Python. A kiedy nie zależy nam
> > > na prędkości?
> >
> > To używamy pythona :)
> To gratuluję umiejętności oszacowania czy wydajność Pythona i wysokopoziomowych
> bibliotek wystarczy.

W pythonie jest bibliotek od cholery, mała szansa, że czegoś nie ma.
Poza tym python ma podobną wydajność, jak ruby, czy perl. Javascript
na v8 jest szybszy, ale js to słaby język i szkoda na niego czasu.

w.

do góry

On Tuesday, January 20, 2015 at 2:01:44 PM UTC+1, Wojciech Muła wrote:
> On Tuesday, January 20, 2015 at 1:21:28 PM UTC+1, M.M. wrote:
> > On Sunday, January 18, 2015 at 10:04:59 PM UTC+1, Wojciech Muła wrote:
> > > > Zgoda - gdy zależy nam na prędkości omijajmy Python. A kiedy nie zależy nam
> > > > na prędkości?
> > >
> > > To używamy pythona :)
> > To gratuluję umiejętności oszacowania czy wydajność Pythona i wysokopoziomowych
> > bibliotek wystarczy.
>
> W pythonie jest bibliotek od cholery, mała szansa, że czegoś nie ma.
> Poza tym python ma podobną wydajność, jak ruby, czy perl. Javascript
> na v8 jest szybszy, ale js to słaby język i szkoda na niego czasu.

Mnie się niedawno zamieliły na dysku 3 wersje programu. Prosta
aplikacja, ale duże xml trzeba do bazy sql przerzucić. Gdy
schodziłem na coraz niższy poziom, to w 3ciej wersji miałem
xmle wrzucone do struktury mniej/więcej takiej:
struct Tag {
QString name;
QString tag;
}
QVector< QVector< Tag > > xml;

I takie rozwiązanie też nie daje rady. Żałuję że od razu nie
skroiłem aplikacji na miarę. Nauczkę tego typu mam już któryś
raz w życiu, ale zawsze jest pokusa żeby użyć czegoś wysokopoziomowego,
choćby w stringu trzymać inty, aby nie rzeźbić N struktur danych.

Czasami ulegam wrażeniu, że na eksperymentach z gotowcami tracę
więcej czasu niż zyskuję.

Pozdrawiam

do góry