On 2015-09-13 13:14, AK wrote:
>> Działa tylko na niszowym systemie operacyjnym do oglądania facebooka.
>> Nie jest w obszerze moich zainteresowań.
> Hehe. Ty jednak naprawde jestes Ayatollayem C++ i (nie daj Boze) Linuxa :)

W ktorym miejscu wyczytałeś coś o Linuxie?

> Slowem pieprzysz Wasc farmazony.
> Na .NET przestawila sie dzis wiekszosc duzych zachodnich i polskich firm
> softwareowych,
> a reszta jest w trakcie.

"Działa tylko na niszowym systemie operacyjnym". Nie wykuczam że firmy
te piszą software akurat dla niszowych systemow operacyjnych. Przykro
mi, u mnie nie zadziała. Też piszę na inna niszę.

>>> To naprawde porzadna technologia (lepsza od Javy).
>> Oczywiście. Zupełnie przeciez inna .... to taki żart.
> Tak. Zupelnie inna gdy _wielojezykowa_ (tylko tyle i az tyle:)

Zupełnie jak java. Może bez udziału jej twórców i niecho chaotycznie ale...

https://en.wikipedia.org/wiki/List_of_JVM_languages

Co zrobił MS? Wziął javę, udając że to coś innego i kontrolował proces
tworzenia aby wyszlo coś spójnego. Wyszło to samo. Pi x drzwi tyle.

> i sprzegnieta dobrze z uznanymi i stosowanymi powszechnie od lat
> technologiami komponentowymi (COM. DCOM).

No i co z tego? Znowu nisza.

>>> I nie jest prawda ze jest zamknieta.
>> Pewno że nie. Przeciez jest tyle innych imple ... oh wait.
> Sa przynajmniej 3. Wystarczy.

A które *działają*? Ale nie że wyświetlaja hello world, tylko wsadzisz
je do respiratora.

> Bedzie wiecej bo MS rok temu "otworzyl" SDK na inne platformy.

Patrz, cały świat porwał sie, nowe impelementacje powstają co tydzień,
wszyscy programisci przechodza na C#, korporacje zwalniają miliony
programistow i zatrudniają studentów. Wooha. Przepraszam, poniosła mnie
ta wizja. Back to work.

>> Chyba bym go jednak nie wstawiał do respiratora. .NETa z resztą też.
> No widzisz. A taki AutoDesk Cie nie posluchal (i setki innych firm:).

One też produkuja respiratory? Czy może tylko duperelowane programy?

> Chlopie, ja od ok pol roku intensywnie ucze sie .NET i C# aby
> wreszcie z luboscia pozbyc sie 30-letniego garba syfiastego C++,
> a ty ciagle tkwisz w tym swym C+sowym ayatollahizmie, heh

To interesujące. Popełniłem trochę kodu w C#. Jakoś nie widzę żadnej
róznicy w stosunku do Javy. Nastepny nudny język, moving on.

>> Przykro mi, C/C++ mają chyba najwieksza obecnie przenośność
>> z powodu dostepnosci kompilatorów na masę egzotycznych architektur, co
>> wcale nie powoduje ze jest ona łatwa do uzyskania przez programistów
>> nie uświadomionych w hardware.
> Portowalem dosc duze systemy C++ sowe na rozne platformy przez
> duza czesc mego zycia zadowodego i moge z _czysta pewnoscia_
> stwierdzic, ze tworzysz mity.
> Super przenosnosc C++ _jest zwykla iluzja_.
> PS: nawet tak prosta i czesto spotykana konstrukcja jak
> unsigned int a;
> ..
> if ( a & 0xFFFCFFDF )
> jest nieprzenosna.

A zauwazyleś ża pisze coś o świadomości hardware? Zakładasz że
problemami przenośnosci zajmują się przygłupy po kursie obiektowości w
C++? NIE. Co ciekawe, stosując prawidlowe wzorce kodu można przenośność
znaczaco ulatwić. C++ nigdy nie będzie dobry do przenoszenia, ale
jednoczesnie jest jedynym językiem o takim szerokim zakresie arch na
ktorych działa. Że cięzko? To dobrze, moja pensja rosnie.

> Wylow mi z programie/systemie liczacym
> nawet zaledwie tylko kilkaset tysiecy linii wszytskie miejsca
> o podobnym "portability failure" ? Ile Ci to czasu zajmie ?

Zero. Code review zajmuje się przy okazji takimi problemami. Ale nie, ja
wiem że masz pogardę do technik Agilowych. Ja też, ale wyciągam z nich
co dobre.

>> Pisząc system operacyjny musisz mieć oba. Używanie dwóch róznych
>> języków żadko kiedy się sprawdza.
>> Nawet jesli dano support do tego w postaci .NET to poza helloworldami
>> nie widziałem dużej aplikacji napisanej w F# i C# jednoczesnie. Jakoś
>> się to nie chce sprawdzać.
> Spytaj dlaczego F# nie jest uzywany.

Uważaj, pryska mit o wielojęzykowości C#, zaraz zostanie z niego tylko
Java po przemalowaniu.

> Ja spotkalem kilka systemow o wspoldzialajacych C# i VB NET.
> Sam pisze np. w IronPythonie na Win i na Mono.
> Dziala toto.

To niewystarczający argument na produkcji.

>> Jeśli piszesz heap to nie unikniesz raw memory. Jeśli piszesz
>> sterownik to nie unikniesz raw memory. Jesli piszesz w embedded to nie
>> unikniesz raw memory. Sorry, sa miejsca gdzie silne typy są tylko
>> kłopotem. I sa miejsca gdzie są zbawienne. Często w tej samej
>> aplikacji. Co zrobić.
> Nie stosowac C++ w "ogolnych zastosowania", ale wylacznie systemowych
> (bo do takich zostal stworzony!).

I KTO TWIERDZI INACZEJ?

>> Nie da się ich obejśc z powodu code review. Przynajmniej w poważnych
>> firmach.
> Hehe :) Nie rozsmieszaj mnie :)
> Zwlaszac w "porzadnuych firmach" wazne jest, aby problem zwyczajnie jak
> najszybciej
> "przestal istniec". _Niewazne_ jakim sposobem.

Pracujesz najwyraźniej w śmieciowych miejscach. To tlumaczy częściowo
dlaczego masz taką pogardę do wszystkiego. W mojej okolicy code review
to codzienność. Podobnie jak masa innych technik poprawiających jakość.
Przykro mi, że to nie pasuje do twoich wyobrażeń o pracy obecnego pokolenia.

> To wlasnie w malych (do czasu:) - bo to kosztowne) jeszcze czasami dba
> sie o code-review itp

Myślę że nie widzialeś za wiele o procesie produkcji oprogramowania.

>> Nikt nie twierdzi że jest eleganckie. Jednak boost::mpl,
>> boost::spirit, boost::phoenix pokazały ze można dużo więcej niż się
>> wydawało że można. BEZ ZMIAN W JĘZYKU. Tak, to są biblioteki pełne
>> workaroundów. Ale jednoczesnie prezentują zdumiewająco czysty frontend
>> dla programisty.
> Jaasne. I zdumiewajaco bledogenny (bo oparty na "metaprogramowaniu
> templaetowym").

Pisuję na codzień. Błedy, jesli sa, zazwyczaj dotyczą kompilacji. Jest
niezwykle mało prawdopodobne abyś dostał błąd runtime w parserze
spirita. Natomiast można sobie sprzelić w stopę, oczywiście.

> Dziekuje bardzo.A wystarczyla by prosta drobna i nie naruszajaca
> backward compatibility
> zmiana w jezyku. (Podobnie jestli chodzi o moduly: Zaden #import nie
> naruszalby
> backward compatibility).

Najwidoczniej C++ ma zostać jaki jest a do innych rzeczy są inne języki.
Mi by się przydały lambdy. Nie ma. W sensie że nie ma w moich
produkcyjnych kompilatorach. Zamiast pieprzyć o wyższości lat 60-tych
mogę lambdy dostać z boost. I używać.

>> Nie. To istotny ficzer. Sa zastosowania gdzie jest on zdecydowanie
>> wygodniejszy w użyciu niż cokolwiek innego. Jest. Używam go.
> Zaden ficzer. To technika dostepna w _kazdym jezyku_ majacym obiekty i
> konstruktor/destruktor).

Tych języków jest niewiele. Jedyny popularny jaki znam to Delphi.
Pozostałe nie mają deterministycznej destrukcji, lub tez wymaga ona
ręcznego uruchomienia.

> W C++ to jednak proteza na znane niedogodnosci (brak finally, brak gc i
> dispose).

Albo rozwiązanie problemów z gc w zastosowaniach gdzie gc tylko
przeszkadza. Nie, C++ nie ma rozwiązać wszystkich problemów świata.
Tylko niektóre.

>>> W dodatku dziurawa jak but (i z boku) bo wiekszosc std:: zupelnie olewa
>>> RAII.
>> Nie. Nie da się olać raii. Ono jest zawsze dostępne. Może masz na
>> mysli że std::vector< Foo* > nic nie zwalnia sam? Nie powinien.
> vector nie zwalnia , strumienie nie zwalniaja (sa calkiem z boku)
> 90% "biblioteki standardowej" nie zwalnia. Widac wyraznie, ze jezyk
> _kompletnie nie wspiera RAII_.

Bibliteki dostarczone z nim nie wspierają RAII. Inne dostarczone przez
społeczność (boost) używaja *wszedzie* tych technik bazując na nich.

> Samemu trza napisac wnostwo RAIIowatch
> wrapperow na istniejace rzeczy.

Nie. 90% kodu już jest. Boost.

> RAII ma to do siebie, ze
> "albo wszystko albo nic". Jesli sie stosuje RAII to trzeba byc wlascwie
> bez wyjatku konsekwentny. Niestety tu C++ nie pomaga.
> Jest podobnie jak przy "silnym typowaniu" C++.
> Mamy "silna kontrole typow" a obok wytrych (void*) :)

Na tym polega niskopoziomowość.

>> Ale C# nie działa nigdzie poza kilkoma platformami. I nawet tam z
>> wielu powodów nie ma sensu w konkretnych zastosowaniach, np. z powodu gc.
> W czym niby przeszkadza gc ?

W systemach real time. W systemach bez heapu. W systemach z
mikroskopijnym heapem. W systemach powolnych. W systemach bez threadów.

> W Simuli nie przeszkadzal. w Pythonie nie
> przeszkadza w Javie nie przeszkadza i w C#/.NET tez.

Widocznie nie trafiłeś na zagadnienie w ktorym przeszkadza. Ja nie
trafiłem na zagadnienie w ktorym grzesiu3 pomaga. Co zrobić. To tylko
życiowy pech.

>> Nieprawda. To tylko styl nauczania programowania obecnie faworyzuje
>> języki imperatywne. Wiele problemów daje się rozwiązać
>> prosciej/inaczej jesli zmienisz paradygmat. A ponieważ aplikacje mają
>> różne problemy czasami musisz mieć język spelniający wiele paradygmatów.
> Jest taki.Oz/Mozart.

Kojeny język akademicki. Mozna tak wyliczać bez końca. Bez wątpienia te
języki są istotne dla rozwoju programowania. Ale są tylko i wyłacznie
głupim argumentam w tego typu dyskusjach. Sorry, liczba programistów na
metr kwadratory znających Mozart wchodzi mi w epsilon.

>> Nawet kiepsko, ale dający taką możliwość. Przy czym żaden projektowany
>> do tego nie zdobył popularności produkcyjnej. Co zrobić.
> Nie poddawac sie "splywowi szamba" .

Ach, czyli jednak pisanie dla sztuki? No to nie ma wyboru, uczelnia,
najlepiej w PL gdzie nikt nie pyta o wdrożenia.

> PS1: Tyle ze funkcyjnosc naprawde nie lezy "homo naledi" :)
> Obiektowosc jest bardziej naturalna.

Nie wiem czy odważyłbym się na takie ogólne wnioski.

>> Mam wątpliwośc czy na tym ma polegać programowanie funkcyjne.
> Funkcyjne ? Funkcyjne polegaloby na braku stanu, a ja
> wole te stowke (stan) w portfelu miec (ma Zona tez :).

Okazuje się w duzych systemach że to może byc wada a nie zaleta.

>> Makra to narzędzie. Możesz sobie ich używać lub nie.
> E tam. Jesli sa , to ktos ich _na pewno_ niestesty uzyje.
> A makra to syf i tyle (niewazne czy w postaci C++sowych tempates czy
> #define).

Makra w lispie to nie są proste #define.

> Jedyne generics jakie mi sie podoba to scisle zintegrowane z jezykiem i
> "typologią"
> jezyka Javowe generics (tez nie bez wad ale nie tak oblesnych jak
> tempates w C++).

generics to nie templates. Różnice są na tyle zasadnicze że w C++
powstało metaprogramowanie a Java ma dalej tylko substytucje typu i tyle.