Operator overloading – da sau ba?

adamsd, on 25 aprilie 2019 - 16:19, said:

Asta n-are nici o treaba cu operator overloading si nici cu C++ in particular. Descrierea s-ar potrivi mai degraba APL - exemplu de pe Wiki, n-am lucrat si nici nu voi lucra vreodata intr-un asemenea limbaj, nefiind matematician.
"This following immediate-mode expression generates a typical set of Pick 6 lottery numbers: six pseudo-random integers ranging from 1 to 40, guaranteed non-repeating, and displays them sorted in ascending order:"

x[⍋x←6?40]

APL, din cate stiu, nu suporta nici o forma de overloading.

Quote

Nu trebuie, ajunge sa stii suficienta matematica (sau fizica). Daca nu, iti pui intrebari prostesti. Dar daca tot ai pomenit de produsul vectorial, ia da tu un google sa vezi ce-i cu el pe la alte dimensiuni. Poate inveti ceva. Apropo, ce-i ala 'vector simplu'?

Quote

Sigur ca da. Cumva n-a luat premiul Nobel pentru nrg (si lucruri conexe) maretia voastra, ci unul pe nume Wilson. Probabil pentru ca a venit si el cu un lucru trivial o data in viata, la astia ca tine care scot cate unul pe zi nu se mai obosesc sa-l dea, ca ar ramane instantaneu fara bani. Tu realizezi cat de penibil poti sa fii?

Edited by parabellum, 25 April 2019 - 16:47.

adamsd, on 25 aprilie 2019 - 16:19, said:

Departe de a incuraja cod format aproape doar din simboluri, insa nu rareori am intalnit cod considerabil de lung care insa exprima o idee (business logic) foarte scurta. Daca am nevoie de 2-3 propozitii pentru a exprima punctual, in cuvinte, ce trebuie sa faca codul insa vad o metoda de 300 de randuri, plina de variabile intermediare, dam in extrema cealalta.

Iar te faci ca nu intelegi. E o diferenta intre ala care ia premiul Nobel pentru fizica si ala care ia formulele si face un program. La fel cum e normal pentru ORICE programator sa nu aibe habar ce se intimpla in TOATE programele dpdv al fizicii sau matematicii la care unii isi bat capul cu anii.

Ce-ti poate spunevun programator e cum sa folosesti practici mai bune pentru a implementa mai bine ce vrei sa implementezi, mai ales in situatia in care vrei sa faci codul public, caz in care conteaza sa fie cit mai usor de inteles sau modificat.

Esti pe aria de programare, nu de fizica sau matematica, si imi pare rau ca te simti atacat din nimic. Nimeni nu-i perfect, dar toti ar trebui sa incerce macar

Quote

Ok, ma fac ca te cred. E trivial sa intelegi si sa implementezi chestii pentru care se dau premii Nobel sau chiar mai simple. Tu si cu celalalt, care banalizati lucrurile, aveti un challenge ca sa demonstrati ca aveti dreptate.

Aveti aici un articol trivial: https://arxiv.org/abs/1202.5664

Dupa cum se vede, niste chestii tratate pe blog (nrg, dmrg, si tebd - desi asta nu explicit, intra la 'tensor networks') sunt mentionate pe acolo. Challenge-ul e sa implementati voi trivial asa ceva, adaugat la ce-am facut eu. Puteti sa implementati de la zero programele pe care le-am implementat eu, cu 'practici mai bune' si bineinteles, pe subiectul threadului, fara nici un fel de operator overloading.

Pentru voi e trivial, daca mie imi ia ore sa implementez ceva, voua va ia minute. Succes!

Prognoza stiintifica: o sa implementati asa ceva cand o zbura porcu'. Superluminic.

Edited by parabellum, 25 April 2019 - 18:39.

parabellum, on 25 aprilie 2019 - 18:38, said:

Iarasi te faci ca nu intelegi. Acolo nu e nimic, absolut nimic de implementat. Evident ca lucrurile sunt banale cand ai formule mura-n gura pe care le intelegi si pe care le translatezi in cod. Nu e ca si cum descoperi tu formulele.

Faci niste confuzii grave intre diverse domenii de specialitate si programare.

Treaba unui programator nu e aceea de a invata domenii diferite de programare, ci de a implementata cereri clar si corect comunicate intr-un limbaj natural(cu un maxim de conventii si formalisme ce se regasesc prin matematica de liceu, maxim facultate licenta).

Daca tu crezi ca a intelege nu stiu chestiuni de specialitate e treaba programatorului, atunci inseamna ca nu stii ce e programarea si in general ingineria software.

Quote

Spune-le si la aia care au avut nevoie de ani ca sa implementeze asa ceva in programe mai serioase.

Quote

Era un banc pe tema asta, despre niste carti (inclusiv Jackson). De cate ori apare cuvantul 'evident', demonstratia ia cel putin cinci pagini. Sigur, aia era pentru lucrurile adevarate, nu pentru prostiile false pe care le emiti tu.
Oricum, ai subliniat cateva chestii:
a) Trebuie sa le intelegi. Partea asta poate sa nu fie deloc triviala. Inainte de a scrie codul care trateaza asa ceva, trebuie sa intelegi. Ai realizat ceva fenomenal aici.
b) Mura-n gura e o prostie. A trebuit sa deduc din formulele alea, nu e ca si cu copy/paste cum iti imaginezi tu. De exemplu, acum m-am apucat de un program DFT in spatiu real pentru blog. Gridul e non-linear. Ghici ce? A trebuit sa deduc formule, pentru ca nu ti le da nimeni pe toate mura in gura cum iti imaginezi. Plus ca in carti mai gasesti si greseli, de aceea e bine sa le deduci si tu, chiar si cand sunt date 'mura in gura'. Am si exemplu intr-unul din proiecte, chiar am pus comentariu in cod, vrei link?

Un exemplu concret unde cineva a avut 'mura in gura':
https://www.physicsf...ermions.965771/
Raspunsul imi apartine, continuarea e aici: https://www.physicsf...ubspace.965747/ Raspunsul pe care l-a primit ala e foarte pertinent (de la 'King Vitamin'), dar culmea, nici ala nu s-a prins care-i treaba cu dmrg. De fapt individul dorea sa stie cum sa limiteze subspatiile in asa fel incat sa se limiteze la un numar constant de fermioni (in tot sistemul) in timpul calculului. O trivialitate, hai sa vedem, intelegi lucruri triviale? Culmea, in cazul asta (deloc in altele) implementarea chiar e triviala. Suspectez ca intelegerea nu e chiar triviala, daca unul care chiar cunoaste ceva n-a priceput care-i faza.

Quote

Lucruri din stiinta, inginerie/tehnologie, nu pot fi comunicate pur prin limbaj natural, e nevoie de matematica. Ce descrii tu acolo e sapatorul de santuri si spalatorul de WCuri din programare.

Quote

Treaba inginerului software e sa transpuna ceva in cod. Acel ceva poate fi foarte des un model matematic. Daca nu esti in stare, ai o problema.

Edited by parabellum, 25 April 2019 - 19:45.

cod printat? wtf?

programatorii adevarati nu printeaza codul ever.

il transcriu cu mana. si cu creionul.

Iulius-Foyas, on 25 aprilie 2019 - 20:36, said:

acum serios, oricare ar fi angajatorul tau, daca esti programator bun, fugi de acolo imediat. daca esti mid-level, stai potolit.


iar latimea codului nu se masoara in randuri, ci in coloane. de unde naiba apareti, sunteti oameni reali?

Edited by OriginalCopy, 25 April 2019 - 20:56.

dani.user, on 25 aprilie 2019 - 18:01, said:

Eu am vazut, si nu suficient de rar pe cit as vrea, metode de peste 1000 de linii, unele chiar recursive, cu o tona de parametri, si nu de genu int, double, ci hashseturi de hashmapuri si alte aberatii. Si evident ca nu ai habar ce contin pentru ca nu aveau generice

Motivele principale ar fi ca erau scrise acum 10-15 ani, cind nici dracu nu se gindea la clean code si alte alea, si in plus probabil ca nici prea mult timp nu aveau la dispozitie, pentru ca estimarile se faceau in functie de cit timp faci ceva sa mearga, nu sa fie si mentenabil.

Mi se pare fascinant codul legacy, e ca si cum te-ai intoarce in anii 80 si te-ai trezi singur intr-o statie de autobuz si linga tine ar fi o doamna cu un cojoc din petece de blana, care tine in mina o plasa din-aia comunista cu trei sticle de lapte fara dop in ea. Cit vezi cu ochii nu vezi nimic, decit doua dacii si un Opel Kadett din 73. Vrei sa-ti verifici fakebooku si iti dai seama ca nu ai telefon mobil. Noroc ca in departare se vede stralucirea buteliilor de gaz si poti merge acasa sa te uiti la Netflix. Oh wait...

Cod printat, poate doar daca lucrezi pentru niste dinozauri care mai au asta ca cerinta.
Si asta cu 80 de coloane e tot relicva de pe vremea dinozaurilor / consolelor text. Acum, in era monitoarelor wide, poti lejer macar sa dublezi aceasta limita - daca asta-ti permite folosirea unor nume mai descriptive de variabile (cu identare corespunzatoare, tinand cont ca unele limbaje sunt ceva mai verbose, etc.). Pe monitorul meu, intra 200 de coloane in Visual Studio - cu tot cu Solution Explorer in stanga.

Pentru review, se folosesc - si e muuuult mai comod - soft-uri speciale.

Unii zic ca nu inveti sa injuri cu adevarat pana cand nu conduci in Bucuresti. Eu zic ca pana cand nu lucrezi la un proiect legacy.

corporatiile sa-si faca forum dedicat unde sa-si trimita angajatii pentru suport si trolling

http://www.corporateforum.com/

Vorbeati despre overloading, inainte sa fiti preocupati de numarul de coloane.

dani.user, on 20 aprilie 2019 - 11:27, said:

1. mereu: pentru constructe matematice, acolo unde au sens
2. niciodata: oriunde altundeva, cu exceptia catorva locatii izolate din cod; si nu ma refer la cazuri izolate in locul de implementare, ci in cazuri izolate in locuri de folosire al operatorului overloaded (mult mai restrictiv)

Despre cai: asa e si in python mai modern, operatorul / e overloaded. Acum, exista doua tipuri de proiecte: 1. cele in care caile catre ceva sunt un aspect important din proiect, si 2. proiectele in care caile nu sunt importante: ai cateva cai catre cateva fisiere/directoare, si aia e. Am lucrat cu ambele tipuri de proiecte.

Facts despre aceste tipuri de proiecte (legat de cai):
1. sunt multe cai, si mai mult ca sigur o idee mai buna e sa mapezi fiecare cale printr-un registru / hashmap / dictionar. Astfel poti rescrie orice cale in functie de mediu, de exemplu in functie de production / canary / orice altceva. E o usa de scapare in plus pentru acest aspect dintr-un proiect (dupa cum am zis, caile sunt un aspect important al proiectului, deci si ceva flexibilitate e buna, daca tot e atat de important)
2. sunt cateva cai. le impachetezi intr-o clasa Configuration sau whatever. Nu prea conteaza ce faci in interior, din exterior oricum folosesti getterii. Acesta e acel loc din proiect unde e ok sa folosesti de cateva ori operator overloading (in cazul nostru pentru /)
3. daca ai o cale in minte, cum o poti gasi rapid in cod? Eu personal folosesc grep si imi structurez codul asa incat sa fie usor de gasit (si spatiile/liniile pot da discoverability peste cap)

Singurul caz in care nici nu se discuta folosirea extensiva a operator overloading este in cazul contructelor matematice (daca sunt pure functions), sau alte situatii pe care nu imi dau seama sa le fi intalnit, dar daca ele exista, tot pure functions trebuie sa fie.


Altfel e prea mult magic pentru ceva pe care il folosesti pentru a simplifica lucrurile, nu pentru a le complica. In proiectele in care am putere de decizie, mereu prioritizez discoverability of the code. Da, sunt exceptii, de exemplu un algoritm mai complicat, unde chiar nu se mai poate face nimic. Dar hai sa fim seriosi: la cai de exemplu, ce e important, discoverability sau altceva? ***

Mai e un motiv pentru care evit operator overloading, dar asta tine de modul meu de lucru, IDE-urile se descurca destul de bine: imi place sa dau grep prin cod, si asa sa invat proiectul. Cu operator overloading lucrurile sunt mult mai dificile. IDE-ul tau gaseste corect toate utilizarile unui overloaded + de exemplu? ***

*** unde bat e simplu: de ce folosesti ceva? De exemplu, operator overloading (sintactic sugar) folosesti pentru a face codul mai usor de citit, in cazul formulelor matematice lungi. bird+dog nu e o formula lunga, si nu ma doare mana sa scriu bird.catch(dog). O formula matematica lunga e una cu paranteze si o bucata buna de termeni. Ideea e sa nu uiti care e motivatia principala care te-a indemnat sa folosesti acel ceva, si sa folosesti acel ceva atunci cand se suprapune cu principiile pe care le-ai stabilit.

Pe scurt: sa nu umbli in zig-zag cu deciziile pe care le iei.

Edited by OriginalCopy, 26 April 2019 - 14:10.

OriginalCopy, on 26 aprilie 2019 - 13:48, said:

Aici e o problema majora, si nu de lungime - bird + dog nu are nici o semnificatie evidenta, sau chiar mai putin evidenta. Daca actiunea este 'catch', aceasta nu e exprimata intuitiv prin '+' (trecand peste faptul ca putine pasari isi petrec timpul prinzand caini ).

Abuzurile, desigur, trebuie evitate. Abuzurile intotdeauna apar, indiferent de cat de mult ingradesti libertatea programatorului - abuzurile de goto, abuzurile de OOP (inclusiv mania "hierarchies of objects EVERYWHERE!!!" ), abuzurile de variabile cat mai scurte... Inteleg asadar reticenta.

Pana la urma decizia apartine fiecarei echipe; eu sunt insa de parere ca operator overloading e util si in alte situatii in afara strict de operatiile matematice. A concatena doua cai folosind '/' e imediat evident; nu vad nici o problema in asta.
Daca respecti conditia - ca operatorul sa aiba un sens evident in acel context - din punctul meu de vedere e OK. Programarea este comunicare, nu matematica; rareori are sens sa fim "puristi".

TS030, on 26 aprilie 2019 - 19:08, said:

Ti-am demonstrat clar ca e fals ce zici! Intregi categorii de erori dispar din unele limbaje, pentru simplul fapt ca nu au diverse caracteristici abuzabile! Asta nu inseamna ca vor fi inlocuite de alte "abuzuri" fiindca sunt posibile si alte abuzurI(cum in mod gresit incerci tu sa sugerezi), ci per total programele vor avea mai putine erori si vor fi mai usor de citit in limbajele care iti dicteaza anumite regulii si bine practici, si nu te lasa faci ce vrei tu.

TS030, on 26 aprilie 2019 - 19:08, said:

TS030, on 26 aprilie 2019 - 19:08, said:

Doamne fereste! De unde ai scos bazaconia asta? "/" este un separator de cale ... sa-l folosesti la a le CONCATENA? acel "imediat evident" e extrem de personal!

Uita ASTA este motivul pentru care operator overloading nu trebuie facut disponibil programatorilor(si chiar si creatorii de compilatoare ar trebui sa aiba niste reguli stricte, ca si astia au inceput sa faca limbajele praf cu "lambda" si alte mizerii)! Ceea ce vi se pare voua "evident" e foarte posibil sa nu fie evident pentru ceilalti!

TS030, on 26 aprilie 2019 - 19:08, said:

Ai comis-o deja! Vezi? Ai comis o eroare de comunicare(care tie ti se parea evidenta!). Si ca tine mai sunt muuuuulti! Ah, sau categoria aia care chiar cred ca programarea ar fi matematica! Daca dai de diletanti din aia, o sa ai nevoie de calmante!

TS030, on 26 aprilie 2019 - 19:08, said:

Pentru mine sunt dezavantaje clare în tipul de proiect 1 (căile sunt un aspect important și des utilizat în proiect), din motivele pe care le-am scris anterior. Deasemenea, raspunde la întrebarea "ide-ul tău găsește...".


Dar pentru tipul 2 de proiect, dacă vii cu asta la mine, îți dau clasa Configuration în brațe și îți zic că e a ta și că poți să faci ce vrei în ea, inclusiv operator/(). Dacă asta te face pe tine să vii zâmbind la muncă, atunci acest compromis merită pentru mine.

adamsd, on 27 aprilie 2019 - 07:41, said:

Cu ce-i atat de diferit:

String settingsFilePath = configPath + "/" + settingsFileName

De

Path settingsFilePath = configPath / settingsFileName

?

Edited by dani.user, 27 April 2019 - 10:00.