-
21. Data: 2017-06-02 15:43:15
Temat: Re: Oszczędności
Od: slawek <f...@f...com>
On Fri, 2 Jun 2017 12:01:11 +0200, "AK" <n...@n...net> wrote:
> Idiotyzmem jest Twoja sugestia ze w Javie czy innych C# rownie
latwo popelnic powazny blad
> czy "ogarnac" kod co w jakims assemblerze.
Równie łatwo nie jest. Jest równie możliwe. Jeżeli w Asemblerze
napiszesz sub zamiast add to może być nieciekawie: błąd semantyczny.
W Javie napiszesz - zamiast + i kaboom... taki sam błąd. W Simulinku
narysujesz linię zamiast do plusa to do minusa... I znowu błąd. W
jakimś Lispowatym napiszesz zamiast plus minus.
Ba! Programując komputer analogowy wetkniesz nie tam gdzie trzeba
kabelek. I pierdut... Znowu błąd.
Po prostu. Gdyby było inaczej... Gdyby istniał język gwarantujący
nieomylność i zero błędów...
Ale tak nie ma. Errare humanum est.
Oczywiście w niektórych językach nie da się szybko pisać dużych
programów. Bo już 100 linijek to pasztet zajęczy. W innych marsz ku
klęsce to 100000 linii. Jednak wywalenie się czegoś przekrytycznego
może być równie lub nierównie bolesne. Z punktu widzenia end usera
jest wsio rawno czy auto rozbiło się przez błąd w mikrokodzie CPU czy
przez błąd w jakimś bajerze napisanym w PHP czy Verilogu.
Swego czasu jeden z moich kolegów wychwał Pascala. Że błąd DOI=1.100
nie jest w nim możliwy. Tego samego dnia wstawił średnik bezpośrednio
po do w taki malowniczy sposób: for i:= 1 to 100 do;
> Co do mojego "potrafienia" to potrafilem i potrafie programowac
produkcyjnie w Algolu, Simuli,
> FORTRANie, COBOLU (slabo:), kilku BASICach (w tym VB), PL/I,
ASMx86, C/C++, Pascalu,
> Iconie, Tclu, Pythonie, C# i Javie (wciaz slabo:). Dotknalem kiedys
tez Prologa, Moduli2, (niestety)
Ale nie znasz Asemblera Z80, nie pisałeś na 68000, Logo, Forth, Jean.
Kiepsko. Nie widzę wśród tego wyliczenia Lisp, Mathematica, F#,
Haskella, Clojure, Lua. Nie ma LabView, Dragona, Keplera. I ty
myślisz że dasz nam radę zaimponować? Może przynajmniej Awk ew.
Scratch?!
> Nie wymieniam to po to, aby sie chwalic (bo to zwykle mlotki/dluta
sa:) ale zeby unaocznic
Ok. To są młotki. I właśnie dlatego że to są młotki to każdym można
sobie samemu rozbić palec.
-
22. Data: 2017-06-02 15:44:46
Temat: Re: Oszczędności
Od: slawek <f...@f...com>
On Fri, 2 Jun 2017 12:01:11 +0200, "AK" <n...@n...net> wrote:
> Prawdziwym chamem i prymitywem jest ten, ktory dla swoich blizej
niesprecyzowanych
> fiksacji/natrectw/"niedopieszczenia" zwyczajnie oklamuje innych
No to popatrz - opis pasuje do ciebie.
-
23. Data: 2017-06-02 15:54:36
Temat: Re: Oszczędności
Od: slawek <f...@f...com>
On Fri, 2 Jun 2017 04:05:36 -0700 (PDT), "M.M." <m...@g...com>
wrote:
> Błąd może być algorytmiczny,
> program nie daje poprawnych wyników dla wszystkich danych wejścio=
> wych -
> co tutaj pomoże język wyższego poziomu?
Oczywiście że tak.
Ogólnie obowiązuje prawo awansu: program jest rozbudowywany tak
długo, aż coraz liczniejsze błędy uniemozliwią jego ulepszanie.
W Asemblerze to może być 300 linijek. W Javie 30000 tysięcy. Asembler
może być czymś odpalam z linii poleceń, program w Javie mieć wypaśne
GUI. Jeden i drugi przypadek może mieć błąd w rodzaju miał być plus a
jest minus.
-
24. Data: 2017-06-02 17:27:27
Temat: Re: Oszczędności
Od: "M.M." <m...@g...com>
On Friday, June 2, 2017 at 3:54:38 PM UTC+2, slawek wrote:
> On Fri, 2 Jun 2017 04:05:36 -0700 (PDT), "M.M." <m...@g...com>
> wrote:
> > Błąd może być algorytmiczny,
> > program nie daje poprawnych wyników dla wszystkich danych wejścio=
> > wych -
> > co tutaj pomoże język wyższego poziomu?
>
> Oczywiście że tak.
>
> Ogólnie obowiązuje prawo awansu: program jest rozbudowywany tak
> długo, aż coraz liczniejsze błędy uniemozliwią jego ulepszanie.
U mnie zwykle to było inaczej. Program rozbudowywałem tak długo, do
póki miałem poczucie, że nie ma błędów. Poczucie że nie
ma błędów, nie jest tożsame z tym że naprawdę nie ma błędów. Z kolei
poczucie że nie ma błędów miałem, gdy PROGRAM MIAŁ ŁADNĄ, UJEDNOLICONĄ
ARCHITEKTURĘ. Innymi słowy, gdy architektura była
na tyle przejrzysta, że panowałem nad całością. W większych
programach trudno było dla całego kodu zaprojektować ujednoliconą
architekturę, ale wtedy robiło się architekturę wspólną dla
modułów, i potem w każdym module mniej lub bardziej podobna
architektura do modułów pozostałych. Niosło to ze sobą ryzyko, że
jakiś moduł stanie się tak zagmatwany, iż na poprawianie lub
przepisywanie go od nowa straci się dużo czasu. Ale cały
program z małymi przestojami zazwyczaj rozwijał się w dobrym
kierunku - o ile główna architektura nadal była dobra do
zmieniających się wymagań.
> W Asemblerze to może być 300 linijek.
> W Javie 30000 tysięcy.
Powiedziałbym, że w asemblerze to może być np. od 1 do 3tys linijek na
moduł, a w Javie, C, C++ może to być też 500-6tys linijek na moduł,
oczywiście 500 linijek w Javie (średnio) daje większą funkcjonalność
niż 500 linijek w asemblerze.
> Asembler
> może być czymś odpalam z linii poleceń, program w Javie mieć wypaśne
> GUI. Jeden i drugi przypadek może mieć błąd w rodzaju miał być plus a
> jest minus.
Tak samo myślę.
Pozdrawiam
-
25. Data: 2017-06-02 17:29:29
Temat: Re: Oszczędności
Od: bartekltg <b...@g...com>
On Friday, June 2, 2017 at 12:01:15 PM UTC+2, AK wrote:
> Użytkownik "slawek" <f...@f...com> napisał:
> Niskopoziomowo nalezy pisac dopiero wtedy gdy wszytsko inne zawiedzie, gdyz po
prostu i zwyczajnie
> jezyki niskopoziomowe (tak tak, w tym C i C++) sa wielokrotnie bardziej
Co jest niskopoziomowego w c++?
C++ daje dostęp do bebechów i przez to daje się tam pisać jak
w przenośnym assemblerze zwanym C (za co powinni bić linijką po rękach)
ale sam w sobie jest zdecydowanie językiem wysokiego poziomu.
pzdr
bartekltg
-
26. Data: 2017-06-02 17:41:51
Temat: Re: Oszczędności
Od: "M.M." <m...@g...com>
On Friday, June 2, 2017 at 5:29:31 PM UTC+2, bartekltg wrote:
> On Friday, June 2, 2017 at 12:01:15 PM UTC+2, AK wrote:
> > Użytkownik "slawek" <f...@f...com> napisał:
>
> > Niskopoziomowo nalezy pisac dopiero wtedy gdy wszytsko inne zawiedzie, gdyz po
prostu i zwyczajnie
> > jezyki niskopoziomowe (tak tak, w tym C i C++) sa wielokrotnie bardziej
>
> Co jest niskopoziomowego w c++?
Może autor miał na myśli "proceduralny C++", bez klas, szablonów,
wyjątków, ale z międleniem nazw i przeładowaniem? Hmmm trudno
tak programować, bo biblioteki używają klas, szablonów i wyjątków
także, choć rzadziej.
Pozdrawiam
-
27. Data: 2017-06-02 18:10:37
Temat: Re: Oszczędności
Od: nikt mnie k_rwa nie lubi 'POPIS/EU <N...@g...pl>
> Może autor miał na myśli "proceduralny C++", bez klas, szablonów,
> wyjątków, ale z międleniem nazw i przeładowaniem? Hmmm trudno
nie drażnij lwa
-
28. Data: 2017-06-02 18:44:48
Temat: Re: Oszczędności
Od: "AK" <n...@n...net>
Użytkownik "bartekltg" <b...@g...com> napisał:
On Friday, June 2, 2017 at 12:01:15 PM UTC+2, AK wrote:
> Użytkownik "slawek" <f...@f...com> napisał:
> Niskopoziomowo nalezy pisac dopiero wtedy gdy wszytsko inne zawiedzie, gdyz po
prostu i zwyczajnie
> jezyki niskopoziomowe (tak tak, w tym C i C++) sa wielokrotnie bardziej
> Co jest niskopoziomowego w c++?
Caly podset czyli C a w nim m.in..
- chory preprocesor zamiast normalnych modulow (a mozna bylo!, patrz C2)
- chore wskazniki i arytmetyke na nich (juz w Silmuli67 byly porzadne
referencje i one starczaly az nadto).
- brak chociazby reflleksji (ze juz o first-class nie wspomne)
co skutkuje statycznoscia wrappingu (nie do obejscia, trzeba generowac
naglowki itp)
- dynamiczny przydzial (a i statyczny) na poziomoe kamienia lupanego
(w takiej Simuli dalo sie np.spokojnie napisac:
begin
integer array a [expr1:expr2, expr3:expr4])
- brak do dzis (mimo wielu standardow i kilku niezaleznych implementacji
Borland i MS) np. jakze przydatnych "properties".
- chore (bo "z boku jezyka") kontenery (STL) skutkujace niewspieraniem ich
przez for (nie ma prawdziwego/normalnego np. foreach), ze juz o pofdejsciu takim
jak np. w Pythonie (comprehensions) nie wspomne.
- na ustandaryzowanie obslugi watkow trzeba bylo czekac 25 lat :)
/w koncu i tak wybrali pthread-y:)/
- na ustandaryzowanie smart pointerow trzeba bylo czekac 20 lat :)
/w koncu i tak wybrali boostowe:)/
- itp itd, mozna by tak do rana..
> C++ daje dostęp do bebechów i przez to daje się tam pisać jak
> w przenośnym assemblerze zwanym C (za co powinni bić linijką po rękach)
C jest bardzo dobry w swej roli (wlasniue przenosnego assemblera)
Upchanie go do C++ bylo zupelnie niepotrzebne (a raczej bylo duzym bledem).
Wystarczylaby w pelni lacznosc z C na poziomie linkera.
> ale sam w sobie jest zdecydowanie językiem wysokiego poziomu.
Tak ?
Moze wtedy gdy pisze sie wylacznie w oparciu np o Qt a nie w "normalnym"
standardowym C++ :)
Ba! Sam autor nie uwaza C++ za jezyk wysokiego poziomu.
Jest to jezyk hybrydowy a elementami obiektowosci przeznaczony
do zastosowan systemowych. Koniec kropka.
Dinozaur
-
29. Data: 2017-06-02 18:51:10
Temat: Re: Oszczędności
Od: "AK" <n...@n...net>
Użytkownik "M.M." <m...@g...com> napisał:
> Hmmm trudno tak programować, bo biblioteki używają klas, szablonów
> i wyjątków także, choć rzadziej.
Tak?. To napisz C++sowy dll, ktory w interface/API ma cus (np pole, parametr metody)
ze
standardowego STL-a...
AK
-
30. Data: 2017-06-02 20:41:01
Temat: Re: Oszczędności
Od: "AK" <n...@n...net>
Użytkownik "slawek" <f...@f...com> napisał w wiadomości
news:almarsoft.6592829290923025392@news.v.pl...
> On Fri, 2 Jun 2017 12:01:11 +0200, "AK" <n...@n...net> wrote:
>> Idiotyzmem jest Twoja sugestia ze w Javie czy innych C# rownie
> latwo popelnic powazny blad
>> czy "ogarnac" kod co w jakims assemblerze.
>
> Równie łatwo nie jest. Jest równie możliwe. Jeżeli w Asemblerze napiszesz sub
zamiast add to może
> być nieciekawie: błąd semantyczny.
>
> W Javie napiszesz - zamiast + i kaboom... taki sam błąd. W Simulinku narysujesz
linię zamiast do
> plusa to do minusa... I znowu błąd. W jakimś Lispowatym napiszesz zamiast plus
minus.
> Ba! Programując komputer analogowy wetkniesz nie tam gdzie trzeba kabelek. I
pierdut... Znowu
> błąd.
>
> Po prostu. Gdyby było inaczej... Gdyby istniał język gwarantujący nieomylność i
zero błędów...
> Ale tak nie ma. Errare humanum est.
>
> Oczywiście w niektórych językach nie da się szybko pisać dużych programów. Bo już
100 linijek to
> pasztet zajęczy. W innych marsz ku klęsce to 100000 linii. Jednak wywalenie się
czegoś
> przekrytycznego może być równie lub nierównie bolesne. Z punktu widzenia end usera
jest wsio rawno
> czy auto rozbiło się przez błąd w mikrokodzie CPU czy przez błąd w jakimś bajerze
napisanym w PHP
> czy Verilogu.
>
> Swego czasu jeden z moich kolegów wychwał Pascala. Że błąd DOI=1.100 nie jest w nim
możliwy. Tego
> samego dnia wstawił średnik bezpośrednio po do w taki malowniczy sposób: for i:= 1
to 100 do;
>> Co do mojego "potrafienia" to potrafilem i potrafie programowac
> produkcyjnie w Algolu, Simuli,
>> FORTRANie, COBOLU (slabo:), kilku BASICach (w tym VB), PL/I,
> ASMx86, C/C++, Pascalu,
>> Iconie, Tclu, Pythonie, C# i Javie (wciaz slabo:). Dotknalem kiedys
> tez Prologa, Moduli2, (niestety)
> Ale nie znasz Asemblera Z80, nie pisałeś na 68000, Logo, Forth,
Ogolnie. Skad wiesze ze nie?.
Nie wymienialem drobnostek z wiadomych powodow :)
> Jean.
Nie pisz o czyms czego nie dotknales (daaaawane czasy: Odra 1305).
Trudno Jean uznac za "pelnoprawny": j.programowania.
Bardziej za baardzo zaawansowany jezyk job-owy/batchowy.
Pomylilo Ci sie zapewne z jeszcze starszym Jovialem (a moze ze Snobolem4?).
AK