W dniu poniedziałek, 21 sierpnia 2017 22:15:55 UTC+2 użytkownik s...@g...com
napisał:
> Ja odnoszę wrażenie, że obecnie programiści nie za bardzo wiedzą jaki język jest na
prawdę najlepszy i myślą, że w zasadzie to najbardziej zależy od zastosowania. Bo w
większości wypadków nie ważne jest jak jest szybki - liczy się jak szybko da się coś
zakodować.

Co więcej, niektórzy programiści (np. ja) śmią twierdzić, że
stwierdzenie, że "język programowania jest szybki", jest błędem
kategorialnym. Może można powiedzieć, że dany język posiada implementację
pozwalającą na szybkie wykonywanie napisanego w nim kodu. Ale w ogólnym
przypadku sprawa nie jest taka prosta.

> Ja natomiast mam inne zdanie na ten temat.
>
> Moim zdaniem (porównując najpopularniejsze języki: Asembler, C, C++, D, Java, PHP,
Python, JavaScript - tyle poznałem i mi to wystarczy) okazuje się, że C++ jest
najlepszy. Oto powody:

Jeżeli chcesz zrobić aplikację działającą w przeglądarce, C++ wiele Ci
nie pomoże -- niestety, jesteś raczej skazany na JavaScript, albo coś,
co się kompiluje do JavaScriptu (Elm, CoffeeScript, TypeScript, PureScript,
ClojureScript, ...)

Jeżeli zaś idzie o stwierdzenie, czy dany przekrój języków jest wystarczający,
to tak naprawdę kwestia nie jest taka oczywista. Ludwig Wittgenstein
stwierdził w "Traktacie logiczno-filozoficznym": "Granice mojego języka
oznaczają granice mojego świata". W podobnym duchu rozumował Paul Graham,
formułując swój "Blub paradox": http://www.paulgraham.com/avg.html

Najlepszy język, jaki znamy, nie pozwala nam obiektywnie spojrzeć na jego wady.
Dopiero znajomość wielu różnych języków pozwala widzieć wady i zalety
w pooszczególnych przypadkach. Moim zdaniem Haskell jest pod wieloma
względami dużo lepszy niż C++. Ale pewnie warto się zapoznać z odmiennymi
sposobami myślenia, takimi z jakimi masz do czynienia w przypadku
języków takich jak Forth, Prolog, Smalltalk czy Scheme.

> 1. Bez udziwnień obsługuje standardowe API obecnych systemów operacyjnych (czyli
C). D ma niby wsparcie dla funkcji C ale trzeba je zdeklarować w języku D.

W C++ też musisz zadeklarować te funkcje jako extern "C".
Zaś jeżeli idzie o udziwnienia, to name mangling jest jednym
z największych, jakie widziałem.

> 2. Zapewnia wszystko to co język obiektowy powinien mieć - a nawet więcej niż wiele
innych języków, bo ma wielodziedziczenie i szablony. I to wszystko ma bez udziwnień -
są to cechy naturalne tego języka.

Szablony zdają mi się jednym wielkim udziwnieniem. Tym bardziej,
że nie zostały zaprojektowane w celu, do którego finalnie zaczęły
być używane.

> Tak więc nie jest uczciwe porównywanie tego języka do Asemblera. Tu bym porównał
raczej Asemblera do łopaty, a C++ do koparki, a języki skryptowe do mini koparek.

W ogóle mówienie o asemblerze jako języku to pomyłka.

> 3. Kompiluje się do kodu maszynowego i przez to działa w sposób naturalny - jak to
przewiduje producent procesora. Jego pliki wykonywalne są najmniejsze z możliwych,

No chyba nie są.

> są prawie tak szybkie jak programy asemblerowe i działają samodzielnie (wymagając
jedynie bibliotek dll - jeśli tak zostały skompilowane - a często wymaga tego
licencja biblioteki). Nie wymaga żadnego interpretera, ani żadnych "maszyn
wirtualnych" które nic nie dają prawdziwemu programiście (bo gdy do C++ przechodzi
się z Asemblera to ręczne zarządzanie pamięcią jest czymś naturalnym i intuicyjnym -
ja w ten sposób się uczyłem, bo to wydawało mi się najsensowniejsze i nadal tak mi
się wydaje). Poza tym obecnie w C++ zarządzanie pamięcią często ogranicza się do
podania "rodzica" jako parametr konstruktora i on usuwa ten nowy obiekt (Qt tak jest
zrobione), lub używa się "sprytnych wskaźników" które usuną obiekt kiedy trzeba (to
implementuje biblioteka standardowa).

Czyli masz miliard różnych sposobów zarządzania pamięcią, co w konsekwencji
utrudnia wnioskowanie o tym, co się wydarzy

> 4. Umożliwia dobrą separację interfejsu (deklaracji) i implementacji. Są pliki *.h
które dobrze opisują zawartość plików *.cpp. To trzeba docenić, bo tego nie ma w
innych (wymienionych) językach z wyjątkiem C.

W Haskellu separacja interfejsu od implementacji jest dużo lepsza
niż w C++

> 5. Jest przenośny. Umiejętnie pisane programy (w Qt ;] ) są bez problemowo
przenośne. A kod nieprzenośny daje się izolować (można wyłączać całe pliki *.cpp i
kompilować warunkowo). Ta przenośność teoretycznie nie jest obarczona jakimś spadkiem
wydajności czy innymi ukrytymi kosztami. Teoretycznie programy C++ są przenośne na
każdą platformę na którą jest odpowiednio aktualny kompilator C++. Jednak ważniejszym
ograniczeniem jest wsparcie danej platformy przez dostawców bibliotek.

Python też jest przenośny między różnymi platformami (w końcu jest napisany
w C). Podobnie Haskell. Scheme jest tak przenośny, że aż ciężko to sobie
wyobrazić. Są kompilatory Scheme do C, kompilatory do kodu maszynowego
popularnych platform, kompilatory do JavaScriptu, interpretery w JavaScripcie,
implementacje na JVM i na CLR.

Zresztą C wydaje się bardziej przenośny niż C++. Z pewnością dużo łatwiej
napisać dla niego kompilator.

> 6. C++ żyje własnym życiem bez dominacji jednej firmy która by narzucała innym jaki
ten język ma być. Nie kompatybilne zmiany się nie przyjmują, bo ludzie chcą mieć
wybór - np.: pod Windows kompilator VC++, a pod Linuxem g++...

Python tak samo. Haskell tak samo. Racket tak samo.

do góry

Użytkownik <s...@g...com> napisał:

> Ja natomiast mam inne zdanie na ten temat.

Dobrze, Wolno Ci przeciez.
Tylko nie kłam ze poznales _cokowiek innego_ poza C/C++
Tak! Madrze ktos zacytowal filozofa: "granice mego jezyka wytyczaja granice mego
swiata"
Twoj swiat bolesnie ograniczaja kraty ++.

AK

do góry

On Monday, August 21, 2017 at 10:15:55 PM UTC+2, s...@g...com wrote:
> 2. Zapewnia wszystko to co język obiektowy powinien mieć - a nawet więcej niż wiele
innych języków, bo ma wielodziedziczenie i szablony. I to wszystko ma bez udziwnień -
są to cechy naturalne tego języka.

Składnia szablonów jest zdrowo popieprzona i wyszedł z tego zagnieżdżony,
mocno koślawy język, z którego wyrósł chwast o nazwie "constexpr". Nie
wspominając, że dzięki szablonom czas kompilacji rośnie drastycznie.

Wielodziedziczenie jest tak cudownie użyteczne, że mamy jeszcze wirtualne
dziedziczenie. :)

> 4. Umożliwia dobrą separację interfejsu (deklaracji) i implementacji. Są pliki *.h
które dobrze opisują zawartość plików *.cpp. To trzeba docenić, bo tego nie ma w
innych (wymienionych) językach z wyjątkiem C.

Człowieku, ty nie wiedziałeś normalnych interfejsów i modułów. Modula, Pascal,
Ada, SML mają to zrobione z głową. Pliki nagłówkowe to jest czysto techniczne
i na dodatek kiepskie rozwiązanie. Te wszystkie porypany "include guards"...
dopiero niedawno #pragma once stało się standardowe, co i tak niewiele pomaga.
Próbuje się łatać to gówno przez tzw. precompiled headers, ale to jest jeszcze
gorsze, rzadko działa i jest niestandardowe.

> 6. C++ żyje własnym życiem bez dominacji jednej firmy która by narzucała innym jaki
ten język ma być. Nie kompatybilne zmiany się nie przyjmują, bo ludzie chcą mieć
wybór - np.: pod Windows kompilator VC++, a pod Linuxem g++...

Życiem C++ kieruje komitet, który miewa posrane pomysły. Albo też zwleka
z wdrożeniem istotnych zmian wieki. Patrz temat conceptów. Patrz wątki.
To wszystko wchodzi do języka w tempie chorego na artretyzm żółwia,
a przyjmuje się powszechnie z kilkuletnim opóźnieniem. Krótko mówiąc
język ma potencjał, tylko kieruje nim ciało, które ma luźny kontakt
z potrzebami rynku.

w.

do góry

On Tuesday, August 22, 2017 at 1:04:32 AM UTC+2, AK wrote:
> Użytkownik <s...@g...com> napisał:
>
> > Ja natomiast mam inne zdanie na ten temat.
>
> Dobrze, Wolno Ci przeciez.
> Tylko nie kłam ze poznales _cokowiek innego_ poza C/C++
> Tak! Madrze ktos zacytowal filozofa: "granice mego jezyka wytyczaja granice mego
swiata"
> Twoj swiat bolesnie ograniczaja kraty ++.

Ale jaka konkretnie mądrość z tego cytatu płynie w kontekście
języków programowania?

Pozdrawiam

do góry

W dniu wtorek, 22 sierpnia 2017 09:42:53 UTC+2 użytkownik M.M. napisał:

> > Tak! Madrze ktos zacytowal filozofa: "granice mego jezyka wytyczaja granice mego
swiata"
> > Twoj swiat bolesnie ograniczaja kraty ++.
>
> Ale jaka konkretnie mądrość z tego cytatu płynie w kontekście
> języków programowania?

Pozwolę sobie odpowiedzieć nieco większym cytatem, pochodzącym od
Alana Kaya, twórcy języka Smalltalk:

Allen Newell visited PARC with his theory of hierarchical thinking
and was challenged to prove it. He was given a programming problem
to solve while the protocol was collected. The problem was: given
a list of items, produce a list consisting of all of the odd indexed
items followed by all of the even indexed items. Newell's internal
programming language resembled IPL-V in which pointers are manipulated
explicitly, and he got into quite a struggle to do the program.
In 2 seconds I wrote down:

oddsEvens(x) = append(odds(x), evens(x))

the statement of the problem in Landin's LISP syntax--and also
the first part of the solution. Then a few seconds later:

where odds(x) = if null(x) ? null(tl(x)) then x
else hd(x) & odds(ttl(x))
evens(x) = if null(x) ? null(tl(x)) then nil
else odds(tl(x))

This characteristic of writing down many solutions in declarative
form and have them also be the programs is part of the appeal
and beauty of this kind of language. Watching a famous guy much
smarter than I struggle for more than 30 minutes to not quite
solve the problem his way (there was a bug) made quite an impression.
It brought home to me once again that "point of view is worth 80 IQ points."
I wasn't smarter but I had a much better internal thinking tool to
amplify my abilities.

http://worrydream.com/EarlyHistoryOfSmalltalk/

do góry

> In 2 seconds I wrote down:
>
> oddsEvens(x) = append(odds(x), evens(x))
>
> the statement of the problem in Landin's LISP syntax--and also
> the first part of the solution. Then a few seconds later:
>
> where odds(x) = if null(x) ? null(tl(x)) then x
> else hd(x) & odds(ttl(x))
> evens(x) = if null(x) ? null(tl(x)) then nil
> else odds(tl(x))

Co za sieczka. To ma być "wysokopoziomowe"?

W języku Wolfram można tak:

oddsEvens[x_] := Join[x[[1 ;; ;; 2]], x[[2 ;; ;; 2]]]

gdzie zapis x[[i ;; ;; s]] oznacza listę elementów wybranych z x, od i-tego do końca
z krokiem s, a Join skleja listy podane jako argumenty.
Jedna linijka kodu, posługując się wyłącznie pojęciami z dziedziny zadanego problemu.
Wtedy można mówić o programowaniu wysokopoziomowym.

> I wasn't smarter but I had a much better internal thinking tool to
> amplify my abilities.

--
Maciej Sobczak * http://www.inspirel.com

do góry

On Tuesday, August 22, 2017 at 10:21:52 AM UTC+2, g...@g...com wrote:
> [...]
> It brought home to me once again that "point of view is worth 80 IQ points."
> I wasn't smarter but I had a much better internal thinking tool to
> amplify my abilities.

Ja też lubię wysokopoziomowe, wręcz deklaratywne rozwiązania. Właściwie to
je uwielbiam. Kłopoty tylko pojawiają się, gdy przestaję o rozwiązaniach
marzyć na kanapie, a zaczynam je implementować.

Gdy opracowałem jakieś nowe rozwiązanie do pewnego problemu, to w głowie
miałem może kilka wzorów/algorytmów, może kilkanaście, i wszystkie
zawierały się w jednej linii kodu. W dodatku były to wzory w całkiem
szerokim sensie uniwersalne, czyli operowały i na drobnych szczegółach, i
na całych, czasami różnorodnych zbiorach takich szczegółów. Czy cały
algorytm można było przenieść na maszynę w "języku zintegrowanym z
myśleniem"? Hmmm nawet jeśli, to jakie napisano najlepsze optymalizatory
dla takich języków programowania?

Pozdrawiam

do góry

W dniu wtorek, 22 sierpnia 2017 13:49:51 UTC+2 użytkownik M.M. napisał:
> On Tuesday, August 22, 2017 at 10:21:52 AM UTC+2, g...@g...com wrote:
> > [...]
> > It brought home to me once again that "point of view is worth 80 IQ points."
> > I wasn't smarter but I had a much better internal thinking tool to
> > amplify my abilities.
>
> Ja też lubię wysokopoziomowe, wręcz deklaratywne rozwiązania. Właściwie to
> je uwielbiam. Kłopoty tylko pojawiają się, gdy przestaję o rozwiązaniach
> marzyć na kanapie, a zaczynam je implementować.
>
> Gdy opracowałem jakieś nowe rozwiązanie do pewnego problemu, to w głowie
> miałem może kilka wzorów/algorytmów, może kilkanaście, i wszystkie
> zawierały się w jednej linii kodu. W dodatku były to wzory w całkiem
> szerokim sensie uniwersalne, czyli operowały i na drobnych szczegółach, i
> na całych, czasami różnorodnych zbiorach takich szczegółów. Czy cały
> algorytm można było przenieść na maszynę w "języku zintegrowanym z
> myśleniem"? Hmmm nawet jeśli, to jakie napisano najlepsze optymalizatory
> dla takich języków programowania?

Podejrzewam że z systemów dostępnych dla Kowalskiego
najlepszy będzie Glasgow Haskell Compiler

do góry

W dniu wtorek, 22 sierpnia 2017 13:13:54 UTC+2 użytkownik Maciej Sobczak napisał:
> > In 2 seconds I wrote down:
> >
> > oddsEvens(x) = append(odds(x), evens(x))
> >
> > the statement of the problem in Landin's LISP syntax--and also
> > the first part of the solution. Then a few seconds later:
> >
> > where odds(x) = if null(x) ? null(tl(x)) then x
> > else hd(x) & odds(ttl(x))
> > evens(x) = if null(x) ? null(tl(x)) then nil
> > else odds(tl(x))
>
> Co za sieczka. To ma być "wysokopoziomowe"?
>
> W języku Wolfram można tak:
>
> oddsEvens[x_] := Join[x[[1 ;; ;; 2]], x[[2 ;; ;; 2]]]
>
> gdzie zapis x[[i ;; ;; s]] oznacza listę elementów wybranych z x, od i-tego do
końca z krokiem s, a Join skleja listy podane jako argumenty.

Faktycznie, właśnie coś takiego sobie myślę widząc zapis
x[[i ;; ;; s]]. I właśnie w ten sposób chciałbym zapisywać
"listę elementów wybranch z x od i-tego miejsca z krokiem s".

Bo to się rozumie samo przez się. Zresztą, jaka mogłaby być inna
interpretacja dla podwójnego średnika oddzielonego spacją w podwójnie
zagnieżdżonym nawiasie kwadratowym?

do góry

> Faktycznie, właśnie coś takiego sobie myślę widząc zapis
> x[[i ;; ;; s]].

Bez czytania dokumentacji i przy pierwszym kontakcie ze składnią? Niezły jesteś.

Ja musiałem przeczytać dokumentację, o tutaj:

http://reference.wolfram.com/language/ref/Part.html

> Zresztą, jaka mogłaby być inna
> interpretacja dla podwójnego średnika oddzielonego spacją w podwójnie
> zagnieżdżonym nawiasie kwadratowym?

Po rzuceniu okiem na linka powyżej (tak nawet bez przewijania, wystarczy początek
strony) interpretacja mogłaby być właśnie taka a nie inna.

I wyobraź sobie, że o hd(x), tl(x) i ttl(x) też trzeba najpierw gdzieś przeczytać, bo
bez tego to są mnemoniki z epoki asemblera, chyba że mam losowo wybrać coś z tych
wyników:

http://www.acronymfinder.com/HD.html
http://www.acronymfinder.com/TL.html
http://www.acronymfinder.com/TTL.html

Pierwsze wyniki to: High Definition Toilet Total

Teraz moja kolej: "jaka mogłaby być inna interpretacja"?

Tak, znam LISPa i wiem co te skróty mogą oznaczać w Twoim SmallTalkowym cytacie, ale
jak trolować, to najlepiej w parach.

Na poważnie, ten Twój przykład mnie kompletnie nie przekonał. Nieparzyste i parzyste
elementy to pojęcia na tyle oczywiste, że nie powinny wymagać rekurencyjnej
rekonstrukcji ani sprawdzania cztery razy (!) czy coś jest nullem, czy nie jest.
Najśmieszniejsze jest to, że ten cytat był o wyższości czegoś nad językiem opartym o
wskaźniki - a tu proszę, cztery razy test na nulla, żeby wybrać z listy co drugi
element? No bez jaj. To jest strzał w stopę. Dobrze, że takie języki to tylko
historia.

--
Maciej Sobczak * http://www.inspirel.com

do góry