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

do góry

Julia

do góry

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

Hmmmm

do góry

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

Pierwszy link z googla trafia do forum:

https://4programmers.net/Forum/Inne/311782-julia_jez
yk_do_obliczen_naukowych

Prawdę powiadają tam?

Pozdrawiam

do góry

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, g...@g...com wrote:
> > Julia
>
> Pierwszy link z googla trafia do forum:
>
> https://4programmers.net/Forum/Inne/311782-julia_jez
yk_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".

do góry

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

do góry

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

do góry

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

do góry

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

do góry

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

do góry