On 2015-09-12 19:26, AK wrote:
>>>>> Tak ? To poczytaj sobie o Simuli67.
>>>>> Moze Ci te dwa ++ z oczu opadna :)
>>>> Nie podaleś żadnego arumentu poza nazwą doskonale znanego języka.
>>> Nie masz pojecia o tym jezyku, a i doskonale znany nie jest.
>> Mam o nim pojęcie. Ostatni raz pisałem jakieś 15 lat temu, z czystej
>> ciekawości. Przyznam, że nie widzę żadnej znaczacej różnicy z C++ w
>> ideach. Róznica tylko w składni.
> Chlopie, przestan pieprzyc glupoty :(. Osmieszasz sie.
> PS: Pokaz mi call by name w C++

boost::phoenix/boost::bind pozwalają na podobne rzeczy. Jak się okazało
support języka nie jest niezbedny. I tak, istnieją rzeczy ktorych
phoenixem nie zrobiszi składnia kompletnie inna. I co z tego?
Programistów z mojej okolicy którzy znają pojecia zbliżone do lazy
evaluation policze na palcach jednej reki. PS. Simula nie była z tym
pierwsza.

, pokaz mi korutyny w C++

fibers. Dosepne w każym dużym OSie i niektórych małych z cooperative
multitasking. Ponadto koprocedury da się implementowac bez wsparcia
języka, najzwyczajniej pisząc kod w specyficzny sposob. Używam na
codzień. Okazało się że wsparcie języka nie jest niezbedne.

> Pokaz mi wspolbieznosc w C++ (bedaca czescia
> jezyka Simula)

Nowe standardy C++ opisują współbieznośc, ale nie jest ona specjalnie
istotna dla samego języka. Przykładem istotnej współbiezności jest
erlang, ale to znowu język bardziej akademicki. Ponadto współbieznośc
dzisiaj jest zarówno ważna jak i mocno odmienna od tego co było 5 lat
temu z uwagi na akceleratory graficzne. Powstały specjalistyczne
dialekty typu OpenCL. Wszystko się rozwija w kierunku trudnym do
przewidzenia, czekam na pierwsze domowe akceleratory FPGA gdzie pojawią
się języki podobne do VHDL/Verilog. Definiowanie wątków w tej chwili nie
jest specjalnie mądre. Nie wiadomo gdzie to się potoczy i model watkow
Simuli czy C++ może byc nic nie wart.

>, pokaz mi pakiety/moduly w C++ (tylko mi
> nie mow o #include bo mi brzuch sie urwie:).

Zdecydowano się na kompatybilnośc z C, więc include pozostały. Tak,
brakuje mi pakietów ale wygląda na to że zostawiono includes głównie z
powodu więszych możliwości metaprogramowania przez makra które jest
bardzo popularne (co nie znaczy że pochwalam). Brak pakietów nie boli aż
tak bardzo.

> O mniejszych rzeczach
> (np dynamiczna deklaracja tablic) nie wspomne.

Obecna od C99 i nikomu nie potrzebna bo zastapiona std::vector.

> Z niczego sie nie wycofuje. C++ jest bardzo kiepski jako jezyk do
> zastosowan ogolnych.
> Tak pisalem od poczatku i zdania nie zmienie.

Super. Nikt nie mowi ze masz zmieniać. Sam stawiasz tezę i z nią
dyskutujesz. Newsowe perpetum-mobile.

> Ba! on nawet nie jest stricte jezykiem obiektowym.

Ojej. Jest też funkcyjny jak trzeba, obiektowy jak trzeba, strukturalny
jak trzeba, są bibliteki metaprogramowania zmieniające go w jezyk
logiczny. Straszne że nie jest *akademicko* obiektowy. Aż się płakać
chcę. Tylko że znowu z tego nic nie wynika.

>> Jest wiele języków bardzo niebezpiecznych jesli sa uzywane przez
> Sęk/problem polega na tym, ze C/C++ jest jezykiem niebezpiecznym _nawet_
> w rekach niezlych i w maire doswiadczonych fachowcow :)

Bo Ci fachowcy spodziewają się opróócz silnej kontroli typów czasem
również reinterpret_cast. Bo takie zagadnienie do rozwiązania. Taka
praca i takie ryzyko.

>> assembler. Nikt się po nim nie spodziewa bezpieczeństwa.
> Nie no jasne.
> Zwlaszcza zestawienie: C++ + Scrum/Agile
> To jest dopiero mieszanka wybuchowa :)) !

A kto zestawia?

> Od jezyka "hybrydowego do zastosowan systemowych" nie
> powinno sie spodziewac jednak pewnego poziomu bezpieczenstwa ?

Nie. Od językow wysokiego poziomu, pracujących w user space tak. Od
języka "do pisania systemów operacyjnych" wymaga się elastyczności na
poziomie manipulowania bajtami w pamięci. Przypominam że pierwotnie do
tego był BCPL, a to byl język kompletnie i 100% niebezpieczny. I uważano
go za najlepszy do pisania OSów. I miałem z nim kontakt. I nie chcę więcej.

> No nie zartuj :)

Dyskutujesz sam ze sobą. Ja tylko prostuję.

>>> i (zwlaszac po ostatnim "standardzie") _niezwykle skomplikowanym_.
>> Jest, no i? Programista C++ zazwyczaj ma większą świadomośc o
>> *wszystkim*.
> Hehe :) A to dobre ! Mam doklandnie odmienne zdanie o wiekszosci
> programistow C/C++ :) Oni w wiekszosci nie maja swiadomosci jaką
> żyletę w zebach miedla :)

Bo masz do czynienia z cienkimi programistami. To że obecnie rynek
programisty IT jest rozcieńczony przez różnego rodzaju PHPowcow i
Pythonowców to trudno - naturalna kolej rzeczy. Fakt że obracasz się w
środowisku kieskich programistów C++ nijak nie powoduje że język jest
zły. Zły to on może być w danym zastosowaniu. I fakt, często jest.

>> Efektem czego dzisiaj można ją znaleźć na smietniku historii a
>> obliczenia wykonuje się na klastrach używając w tym celu obleśnych
>> językow z gatunku plusowych albo nie daj Boże Pythona. Ale Ci ludzie
>> sa głupi. Zrobili coś znakomitego a ono nie chce być znakomite. Shit.
> Nie. Ci ludzie byli bardzo madrzy.
> Glupi to sa Ci ktorzy woleli badziew w rodzaju C/C++ zamiast porzadnego
> jezyka jakim byla np. Simula.

To interesujące. To by oznaczało że jakieś 2 pokolenia naukowców są
głupie lub przynajmniej tępawe wybierają nie simule tylko coś innego.
Interesująca teza. Jestem pewny że to nie brak biblitek, kiepska
skalowalnośc, brak narzędzi były powodem. To tylko glupota. Tak.

PS. Jeszcze 5 lat temu kolega rozwijał oprogramowanie naukowe napisane w
Forth. Nie Fortranie. W *FORTH*. Tak, tam również ktoś wziąl porzadny
jezyk do konkretnego zastosowania. Nie mam więc zaufania do oceny
przydatnosci języka przez naukowców. Ale żeby wszyscy głupi? E, chyba nie.

> Zupelnymi baranami sa natomiast Ci ktorzy nie probuja nawet dostrzec
> jakosci Simuli czy innych porzadnych jezykow programowania.

Ale co Ci po jakości Simuli kiedy obecnie nie ma zagadnień w ktorych
jest używana i nie bedzie? Wszystkie ficzery Simuli są dostępne w
innych, żywych językach. Ktoś *dostrzegł* zalety i jakość. A sama Simula
nikomu się do niczego nie przyda w tej chwili.

> PS: Co do Pythona. Dlaczego "nie daj Boze?". Numpy czy Scipy
> pythonowe sa juz calkiem ok (polecam jeszcze numexpr - w duzym
> stopniu neutralizuje problem z pythonowym GIL).

Ponieważ python przyciąga narybek kiepskiej jakości sugerując że jest
językiem prostym w użyciu. O tym że tak nie jest zazwyczaj przekonuja
się firmy w połowie projektu pisanego przez studentów. Ogólnie jest mało
dobrej jakości kodu w Pythonie. Obserwacja własna, nie zawsze trzeźwa.

>> Jest gorsza bo bezuzyteczna. Nie ma ani programistów, ani zaplecza
> No ale jaka w tym wina _jezyka_) Simula :)

Jak nie to pewno kosmitów. Tych co pisza w C++.

> Wina to wejscie PCtow, sila USA i jego C nad dunskia Simula,
> przegapienie przez tworcow porzadnych kompilatorow roli
> i szybkosi rozwoju PC-tow itp itd

Historia informatyki to historia pomyłek.

> Ale nie samego jezyka Simula na mily Bog !:)

A kto mówi że simula jest zła? Jest tylko bezużyteczna. To co innego.

> PS: Jednak jestes typowym "Ayatollahem C++" :)

Nie.

> PS1: Tego sie nie da uleczyc, musisz z tym zyc az do smierci :)

Nie.

>> nawet współczesnie jak Closure, które nazwyczajniej przegrają z
>> dowolnym badziewiem. Tak się to kręci.
> Po pierwsze: Closure nie jest zadna rewolucja. Lisp juz byl

Closue to Lisp. Ale Lisp to nie Closure. Closure wprowadza kilka
ciekawych koncepcji. Być może inne jezyki je zassają i na tym jego rola
się zakończy. Jak Simuli.

> Po drugie: wcale mnie nie cieszy ze Closure przegrywa, ale programowane
> funkcyjne zwyczajne "nie lezy" czlowiekowi/jego naturze "sekwencyjnego
> myslenia".

Ma rozwijać warsztat. Nikt nie zmusza do napisania UI w języku
funkcyjnym bo to nie naturalne. Ale chciałbym mieć język posługujący sie
swobonie konstrukcjami funkcyjnymi, obiektowymi, logicznymi. Mogę wziąśc
Scale i stanąc na pustyni 3rd-party z zerowym dostępem do programistów.
"Dobrze dobrany język do zagadnienia" nie ozancza że da się go użyć.
Czasem wystarczy wybrać popularny język troche pasujacy do zagadnienia
ale ekonomicznie uzasadniony. Myślę że C++/Java/C# to takie języki.
Ekonomicznie uzasadnione.

>> Zupelnie niepodobna. Klasy i obiekty. Tam klasy i obiekty. Tu
>> wirtualne funckjie i tam wirtualne funkcje. Zupelnie niepodobna. Ani
>> trochę.
> No wiesz. Czlowiek i bocian tez maja po dwie nogi.
> Tyle ze czlowiek za cholere d..py w gore nie oderwie (nawet wczesna
> jesienią).
> Slowem: bzdurzysz. Nie masz pojecia nawet bladego o Simuli.

Obawiam się że trochę mam. Przyznam oczywiscie że za moich czasów była
to już prehistoria. Więc nie miałem okazji siedzieć na twardym stołku
przy Odrze i pisać koprocedury. Pisze je dzisiaj w C++, Javie i co tam
jeszcze mam. Świadomośc programisty to stosowanie róznych narzędzi
wyjetych z róznych koncepcji. Simula mnie już nie obchodzi, ale stosuje
z niej obiektowość, koprocedury, lazy evaluation.