W dniu poniedziałek, 19 listopada 2018 21:18:16 UTC+1 użytkownik s...@g...com
napisał:
> > Warto przyjrzeć się językowi Idris i typom zależnym. Twórca Idris, Edwin Brady,
> > opowiada tutaj o nim z humorem:
> > https://www.youtube.com/watch?v=zSsCLnLS1hg
>
> Po po pierwsze, primo:
> 1. C++ jest zupełnie wystarczający do wszystkiego.

Im ciaśniejsze mamy umysły, tym węższe jest nasze
wyobrażenie "wszystkiego", i tym łatwiej nam znaleźć
"jendą rzecz, która nadaje się do wszystkiego".

Dla mnie Scheme jest ostatecznym językiem programowania.
Ale mimo tego rozglądam się dookoła, bo w różnych miejscach
można znaleźć różne ciekawe pomysły.

> A to co nie produkcyjne może być w Bash lub Pythonie.

A dlaczego nie w C++?

> A jak chcemy zrobić bazkę to dodatkowo Sql.

A dlaczego nie C++?

I czy oprócz C++, basha, pythona, htmla, javascriptu i sql znasz
jeszcze jakieś języki?

> Jest tego dość by mieć czego się uczyć przez 5 lat!

Najwidoczniej siedzę w tych tematach dłużej niż 5 lat.

> Po drugie, primo:
> 2. W języku programowania jest najważniejsze by był kompilowany do kodu maszynowego
(niżej nie zejdziemy - chyba że jeżyki opisu sprzętu Vhdl/Verilog są nam
niestraszne).

Dlaczego to jest najważniejsze?

> Po trzecie, primo:
> 3. Nie język programowania z Ciebie robi programistę, ale algorytmy jakich używasz.

Nie rozumiem.
Myślałem, że to programowanie robi ze mnie programistę.

> Więc może sobie oszczędź tych wyjazdów z "odlotowymi" językami programowania, bo to
wrabianie w stratę czasu na bzdury!

Jeżeli nie chcesz, to się tego nie ucz.
Jeżeli kogoś to zainteresuje, to sobie obejrzy.
Akurat ma związek z tematem, który został poruszony
(oraz wartość rozrywkową)

> Lepiej już zaprojektować jakiś program (poćwiczyć projektowanie) z jakimiś
ciekawymi algorytmami (poćwiczyć projektowanie algorytmów i ew. złożoność
obliczeniową), a potem zastanowić się co w naszym dotychczasowym stylu kodowania było
nie tak i to zakodować to wg najnowszych pomysłów i spostrzeżeń (poćwiczyć
kodowanie).

No, jak się uczy podstaw, to warto ćwiczyć podstawy.

Przy okazji, "asercja" to po prostu inne słowo na "stwierdzenie"
albo "uznawanie".
Mówiąc technicznie, jest to kategoria wyrażenia należąca do
tak zwanych "postaw propozycjonalnych", czyli aktów mentalnych,
których możemy dokonywać względem sądów logicznych (czyli
odniesień wyrażeń językowych, które mają wartość logiczną, tj.
mogą być prawdziwe albo fałszywe).

Inne przykłady postaw propozycjonalnych to np. założenie
(hipoteza), wątpienie albo odrzucenie.

Gottlob Frege jest autorem nowożytnej analizy pojęcia asercji.
Polecam lekturę (to będzie albo Begriffschrift, albo Grundlagen
den Arithmetik).

> To jest racjonalne a nie strata czasu na kolejny (zbędny) język programowania.

Skąd wiesz, że to "kolejny (zbędny) język programowania"?
Na jakiej podstawie formułujesz taki sąd?

> Jak nie rozumiesz tego: to jest tak jak byś pożyczał od kogoś innego instrukcję
obsługi samochodu i się jarał jakie wymienione są tam ficzery - to paranoja masz swój
wózek i masz gdzieś ficzery wymienione w instrukcji kumpla - co najwyżej można na
temat tych ficzerów pogadać 5 min a nie czytać o tym tydzień!!!

Nie rozumiem porównania.
Serio.
C++ to najgorszy język, z jakim miałem styczność.
Już dawno oddałem go na złom.
C++ sprawia, że pierdołowate programiki, które w innych
językach zajęłyby kilka linijek, urastają do rangi
wielkiego osiągnięcia.

> Do trzeciego primo mam takie spostrzeżenie: zastanawiasz się czasem co programujesz
na co dzień?!? Czy nie jest tak, że przez prawie czas po prostu kopiujesz zmienne z
jednego miejsca w drugie?!? walcząc przy tym z jakimś obcym Api?!?

Nie mam tak. Choć przyznam, że pracując przez ostatni rok
w korporacji robiłem w ramach pracy dosłownie dokładnie to.
Tzn. pisałem kod, który generował instrukcje asemblera,
które wykorzystywały jakieś egzotyczne rozszerzenia procesorów
do tego, żeby o kilka promili szybciej (na niektórych benczmarkach)
implementować biblioteczną funkcję memmove.
Ale zrezygnowałem z pracy w korporacji.

Programując, staram się minimalizować dystans pomiędzy moimi
myślami a programami. Język programowania jest dla mnie
precyzyjną formą wyrazu myśli.

> Ja np w ciągu pół roku zakodowałem tylko jeden algorytm z prawdziwego zdarzenia
(problem producenta i konsumenta), co mi zajęło parę dni (walka z Api gniazdek i
funkcją select Linux-a). Natomiast przez pozostały czas tylko kopiuję z jednego w
drugie (wyświetlanie danych, zapisy do bazy i edycja parametrów urządzeń). Ale i tak
jestem zadowolony, że mam tą robotę. Dobre jest to, że ten spadkowy projekt
opanowałem i prowadzę ku końcowi. A teraz przygotowujemy się do stworzenia nowego
ciekawego systemu z kilkoma algorytmami (ale i tak kopiowania danych będzie pewnie
95% kodu systemu).

Trzymam kciuki.
Jak będziecie używać mojej funkcji memmove, to może nawet zadziała
o ćwierć promila szybciej na niektórych procesorach.

do góry

On 2018-11-19 21:18, s...@g...com wrote:
>> Warto przyjrzeć się językowi Idris i typom zależnym. Twórca Idris, Edwin Brady,
>> opowiada tutaj o nim z humorem:
>> https://www.youtube.com/watch?v=zSsCLnLS1hg
>
> Po po pierwsze, primo:
> 1. C++ jest zupełnie wystarczający do wszystkiego.

Boze jedyny... to juz nie jest odlot.
To niczym nie skazone wstecznictwo i betoniarstwo - wlasciwie
eliminujace z zawodu zwanego programostą.

AK

do góry

On 2018-11-19 23:12, g...@g...com wrote:

> Dla mnie Scheme jest ostatecznym językiem programowania.

Nastepny odlot ?

>> Po trzecie, primo:
>> 3. Nie język programowania z Ciebie robi programistę, ale algorytmy jakich
używasz.
>
> Nie rozumiem.
> Myślałem, że to programowanie robi ze mnie programistę.

Akurat tu IMHO przedpicsca ma racje.
Nie mlotek "robi" rzemieslnika, ale wlasnie "warsztat".

>> Więc może sobie oszczędź tych wyjazdów z "odlotowymi" językami programowania,
>> bo to wrabianie w stratę czasu na bzdury!
>
> Jeżeli nie chcesz, to się tego nie ucz.
> Jeżeli kogoś to zainteresuje, to sobie obejrzy.
> Akurat ma związek z tematem, który został poruszony
> (oraz wartość rozrywkową)

Schizofrenika chcesz przekonac, ze rzeczywistosc to rzeczywistosc?
Pozyj jeszcze kilka latek, to przekonasz sie ze "kultura" dla chama
jest dla niego tylko pozywka, a "reality" da schizofrenika jest taka
sama abstrakcja jak dla nas zycie na Sloncu. Zwyczajnie odpusc.
Chama i glupca (fir) nalezy bezwzglednie tepic, a schizofrenika
zostawic i jedynie wspolczuc (schizofrenia tak naprawde jest
nieuleczalna. Owszem... jest zaleczalna - jak alkoholizm - ale pod
warunkiem, ze dotkniety ta paskudna choroba sam tego chce).

> Serio.
> C++ to najgorszy język, z jakim miałem styczność.
> Już dawno oddałem go na złom.
> C++ sprawia, że pierdołowate programiki, które w innych
> językach zajęłyby kilka linijek, urastają do rangi
> wielkiego osiągnięcia.

O tak. Duzo w tym racji.

AK

do góry

> > A to co nie produkcyjne może być w Bash lub Pythonie.
>
> A dlaczego nie w C++?

Żeby było szybciej?!?

> > A jak chcemy zrobić bazkę to dodatkowo Sql.
>
> A dlaczego nie C++?

Bo taki mamy standard dla relacyjnych baz danych?!?

> I czy oprócz C++, basha, pythona, htmla, javascriptu i sql znasz
> jeszcze jakieś języki?

Asembler, Php, RegExp - to chyba już wszystko. Trochę liznąłem Java, ale to czysty
koszmar...

> > Po drugie, primo:
> > 2. W języku programowania jest najważniejsze by był kompilowany do kodu
maszynowego (niżej nie zejdziemy - chyba że jeżyki opisu sprzętu Vhdl/Verilog są nam
niestraszne).
>
> Dlaczego to jest najważniejsze?

Żeby program działał bez sztucznych narzutów (typu maszyny wirtualne i interpretery).

> > Lepiej już zaprojektować jakiś program (poćwiczyć projektowanie) z jakimiś
ciekawymi algorytmami (poćwiczyć projektowanie algorytmów i ew. złożoność
obliczeniową), a potem zastanowić się co w naszym dotychczasowym stylu kodowania było
nie tak i to zakodować to wg najnowszych pomysłów i spostrzeżeń (poćwiczyć
kodowanie).
>
> No, jak się uczy podstaw, to warto ćwiczyć podstawy.

To nie tylko podstawy, to również szlifowanie i rozwój z każdym nowym projektem.

> > To jest racjonalne a nie strata czasu na kolejny (zbędny) język programowania.
>
> Skąd wiesz, że to "kolejny (zbędny) język programowania"?
> Na jakiej podstawie formułujesz taki sąd?

Jw.

> C++ to najgorszy język, z jakim miałem styczność.
> Już dawno oddałem go na złom.

Najwyraźniej jesteś oportunistą! Widziałeś tą listę:
http://www.lextrait.com/Vincent/implementations.html
?!?
Na pierwszym miejscu C++ i na drugim Java - reszta języków na marginesie...

> C++ sprawia, że pierdołowate programiki, które w innych
> językach zajęłyby kilka linijek, urastają do rangi
> wielkiego osiągnięcia.

Ta... Bo co?!? Bo ktoś Ci zabronił używania Qt?!? A może się nie chciało?!?

> Trzymam kciuki.
> Jak będziecie używać mojej funkcji memmove, to może nawet zadziała
> o ćwierć promila szybciej na niektórych procesorach.

Arm?!? Raspbian z tego co wiem ma własne optymalizowane funkcje memcpy() przez co
debuger przy uruchamianiu zgłasza błąd "illegal instruction" (jednak breakpoint-y
działają), natomiast z tego samego powodu Valgrind nie działa wcale...
Jednak jeszcze nie podjęto decyzji o bazie sprzętowej (może będzie to Arm a może
Amd64).

do góry

AK <n...@n...net> wrote:

> (schizofrenia tak naprawde jest nieuleczalna. Owszem... jest zaleczalna
> - jak alkoholizm - ale pod warunkiem, ze dotkniety ta paskudna choroba
> sam tego chce).

Tu jest właśnie problem.

Są leki, które zmniejszają objawy (np. kwetiapina), ale schizofrenik sam
musi dostrzec problem, podczas gdy taka jest niestety natura tej choroby,
że go nie dostrzega, a wszelkie próby (szczerej) pomocy traktuje jak atak
na swoją tożsamość.

Co do C++ vs inne języki -- IMO narzędzia należy dobierać do celu, który
chce się osiągnąć, a nie odwrotnie. Dobry programista to taki, który ma
szerokie horyzonty, *zna* różne języki na tyle, że zna ich dobre i słabe
strony i wie, w jakim zastosowaniu który język sprawdzi się najlepiej.
Jeśli pracę z jednymi językami lubi bardziej niż z innymi, to jest to
poparte czymś więcej niż "nie chciało mi się tego uczyć, to sobie to
znienawidzę i uznam, że nie jest potrzebne".

--
https://www.youtube.com/watch?v=9lSzL1DqQn0

do góry

fir <p...@g...com> wrote:

> nie mozna byc normalnym robica takie rzeczy - teraz pytanie skad takie
> ludzkie gowno sie znalazlo na czacie zamiast siedziec z innymi downami w
> celi gdzie charakterystycznie bardziej by pasowalo?

Tomku drogi,

Coś ci się bardzo pomyliło. Nie siedzimy na czacie tylko na grupie
dyskusyjnej. Może dobrze byłoby, gdybyś odstawił czat na Onecie, gdzie
spędzasz czas rozmawiając na arcyciekawe tematy z mocno nieletnimi
dziewczynkami, bo zaczyna ci to szkodzić.

--
https://www.youtube.com/watch?v=9lSzL1DqQn0

do góry

W dniu poniedziałek, 19 listopada 2018 23:12:21 UTC+1 użytkownik g...@g...com
napisał:
> Jak będziecie używać mojej funkcji memmove, to może nawet zadziała
> o ćwierć promila szybciej na niektórych procesorach.

takie teksty nie brzmia za madrze (pominawszy fakt ze tego typu spory/dyskusje (tego
okreslonego typu) wogole nie sa za madre) (z trzeciej stony wlaczanie sie w takie
logiczne podejscie
(typu wypowiadanie zdan i rozrtrzasanie co jest rpawda a co nie) jest ok)

ile to jest cwierc promila? 0.025 %,
cos tu nie gra, wygladami na to ze
ktos kto to pisze ma bardzo osobliwe podejscie do optymalizacji i robil to albo jakos
dziwnie albo zupelnie zle
albo wogole

ja optymalizowalem relatywnie sporo i

1)
takie wartosci jak 0.025% nie wchodza
tam wogole w gre bo te czasy wogole nie sa tak stabilne by moc to zauwazyc i zmierzyc
(aq czas czystego memcopy to juz wogole gdy ja to mierzylem niezle oscylowal)
2)
samego memcopy raczej sie nie optymalizuje bo przestrzen by tu poprawic jest mala ale
juz cale okolice bliskie
memcopy - jak najbardziej
3) czynniki jakimi mozesz przyoptymalizowac juz calkiem dobrze ale zwyczajnie
napisany kod w c czy tam c++ moga byc naprawde spore, i wtedy nie wyrazasz tez tego
raczej w procentach tylko w 'x' ile razy, to ilemozesz osiagnac zalezy od natury
zagadnienia i od tego jak wstepnie przyoptymalizowany byl kod oraz od tego jak bardzo
daleko chesz isc w ta optymalizacje

ale moje przykladowe casy jakie ja znam

1) kiepsko napisany kod 60 ms na ramke
2) pobawianie sie z flagami kompilacji
(ale takie ktore polega na tym ze po roznych zmianach patrzysz na wplyw a nie tylko
na pale wlaczysz kilka) oraz wogole
wyodrebnienie petli i przepisanie jaj tak by bylo jasne co tam sie dzieje (jelsi ktos
napisal bez wiekszej uwagi) 30 ms na ramke

(dla mnie to pow punkt startoway bo jzu na starcie zwracam na to uwage)

3) poprzepisywanie, porozwijanie wyrazen, zredukowanie dzielen, poprzepisywanie na
inline (choc to malo pomaga raczej chodzi o to by miec wglad co tam sie dzieje),
ogolne poupraszczanie tak ze kod bardziej jest przyjazny podejsciu optymalizacyjnemu
- 16 ms

4) tabelaryzowanie kawalkow kodu, porozbijanie kodu na specjalne casy pod wzgledem
optymalizacji, dorobienie skomplikowanych algorytmow 'odrzucania roboty', zagladanie
do generowanego asma, ew wwalenie paru intrinsincow sse... przerobienie niektorych
czesci na kod ktory dzial w sposob lekko przyblizony (zlinearyzowany) (strata jakosc
wzgl szybkosci) - 1.6- 1.2 ms

5) zejscie na poziom asma i robienie jakiegos hardkoru w mikrokodzie razem ew jeszcze
z dorobieniem jeszcze wiekszych rewolucji w algorytmach odrzucania - prawdopodobnie
jeszcze mozna przyspieszyc 2 razy (i zejsc ponizej milisekundy ale to juz hardkor i
tego nie robie za duzo roboty i nei znam az takl asma


slowem jak ktos mowi ze optymalizacja to walka o promile to raczej nie wie co mowi,
wg mopich doswiadczen optymalizacja to raczej 'srednio' czynnik 10x 15x jeslis ie
nawet zaczyna z calkiem poprawnego kodu w c

nie widze przypadku w ktorych mowienie o promilach mialoby sens - bo to chyab
musialobybyc w wypadku potwznie przyoptymalizowanego kodu a taki kod ma juz wtedy
procentowo spoore fluktuacje wiec gadanie o promilach nie ma sensu

do góry

W dniu wtorek, 20 listopada 2018 10:43:47 UTC+1 użytkownik Queequeg napisał:
> fir <p...@g...com> wrote:
>
> > nie mozna byc normalnym robica takie rzeczy - teraz pytanie skad takie
> > ludzkie gowno sie znalazlo na czacie zamiast siedziec z innymi downami w
> > celi gdzie charakterystycznie bardziej by pasowalo?
>
> Tomku drogi,
>
> Coś ci się bardzo pomyliło. Nie siedzimy na czacie tylko na grupie
> dyskusyjnej. Może dobrze byłoby, gdybyś odstawił czat na Onecie, gdzie
> spędzasz czas rozmawiając na arcyciekawe tematy z mocno nieletnimi
> dziewczynkami, bo zaczyna ci to szkodzić.
>
no tak, pokazowa odpowiedz w stylu malpiej knajackiej gnidy, ktora nie wstydzi sie
tym stylem epatowac

cos sie znowu wyraznie pomylilo swinskiemu mariuszkowi czy tam adasiowi jakkolwiek
ten burak sie nazywa,

fakt ze tego typu gnidy stanowia dolny odsetek 10% usenetu jest faktem i probowani
uczenia ich normalnosci (czego probuje godek) ma takie szanse powoedzenie jak
wpuszczanie czerwonopyskiego plujacego na podloge dresa (lub dresow) na wyklad z
filozofii

ja proponuje separacje a w wypadkach skrajnych mile odsiadki w wiezieniach w ktorych
wlasnie czesta goszcza tego poziomu buraki

do góry

On 2018-11-20 10:35, Queequeg wrote:
> Jeśli pracę z jednymi językami lubi bardziej niż z innymi, to jest to
> poparte czymś więcej niż "nie chciało mi się tego uczyć, to sobie to
> znienawidzę i uznam, że nie jest potrzebne".

O własnie! Dokładnie tak.

AK

do góry

> > To następna obserwacja: jeśl wpływa to na runtime release należy to
> > odrzucić. Wszelakie checkery asercyjne, za wyjątkiem programowania
> > defensywanego, nie mogą istnieć w kodzie produkcyjnym.
>
> Nigdy nie rozumiałem sensu tego rozumowania

Sens jest również taki, że (jak na ironię!) w systemach krytycznych nie da się
spełnić kryterium 100% pokrycia kodu testami czegoś, co ma asserta. Tzn. jeśli w
kodzie jest assert, który *z założenia* ma się nigdy nie wykonać, to jest to tzw.
dead code i ma go nie być. Bo jeśli jest, to nie da się go przetestować. Albo
inaczej: nie da się wykazać testami, że coś się nigdy nie wykona, więc nie da się
zdobyć w ten sposób pewności, że się nie wykona. A jeśli osiągniemy tą pewność innymi
metodami (np. formalnymi), to asserta dynamicznego może wtedy w ogóle nie być.
Zupełnie niezależnie od tego, w pewnych środowiskach walnięcie assertem jest bez
sensu, bo i tak nie ma do kogo przekazać sterowania. Assert w rozruszniku serca jest
bez sensu, nie tylko technicznie, ale też filozoficznie.

To nie jest tylko kwestia szybkości działania, to może być też kwestia sensowności
istnienia samego asserta.

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

do góry