Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #33607 > unrolled thread

Czemu Python jest jaki jest?

Back to article view | Back to pl.comp.programming

Contents

  Czemu Python jest jaki jest? "M.M." <mmarszik@gmail.com> - 2019-12-19 18:26 -0800
    Czemu Python jest jaki jest? godek.maciek@gmail.com - 2019-12-19 22:39 -0800
      Re: Czemu Python jest jaki jest? "M.M." <mmarszik@gmail.com> - 2019-12-19 22:57 -0800
      Re: Czemu Python jest jaki jest? "M.M." <mmarszik@gmail.com> - 2019-12-19 22:59 -0800
        Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2019-12-20 00:28 -0800
    Re: Czemu Python jest jaki jest? Roman Tyczka <noemail@because.no> - 2019-12-20 12:43 +0100
      Re: Czemu Python jest jaki jest? "M.M." <mmarszik@gmail.com> - 2019-12-20 06:54 -0800
      Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2019-12-30 07:26 +0100
        Re: Czemu Python jest jaki jest? Roman Tyczka <noemail@because.no> - 2019-12-30 21:39 +0100
          Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2019-12-30 23:46 +0100
            Re: Czemu Python jest jaki jest? Roman Tyczka <noemail@because.no> - 2020-01-02 13:15 +0100
              Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-02 18:16 +0100
                Re: Czemu Python jest jaki jest? J-23 <Baczeklu@poczta.fm> - 2020-01-02 20:45 +0100
                  Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-03 00:20 +0100
                    Re: Czemu Python jest jaki jest? J-23 <Baczeklu@poczta.fm> - 2020-01-03 02:02 +0100
                Re: Czemu Python jest jaki jest? Roman Tyczka <noemail@because.no> - 2020-01-03 09:15 +0100
    Re:Czemu Python jest jaki jest? slawek <x.y@org.org> - 2019-12-30 07:08 +0100
    Re: Czemu Python jest jaki jest? J-23 <Baczeklu@poczta.fm> - 2020-01-02 01:42 +0100
    Re:Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-02 09:46 +0100
      Re: Czemu Python jest jaki jest? J-23 <Baczeklu@poczta.fm> - 2020-01-02 20:30 +0100
        Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-02 12:58 -0800
          Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-03 00:35 +0100
            Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-03 04:04 -0800
              Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-03 18:12 +0100
                Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-03 09:32 -0800
                  Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-03 19:17 +0100
                    Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-03 11:32 -0800
                      Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-03 21:22 +0100
                        Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-03 12:39 -0800
                          Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-04 01:15 +0100
                            Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-03 16:23 -0800
                              Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-04 09:26 +0100
                                Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-04 00:50 -0800
                                  Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-04 10:51 +0100
                                    Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-04 02:13 -0800
                                  Re: Czemu Python jest jaki jest? fir <profesor.fir@gmail.com> - 2020-01-04 04:39 -0800
                                    Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-04 06:48 -0800
                                      Re: Czemu Python jest jaki jest? fir <profesor.fir@gmail.com> - 2020-01-04 07:09 -0800
                                    Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-04 18:40 +0100
                                    Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-04 19:02 +0100
                                      Re: Czemu Python jest jaki jest? "M.M." <mmarszik@gmail.com> - 2020-01-04 10:33 -0800
          Re: Czemu Python jest jaki jest? J-23 <Baczeklu@poczta.fm> - 2020-01-03 20:47 +0100
            Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-03 12:27 -0800
              Re: Czemu Python jest jaki jest? J-23 <Baczeklu@poczta.fm> - 2020-01-04 00:32 +0100
                Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-03 15:55 -0800
                  Re: Czemu Python jest jaki jest? J-23 <Baczeklu@poczta.fm> - 2020-01-04 02:32 +0100
                    Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-04 00:08 -0800
                      Re: Czemu Python jest jaki jest? J-23 <Baczeklu@poczta.fm> - 2020-01-04 22:03 +0100
                        Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-04 14:18 -0800
                          Re: Czemu Python jest jaki jest? J-23 <Baczeklu@poczta.fm> - 2020-01-05 02:45 +0100
                            Re: Czemu Python jest jaki jest? fir <profesor.fir@gmail.com> - 2020-01-05 00:39 -0800
                              Re: Czemu Python jest jaki jest?b J-23 <Baczeklu@poczta.fm> - 2020-01-05 23:15 +0100
                                Re: Czemu Python jest jaki jest?b godek.maciek@gmail.com - 2020-01-05 15:30 -0800
                                  Re: Czemu Python jest jaki jest?b J-23 <Baczeklu@poczta.fm> - 2020-01-06 01:40 +0100
                                    Re: Czemu Python jest jaki jest?b godek.maciek@gmail.com - 2020-01-06 02:12 -0800
                            Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-05 10:25 +0100
                              Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-06 02:34 -0800
                            Re: Czemu Python jest jaki jest? godek.maciek@gmail.com - 2020-01-05 15:59 -0800
      Re: Czemu Python jest jaki jest? "M.M." <mmarszik@gmail.com> - 2020-01-02 12:51 -0800
        Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-03 01:18 +0100
          Re: Czemu Python jest jaki jest? "M.M." <mmarszik@gmail.com> - 2020-01-02 19:40 -0800
          Re: Czemu Python jest jaki jest? "M.M." <mmarszik@gmail.com> - 2020-01-09 04:57 -0800
    Re:Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-03 10:04 +0100
      Re: Czemu Python jest jaki jest? J-23 <Baczeklu@poczta.fm> - 2020-01-03 20:56 +0100
        Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-04 09:31 +0100
          Re: Czemu Python jest jaki jest? J-23 <Baczeklu@poczta.fm> - 2020-01-04 22:18 +0100
            Re: Czemu Python jest jaki jest? slawek <x.y@org.org> - 2020-01-04 23:48 +0100
              Re: Czemu Python jest jaki jest? "M.M." <mmarszik@gmail.com> - 2020-01-05 10:33 -0800
            Re: Czemu Python jest jaki jest? "M.M." <mmarszik@gmail.com> - 2020-01-05 10:18 -0800

Page 1 of 4  [1] 2 3 4  Next page →

#33607 — Czemu Python jest jaki jest?

W dzisiejszych czasach z jednej strony mamy tak zawiły, rozbudowany i zależny
od platformy język programowania jak C++, z drugiej strony mamy (chyba?) 
totalne przeciwieństwo tego języka, mianowicie język Python. Rozumiem że
było zapotrzebowanie na łatwy język programowania z przejrzystymi 
bibliotekami. Zastanawia mnie tylko dlaczego nie stworzono łatwego języka 
programowania, który by miał opcję ręcznego zarządzania pamięcią, byłby
kompilowany do ultra-wydajnego kodu maszynowego, no i który miałby składnię
wzorowaną na C++, Javie, C# i z biblioteką standardową wzorowaną na QT? 
Nie wierzę, żeby pisanie w języku javo-podobnym byłoby takie trudne do 
opanowania, albo proces tworzenia oprogramowania byłby wolniejszy nią w Pythonie.
Jak ktoś nie chce się babrać w typowanie zmiennych, to język programowania 
może mieć wbudowany typ variant, a do klas dodatkowe słowo kluczowe dynamic -
klasa z takim słowem kluczowym mogłaby mieć dynamicznie dodawane pola i
metody - działałoby to też wolno, ale byłoby jako opcja, a nie przymus.

Pozdrawiam

[toc] | [next] | [standalone]

#33608

Julia

[toc] | [prev] | [next] | [standalone]

#33609

On Friday, December 20, 2019 at 7:39:45 AM UTC+1, godek...@gmail.com wrote:
> Julia

Hmmmm

[toc] | [prev] | [next] | [standalone]

#33610

On Friday, December 20, 2019 at 7:39:45 AM UTC+1, godek...@gmail.com wrote:
> Julia

Pierwszy link z googla trafia do forum:

https://4programmers.net/Forum/Inne/311782-julia_jezyk_do_obliczen_naukowych

Prawdę powiadają tam?

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#33611

W dniu piątek, 20 grudnia 2019 07:59:37 UTC+1 użytkownik M.M. napisał:
> On Friday, December 20, 2019 at 7:39:45 AM UTC+1, godek...@gmail.com wrote:
> > Julia
> 
> Pierwszy link z googla trafia do forum:
> 
> https://4programmers.net/Forum/Inne/311782-julia_jezyk_do_obliczen_naukowych
> 
> Prawdę powiadają tam?

Z tego co widzę, wymieniają tam raczej różne opinie.

W każdym razie nie ulega wątpliwości, że z nowymi językami jest tak, że osoby przyzwyczajone do starych języków wolą pozostać przy starych językach. Są wyłomowcy, którzy rozwijają "własne języki", a niektórzy z nich mają nawet to szczęście, że im się udaje zbudować wokół tych języków jakąś społeczność.

Innymi słowy: nawet jeśli stworzono, to nikt i tak tego nie użyje.
(Chyba że jakaś duża korporacja zacznie to promować, jak to miało miejsce np. z językami w rodzaju Swift czy Kotlin)

Zaś co do Twojego pytania: "dlaczego nie stworzono łatwego języka programowania, który by miał opcję ręcznego zarządzania pamięcią, byłby kompilowany do ultra-wydajnego kodu maszynowego, no i który miałby składnię wzorowaną na C++, Javie, C# i z biblioteką standardową wzorowaną na QT?"

to chyba w zamyśle właśnie C++ ma być takim językiem. (i chyba nawet taki jest. Zwłaszcza jeśli używasz Qt)

Zresztą z tą opcją "ręcznego zarządzania pamięcią" to trochę jakby pytać 

"dlaczego nie stworzono łatwego języka programowania, który byłby trudny".

[toc] | [prev] | [next] | [standalone]

#33612

On Thu, 19 Dec 2019 18:26:22 -0800 (PST), M.M. wrote:

> Zastanawia mnie tylko dlaczego nie stworzono łatwego języka 
> programowania, który by miał opcję ręcznego zarządzania pamięcią, byłby
> kompilowany do ultra-wydajnego kodu maszynowego, no i który miałby składnię
> wzorowaną na C++, Javie, C# i z biblioteką standardową wzorowaną na QT? 

Sporo tych wymagań spełnia współczesny Object Pascal, czy to Delphi czy
FPC. 
Nie jest oczywiście C-like, ale zarówno niskopoziomowy, gdy trzeba, czyli
ręczne alokację pamięci, wskaźniki, wstawki ASM, jak i wysokopoziomowy, z
interfejsami, generykami, anomousami, rekordami z metodami, pełnym OOP i
RTTI. 
Jest łatwy i czytelny. 

-- 
pozdrawiam
Roman Tyczka

[toc] | [prev] | [next] | [standalone]

#33613

On Friday, December 20, 2019 at 12:43:48 PM UTC+1, Roman Tyczka wrote:
> On Thu, 19 Dec 2019 18:26:22 -0800 (PST), M.M. wrote:
> 
> > Zastanawia mnie tylko dlaczego nie stworzono łatwego języka 
> > programowania, który by miał opcję ręcznego zarządzania pamięcią, byłby
> > kompilowany do ultra-wydajnego kodu maszynowego, no i który miałby składnię
> > wzorowaną na C++, Javie, C# i z biblioteką standardową wzorowaną na QT? 
> 
> Sporo tych wymagań spełnia współczesny Object Pascal, czy to Delphi czy
> FPC. 
> Nie jest oczywiście C-like, ale zarówno niskopoziomowy, gdy trzeba, czyli
> ręczne alokację pamięci, wskaźniki, wstawki ASM, jak i wysokopoziomowy, z
> interfejsami, generykami, anomousami, rekordami z metodami, pełnym OOP i
> RTTI. 
> Jest łatwy i czytelny. 

Nie wiem czy to wszystko jest potrzebne w przeciętnej aplikacji. MOże zamiast
dostępu do ASM, by wstarczyły długie typy i kompilator z umiejętnością
optymalizowania? Mi się w Javie bardzo dobrze programowało. Int to był int,
string to był string, itd. Taka wydajniejsza Java z opcją ręcznego 
zarządzania pamięcią, kompilowana do kodu binarnego i bez przesady z
wirtualnymi funkcjami - była by blisko mojego ideału.

Pozdrawiam 

[toc] | [prev] | [next] | [standalone]

#33627

Roman Tyczka <noemail@because.no> Wrote in message:
> Sporo tych wymagań spełnia współczesny Object Pascal, czy to Delphi czyFPC.

Pascal jest równie ciekawy jak silnik Trabanta. Fajnie mieć coś
 takiego w garażu, ale nie należy się łudzić że ekologiczne, że
 będą do tego części zamienne, że to i tamto, bo to przecież
 niemieckie auto.

Pascal nie ma niczego więcej niż można to mieć w C++. W C++ są
 rzeczy których nie ma Pascal. Analogiczne porównanie pomiędzy
 Pascalem a Javą (Adą, ECMA Script, ...) daje to samo: Pascal nie
 ma niczego do zaoferowania poza nostalgią za latami
 70-tymi.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[toc] | [prev] | [next] | [standalone]

#33629

On Mon, 30 Dec 2019 07:26:25 +0100 (GMT+01:00), slawek wrote:

>> Sporo tych wymagań spełnia współczesny Object Pascal, czy to Delphi czyFPC.
> 
> Pascal jest równie ciekawy jak silnik Trabanta. Fajnie mieć coś
>  takiego w garażu, ale nie należy się łudzić że ekologiczne, że
>  będą do tego części zamienne, że to i tamto, bo to przecież
>  niemieckie auto.
> 
> Pascal nie ma niczego więcej niż można to mieć w C++. W C++ są
>  rzeczy których nie ma Pascal. Analogiczne porównanie pomiędzy
>  Pascalem a Javą (Adą, ECMA Script, ...) daje to samo: Pascal nie
>  ma niczego do zaoferowania poza nostalgią za latami
>  70-tymi.

Mowa o Object Pascalu, a nie Pascalu '70.

-- 
pozdrawiam
Roman Tyczka

[toc] | [prev] | [next] | [standalone]

#33630

Roman Tyczka <noemail@because.no> Wrote in message:
> On Mon, 30 Dec 2019 07:26:25 +0100 (GMT+01:00), slawek wrote:>> Sporo tych wymagań spełnia współczesny Object Pascal, czy to Delphi czyFPC.> > Pascal jest równie ciekawy jak silnik Trabanta. Fajnie mieć coś>  takiego w garażu, ale nie należy się łudzić że ekologiczne, że>  będą do tego części zamienne, że to i tamto, bo to przecież>  niemieckie auto.> > Pascal nie ma niczego więcej niż można to mieć w C++. W C++ są>  rzeczy których nie ma Pascal. Analogiczne porównanie pomiędzy>  Pascalem a Javą (Adą, ECMA Script, ...) daje to samo: Pascal nie>  ma niczego do zaoferowania poza nostalgią za latami>  70-tymi.

>Mowa o Object Pascalu, a nie Pascalu '70.-- pozdrawiamRoman Tyczka


Jeden pies: Cambridge Pascal, G Pascal, Turbo Pascal, Object
 Pascal, Delphi... 

No dobrze: dokręć do Trabanta alufelgi, dodaj spoilery i kubełkowe
 fotele z F1, zainstaluj turbosprężarkę... Dalej to będzie
 Trabant.

Pascal nie jest złym językiem. Po prostu są lepsze. A i niezbyt
 nadaje się do obliczeń numerycznych. Ma parę niezłych pomysłów,
 parę istotnych braków i parę dyskwalifikujących. Problem z Delphi
 można spowadzić do analogii "warto uczyć się języka polskiego bo
 kaszubski jest fajny". Tyle że dla np. przeciętnego kanadyjczyka
 uczenie się polskiego jest równie przydatne jak uczenie się
 Pascala. Nawet jeżeli byłby to dialekt kaszubski lub
 Delphi.

A czy ja znam Pascala? Przez ileś tam lat pisałem prawie tylko w
 Pascalu, więc coś tam jeszcze pamiętam ;)

Więc nie piszę z pozycji antyfana, ale raczej kogoś kto mając
 sentyment do " starych dobrych czasów" musi jednak dbać aby nie
 zostać leśnym dziadkiem nie potrafiącym nadążyć za
 postępem.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[toc] | [prev] | [next] | [standalone]

#33637

On Mon, 30 Dec 2019 23:46:12 +0100 (GMT+01:00), slawek wrote:

>>Mowa o Object Pascalu, a nie Pascalu '70.-- pozdrawiamRoman Tyczka
> 
> 
> Jeden pies: Cambridge Pascal, G Pascal, Turbo Pascal, Object
>  Pascal, Delphi... 

To, że wszystkie te języki mają begin/end nie oznacza, że różni je tylko
nazwa.
 
> No dobrze: dokręć do Trabanta alufelgi, dodaj spoilery i kubełkowe
>  fotele z F1, zainstaluj turbosprężarkę... Dalej to będzie
>  Trabant.

Nie wiem czy ta analogia z trampkiem jest trafiona, w latach '70 były też
jakieś Mustangi czy inne Dodge, może tędy?
 
> Pascal nie jest złym językiem. Po prostu są lepsze. A i niezbyt
>  nadaje się do obliczeń numerycznych. 

Nikt nie twierdzi inaczej.

> Ma parę niezłych pomysłów,
>  parę istotnych braków i parę dyskwalifikujących. 

Mógłbyś te dyskwalifikujące wymienić? Pytam z ciekawości. Istotne braki też
jakieś tam znam, choć pewnie inne, bo niekoniecznie np. numeryka
rozbudowana jest mi osobiście potrzebna.

> Problem z Delphi  można spowadzić do analogii "warto uczyć się języka polskiego bo
>  kaszubski jest fajny". Tyle że dla np. przeciętnego kanadyjczyka
>  uczenie się polskiego jest równie przydatne jak uczenie się
>  Pascala. Nawet jeżeli byłby to dialekt kaszubski lub
>  Delphi.

Nikogo nie namawiam do nauki, odpowiedziałem tylko na pytanie.
 
> A czy ja znam Pascala? Przez ileś tam lat pisałem prawie tylko w
>  Pascalu, więc coś tam jeszcze pamiętam ;)
> 
> Więc nie piszę z pozycji antyfana, ale raczej kogoś kto mając
>  sentyment do " starych dobrych czasów" musi jednak dbać aby nie
>  zostać leśnym dziadkiem nie potrafiącym nadążyć za
>  postępem.

Tak, to też rozumiem i popieram.

-- 
pozdrawiam
Roman Tyczka

[toc] | [prev] | [next] | [standalone]

#33638

Roman Tyczka <noemail@because.no> Wrote in message:
> To, że wszystkie te języki mają begin/end nie oznacza, że różni je tylkonazwa.

Dlatego jeżeli już ma być begin-end to jednak Ada, a nie Algol czy
 Pascal.

>Mógłbyś te dyskwalifikujące wymienić? Pytam z ciekawości. Istotne braki teżjakieś tam znam, choć pewnie inne, bo niekoniecznie np. numerykarozbudowana jest mi osobiście potrzebna.

Brak dynamicznych tablic. Brak standardu wiązania z bibliotekami.
 Niemożliwość napisania własnej funkcji przyjmującej argumenty tak
 jak we wbudowanej write. Nieprzenośne przekazywanie funkcji jako
 parametru. Liczne, ale niekompatybilne, dialekty. Brak wyjątków.
 Brak namespaces. Zbyt mocne powiązanie z jednym producentem -
 vendor lock. Do tego np. błędna implementacja delay przez
 Borlanda - na szybkich (mniej więcej Pentium 1 @60 MHz) CPU
 programy po prostu nie działały bo startup code wkładał się z div
 by 0 na kalibracji delay. Trudności z użyciem dla low-level - w
 czym zwkłe C jest gorsze tylko od asemblera. Brak templates. Brak
 makrodefinicji. Brak STL. Brak fork. Brak arytmetyki wskaźników.
 Brak asm jako słowa kluczowego. Brak możliwości współpracy z
 Fortranem. Brak krótkiej ewaluacji. Brak refleksji. Brak
 dekoratorów.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[toc] | [prev] | [next] | [standalone]

#33640

W dniu 02.01.2020 o 18:16, slawek pisze:
> Roman Tyczka <noemail@because.no> Wrote in message:
>> To, że wszystkie te języki mają begin/end nie oznacza, że różni je tylkonazwa.
> 
> Dlatego jeżeli już ma być begin-end to jednak Ada, a nie Algol czy
>   Pascal.
> 
>> Mógłbyś te dyskwalifikujące wymienić? Pytam z ciekawości. Istotne braki teżjakieś tam znam, choć pewnie inne, bo niekoniecznie np. numerykarozbudowana jest mi osobiście potrzebna.
> 
> Brak dynamicznych tablic. Brak standardu wiązania z bibliotekami.
>   Niemożliwość napisania własnej funkcji przyjmującej argumenty tak
>   jak we wbudowanej write. Nieprzenośne przekazywanie funkcji jako
>   parametru. Liczne, ale niekompatybilne, dialekty. Brak wyjątków.
>   Brak namespaces. Zbyt mocne powiązanie z jednym producentem -
>   vendor lock. Do tego np. błędna implementacja delay przez
>   Borlanda - na szybkich (mniej więcej Pentium 1 @60 MHz) CPU
>   programy po prostu nie działały bo startup code wkładał się z div
>   by 0 na kalibracji delay. Trudności z użyciem dla low-level - w
>   czym zwkłe C jest gorsze tylko od asemblera. Brak templates. Brak
>   makrodefinicji. Brak STL. Brak fork. Brak arytmetyki wskaźników.
>   Brak asm jako słowa kluczowego. Brak możliwości współpracy z
>   Fortranem. Brak krótkiej ewaluacji. Brak refleksji. Brak
>   dekoratorów.
> 
> 

Strasznie ubogi ten Pascal z tego co piszesz :) Tylko widzisz większość 
rzeczy które tu wymieniłeś sa dostępne.

Błąd związany z Pentium o którym piszesz nie był domeną tylko Pascala w 
tamtym czasie - mało tego odpowiednie ustawienie flag kompilatora 
eliminowało ten problem.

Ale ok nie wcinam wam się w wątek - zrobiłem to tylko z powodu błędu na 
procesorach

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#33647

J-23 <Baczeklu@poczta.fm> Wrote in message:
> Strasznie ubogi ten Pascal z tego co piszesz :) Tylko widzisz większość rzeczy które tu wymieniłeś sa dostępne.Błąd związany z Pentium o którym piszesz nie był domeną tylko Pascala w tamtym czasie.

Tak, większość z tych rzeczy była dostępna w C++ w XX wieku. W
 Pascalu/Delphi nie. Jeżeli coś pomyliłem, to napisz konkretnie
 co. Może Pascal ma obsługę wyjątków? Nie ma? No właśnie. A może
 nie jest prawdą że co dialekt Pascala to w inny sposób
 przekazywało się funkcję/procedurę jako parametr (mały myk - były
 wersje, bodajże Turbo Pascal, gdzie to w ogóle było niemożliwe)?
 A może jest już STL dla Pascala? To może można redefiniować
 operatory w Pascalu?!

Mylisz też, misiaczku, tzw. Pentium Bug z błedem delay. Ten
 pierwszy był błędem samego CPU - Intel Pentium we wczesnej wersji
 - instrukcja fdiv mogła, w pewnych okolicznościach przyrody,
 "dawać mniej dokładne wyniki" - np. zamiast 4.0 wychodziło
 5.0.

Ten drugi to błąd w kodzie startup Turbo Pascala - program na
 dzień dobry robił pustą pętlę z n iteracjami mierząc ile to czasu
 t zajmuje, potem dzielił n/t po to aby skalibrować działanie
 funkcji delay. Dowcip w tym że przy szybkich procesorach, takich
 jak Pentium, wychodziło t = 0.0 z oczywistym efektem. Co
 powodowało że nieoczekiwanie wszystkie programy (exe) zrobione w
 Turbo Pascalu przestawały dawać się uruchamiać. Oczywiście,
 powstał patch - nadpisujący kod startowy w exe-kach. Tyle że były
 to czasy gdy nie było aktualizacji Windows trzy razy na godzinę.
 


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[toc] | [prev] | [next] | [standalone]

#33650

W dniu 03.01.2020 o 00:20, slawek pisze:
> J-23 <Baczeklu@poczta.fm> Wrote in message:
>> Strasznie ubogi ten Pascal z tego co piszesz :) Tylko widzisz większość rzeczy które tu wymieniłeś sa dostępne.Błąd związany z Pentium o którym piszesz nie był domeną tylko Pascala w tamtym czasie.
> 
> Tak, większość z tych rzeczy była dostępna w C++ w XX wieku. W
>   Pascalu/Delphi nie. Jeżeli coś pomyliłem, to napisz konkretnie
Właśnie o to chodzi że większość tych rzeczy które wymieniłeś byly 
jeszcze w latach 90 tych
>   co. Może Pascal ma obsługę wyjątków? Nie ma?
Nie ma obsługi wyjątków od kiedy :P?? Bo są od dawna nawet wersji nie ma 
co przytaczać :P ale try...except...finally było na bank w latach 90 
tych juz :)
  No właśnie. A może
>   nie jest prawdą że co dialekt Pascala to w inny sposób
>   przekazywało się funkcję/procedurę jako parametr (mały myk - były
>   wersje, bodajże Turbo Pascal, gdzie to w ogóle było niemożliwe)?

Dialekt Pascala się zmieniał i zmienia nadal ale inne języki i ich 
dialekty też się zmieniają - proste (także marny zarzut że język się 
rozwija)

>   A może jest już STL dla Pascala? 
Są :) nie są tak rozwinięte jak w C++ ale są :)

To może można redefiniować
>   operatory w Pascalu?!
Tego brak
> 
> Mylisz też, misiaczku, tzw. Pentium Bug z błedem delay. Ten
>   pierwszy był błędem samego CPU - Intel Pentium we wczesnej wersji
zgadza się i wystarczyła wstawka asembler owa lub pogrzebanie z 
przełącznikami kompilatora by to naprawić. Nawet pamiętam do dziś że 
zrobiłem sobie narzędzie gdzie w lini komend podawałem ścieżkę programu 
i w ten sposób odpalałem program i tego problemu nie było
>   - instrukcja fdiv mogła, w pewnych okolicznościach przyrody,
>   "dawać mniej dokładne wyniki" - np. zamiast 4.0 wychodziło
>   5.0.
> 
> Ten drugi to błąd w kodzie startup Turbo Pascala - program na
>   dzień dobry robił pustą pętlę z n iteracjami mierząc ile to czasu
>   t zajmuje, potem dzielił n/t po to aby skalibrować działanie
>   funkcji delay. Dowcip w tym że przy szybkich procesorach, takich
>   jak Pentium, wychodziło t = 0.0 z oczywistym efektem. Co
>   powodowało że nieoczekiwanie wszystkie programy (exe) zrobione w
>   Turbo Pascalu przestawały dawać się uruchamiać. Oczywiście,
>   powstał patch - nadpisujący kod startowy w exe-kach. Tyle że były
>   to czasy gdy nie było aktualizacji Windows trzy razy na godzinę.

O tym samym mówimy :) ja napisałem to raz i miałem z głowy. Właśnie w 
taki sposób jak opisałem powyżej

Dodam nawet że miło wspominam ten czas bo z tego w tamtym czasie miałem 
spory grosz :)
>   
> 
> 
> ----Android NewsGroup Reader----
> http://usenet.sinaapp.com/
> 

[toc] | [prev] | [next] | [standalone]

#33653

On Thu, 2 Jan 2020 18:16:45 +0100 (GMT+01:00), slawek wrote:

>> To, że wszystkie te języki mają begin/end nie oznacza, że różni je tylkonazwa.
> 
> Dlatego jeżeli już ma być begin-end to jednak Ada, a nie Algol czy
>  Pascal.
> 
>>Mógłbyś te dyskwalifikujące wymienić? Pytam z ciekawości. Istotne braki teżjakieś tam znam, choć pewnie inne, bo niekoniecznie np. numerykarozbudowana jest mi osobiście potrzebna.

Jak pisałem poprzednio, gdy mówimy o dzisiejszym Object Pascalu to:
 
> Brak dynamicznych tablic. 

są oczywiście i to od dawna

> Brak standardu wiązania z bibliotekami.

nie wiem na czym standard miałby polegać, ale biblioteki z innych języków
da się używać, a także linkować pliki .obj

>  Niemożliwość napisania własnej funkcji przyjmującej argumenty tak
>  jak we wbudowanej write. 

To prawda, choć jeśli dopuścić zapis wywołania z tablicą:

DoJob([1, 'text', 6.5]);
DoJob(['text', 15]);

to się da.

>  Nieprzenośne przekazywanie funkcji jako
>  parametru. 

Typy funkcyjne/proceduralne są od bardzo dawna, od dekady są też metody
anonimowe, więc można ich wszystkich używać jako parametrów

> Liczne, ale niekompatybilne, dialekty. 

To prawda.

> Brak wyjątków.

Są od dekad.

>  Brak namespaces. 

Tak, tego brakuje

> Zbyt mocne powiązanie z jednym producentem -  vendor lock. 

To nie jest argument przeciw językowi.

>  Do tego np. błędna implementacja delay przez
>  Borlanda - na szybkich (mniej więcej Pentium 1 @60 MHz) CPU
>  programy po prostu nie działały bo startup code wkładał się z div
>  by 0 na kalibracji delay. 

Problem sprzed ponad 20 lat - nieistniejący.

> Trudności z użyciem dla low-level - w czym zwkłe C jest gorsze tylko od asemblera. 

Czyli konkretnie co?

>  Brak templates. Brak makrodefinicji. 

Są za to generyki.

> Brak STL. 

Jest Spring:
https://spring4d.4delphi.com/docs/master/Html/index.htm?Spring.Base.htm

> Brak fork. 

Fakt

> Brak arytmetyki wskaźników.

Od ponad dekady jest 

https://helloacm.com/pointer-arithmetic-in-delphi/

>  Brak asm jako słowa kluczowego. 

Od dekad:

http://docwiki.embarcadero.com/RADStudio/Rio/en/Assembly_Expressions

> Brak możliwości współpracy z Fortranem. 

To jest jakiś uniwersalny wymóg dla języków?

> Brak krótkiej ewaluacji. 

Od dekad:

http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/compdirsbooleanshortcircuitevaluation_xml.html

> Brak refleksji. 

http://robstechcorner.blogspot.com/2009/09/delphi-2010-rtti-basics.html

> Brak dekoratorów.

Jeśli masz na myśli to co w Javie nazywa się annotations, to są attributes:

http://docwiki.embarcadero.com/RADStudio/Rio/en/Attributes_and_RTTI

-- 
pozdrawiam
Roman Tyczka

[toc] | [prev] | [next] | [standalone]

#33626

"M.M." <mmarszik@gmail.com> Wrote in message:
> W dzisiejszych czasach z jednej strony mamy tak zawiły, rozbudowany i zależnyod platformy język programowania jak C++, z drugiej strony mamy (chyba?) totalne przeciwieństwo tego języka, mianowicie język Python. [...] Nie wierzę, żeby pisanie w języku [...]


1. W dzisiejszych czasach mamy około 2000 różnych języków
 programowania. Takich jak np. Nemerle, Haskel, Verilog, C--,
 Forth, Lisp, Prolog czy nawet Bash. Nie licząc asemblerów - inny
 dla Z80, inny dla ARM itd.

2. Wiara to nawet przydatna rzecz. Ale ortogonalna do wiedzy.
 Pisanie w javopodobnym (a może po prostu w Javie, przecież sama
 Java jest chyba javopodobna, czyż nie?!) jest dla ponad 90%
 populacji tzw. homo sapiens awykonalne. Python niczego nie
 zmienia. Pisanie w Pythonie może być trudniejsze niż w C++.
 Python ma większy poziom abstrakcji, a większość ludzi ma
 problemy z myśleniem abstrakcyjnym. 


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[toc] | [prev] | [next] | [standalone]

#33633

W dniu 20.12.2019 o 03:26, M.M. pisze:
> W dzisiejszych czasach z jednej strony mamy tak zawiły, rozbudowany i zależny
> od platformy język programowania jak C++, z drugiej strony mamy (chyba?)
> totalne przeciwieństwo tego języka, mianowicie język Python.
C++ powstał po co innego a Python po co innego. Wiem że w Pythonie da 
się napisać nawet aplikacje okienkową i będzie to działać tylko czy to 
jest dobry pomysł, albo inaczej widziałeś w Pythonie aplikację tak 
rozbudowaną jak w jeżykach kompilowanych? Ja nie widziałem i raczej nie 
zobaczę:)

Język skryptowy z językiem kompilowanym takie zestawienie nie ma sensu 
bo one powstały zupełnie do odmiennych rzeczy i pomimo tego że tak jak 
wspomniałem w Pythonie da się robić nawet aplikacje okienkowe tego robić 
się nie powinno

Tak jak teraz jest moda przenoszenia większości aplikacji do Weba to tak 
naprawdę żaden duży system np ERP nie będzie tak samo szybki jak ten 
napisany w języku kompilowanym a WEB w tych aplikacjach pozostaje 
dodatkiem bo posiada uboższe funkcje jak aplikacja kompilowana.

Znam kilka przykładów gdzie duże aplikacje zostały przeniesione na 
języki skryptowe i na WEB ale chodzi to dużo wolniej niż aplikacja w 
języku kompilowanym
  Rozumiem że
> było zapotrzebowanie na łatwy język programowania z przejrzystymi
> bibliotekami. Zastanawia mnie tylko dlaczego nie stworzono łatwego języka
> programowania, który by miał opcję ręcznego zarządzania pamięcią,

Co masz na myśli pisząc "Ręczne zarządzanie pamięcią"? Rozwiń... bo 
jeżeli masz na myśli alokowanie i zwalnianie pamięci to m.in zrobisz w 
pascalu. Ma to swoje wady i zalety ale tak zwany "Garbage collection", 
który jest implementowany w wielu językach ma więcej zalet niż wad

  byłby
> kompilowany do ultra-wydajnego kodu maszynowego, no i który miałby składnię
> wzorowaną na C++, Javie, C# i z biblioteką standardową wzorowaną na QT?

Chociaż byś napisał ultra wydajny kompilator który buduje taki kod 
maszynowy o jakim piszesz on w 95% albo i jeszcze więcej nie osiągnie 
takiego wydajnego kodu jaki ty sobie zakładasz. Powód? Człowiek on jest 
najsłabszym ogniwem bo to on piszę kod który jest na tyle niedoskonały 
by robić narzuty na wydajności. Jednocześnie ten sam kod pozwala się 
kompilować i działać tak jak jego twórca sobie zakładał. Ale to tylko 
jeden z aspektów pisania wydajnego kodu. Po drugiej stronie stoi mnogość 
urządzeń na którym dany kod w postaci oprogramowania ma pracować.

Doskonałym przykładem tutaj jest firma Apple która przeżywa rózne 
momenty w swoim istnieniu ale jest znana z tego że ich oprogramowanie 
działa dużo wydajniej niż odpowiedniki czy pierwowzory (jak kto woli) 
Microsoftu. Powód? Znany chyba wszystkim ich oprogramowanie działa na 
wąskiej gamie sprzętu, a to pozwala je zoptymalizować pod względem 
wydajności.

Niejednokrotnie ten sam kod ten, sam kompilator a różne platformy może 
się zdarzyć że będzie zachowywał się zupełnie inaczej na 2 różnych 
platformach

> Nie wierzę, żeby pisanie w języku javo-podobnym byłoby takie trudne do
> opanowania, albo proces tworzenia oprogramowania byłby wolniejszy nią w Pythonie.

Szybkość pisania oprogramowania w dzisiejszych czasach w bardzo małyn 
stopniu zależy od samego języka programowania. (No chyba że się ktoś 
uczy danego języka to wtedy ma to znaczenie)

Obecnie szybkość pisania danego oprogramowania zależy od ilości 
bibliotek które posiada dany język stąd tak popularne są dziś 
Java/JavaScript/Python/Ruby itd

Oczywiście każdy z tych języków pod względem wydajności jest różny.

By to zobrazować powrócę na chwilę do Pascala który to jest przez wielu 
nazywanym archaicznym językiem i pod względem liczby firm które tworzą w 
tym języku nowe rzeczy (Są takie :)) jest np stosunkowo mało chociaż kod 
maszynowy pascala jest pod względem szybkości na poziomie języka C 
(można znaleźć w sieci materiały to potwierdzające) Jednak C jest 
bardziej popularny niż Pascal i większości szybciej w nim napiszemy 
jakieś zaawansowane oprogramowanie szybciej niż w Pascalu bo mamy na 
starcie większą gamę bibliotek dostępnych do C niż do Pascala

> Jak ktoś nie chce się babrać w typowanie zmiennych, to język programowania
> może mieć wbudowany typ variant, a do klas dodatkowe słowo kluczowe dynamic -
> klasa z takim słowem kluczowym mogłaby mieć dynamicznie dodawane pola i
> metody - działałoby to też wolno, ale byłoby jako opcja, a nie przymus.

Podsumowując obecnie mamy dostępnych tyle języków że jest w czym wybrać 
i przymusu nie ma :) by coś stosować albo nie. Moim zdaniem pisanie 
kolejnego języka do czegoś co już istnieje mija się z celem. Brak jest 
moim zdaniem dobrych środowisk programistycznych do wykonania 
konkretnego typu zadań. Do wielu języków znajdziemy po 2 - 3 środowiska 
programistyczne np tak jest do C/C++, Javy ich środowiska są bardzo 
dobrę ale np do większości języków tzw. skryptowych nie ma dedykowanych 
środowisk praktycznie wcale te co są, są w większości pluginami do 
danego języka skryptowego gdzie po zainstalowaniu lub po długiej 
konfiguracji jakaś wtyczka staje się niekompatybilna i trafia cię szlag.

Pozdrawiam
J-23

[toc] | [prev] | [next] | [standalone]

#33634

Jest wiele mitów:

1. "Python to język skryptowy" - mit - podział na języki skryptowe
 i nie-skryptowe wymagałby zdefiniowania "skryptowości" - jak
 dotąd nikomu nie udało się tego dobrze zrobić. Czy Lua to język
 skryptowy? A Basic? Czym różni się semantycznie for z Javy, C++ i
 AWK? A taki Postscript to jest jaki?!

2. "Nie ma sensu robić programów z GUI w Pythonie" - mit - bo
 takie programy jest łatwiej zrobić niż w C++. Choćby w tym sensie
 że biblioteka Qt wymaga w przypadku C++ gimnastyki z
 metakompilatorem, a Python tego nie potrzebuje. Osobną sprawą
 jest kwestia czy każdy program powinien mieć GUI ? - ale
 odpowiedź na to nie zależy od języka.

3. "Python nie kompiluje się" - mit - są kompilatory Pythona.
 Ponadto podział języków na interpretowane (translatory) i
 kompilowane (kompilatory) jest dziś głupotą - mamy JIT i podobne
 techniki. A DLL dla Pythona są w natywnym.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[toc] | [prev] | [next] | [standalone]

#33639

W dniu 02.01.2020 o 09:46, slawek pisze:
> Jest wiele mitów:
> 
> 1. "Python to język skryptowy" - mit - podział na języki skryptowe
>   i nie-skryptowe wymagałby zdefiniowania "skryptowości" - jak
>   dotąd nikomu nie udało się tego dobrze zrobić. Czy Lua to język
>   skryptowy? A Basic? Czym różni się semantycznie for z Javy, C++ i
>   AWK? A taki Postscript to jest jaki?!

Skoro tak zadajesz pytanie to kompletnie albo nie wiesz co się dzieje w 
momencie kompilacji albo udajesz że nie wiesz - stawiam na to drugie :)

https://pl.wikipedia.org/wiki/Kompilator

Już prosta definicja z wiki (która jest uproszczona) pokazuje że zadanie 
pytania cytuje: "czym różni się for z javy, C++.." jest to nie właściwe 
pytanie. Bo odpowiedz jest bardzo prosta - sposobem wykonania tej 
instrukcji - efekt pozostaje taki sam w obu przypadkach ale sposób ich 
wykonania jest zupełnie różny. To właśnie dany sposób wykonania 
poszczególnych instrukcji sprawia że te instrukcje w danym języku będą 
wykonane szybciej inne wolniej... bardziej po chłopsku już się tego nie 
da chyba napisać :)

Podział na języki skryptowe i kompilowane jest raczej prosty. Bardziej 
skomplikowane jest rozróżnienie języka skryptowego i języka który działa 
na maszynie wirtualnej - tj Java .NET które są świetne ale potrzeba do 
nich środowiska uruchomieniowego.

> 
> 2. "Nie ma sensu robić programów z GUI w Pythonie" - mit - bo
>   takie programy jest łatwiej zrobić niż w C++. Choćby w tym sensie
>   że biblioteka Qt wymaga w przypadku C++ gimnastyki z
>   metakompilatorem, a Python tego nie potrzebuje. Osobną sprawą
>   jest kwestia czy każdy program powinien mieć GUI ? - ale
>   odpowiedź na to nie zależy od języka.

Okienka to tylko przykład. Jakoś nie widać oprogramowania w Pythonie np 
do obrobki Grafiki czy wideo. Znając Pythona wiem że żadne programy 
większego kalibru nie powstały i nie powstaną (No chyba ze coś znasz to 
podziel się linkiem)

Nie każdy program musi mieć GUI i powiem szczerze czy on jest czy go nie 
ma to i tak pozycji Pythona to nie zmienia - nadal pozostaje językiem w 
którym większość piszę proste skrypty i strony www.

Ma swoje zalety ale jednak przegrywa z językami kompilowanymi gdy np 
zależy nam na pisaniu coś pod konkretną platformę sprzętową

> 
> 3. "Python nie kompiluje się" - mit - są kompilatory Pythona.
>   Ponadto podział języków na interpretowane (translatory) i
>   kompilowane (kompilatory) jest dziś głupotą - mamy JIT i podobne
>   techniki.

Napisz jak to JIT działa wtędy będę wiedział czy wiesz o czym piszesz :)

Już wspomniałem że języki skryptowe jest ciężko odróżnić od wykonywanych 
na maszynach wirtualnych :)

Pamiętaj o tym pisząc o JIT :)
  A DLL dla Pythona są w natywnym.

W natywnym czym?

W Pythonie z tego co wiem można bez problemu użyć DLL napisanej np w C, 
ale pisać...? Może jest nigdy w te stronę się nie bawiłem ale stawiam na 
to że jeśli jest taka możliwość to czysty Python to nie jest :)

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | pl.comp.programming

csiph-web