Exprimarea algoritmilor folosind diferite limbaje

S-a dus adus in discutie ca un anume limaj poate permite o exprimare mai clara a unui algoritm decat altul.

E cineva interesat de exemple practice?

Daca da, veniti cu un exemplu de algoritm, o implementare generalizata a sa intr-un limbaj, iar altii vor oferi, spre comparatie, implementari in alte limbaje ale aceluiasi algoritm.

interesant topicul tau.....speram sa se umple de exemple...... ca vroiam sa vad si eu ce e aia optimizare

0 interes, deci se va inchide.

din ce inteleg eu ar fi cam asa....
decat sa utilizezi 2x2x2x2x2 folosesti 16x2 ca sa scurtezi incarcarea in ram si marimea fisierului....asta fiind un exemplu extrem de simplist

sau spe exemplu acolo unde in loc de doua if-uri pui un while

Chiar deloc. Era vorba de limbaje diferite de programare, ex cum exprimi un algoritm in Java versus in F#

atunci titlul trebuia sa sa fie "optimizarea in unele limbaje fata de altele" pentru ca titlul astfel lasa loc de interpretari....
in cazul asta atunci daca un limbaj nu permite while sa zicem si numai if atunci totul e mai greu
sau spre exemplu daca nu ai ++i .....ar fi mult mai greu

Titlul e corect. Optimizare in contextul algoritmilor inseamna altceva.

bun pai atunci e exact cum am zis .....daca lipseste o sintaxa anume din un limbaj asta limiteaza enorm optimizarea .....

am gasit ceva pe net despre optimizare si cam la asta incerc sa ma refer

exemplu 1
if( Condition ) {
    Case A;
    } else {
    Case B;
    }
exemplu 2
Case B;
    if( Condition ) {
    Undo Case B;
    Case A;
    }

asta in cadrul aceluiasi limbaj de programare insa ma gandesc ca lucrurile sunt exact la fel si in cazul de limbaje diferite

Te gandesti gresit.
Cand exprimi o poezie de dragoste in engleza vs chineza nu inseamna ca un limbaj e mai prost decat altul fiindca foloseste alte elemente. E pur si simplu altceva.

Hai sa luam niste chestii basic ... the building blocks...

o functie care calculeaza media aritmetica a doua numere

C/C++/C#/Java

double average(double x, double y) {
	return (x + y) / 2;
}

OCaml:

let average a b =
	(a +.  /. 2.0;;

Lisp:

(defun average (1st-number 2nd-number)
  (/ (+ 1st-number 2nd-number) 2))

Asadar.. In C-like avem tipul returnat, delimitarea parametrilor de functie prin paranteze, specificarea tipului parametrilor, delimitarea clara a blocului de cod ce tine de functie, claritate maxima unde si ce se returneaza... totul e cat se poate de citibil, logic si clar...

In OCaml nu avem paranteze care sa delimiteze parametrii de cod.. am putea scrie let a b c (a ar fi functia iar b si c parametri) ... avem operatii cu punctulete...

In Lisp avem o amplasare a operatorilor si operanzilor de te doare mintea

Niciunul din astea nu-ti spune exact ce returneaza si ce parte din cod face asta ...

Unii or sa zica, dar "hei, sintaxa si restul le inveti"... extrem de gresit! sau daca vreti, le inveti cam degeaba... ceea ce nu are logica naturala pentru om duce inevitabil la mai multe greseli decat ceea ce are logica si e mai clar si mai apropiat de limbajul uman...

exemplele astea sunt simplute, dar in exemple mai complicate se poate face cod greu de citit si se poate gresi usor... nu mai zic, adeptii limbajelor functionale au o boala extrema de a scrie cod cat mai criptic, iar recomandari si bune practici precum cele din Java de a-ti denumi varibilele, functiile/metodele in mod cat mai logic, cat mai citet sunt chestii subtirele, superficiale, cvasi-inexistente in limbajele functionale...

Cica dupa mintea unora asta ar fi un exemplu "crystal clear" de quicksort in Haskell:

quicksort [] = []
quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater)
	where
		lesser = filter (< p) xs
		greater = filter (>= p) xs

Ce dracu e "crystal clear"? Ca nu e nimic...

Actually, asta e motivul pentru care limbajele functionale nu prind in industrie pe scara larga: cod foarte criptic, usor de facut greseli, debugging greu sau imposibil de facut, mentenanta de cosmar... si nu, balaria e cu "poti scrie si cod bun si cod prost in orice limbaj" nu tine in practica... pur si simplu asta e realitatea verificabila: codul functional in vasta majoritatea a cazurilor e foarte, foarte criptic, pe cand codul in sa zicem java e foarte clar(s-au introdus si aici niste ineptii... ghici de cine? de idiotii care au impins introducerea unor chestii asa zis functionale)

din punctul meu de vedere iti dau dreptate ...in exemplul de mai sus lisp mi se pare cel mai complicat....

Ar putea fi transpuse exemplele din aria C/C++ Incepatori in alte limbaje in ideea lipsei de inspiratie?

Da. Totul e sa se puna accent pe exprimarea cat mai buna a ideei algoritmului in cod. Multe din exemplele de acolo nu tin cont de asa ceva (exemplul tipic: luate la rand toate literele alfabetului pentru nume de variabile)

Nu inteleg ce e asa greu la Lisp. +  , -  ,  * ,  /  ....sunt functii si nu simpli operatori ca in limbajele imperative.  Ex: (scade 7 2) => 5. E o functie 'scade' care ia doua argumente: 7 si 2 , si produce un rezultat 5 . Daca as scrie : (imparte (aduna 5 6) 2) ai intelege mai usor? Cam asta face functia ta average.   Daca as avea o functie care face sa se aprinda becul ar fi :
   (aprinde bec), unde functia este aprinde si bec este argumentul . Sau (aprinde bec1 bec2 de-pe-hol). Iar in Haskell ai o  operatie monoidala de compunere a doua liste si o implementare quicksort simpla. [1,2,3,] ++ [6,7,8] = [1,2,3,6,7,8].  '++' e de fapt tot o functie care  "aduna"  doua liste,  dar care poate fi scrisa ca si operator infix (desi nu e).Ai
   (quicksort    nr-mai-mici-decat-p  )   ++   [p] ++   (quicksort nr-mai-mari-decat-p  ), si un base case pentru care (quicksort lista-goala) = lista-goala

Edited by Ltschmer, 30 December 2017 - 21:56.