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

> gołębi, a kogoś zabawy pejczem. Rekursyjne (w PL nie ma czegoś
> takiego jak "rekurencja")

> https://pl.wikipedia.org/wiki/Rekurencja

Slawek ma racje. To "nowomowa".
Oryginalnie byla tylko rekursja
Oryginalnie bylo tylko FORTRANu i Algolu a nie "dzisiejsze" Fortrana , Algola
itp itd

AK


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

do góry

W dniu środa, 23 sierpnia 2017 22:34:09 UTC+2 użytkownik AK napisał:
> Użytkownik "slawek" <f...@f...com> napisał:
> > Tyle że odczucia są subiektywne, a więc lepiej zostawić je humanistom i innym
specjalistom od
> > mniemamologii stosowanej.
>
> Niekoniecznie.
> > Bo powoli dryfujemy w stronę kłótni czy lepiej jest pisać append czy Join.
>
> Najlep pisac normalnie:
> No w Pythonie
>
> a = [1,2,3]
> b = [4,5,6]
> a += b
>
> Mozna prosciej ?

Używanie destruktywnego przypisania to ogólnie umiarkowanie dobry pomysł.
Co jeżeli tablica a była używana w jakimś kontekście?
Właśnie ją zmieniłeś.
No ale niech będzie

c = a + b

> PS: szczegol skladniowy? Nie!. w Pythonie tez mona a.extend(b) ale..
> += zapamieta sie bo jest uniwersalne w sensie skladni, a extend/join/merge/itp jest
specyficzne dla
> API/lib-str jezyka

nie jest "uniwersalne w sensie składni"
W haskellu byś napisał

c = a ++ b

i pewnie użycie takiego operatora wiązałoby się z takim uzasadnieniem,
że po + można się spodziewać, że jest przemienne, ale sklejanie list
nie jest przemienne.

W PHP do sklejania stringów używa się operatora ".". Każdy operator
i każda nazwa funkcji mają charakter konwencji.

W Lispie budowanie złożonych struktur jest poniekąd wyróżnione,
i by się pisało `(,@a ,@b) (ewentualnie z modyfikacjami quasiquote'a
`(,a ... ,b ...))

Zatem tak, szczegół składniowy.

do góry

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

> a = [1,2,3]
> b = [4,5,6]
> a += b
>
> Mozna prosciej ?

> Używanie destruktywnego przypisania to ogólnie umiarkowanie dobry pomysł.
> Co jeżeli tablica a była używana w jakimś kontekście?

Nie wydziwiaj. Dobrze ?

> Właśnie ją zmieniłeś.

Bo tak chcialem!.

> No ale niech będzie

> że po + można się spodziewać, że jest przemienne, ale sklejanie list
> nie jest przemienne.

Panie :) Ludzie normalni nie mysla numeryka :). Dla nich plus to plus
i doskonale rozrozniaja ze a + b to co innego nic b + a

> W PHP do sklejania stringów używa się operatora ".". Każdy operator
> i każda nazwa funkcji mają charakter konwencji.

Kolejne wydziwianie. Szlag mnie trafia na PHPowa skladnie .!

AK

do góry

W dniu czwartek, 24 sierpnia 2017 00:15:29 UTC+2 użytkownik AK napisał:

>
> > a = [1,2,3]
> > b = [4,5,6]
> > a += b
> >
> > Mozna prosciej ?
>
> > Używanie destruktywnego przypisania to ogólnie umiarkowanie dobry pomysł.
> > Co jeżeli tablica a była używana w jakimś kontekście?
>
> Nie wydziwiaj. Dobrze ?
>
> > Właśnie ją zmieniłeś.
>
> Bo tak chcialem!.

Nawet pal licho mutowalność samuch zmiennych.

>>> a = [1,2,3]
>>> c = a
>>> b = [4,5,6]
>>> a += b
>>> a
[1,2,3,4,5,6]
>>> c
[1,2,3,4,5,6]
(ups!)

mogłeś przy okazji zmienić coś, czego zmienić nie chciałeś.

Dla porównania:
>>> a = [1,2,3]
>>> c = a
>>> b = [4,5,6]
>>> a = a + b
>>> a
[1,2,3,4,5,6]
>>> c
[1,2,3]

Serio, mutowalne operacje w kodzie to pomyłka.

https://en.wikipedia.org/wiki/Action_at_a_distance_(
computer_programming)

> > No ale niech będzie
>
> > że po + można się spodziewać, że jest przemienne, ale sklejanie list
> > nie jest przemienne.
>
> Panie :) Ludzie normalni nie mysla numeryka :). Dla nich plus to plus
> i doskonale rozrozniaja ze a + b to co innego nic b + a

To nie jest "myślenie numeryką", tylko "myślenie algebrą".

> > W PHP do sklejania stringów używa się operatora ".". Każdy operator
> > i każda nazwa funkcji mają charakter konwencji.
>
> Kolejne wydziwianie. Szlag mnie trafia na PHPowa skladnie .!

No widzisz. Ciebie trafia, kogoś innego nie trafia. Tobie się podoba
używanie + do konkatenacji tablic, a ktoś inny woli użyć do tego innego
symbolu, i każdy może mieć jakieś swoje powody, żeby myśleć tak, jak myśli.

do góry

W dniu środa, 23 sierpnia 2017 22:36:36 UTC+2 użytkownik AK napisał:
>
> > gołębi, a kogoś zabawy pejczem. Rekursyjne (w PL nie ma czegoś
> > takiego jak "rekurencja")
>
> > https://pl.wikipedia.org/wiki/Rekurencja
>
> Slawek ma racje. To "nowomowa".
> Oryginalnie byla tylko rekursja

"Oryginalnie"?
Oba te słowa są zapożyczeniem z łaciny, może za pośrednictwem
angielskiego. Nie ma tutaj miejsca na żadną oryginalność.

> Oryginalnie bylo tylko FORTRANu i Algolu a nie "dzisiejsze" Fortrana ,
> Algola itp itd

Nawet jeśli kiedyś używano języka inaczej niż dziś się go używa,
to co miałoby z tego wynikać?
Pytanie jest retoryczne, proszę nie odpowiadać. Tego rodzaju
spory należą do najbardziej bezsensownych, w jakich można uczestniczyć.
To jest normalne, że język podlega ewolucji.

do góry

> Mogę podać inny przykład, bliższy temu, o czym tutaj jest mowa.
>
> for (int i = 0; i < ticks_per_frame; i++) {
> for_each(in_seq(sectors), bind2nd(mem_fun(&Sector::update), 0.07));
> for_each(in_seq(portals), bind2nd(mem_fun(&Portal::update), 0.07));
> for_each(in_seq(ropes), bind2nd(mem_fun(&Rope::update), 0.07));
> }

Faktycznie koszmarek.

> Dla odmiany taki chociażby Python pozwoliłby wyrazić te konstrukcje
> np. tak:
>
> for instance in range(ticks_per_second):
> for sector in sectors:
> sector.update(0.07)

A gdzieś tak od pół dekady C++ pozwala tak:

for (Sector & s : sectors)
s.update(0.07);

W pewnym okresie była taka moda, że chyba wszystkie języki teraz mają coś podobnego.

> > Ale przecież operatory w Wolframie też można wypowiedzieć.
> > Np. operator indeksowania (to te podwójne nawiasy) nazywa się
> > Part.
>
> Dziwne. Nie przyszło mi do głowy, żeby [[_ ;; ;; _]] wymówić "Part".

Dziwne. Tak się właśnie ten operator nazywa. Podobnie, + nazywa się Plus. Itd.

> Prędzej wymówiłbym to jako "otwórz nawias kwadratowy, otwórz nawias
> kwadratowy, coś, spacja, średnik, średnik, spacja, średnik, średnik,
> spacja, coś, zamknij nawias kwadratowy, zamknij nawias kwadratowy".

Jasne. A wywołanie funkcji w SmallTalku wymawiasz "ttl, otwórz nawias okrągły, coś,
zamknij nawias okrąły". Nie silmy się na takie trolowanie.

> Wątpliwości w dalszym ciągu wzbudza rola podkreślnika po argumencie
> po lewej stronie znaku ":=",

To jest wzorzec, który akceptuje cokolwiek. Czyli jest to definicja funkcji, która ma
jeden argument dowolnego typu. Można wzorzec ograniczyć np tak:

oddsEvens[x_List] := ...

i wtedy jest to funkcja, która ma jeden argument typu List.
W tym przypadku można byłoby tak zrobić, ale wtedy taka funkcja działałaby tylko z
listami, a akurat nie tylko listy mają taką strukturę, którą moglibyśmy chcieć w ten
sposób uporządkować. Dlatego wolałem zostawić szerszy wzorzec.

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

> oraz to, dlaczego do wyrażenia tożsamości
> użyto symbolu powszechnie używanego w informatyce w roli przypisania.

Bo to jest przypisanie. Tak się właśnie definiuje funkcje.

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

> Podwójnych podwójnych średników też nie lubię.

To napisz x[[1;;-1;;2]], wtedy będzie widać, że indeksowanie jest od 1 do końca. Ta
spacja między średnikami to opuszczone -1.

> Zgadzam się.
> Gdybyśmy zresztą nawet nie dysponowali funkcją Parts, moglibyśmy
> ją sobie zdefiniować przy pomocy cons, car, cdr i rekurencji.

I to jest właśnie coś, czego nie lubię.
Indeksowanie jest naturalną operacją i dla komputera (w sensie: hardware) bardziej
podstawową. Dlatego wolę, jeśli język ją wspiera bezpośrednio.

W ogóle, w naturze nie ma procesów rekurencyjnych. To jest na siłę wciskany ludziom
kit, że rekurencja jest podstawą innych rzeczy. Dlatego języki promujące rekurencję
jako podstawową konstrukcję są nienaturalne - zarówno w nauce, jak i w wykonaniu.

> Że języki, które znamy, warunkują sposób, w jaki myślimy,

Niezupełnie. Pierwszy język może to warunkować (i Wittgensteinowi chodziło o język
naturalny). Natomiast później nasze myślenie może warunkować pozostałe wybory.

> Nie wiem zresztą, czy miał przekonać. Raczej miał stanowić
> ilustrację tego, w jaki sposób ta maksyma odzwierciedla się
> w kontekście języków programowania. Sądzę, że -- mimo wszystkich
> zarzutów, jakie wysnułeś, dotyczących rozwiązania wymyślonego
> przez Kaya (i które nb nijak się mają do tego, co chciałem
> zakomunikować) -- stanowi dobrą ilustrację.

Tak. Kiepski język prowadzi do kiepskiego myślenia i w rezultacie do kiepskich
programów. :-)

> w szczególności warto przyglądać się
> temu, jak historycznie kształtowały się nasze sposoby rozumienia
> obliczania i komputerów.

Tak.

> Skoro mowa o kontekście, może zamiast pokazywać przykład
> w Mathematice, która stosunkowo niewiele różni się od ISWIMa z lat 60.,
> może spróbowałbyś pokazać rozwiązanie tego zadania w nowoczesnym
> języku, jakim jest C++, żebyśmy zobaczyli

Dlaczego? Ty nie pokazałeś przykładu w C++. :-)

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

do góry

W dniu czwartek, 24 sierpnia 2017 10:25:26 UTC+2 użytkownik Maciej Sobczak napisał:
> > Mogę podać inny przykład, bliższy temu, o czym tutaj jest mowa.
> >
> > for (int i = 0; i < ticks_per_frame; i++) {
> > for_each(in_seq(sectors), bind2nd(mem_fun(&Sector::update), 0.07));
> > for_each(in_seq(portals), bind2nd(mem_fun(&Portal::update), 0.07));
> > for_each(in_seq(ropes), bind2nd(mem_fun(&Rope::update), 0.07));
> > }
>
> Faktycznie koszmarek.

Najgorsze jest to, że Stroustrup sam do czegoś takiego zachęcał.

> > Dla odmiany taki chociażby Python pozwoliłby wyrazić te konstrukcje
> > np. tak:
> >
> > for instance in range(ticks_per_second):
> > for sector in sectors:
> > sector.update(0.07)
>
> A gdzieś tak od pół dekady C++ pozwala tak:
>
> for (Sector & s : sectors)
> s.update(0.07);

Niestety, owe przeboje miały miejsce ponad dekadę temu.
Z tego co widziałem, w późniejszym kodzie zrobiłem sobie
coś takiego:

for_every(body , bodies)
(*body)->update(0.07);

gdzie for_every zdefiniowałem sobie jako następujące makro:

#define for_every(ITERATOR, COLLECTION) \
for(typeof(COLLECTION.begin()) ITERATOR = COLLECTION.begin(); \
ITERATOR != COLLECTION.end(); ++ITERATOR)

aż się dziwię, że byłem wtedy na tyle mądry, żeby nie napisać

#define in ,

Ale to był już okres schyłkowy, po którym dałem sobie spokój z C++em
(poza tym, że czasem go trochę używałem, jak potrzebowałem np. tablicy
haszującej albo innej kolekcji odmiennej od tablicy i ew. listy linkowanej)

> > > Ale przecież operatory w Wolframie też można wypowiedzieć.
> > > Np. operator indeksowania (to te podwójne nawiasy) nazywa się
> > > Part.
> >
> > Dziwne. Nie przyszło mi do głowy, żeby [[_ ;; ;; _]] wymówić "Part".
>
> Dziwne. Tak się właśnie ten operator nazywa. Podobnie, + nazywa się Plus. Itd.

Że + nazywa się Plus, to bym jeszcze może odgadnął.

> > Prędzej wymówiłbym to jako "otwórz nawias kwadratowy, otwórz nawias
> > kwadratowy, coś, spacja, średnik, średnik, spacja, średnik, średnik,
> > spacja, coś, zamknij nawias kwadratowy, zamknij nawias kwadratowy".
>
> Jasne. A wywołanie funkcji w SmallTalku wymawiasz "ttl, otwórz
> nawias okrągły, coś, zamknij nawias okrąły". Nie silmy się na
> takie trolowanie.

Akurat w Smalltalku masz zupełnie inną składnię, w której nie ma nawiasów.
Na matematyce uczono mnie, żeby f(x) czytać jako "f od x" albo
"wartośćć f w punkcie x". Nie uczono mnie, jak czytać [[_ ;; ;; _]]

> > Wątpliwości w dalszym ciągu wzbudza rola podkreślnika po argumencie
> > po lewej stronie znaku ":=",
>
> To jest wzorzec, który akceptuje cokolwiek. Czyli jest to definicja funkcji, która
ma jeden argument dowolnego typu. Można wzorzec ograniczyć np tak:

Napisałem "wątpliwości", a nie "ciekawość" ;]

> oddsEvens[x_List] := ...
>
> i wtedy jest to funkcja, która ma jeden argument typu List.
> W tym przypadku można byłoby tak zrobić, ale wtedy taka funkcja działałaby tylko z
listami, a akurat nie tylko listy mają taką strukturę, którą moglibyśmy chcieć w ten
sposób uporządkować. Dlatego wolałem zostawić szerszy wzorzec.
>
> http://reference.wolfram.com/language/ref/Blank.html
>
> > oraz to, dlaczego do wyrażenia tożsamości
> > użyto symbolu powszechnie używanego w informatyce w roli przypisania.
>
> Bo to jest przypisanie. Tak się właśnie definiuje funkcje.
>
> http://reference.wolfram.com/language/ref/SetDelayed
.html

Może w Mathematice, ale nie w matematyce. W matematyce
do określania tożsamości używa się symbolu =. Tego samego
symbolu używa się w ISWIM czy Haskell (w taki sam sposób).

> > Podwójnych podwójnych średników też nie lubię.
>
> To napisz x[[1;;-1;;2]], wtedy będzie widać, że indeksowanie jest od 1 do końca. Ta
spacja między średnikami to opuszczone -1.

Włos na głowie jeży się coraz bardziej.

> > Zgadzam się.
> > Gdybyśmy zresztą nawet nie dysponowali funkcją Parts, moglibyśmy
> > ją sobie zdefiniować przy pomocy cons, car, cdr i rekurencji.
>
> I to jest właśnie coś, czego nie lubię.
> Indeksowanie jest naturalną operacją i dla komputera (w sensie: hardware) bardziej
podstawową. Dlatego wolę, jeśli język ją wspiera bezpośrednio.
>
> W ogóle, w naturze nie ma procesów rekurencyjnych.
> To jest na siłę wciskany ludziom kit, że rekurencja jest
> podstawą innych rzeczy. Dlatego języki promujące rekurencję
> jako podstawową konstrukcję są nienaturalne - zarówno w nauce,
> jak i w wykonaniu.

To nie jest wciskanie ludziom kitu. Rekurencja w ogólności
jest prostsza do zrozumienia dla ludzi. Jeżeli spojrzeć na
rzeczy, które dzieją się w logice, to praktycznie wszystkie
podstawowe aksjomatyki mają charakter rekurencyjny, a bardzo
wiele dowodów jest indukcyjnych. Istnieje wiele zagadnień,
na przykład w kombinatoryce i teorii języków, które
mają bardzo naturalny sposób wyrazu przy pomocy rekurencji,
i których wyrażenie bez rekurencji w praktyce wymaga
"emulowania rekurencji" (np. tworzenia jawnych stosów).

Z rekurencją jest jednak taki problem, że o ile przy programowaniu
funkcyjnym jest prosta, o tyle analiza programów proceduralnych
używających rekurencję potrafi przyprawić o zawrót głowy.

> > Że języki, które znamy, warunkują sposób, w jaki myślimy,
>
> Niezupełnie. Pierwszy język może to warunkować
> (i Wittgensteinowi chodziło o język naturalny).
> Natomiast później nasze myślenie może warunkować pozostałe wybory.

Nie sądzę, żeby Wittgensteinowi chodziło ściśle o język naturalny.
Wittgenstein pisał "Traktat Logiczno-Filozoficzny" pod silnym wpływem
pism Fregego, który stworzył swój własny formalizm do precyzyjnego
zapisywania myśli (który finalnie ewoluował w coś, co dzisiaj znamy
jako rachunek predykatów). Ciekawostką nieujętą w komiksie jest to,
że Frege traktował swoją pracę jako realizację idei Leibniza zwanej
"calculus ratiocinator" albo "characteristica universalis", polegającej
na stworzeniu rachunku opisującego ludzkie myślenie. (Od innej strony
-- właśnie języka naturalnego -- do tej idei podszedł profesor Andrzej
Bogusławski z Uniwersytetu Warszawskiego, którego praca zainspirowała
Annę Wierzbicką do rozwinięcia systemu zwanego "Naturalnym Metajęzykiem
Semantycznym", będącego próbą ekstrakcji podstawowych "atomów znaczeniowych"
pozwalających opisać ludzkie rozumienie. Ot, ciekawostka)

Nota bene ta historia (tzn. o Fregem i Wittgensteinie) została bardzo
ładnie opowiedziana w komiksie pt. Logicomix, wydanym również w
języku polskim (zdaje się że wydawnictwo W.A.B.)

I oczywiście, ja się z Tobą zgadam, że nie jest tak, że "wszystko
jest językiem" -- że nasze doświadczenie jest w dużej mierze pozajęzykowe.
Ale trochę prawdy jest w tym Wittgensteinowskim stwierdzeniu.

> > Nie wiem zresztą, czy miał przekonać. Raczej miał stanowić
> > ilustrację tego, w jaki sposób ta maksyma odzwierciedla się
> > w kontekście języków programowania. Sądzę, że -- mimo wszystkich
> > zarzutów, jakie wysnułeś, dotyczących rozwiązania wymyślonego
> > przez Kaya (i które nb nijak się mają do tego, co chciałem
> > zakomunikować) -- stanowi dobrą ilustrację.
>
> Tak. Kiepski język prowadzi do kiepskiego myślenia
> i w rezultacie do kiepskich programów. :-)

Tak. To jest wniosek na poziomie ogólnym.
Z kolei nieznajomość historii prowadzi do tego,
że nie rozumiemy wartości tego, co posiadamy.
Allen Newell to naprawdę był niegłupi facet,
ale w czasach "po wynalezieniu Lispa" trudno
zrozumieć, jak ktoś mógł wpaść na coś tak pokracznego,
jak IPL.


> > Skoro mowa o kontekście, może zamiast pokazywać przykład
> > w Mathematice, która stosunkowo niewiele różni się od ISWIMa z lat 60.,
> > może spróbowałbyś pokazać rozwiązanie tego zadania w nowoczesnym
> > języku, jakim jest C++, żebyśmy zobaczyli
>
> Dlaczego? Ty nie pokazałeś przykładu w C++. :-)

:)
Ja swoje stanowisko dotyczące C++ staram się jasno artykułować.
W moim odczuciu to nie jest dobry język do formułowania myśli.
W jakimś sensie jest to wartościowy eksperyment dla tych, którzy
potrafią się uczyć na cudzych błędach, bo wydaje mi się, że
nie ma błędu, którego projektanci C++ by nie popełnili.

Jeżeli Twój stosunek do C++ jest równie sceptyczny, co mój,
to może ten apel powinienem skierować do entuzjastów tego
języka. Ktoś się podejmie?

do góry

On Thursday, August 24, 2017 at 11:38:34 AM UTC+2, g...@g...com wrote:
> Ja swoje stanowisko dotyczące C++ staram się jasno artykułować.
Każdy ma takie prawo.


> W moim odczuciu to nie jest dobry język do formułowania myśli.
W C++ przy pomocy odpowiednio zdefiniowanych klas, metod i
funkcji, można utworzyć sobie "język", może nie do formułowania
myśli, ale do zwięzłego rozwiązania problemu.


> W jakimś sensie jest to wartościowy eksperyment dla tych, którzy
> potrafią się uczyć na cudzych błędach, bo wydaje mi się, że
> nie ma błędu, którego projektanci C++ by nie popełnili.
C++ to asembler obiektowy. Dużo lepiej nie da się takiego
języka zaprojektować. Ja czasami też bym chciał w C++ programować
ciut dalej od warstwy sprzętowej. Ale cóż, jest jak jest.

Projektanci C++ mogli zrobić dwa języki wywodzące się z C:
jeden kompatybilny z C i dający się szybko skompilować na
byle jakim sprzęcie, a drugi wysokopoziomowy, niekompatybilny i
stawiający na wygodę programisty a nie na wygodę kompilatora, czy
optymalizatora. To był ich jedyny poważny błąd że nie wywiedli z
języka C dwóch standardów np. C++ i D++.


> Jeżeli Twój stosunek do C++ jest równie sceptyczny, co mój,
> to może ten apel powinienem skierować do entuzjastów tego
> języka. Ktoś się podejmie?
W wielu praktycznych zastosowaniach nie ma alternatywy.


Pozdrawiam

do góry

W dniu czwartek, 24 sierpnia 2017 12:20:37 UTC+2 użytkownik M.M. napisał:
> On Thursday, August 24, 2017 at 11:38:34 AM UTC+2, g...@g...com wrote:
> > Ja swoje stanowisko dotyczące C++ staram się jasno artykułować.
> Każdy ma takie prawo.
>
>
> > W moim odczuciu to nie jest dobry język do formułowania myśli.
> W C++ przy pomocy odpowiednio zdefiniowanych klas, metod i
> funkcji, można utworzyć sobie "język", może nie do formułowania
> myśli, ale do zwięzłego rozwiązania problemu.

W książce "Lekcja Programowania" był taki cytat:

"Dobry programista poradzi sobie z ubogim językiem
czy pokracznym systemem operacyjnym, ale nawet
najlepsze środowisko programistyczne nie uratuje
słabego programisty"

i oczywiście w jakimś sensie jest to truizm. Tyle
że może wytwarzać fałszywe przeświadczenie, że
jakość języka programowania nie ma żadnego znaczenia,
a jakość programisty ma wyłączne znaczenie.
Wydaje mi się, że przykład Allena Newella i Alana Kaya
pokazuje, że tak nie jest.

Dobry programista poradzi sobie z C++ -- z czasem nauczy
się omijać pułapki i obchodzić jego ograniczenia. Wytworzy
"swój własny" sposób programowania w C++, w którym będzie
się w stanie bez problemu poruszać. Wytworzy sobie swoją
własną bibliotekę klas, metod i definicji, w którym będzie
w stanie "rozwiązywać problemy" czy budować systemy. Jeśli
będzie musiał.

Tyle że moim zdaniem to nie jest dobra droga dla rozwoju
przemysłu i programisty. Lepiej mieć wspólny język, którym
możemy się bez problemu porozumieć -- tym bardziej, że
często samo sformułowanie problemu jest już jego rozwiązaniem
(albo jego kluczową częścią).

> > W jakimś sensie jest to wartościowy eksperyment dla tych, którzy
> > potrafią się uczyć na cudzych błędach, bo wydaje mi się, że
> > nie ma błędu, którego projektanci C++ by nie popełnili.
> C++ to asembler obiektowy. Dużo lepiej nie da się takiego
> języka zaprojektować.

Nie rozumiem. Co to jest "asembler obiektowy"?

> Ja czasami też bym chciał w C++ programować
> ciut dalej od warstwy sprzętowej. Ale cóż, jest jak jest.
>
> Projektanci C++ mogli zrobić dwa języki wywodzące się z C:

Projektanci C++ nie są jedynymi osobami na świecie, które
mogą robić języki programowania. (często mam wrażenie, że
sukces C++ wziął się stąd, że było wiele osób, którym wydawało
się, że jest inaczej)

> > Jeżeli Twój stosunek do C++ jest równie sceptyczny, co mój,
> > to może ten apel powinienem skierować do entuzjastów tego
> > języka. Ktoś się podejmie?
> W wielu praktycznych zastosowaniach nie ma alternatywy.

Zawsze jest jakaś alternatywa. Czasem po prostu trzeba włożyć
nieco pracy, żeby jej poszukać.

do góry

W dniu czwartek, 24 sierpnia 2017 13:02:09 UTC+2 użytkownik g...@g...com
napisał:
> W dniu czwartek, 24 sierpnia 2017 12:20:37 UTC+2 użytkownik M.M. napisał:
> > C++ to asembler obiektowy. Dużo lepiej nie da się takiego
> > języka zaprojektować.
>
> Nie rozumiem. Co to jest "asembler obiektowy"?
>

jak juz o makroassembler obiektowy ;c

(mrugam bo jest to troche faktem i zarazem jest tym cos dosyc komicznego (bo m.in.
faktycznie c++ jest na przyklad bardziej makroassemblerem niz c (o ktorym mozna by
powiedziec moze na upartego ze jest jakims tam asemblerem ale o wiele mniej niz o
c++, gdzie w tym gaszczu makr mozna sie niezle zamotac - gdzie w tedy juz nie motasz
sie w asemblerze tylko w makrach ;c)


[btw ostatnio pracuje nad swoim asemblerem "org-asm" jestem juz bardzo blisko do
wrzucenia do sciagniecie pierwszej dzialajacej choc okrojonej wersji testowej, moze
napisze o tym posta bo to okazalo sie pisanie tego dosyc ciekawe (zwlaszcza ze ladnie
integruje sie z moim "siclem")

tak naprawde z tej roboty zostalo mi zrobienie tlumaczenie etykiet na konkretne
adresy (co chyab dzis bede robic) i spiecie roznych zrobionych juz z grubsza kawalkow
w jedno et voila]

do góry