Disputa: Static vs Dynamic type, linie de comanda versus GUI
- Manu
- General de divizie
- Mesaje: 4120
- Membru din: 02 Feb 2007, 01:15
- Localitate: Cluj-Napoca
- Contact:
Ca sa vezi ce discutii isca o versiune noua de JAWS... Poate unii vor crede ca multe de aici sunt noutati pe care nu le inteleg si astfel vor trece pe NVDA.
Despre preferinta pentru strongly sau dynamic typed am mai vorbit noi, pana la urma la nivelul actual al unor limbaje de programare poate ca nici nu mai conteaza atat de mult care dintre cele doua variante ar fi mai buna, atata vreme cat codul e astfel scris incat sa nu apara bugurile.
Sincer si eu sunt pentru static type, asta pentru ca am inceput cu JAWS Scripting, abia mai tarziu am scris mici scripturi in PHP sau AutoIt, doar dupa ce am inteles mai bine ce inseamna a programa facand cate ceva in BGT sau C++.
Dupa ce le-am vazut pe acestea cateva, am ramas cu ideea ca nu sunt sigur pe mine in Dynamic:
la PHP am omis sa pun doua egaluri pentru verificarea unei conditii si se facea acolo asignare de valoare, conditia fiind evaluata ca adevarata. In Autoit verificam doua variabile carora le-am atribuit valori numerice, nu am utilizat nicaieri ghilimea sau apostrof, dar la comparare se apuca sa spuna ca 10 e mai mic decat 9, asta pentru ca le vedea cumva alfabetic.
Toate acestea erau desigur din cauza lipsei de experienta in lucrul cu acel limbaj, ar fi trebuit sa folosesc functii de parsare la int etc, functii care pana la urma faceau ca munca sa fie in plus la fel ca in cazul initierii variabilelor cu un tip anume. De asemenea poate ca un motiv ar fi si limbajele amintite, in sine, care au minusurile pe care le au.
Cred totusi ca, in lipsa practicii indelungate cu un limbaj Dynamic, erorile vor fi mult mai probabile decat in cazul unui limbaj static, asta pentru ca nu stii la ce sa te astepti, nu stii ce s-o mai fi intampland cu valoarea unei variabile la runtime, daca nu cumva la runtime evaluarile vor da peste cap putin lucrurile.
Avantajul este la Static ca se verifica la vremea compilarii daca totusi nu sunt inadvertente, scade mult probabilitatea erorilor, asta o spun din ce am simtit eu de-a lungul timpului relativ scurt decand "programez", nu din manuale si ce stiu ce carti, pot da exemple.
Dar e foarte clar ca daca programezi in Perl 11 ani nu mai pot aparea astfel de inadvertente.
De asemenea sunt convins ca nu poate fi comparat Perl cu PHP, am retinut clar din multele discutii de pe acest forum, reiese de asemenea din Portofoliu, urmarind exact la ce proiecte a fost folosit unul sau altul.
Cred de asemenea ca firmele mari care creeaza si intretin diverse limbaje, nu vor incuraja prea curand dynamic type, probabil pentru ca se va considera pierderea timpului la interpretor, care trebui sa faca mai multe verificari trebuind sa isi bata mai mult capul cu tipul valorilor. In ceea ce priveste timpul probabil ca utilizarea unor operatori diferiti pentru operatii cu stringuri si numere, face ca verificarile sa fie mai putine, timpul de rulare sa fie scurtat.
Mai zic ei ca si memoria ocupata de o variabila nu poate fi bine controlata, nu poti crea o variabila care sa fii sigur ca ocupa doar un byte, daca tot e nevoie de ea doar pentru true sau false. Aici se poate spune repede ca memoriile sunt atat de mari in prezent incat nu conteaza deloc asta.
Deci, discutiile pot merge la nesfarsit, e in functie de cum ne obisnuim, sub influenta cui am ajuns mai pe la inceput etc.
In orice caz, destul de putin probabil, fie si din cauza profesorilor de matematica, sa ajunga cineva la inceput sa mearga pe Dynamic type, decat daca nu a inceput cu PHP cand timpul liber a devenit mai lung dupa terminarea scolii si s-a dorit crearea unui site cat de cat mai complex.
IonPop, sunt curios cum ai ajuns sa te stabilesti pe limbajul Perl? Trebuie sa fi fost si tu influentat, nu cred ca ai luat limbajele la rand si te-ai oprit la acesta spunand: gata, imi satisface absolut toate nevoile.
Despre preferinta pentru strongly sau dynamic typed am mai vorbit noi, pana la urma la nivelul actual al unor limbaje de programare poate ca nici nu mai conteaza atat de mult care dintre cele doua variante ar fi mai buna, atata vreme cat codul e astfel scris incat sa nu apara bugurile.
Sincer si eu sunt pentru static type, asta pentru ca am inceput cu JAWS Scripting, abia mai tarziu am scris mici scripturi in PHP sau AutoIt, doar dupa ce am inteles mai bine ce inseamna a programa facand cate ceva in BGT sau C++.
Dupa ce le-am vazut pe acestea cateva, am ramas cu ideea ca nu sunt sigur pe mine in Dynamic:
la PHP am omis sa pun doua egaluri pentru verificarea unei conditii si se facea acolo asignare de valoare, conditia fiind evaluata ca adevarata. In Autoit verificam doua variabile carora le-am atribuit valori numerice, nu am utilizat nicaieri ghilimea sau apostrof, dar la comparare se apuca sa spuna ca 10 e mai mic decat 9, asta pentru ca le vedea cumva alfabetic.
Toate acestea erau desigur din cauza lipsei de experienta in lucrul cu acel limbaj, ar fi trebuit sa folosesc functii de parsare la int etc, functii care pana la urma faceau ca munca sa fie in plus la fel ca in cazul initierii variabilelor cu un tip anume. De asemenea poate ca un motiv ar fi si limbajele amintite, in sine, care au minusurile pe care le au.
Cred totusi ca, in lipsa practicii indelungate cu un limbaj Dynamic, erorile vor fi mult mai probabile decat in cazul unui limbaj static, asta pentru ca nu stii la ce sa te astepti, nu stii ce s-o mai fi intampland cu valoarea unei variabile la runtime, daca nu cumva la runtime evaluarile vor da peste cap putin lucrurile.
Avantajul este la Static ca se verifica la vremea compilarii daca totusi nu sunt inadvertente, scade mult probabilitatea erorilor, asta o spun din ce am simtit eu de-a lungul timpului relativ scurt decand "programez", nu din manuale si ce stiu ce carti, pot da exemple.
Dar e foarte clar ca daca programezi in Perl 11 ani nu mai pot aparea astfel de inadvertente.
De asemenea sunt convins ca nu poate fi comparat Perl cu PHP, am retinut clar din multele discutii de pe acest forum, reiese de asemenea din Portofoliu, urmarind exact la ce proiecte a fost folosit unul sau altul.
Cred de asemenea ca firmele mari care creeaza si intretin diverse limbaje, nu vor incuraja prea curand dynamic type, probabil pentru ca se va considera pierderea timpului la interpretor, care trebui sa faca mai multe verificari trebuind sa isi bata mai mult capul cu tipul valorilor. In ceea ce priveste timpul probabil ca utilizarea unor operatori diferiti pentru operatii cu stringuri si numere, face ca verificarile sa fie mai putine, timpul de rulare sa fie scurtat.
Mai zic ei ca si memoria ocupata de o variabila nu poate fi bine controlata, nu poti crea o variabila care sa fii sigur ca ocupa doar un byte, daca tot e nevoie de ea doar pentru true sau false. Aici se poate spune repede ca memoriile sunt atat de mari in prezent incat nu conteaza deloc asta.
Deci, discutiile pot merge la nesfarsit, e in functie de cum ne obisnuim, sub influenta cui am ajuns mai pe la inceput etc.
In orice caz, destul de putin probabil, fie si din cauza profesorilor de matematica, sa ajunga cineva la inceput sa mearga pe Dynamic type, decat daca nu a inceput cu PHP cand timpul liber a devenit mai lung dupa terminarea scolii si s-a dorit crearea unui site cat de cat mai complex.
IonPop, sunt curios cum ai ajuns sa te stabilesti pe limbajul Perl? Trebuie sa fi fost si tu influentat, nu cred ca ai luat limbajele la rand si te-ai oprit la acesta spunand: gata, imi satisface absolut toate nevoile.
Errare humanum est, sed perseverare diabolicum...
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
"Despre preferinta pentru strongly sau dynamic typed am mai vorbit noi, pana la urma la nivelul actual al unor limbaje de programare poate ca nici nu mai conteaza atat de mult care dintre cele doua variante ar fi mai buna, atata vreme cat codul e astfel scris incat sa nu apara bugurile.".
Poti sa scri la fel de usor un program in care sa apara erori, indiferent in ce limbaj este scris si indiferent daca acel limbaj foloseste o metoda bazata pe obiecte sau una functionala sau daca este dinamic sau static typed.
"Sincer si eu sunt pentru static type, asta pentru ca am inceput cu JAWS Scripting, abia mai tarziu am scris mici scripturi in PHP sau AutoIt, doar dupa ce am inteles mai bine ce inseamna a programa facand cate ceva in BGT sau C++.".
Dupa cum am mai spus, asta conteaza cel mai mult. Conteaza in ce limbaj ai cea mai multa experienta, si indiferent ce ar spune oricine, tot in acel limbaj vei programa mai usor si cu mai putine erori, indiferent de care tip este.
E ca si cu muzica, daca auzi o melodie cantata prima data de cineva iar apoi peste ani o auzi cantata de altcineva, parca iti place tot mai mult prima varianta, chiar daca nu este cea originala.
Daca ai auzit prima data Knockin' on heaven's door cantata de Guns 'n Roses exista mici sanse sa iti placa mai mult varianta originala cantata de Bob Dylan, chiar daca ea este cea originala.
"Dupa ce le-am vazut pe acestea cateva, am ramas cu ideea ca nu sunt sigur pe mine in Dynamic:
la PHP am omis sa pun doua egaluri pentru verificarea unei conditii si se facea acolo asignare de valoare, conditia fiind evaluata ca adevarata. In Autoit verificam doua variabile carora le-am atribuit valori numerice, nu am utilizat nicaieri ghilimea sau apostrof, dar la comparare se apuca sa spuna ca 10 e mai mic decat 9, asta pentru ca le vedea cumva alfabetic.
Toate acestea erau desigur din cauza lipsei de experienta in lucrul cu acel limbaj, ar fi trebuit sa folosesc functii de parsare la int etc, functii care pana la urma faceau ca munca sa fie in plus la fel ca in cazul initierii variabilelor cu un tip anume.".
Nu sunt utilizator nici de PHP si nici de Autoit, asa ca nu pot comenta despre ele, insa aceste probleme se datoreaza si obisnuintei de a lucra cu alte limbaje care nu ofera anumite facilitati. Iar posibilitatea de a asigna valori in locuri unde in alte locuri este posibil doar sa verifici egalitati poate fi un avantaj, nu un dezavantaj, insa trebuie sa folosesti operatorul de care ai nevoie.
Dar depinde de ce nevoi ai. Daca nu ai nevoie sa faci lucruri prea complicate cu foarte putin cod, ci preferi sa scri o gramada de linii de cod dar fiecare sa fie clar ce si cum face, este o preferinta normala ca orice alte preferinte, si atunci sigur nu vei prefera limbaje care fac lucruri magice, adica cu putin cod, fara a specifica prea multe, dar chiar imposibil de inteles de incepatori care nu au studiat prea multa documentatie.
Daca ai studiat si sti ce reprezinta acele mici bucati de cod, este mai simplu si mai rapid de lucrat cu astfel de limbaje.
Asa ca nu limbajele in sine reprezinta o diferenta, fiindca ele doar ofera anumite facilitati (si dezavantaje) pe care noi le favorizam in functie de preferintele noastre.
"De asemenea poate ca un motiv ar fi si limbajele amintite, in sine, care au minusurile pe care le au.".
Minusuri au destule toate limbajele.
Unele pot fi rulate doar pe un anumit sistem de operare, sau consuma multe resurse, sau trebuie sa scri in ele de zece ori mai mult cod decat in altele, sau trebuie compilate fiind ceva mai dificil sa le folosesti in programarea pentru web, sau pentru a programa in ele mai usor ai neaparata nevoie de un IDE care costa, sau in anumite domenii pur si simplu ofera mai putine facilitati decat altele, cum ar fi de exemplu diverse biblioteci de care ai nevoie, sau facilitatile oferite de motorul de regular expressions, sau parsarea paginilor web etc.
Dar toate astea depind de ce anume vrei sa faci cu ele. Daca in principal creezi aplicatii cu interfata web, atunci sigur iti place mai mult PHP sau Perl/Python/Ruby decat Java sau C sau C++, chiar daca in toate limbajele amintite se pot crea pagini web, dar daca ai in primul rand nevoie sa creezi programe cu interfata grafica, si in primul rand pentru Windows, atunci este clar ca C#/Java/C++ + MFC sunt optiuni mai bune din punctul de vedere al facilitatilor oferite pentru crearea interfetei grafice decat PHP/Perl/Python/Ruby.
"Cred totusi ca, in lipsa practicii indelungate cu un limbaj Dynamic, erorile vor fi mult mai probabile decat in cazul unui limbaj static, asta pentru ca nu stii la ce sa te astepti, nu stii ce s-o mai fi intampland cu valoarea unei variabile la runtime, daca nu cumva la runtime evaluarile vor da peste cap putin lucrurile.".
La runtime o variabila nu are cum sa se modifice decat daca intervine un element extern diferit, introdus de utilizator sau o variabila de mediu, sau ceva preluat dintr-un fisier etc.
Iar cand preiei absolut orice fel de informatii din mediul extern, intotdeauna le verifici indiferent de limbajul in care programezi. Daca nu le verifici, pot aparea erori in orice limbaj.
Daca intr-un program se tot aduna si scad si inmultesc variabile de tip int, nu se poate intampla ceva care sa le faca sa se transforme singure in stringuri.
"Avantajul este la Static ca se verifica la vremea compilarii daca totusi nu sunt inadvertente, scade mult probabilitatea erorilor, asta o spun din ce am simtit eu de-a lungul timpului relativ scurt decand "programez", nu din manuale si ce stiu ce carti, pot da exemple.
Dar e foarte clar ca daca programezi in Perl 11 ani nu mai pot aparea astfel de inadvertente.".
In momentul compilarii pot sa nu apara probleme, dar un utilizator poate introduce o valoare incorecta care sa dea peste cap programul in runtime daca nu se face o verificare, si aceasta problema poate aparea in toate limbajele.
Si dupa cum am mai spus, daca vrei, in Perl poti sa folosesti modulul Moose si sa iti definesti daca vrei si tipurile de variabile, inca intr-un mod extrem de strict. De exemplu poti sa spui ca o variabila de tip int sa aiba doar o valoare intre 1 si 18, in caz contrar sa fie considerata invalida, si asta cu un cod simplu, nu o verificare manuala cu if si else.
"Cred de asemenea ca firmele mari care creeaza si intretin diverse limbaje, nu vor incuraja prea curand dynamic type, probabil pentru ca se va considera pierderea timpului la interpretor, care trebui sa faca mai multe verificari trebuind sa isi bata mai mult capul cu tipul valorilor. In ceea ce priveste timpul probabil ca utilizarea unor operatori diferiti pentru operatii cu stringuri si numere, face ca verificarile sa fie mai putine, timpul de rulare sa fie scurtat.".
Robotul Google este scris in Python si multe pagini Google sunt create in Python. Am vazut pe jobs.perl.org si oferte de angajare la Google pentru programatori in Perl, cei de la booking.com angajeaza gramezi de programatori in Perl si sunt dispusi si sa rezolve cu vizele in Amsterdam, cu mutarea daca este nevoie, si Microsoft a finantat dezvoltarea anumitor bucati din Perl pentru Windows, ba am vazut anunt ca angajeaza programatori in Perl si firma Apple, asa ca nu prea este adevarat ca firmele mari nu folosesc limbaje dinamice, dupa cum am aratat si in mesajul anterior.
Ba Guido van Rossum, cel care a creat limbajul Python chiar a fost angajat de Google, asa ca Google chiar sustine dezvoltarea unui limbaj dinamic.
Iar Ruby a fost folosit de firma 37 Signals pentru a crea framework-ul Ruby on Rails pe care l-au folosit apoi pentru a crea cel mai important site de project management, basecamp.com.
Putem lauda si PHP care este folosit de Facebook si Yahoo, si cred ca sunt firme suficient de mari pentru a arata ca cunoscatorii nu se tem de povesti despre limbaje, ci pur si simplu aleg ce este mai bine pentru ele.
Intr-o aplicatie web, dar ma rog, una moderna, nu care foloseste scripturi CGI, programele ruleaza o singura data cand porneste serverul web, si gata, apoi stau gata compilate in memorie o lunga durata de timp si doar servesc cererile.
Ma rog, php nu functioneaza chiar asa, dar alte limbaje mai ca lumea da.
Asa ca chiar nu conteaza cu ce viteza se compileaza toate programele necesare fiindca compilarea si rularea lor se face doar o singura data, iar apoi functioneaza foarte rapid.
Oricum, nu prea vei vedea in curand pagini web create in C sau C++ chiar daca si cu aceste limbaje se pot crea pagini web si chiar daca C este in mod evident mult mai rapid decat alte limbaje. Si asta fiindca chiar daca ruleaza rapid, se pierde oricum cel mai mult timp cu altele decat generarea codului html, cum ar fi munca bazelor de date implicate, transferul datelor de la server la browser, iar munca necesara pentru a crea un site in C este de zeci de ori mai greoaie decat in alte limbaje ca PHP/Perl/Python/Ruby...
Asa ca viteza este buna acolo unde este nevoie de ea, doar ca nu oriunde are cine stie ce influenta.
"Mai zic ei ca si memoria ocupata de o variabila nu poate fi bine controlata, nu poti crea o variabila care sa fii sigur ca ocupa doar un byte, daca tot e nevoie de ea doar pentru true sau false. Aici se poate spune repede ca memoriile sunt atat de mari in prezent incat nu conteaza deloc asta.".
Memoria conteaza foarte mult, insa doar in anumite circumstante.
Dupa cum am spus, de exemplu este important cat de multa memorie se consuma cand vrei sa folosesti un server vps, fiindca platesti din greu pentru mai multa memorie, dar in acele cazuri tot nu este nevoie de a restrictiona atat de mult consumul de resurse ca in cazul crearii unui driver de exemplu, care vrei sa functioneze super rapid si cu consum minim de resurse, ca sa poata functiona ok pe orice computer. Acolo da, chiar daca trebuie sa muncesti de zeci de ori mai mult, trebuie sa folosesti C, si cu siguranta ca Perl sau alte limbaje dinamice nu va fi bun, si nici C# sau Java.
"Deci, discutiile pot merge la nesfarsit, e in functie de cum ne obisnuim, sub influenta cui am ajuns mai pe la inceput etc.".
Exact, si mai depinde de ce anume vrem sa facem. Stiu totusi ca ceea ce vrem sa facem depinde intr-o oarecare masura si de ceea ce stim sa facem.
"In orice caz, destul de putin probabil, fie si din cauza profesorilor de matematica, sa ajunga cineva la inceput sa mearga pe Dynamic type, decat daca nu a inceput cu PHP cand timpul liber a devenit mai lung dupa terminarea scolii si s-a dorit crearea unui site cat de cat mai complex.".
Nici eu nu am inceput sa programez intr-un limbaj dinamic. La inceput faceam un soi de super mini programele in .bat, dar fiindca vroiam sa am acces la internet si eram nevoit sa sparg un cont al colegilor de la facultatea de matematica-informatica, fiindca doar ei aveau cont cu acces la internet, am invatat Pascal. Si cu el am reusit sa sparg parolele la ceva mai mult de 50 de conturi sub sistemul de operare Novell Netware, cu speranta ca pentru unele conturi vor fi aceleasi parole si pentru conturile sub Sun OS, adica sub Unix, fiindca doar cu acele conturi se putea accesa internetul, si intr-adevar am reusit accesul prin intermediul a 3 conturi asa ca a fost suficient.
Mai tarziu am invatat putin Visual Basic, putin Javascript, putin VBA, si cu ele am creat si vandut cateva programe pentru cateva firme.
"IonPop, sunt curios cum ai ajuns sa te stabilesti pe limbajul Perl? Trebuie sa fi fost si tu influentat, nu cred ca ai luat limbajele la rand si te-ai oprit la acesta spunand: gata, imi satisface absolut toate nevoile.".
Povestea:
Perl am inceput sa invat doar dupa ce mi-am pierdut vederea.
L-am intrebat pe Mircea Vutcovici care ar fi cel mai potrivit limbaj de programare pentru a crea pagini web.
El mi-a spus ca Perl sau PHP. De PHP auzisem inainte de a imi pierde vederea fiindca organiza o firma cursuri de programare in "Personal Home Page" fiindca aceasta este denumirea de pe atunci a PHP-ului.
Iar despre Perl mai auzisem de la o colega care lucra pe Marketing la Dynamic Network Technologies, o firma de software si furnizor de internet din cluj care apartinea Fundatiei Soros, si care fusese infiintata de cel care conduce acum firma de software Recognos. Ei foloseau Perl pentru diverse programe pe care le creau pentru ei si pentru diversi clienti din SUA.
Asa ca am descrcat kiturile de PHP si Perl, am incercat prima data sa instalezi PHP-ul, dar nu stiu ce drac avea kitul ca nu am reusit sa il instalez, asa ca am instalat Perl care a functionat foarte bine, apoi am cautat manuale pe web si am gasit zeci de carti in format .chm, m-am subscris la diverse grupuri de discutii, acesta fiind un element foarte important, fiindca spre deosebire de alte limbaje dinamice ca Python sau Ruby sau PHP, Perl are o comunitate mult mai bine inchegata cu multe liste de discutii pe multe teme, ba chiar un soi de cluburi denumite "Perl Mongers". Perl Mongers s-a infiintat de vre-un an si ceva si in Cluj si mai exista si in alte orase universitare din Romania, iar in Cluj am participat la vre-o 4 intalniri pana acum, la care au venit speakeri locali si din strainatate si au prezentat diverse chestii, module etc.
Cam asta a fost totusi doar la inceput, dar apoi am incercat sa caut ce ma interesa pe mine, si anume care este cel mai bun limbaj pentru procesat text, si am fost placut surprins sa aflu ca este exact Perl, si nu alte limbaje promovate mult mai mult de diverse firme.
M-a interesat procesarea de text fiindca acesta este cel mai natural mod de a schimba informatii complexe, si este in mod evident cel mai accesibil pentru orbi si intr-adevar mi-a fost foarte util de multe ori ca am putut sa lucrez in Perl.
Am citit si de curand despre suportul Unicode in Perl, spunandu-se ca el este bun doar in limbajele Java si Perl. Nu stiu cum este in C#, fiindca el este foarte apropiat de Java, dar spun doar ce am citit.
Si asta fiindca in Python 2.7 suportul este nasol de tot (daca cumva exista suport in aceasta versiune), iar in Python 3 care nu este compatibil cu Python 2.7 si in care nu functioneaza multe module Python se ofera suport Unicode ceva mai bun, dar nu excelent, si se dadeau exemple de astfel de probleme, legate de exemplu de facilitatile de procesare a codului Unicode in regular expressions.
Or asta pe mine ma intereseaza, fiindca cum nu sunt american si multumit sa pot citi doar in engleza, imi place sa pot procesa ca lumea caracterele Unicode. Am spus insa ca doar am citit, fiindca stiu ca suportul Unicode in Perl este bun, dar personal nu am testat in alte limbaje ca sa pot face o comparatie.
In legatura cu regular expressions, este evident ca este cel mai bun motor de regular expressions din toate limbajele, iar asta este de asemenea ceva foarte important pentru procesarea de text.
Multe alte limbaje folosesc Perl regular expressions, dar de fapt folosesc doar o biblioteca preg care nu ofera toate facilitatile oferite de regular expressions in Perl, si dupa cate am vazut in ultimele versiuni de Perl, s-au mai adaugat noi si noi facilitati in motorul de regular expressions.
Ma rog, dupa cativa ani am zis ca poate nu ar fi rau sa invat si PHP, ca tot nu e cine stie ce complicat. Asa ca am instalat PHP si am creat un mic site de test, numai ca imi tot dadea o eroare desi foloseam un cod foarte simplu. Chiar m-am subscris la o lista de discutii de PHP ca sa intreb care este problema, si in final mi-a spus un utilizator ca problema mea se datoreaza unui bug cunoscut in PHP, si ca imi recomanda sa descarc versiunea urmatoare care era pe atunci beta, si ca in ea s-a rezolvat acea problema.
Atunci mi-a disparut brusc increderea in PHP si l-am abandonat.
Dupa alti cativa ani, dupa ce stiam mult mai bine Perl, am cautat informatii de nivel mai inalt in PHP, nu doar despre simpla programare low level, ci am cautat ce module exista pentru procesarea de formulare, ce sisteme de templating, ce framework-uri etc.
Module pentru procesat formulare nu am gasit deloc, dar am gasit cateva sisteme de procesat template-uri, si dintre ele pot spune ca Smarty este OK. Am gasit si mai multe framework-uri pentru creat aplicatii web, insa cu foarte foarte multe limitari in comparatie cu ceea ce oferea framework-ul Catalyst in Perl. Mai exact, unele dintre ele te obligau sa folosesti doar sistemul lor propriu de template si nu cel pe care vroiai tu, altele permiteau doar un anumit sistem de template extern, deci tot nu puteai alege, altele ofereau ORM-ul lor propriu (object relational manager), si multe astfel de limitari, dar cred ca cel mai mult mi-a displacut ca in majoritatea lor trebuia sa creezi o asociere statica intre directorul virtual, adica adresa web accesata si functia care era executata, asa ca daca schimbai ceva in program, in numele functiei de exemplu, trebuia sa modifici si asocierile in fisierul cu acele asocieri. In final am gasit ca cel mai bun framework pentru PHP este CodeIgniter fiindca avea si el limitarile lui, dar nu chiar atat de multe.
Numai ca totusi nu am gasit chiar absolut nici un avantaj in a folosi PHP chiar cu un web framework in comparatie cu Perl si Catalyst, asa ca nu mi-am mai batut capul cu PHP.
Am mai testat si alte limbaje ca Java, C#, Python, chiar putin si Ruby, si ele sunt toate OK, insa nu prea am avut nevoie de ele, fiindca pe partea de web Perl este bun, asa ca nu am avut nevoie de Python sau Ruby, iar pentru aplicatii cu interfata grafica pentru Windows C# este OK chiar daca nu am gasit interfetele create cu el la fel de responsive ca cele create cu widgeturi native win32, insa nu mi-a placut ca trebuie sa scri foarte mult cod in comparatie cu Perl, si dupa ce te obisnuiesti sa faci anumite lucruri super rapid, si mai poti folosi si diverse module facute de altii, si testate de multi altii, este un pic cam dezamagitor sa vezi ca trebuie sa scri o multime de linii de cod doar ca sa faci acelasi lucru...
Java nu prea mi-a placut fiindca desi poti crea pentru programele in Java fisiere executabile care sa ruleze sub Windows, totusi Java trebuie sa fie instalat, consuma cam multe resurse, nici de rulat programele nu rulau prea rapid, iar cand creezi programe cu o interfata grafica pe care deseori trebuie sa le pornesti si opresti... asta conteaza.
De multe ori insa de atunci Java a fost optimizat si ruleaza mai bine, si ma rog, poate conteaza si faptul ca acum am un computer mai rapid...
Asa ca pot spune ca folosesc Perl dintr-o intamplare. Poate ca daca ar fi functionat acel kit de PHP as fi reusit sa il instalez, si cum limbajul este simplu probabil ca mi-ar fi placut si as fi continuat cu el poate chiar fara sa mai incerc si Perl.
Asa ca vezi ca uneori e un mare avantaj cand nu reusesti sa instalezi un program .
Poti sa scri la fel de usor un program in care sa apara erori, indiferent in ce limbaj este scris si indiferent daca acel limbaj foloseste o metoda bazata pe obiecte sau una functionala sau daca este dinamic sau static typed.
"Sincer si eu sunt pentru static type, asta pentru ca am inceput cu JAWS Scripting, abia mai tarziu am scris mici scripturi in PHP sau AutoIt, doar dupa ce am inteles mai bine ce inseamna a programa facand cate ceva in BGT sau C++.".
Dupa cum am mai spus, asta conteaza cel mai mult. Conteaza in ce limbaj ai cea mai multa experienta, si indiferent ce ar spune oricine, tot in acel limbaj vei programa mai usor si cu mai putine erori, indiferent de care tip este.
E ca si cu muzica, daca auzi o melodie cantata prima data de cineva iar apoi peste ani o auzi cantata de altcineva, parca iti place tot mai mult prima varianta, chiar daca nu este cea originala.
Daca ai auzit prima data Knockin' on heaven's door cantata de Guns 'n Roses exista mici sanse sa iti placa mai mult varianta originala cantata de Bob Dylan, chiar daca ea este cea originala.
"Dupa ce le-am vazut pe acestea cateva, am ramas cu ideea ca nu sunt sigur pe mine in Dynamic:
la PHP am omis sa pun doua egaluri pentru verificarea unei conditii si se facea acolo asignare de valoare, conditia fiind evaluata ca adevarata. In Autoit verificam doua variabile carora le-am atribuit valori numerice, nu am utilizat nicaieri ghilimea sau apostrof, dar la comparare se apuca sa spuna ca 10 e mai mic decat 9, asta pentru ca le vedea cumva alfabetic.
Toate acestea erau desigur din cauza lipsei de experienta in lucrul cu acel limbaj, ar fi trebuit sa folosesc functii de parsare la int etc, functii care pana la urma faceau ca munca sa fie in plus la fel ca in cazul initierii variabilelor cu un tip anume.".
Nu sunt utilizator nici de PHP si nici de Autoit, asa ca nu pot comenta despre ele, insa aceste probleme se datoreaza si obisnuintei de a lucra cu alte limbaje care nu ofera anumite facilitati. Iar posibilitatea de a asigna valori in locuri unde in alte locuri este posibil doar sa verifici egalitati poate fi un avantaj, nu un dezavantaj, insa trebuie sa folosesti operatorul de care ai nevoie.
Dar depinde de ce nevoi ai. Daca nu ai nevoie sa faci lucruri prea complicate cu foarte putin cod, ci preferi sa scri o gramada de linii de cod dar fiecare sa fie clar ce si cum face, este o preferinta normala ca orice alte preferinte, si atunci sigur nu vei prefera limbaje care fac lucruri magice, adica cu putin cod, fara a specifica prea multe, dar chiar imposibil de inteles de incepatori care nu au studiat prea multa documentatie.
Daca ai studiat si sti ce reprezinta acele mici bucati de cod, este mai simplu si mai rapid de lucrat cu astfel de limbaje.
Asa ca nu limbajele in sine reprezinta o diferenta, fiindca ele doar ofera anumite facilitati (si dezavantaje) pe care noi le favorizam in functie de preferintele noastre.
"De asemenea poate ca un motiv ar fi si limbajele amintite, in sine, care au minusurile pe care le au.".
Minusuri au destule toate limbajele.
Unele pot fi rulate doar pe un anumit sistem de operare, sau consuma multe resurse, sau trebuie sa scri in ele de zece ori mai mult cod decat in altele, sau trebuie compilate fiind ceva mai dificil sa le folosesti in programarea pentru web, sau pentru a programa in ele mai usor ai neaparata nevoie de un IDE care costa, sau in anumite domenii pur si simplu ofera mai putine facilitati decat altele, cum ar fi de exemplu diverse biblioteci de care ai nevoie, sau facilitatile oferite de motorul de regular expressions, sau parsarea paginilor web etc.
Dar toate astea depind de ce anume vrei sa faci cu ele. Daca in principal creezi aplicatii cu interfata web, atunci sigur iti place mai mult PHP sau Perl/Python/Ruby decat Java sau C sau C++, chiar daca in toate limbajele amintite se pot crea pagini web, dar daca ai in primul rand nevoie sa creezi programe cu interfata grafica, si in primul rand pentru Windows, atunci este clar ca C#/Java/C++ + MFC sunt optiuni mai bune din punctul de vedere al facilitatilor oferite pentru crearea interfetei grafice decat PHP/Perl/Python/Ruby.
"Cred totusi ca, in lipsa practicii indelungate cu un limbaj Dynamic, erorile vor fi mult mai probabile decat in cazul unui limbaj static, asta pentru ca nu stii la ce sa te astepti, nu stii ce s-o mai fi intampland cu valoarea unei variabile la runtime, daca nu cumva la runtime evaluarile vor da peste cap putin lucrurile.".
La runtime o variabila nu are cum sa se modifice decat daca intervine un element extern diferit, introdus de utilizator sau o variabila de mediu, sau ceva preluat dintr-un fisier etc.
Iar cand preiei absolut orice fel de informatii din mediul extern, intotdeauna le verifici indiferent de limbajul in care programezi. Daca nu le verifici, pot aparea erori in orice limbaj.
Daca intr-un program se tot aduna si scad si inmultesc variabile de tip int, nu se poate intampla ceva care sa le faca sa se transforme singure in stringuri.
"Avantajul este la Static ca se verifica la vremea compilarii daca totusi nu sunt inadvertente, scade mult probabilitatea erorilor, asta o spun din ce am simtit eu de-a lungul timpului relativ scurt decand "programez", nu din manuale si ce stiu ce carti, pot da exemple.
Dar e foarte clar ca daca programezi in Perl 11 ani nu mai pot aparea astfel de inadvertente.".
In momentul compilarii pot sa nu apara probleme, dar un utilizator poate introduce o valoare incorecta care sa dea peste cap programul in runtime daca nu se face o verificare, si aceasta problema poate aparea in toate limbajele.
Si dupa cum am mai spus, daca vrei, in Perl poti sa folosesti modulul Moose si sa iti definesti daca vrei si tipurile de variabile, inca intr-un mod extrem de strict. De exemplu poti sa spui ca o variabila de tip int sa aiba doar o valoare intre 1 si 18, in caz contrar sa fie considerata invalida, si asta cu un cod simplu, nu o verificare manuala cu if si else.
"Cred de asemenea ca firmele mari care creeaza si intretin diverse limbaje, nu vor incuraja prea curand dynamic type, probabil pentru ca se va considera pierderea timpului la interpretor, care trebui sa faca mai multe verificari trebuind sa isi bata mai mult capul cu tipul valorilor. In ceea ce priveste timpul probabil ca utilizarea unor operatori diferiti pentru operatii cu stringuri si numere, face ca verificarile sa fie mai putine, timpul de rulare sa fie scurtat.".
Robotul Google este scris in Python si multe pagini Google sunt create in Python. Am vazut pe jobs.perl.org si oferte de angajare la Google pentru programatori in Perl, cei de la booking.com angajeaza gramezi de programatori in Perl si sunt dispusi si sa rezolve cu vizele in Amsterdam, cu mutarea daca este nevoie, si Microsoft a finantat dezvoltarea anumitor bucati din Perl pentru Windows, ba am vazut anunt ca angajeaza programatori in Perl si firma Apple, asa ca nu prea este adevarat ca firmele mari nu folosesc limbaje dinamice, dupa cum am aratat si in mesajul anterior.
Ba Guido van Rossum, cel care a creat limbajul Python chiar a fost angajat de Google, asa ca Google chiar sustine dezvoltarea unui limbaj dinamic.
Iar Ruby a fost folosit de firma 37 Signals pentru a crea framework-ul Ruby on Rails pe care l-au folosit apoi pentru a crea cel mai important site de project management, basecamp.com.
Putem lauda si PHP care este folosit de Facebook si Yahoo, si cred ca sunt firme suficient de mari pentru a arata ca cunoscatorii nu se tem de povesti despre limbaje, ci pur si simplu aleg ce este mai bine pentru ele.
Intr-o aplicatie web, dar ma rog, una moderna, nu care foloseste scripturi CGI, programele ruleaza o singura data cand porneste serverul web, si gata, apoi stau gata compilate in memorie o lunga durata de timp si doar servesc cererile.
Ma rog, php nu functioneaza chiar asa, dar alte limbaje mai ca lumea da.
Asa ca chiar nu conteaza cu ce viteza se compileaza toate programele necesare fiindca compilarea si rularea lor se face doar o singura data, iar apoi functioneaza foarte rapid.
Oricum, nu prea vei vedea in curand pagini web create in C sau C++ chiar daca si cu aceste limbaje se pot crea pagini web si chiar daca C este in mod evident mult mai rapid decat alte limbaje. Si asta fiindca chiar daca ruleaza rapid, se pierde oricum cel mai mult timp cu altele decat generarea codului html, cum ar fi munca bazelor de date implicate, transferul datelor de la server la browser, iar munca necesara pentru a crea un site in C este de zeci de ori mai greoaie decat in alte limbaje ca PHP/Perl/Python/Ruby...
Asa ca viteza este buna acolo unde este nevoie de ea, doar ca nu oriunde are cine stie ce influenta.
"Mai zic ei ca si memoria ocupata de o variabila nu poate fi bine controlata, nu poti crea o variabila care sa fii sigur ca ocupa doar un byte, daca tot e nevoie de ea doar pentru true sau false. Aici se poate spune repede ca memoriile sunt atat de mari in prezent incat nu conteaza deloc asta.".
Memoria conteaza foarte mult, insa doar in anumite circumstante.
Dupa cum am spus, de exemplu este important cat de multa memorie se consuma cand vrei sa folosesti un server vps, fiindca platesti din greu pentru mai multa memorie, dar in acele cazuri tot nu este nevoie de a restrictiona atat de mult consumul de resurse ca in cazul crearii unui driver de exemplu, care vrei sa functioneze super rapid si cu consum minim de resurse, ca sa poata functiona ok pe orice computer. Acolo da, chiar daca trebuie sa muncesti de zeci de ori mai mult, trebuie sa folosesti C, si cu siguranta ca Perl sau alte limbaje dinamice nu va fi bun, si nici C# sau Java.
"Deci, discutiile pot merge la nesfarsit, e in functie de cum ne obisnuim, sub influenta cui am ajuns mai pe la inceput etc.".
Exact, si mai depinde de ce anume vrem sa facem. Stiu totusi ca ceea ce vrem sa facem depinde intr-o oarecare masura si de ceea ce stim sa facem.
"In orice caz, destul de putin probabil, fie si din cauza profesorilor de matematica, sa ajunga cineva la inceput sa mearga pe Dynamic type, decat daca nu a inceput cu PHP cand timpul liber a devenit mai lung dupa terminarea scolii si s-a dorit crearea unui site cat de cat mai complex.".
Nici eu nu am inceput sa programez intr-un limbaj dinamic. La inceput faceam un soi de super mini programele in .bat, dar fiindca vroiam sa am acces la internet si eram nevoit sa sparg un cont al colegilor de la facultatea de matematica-informatica, fiindca doar ei aveau cont cu acces la internet, am invatat Pascal. Si cu el am reusit sa sparg parolele la ceva mai mult de 50 de conturi sub sistemul de operare Novell Netware, cu speranta ca pentru unele conturi vor fi aceleasi parole si pentru conturile sub Sun OS, adica sub Unix, fiindca doar cu acele conturi se putea accesa internetul, si intr-adevar am reusit accesul prin intermediul a 3 conturi asa ca a fost suficient.
Mai tarziu am invatat putin Visual Basic, putin Javascript, putin VBA, si cu ele am creat si vandut cateva programe pentru cateva firme.
"IonPop, sunt curios cum ai ajuns sa te stabilesti pe limbajul Perl? Trebuie sa fi fost si tu influentat, nu cred ca ai luat limbajele la rand si te-ai oprit la acesta spunand: gata, imi satisface absolut toate nevoile.".
Povestea:
Perl am inceput sa invat doar dupa ce mi-am pierdut vederea.
L-am intrebat pe Mircea Vutcovici care ar fi cel mai potrivit limbaj de programare pentru a crea pagini web.
El mi-a spus ca Perl sau PHP. De PHP auzisem inainte de a imi pierde vederea fiindca organiza o firma cursuri de programare in "Personal Home Page" fiindca aceasta este denumirea de pe atunci a PHP-ului.
Iar despre Perl mai auzisem de la o colega care lucra pe Marketing la Dynamic Network Technologies, o firma de software si furnizor de internet din cluj care apartinea Fundatiei Soros, si care fusese infiintata de cel care conduce acum firma de software Recognos. Ei foloseau Perl pentru diverse programe pe care le creau pentru ei si pentru diversi clienti din SUA.
Asa ca am descrcat kiturile de PHP si Perl, am incercat prima data sa instalezi PHP-ul, dar nu stiu ce drac avea kitul ca nu am reusit sa il instalez, asa ca am instalat Perl care a functionat foarte bine, apoi am cautat manuale pe web si am gasit zeci de carti in format .chm, m-am subscris la diverse grupuri de discutii, acesta fiind un element foarte important, fiindca spre deosebire de alte limbaje dinamice ca Python sau Ruby sau PHP, Perl are o comunitate mult mai bine inchegata cu multe liste de discutii pe multe teme, ba chiar un soi de cluburi denumite "Perl Mongers". Perl Mongers s-a infiintat de vre-un an si ceva si in Cluj si mai exista si in alte orase universitare din Romania, iar in Cluj am participat la vre-o 4 intalniri pana acum, la care au venit speakeri locali si din strainatate si au prezentat diverse chestii, module etc.
Cam asta a fost totusi doar la inceput, dar apoi am incercat sa caut ce ma interesa pe mine, si anume care este cel mai bun limbaj pentru procesat text, si am fost placut surprins sa aflu ca este exact Perl, si nu alte limbaje promovate mult mai mult de diverse firme.
M-a interesat procesarea de text fiindca acesta este cel mai natural mod de a schimba informatii complexe, si este in mod evident cel mai accesibil pentru orbi si intr-adevar mi-a fost foarte util de multe ori ca am putut sa lucrez in Perl.
Am citit si de curand despre suportul Unicode in Perl, spunandu-se ca el este bun doar in limbajele Java si Perl. Nu stiu cum este in C#, fiindca el este foarte apropiat de Java, dar spun doar ce am citit.
Si asta fiindca in Python 2.7 suportul este nasol de tot (daca cumva exista suport in aceasta versiune), iar in Python 3 care nu este compatibil cu Python 2.7 si in care nu functioneaza multe module Python se ofera suport Unicode ceva mai bun, dar nu excelent, si se dadeau exemple de astfel de probleme, legate de exemplu de facilitatile de procesare a codului Unicode in regular expressions.
Or asta pe mine ma intereseaza, fiindca cum nu sunt american si multumit sa pot citi doar in engleza, imi place sa pot procesa ca lumea caracterele Unicode. Am spus insa ca doar am citit, fiindca stiu ca suportul Unicode in Perl este bun, dar personal nu am testat in alte limbaje ca sa pot face o comparatie.
In legatura cu regular expressions, este evident ca este cel mai bun motor de regular expressions din toate limbajele, iar asta este de asemenea ceva foarte important pentru procesarea de text.
Multe alte limbaje folosesc Perl regular expressions, dar de fapt folosesc doar o biblioteca preg care nu ofera toate facilitatile oferite de regular expressions in Perl, si dupa cate am vazut in ultimele versiuni de Perl, s-au mai adaugat noi si noi facilitati in motorul de regular expressions.
Ma rog, dupa cativa ani am zis ca poate nu ar fi rau sa invat si PHP, ca tot nu e cine stie ce complicat. Asa ca am instalat PHP si am creat un mic site de test, numai ca imi tot dadea o eroare desi foloseam un cod foarte simplu. Chiar m-am subscris la o lista de discutii de PHP ca sa intreb care este problema, si in final mi-a spus un utilizator ca problema mea se datoreaza unui bug cunoscut in PHP, si ca imi recomanda sa descarc versiunea urmatoare care era pe atunci beta, si ca in ea s-a rezolvat acea problema.
Atunci mi-a disparut brusc increderea in PHP si l-am abandonat.
Dupa alti cativa ani, dupa ce stiam mult mai bine Perl, am cautat informatii de nivel mai inalt in PHP, nu doar despre simpla programare low level, ci am cautat ce module exista pentru procesarea de formulare, ce sisteme de templating, ce framework-uri etc.
Module pentru procesat formulare nu am gasit deloc, dar am gasit cateva sisteme de procesat template-uri, si dintre ele pot spune ca Smarty este OK. Am gasit si mai multe framework-uri pentru creat aplicatii web, insa cu foarte foarte multe limitari in comparatie cu ceea ce oferea framework-ul Catalyst in Perl. Mai exact, unele dintre ele te obligau sa folosesti doar sistemul lor propriu de template si nu cel pe care vroiai tu, altele permiteau doar un anumit sistem de template extern, deci tot nu puteai alege, altele ofereau ORM-ul lor propriu (object relational manager), si multe astfel de limitari, dar cred ca cel mai mult mi-a displacut ca in majoritatea lor trebuia sa creezi o asociere statica intre directorul virtual, adica adresa web accesata si functia care era executata, asa ca daca schimbai ceva in program, in numele functiei de exemplu, trebuia sa modifici si asocierile in fisierul cu acele asocieri. In final am gasit ca cel mai bun framework pentru PHP este CodeIgniter fiindca avea si el limitarile lui, dar nu chiar atat de multe.
Numai ca totusi nu am gasit chiar absolut nici un avantaj in a folosi PHP chiar cu un web framework in comparatie cu Perl si Catalyst, asa ca nu mi-am mai batut capul cu PHP.
Am mai testat si alte limbaje ca Java, C#, Python, chiar putin si Ruby, si ele sunt toate OK, insa nu prea am avut nevoie de ele, fiindca pe partea de web Perl este bun, asa ca nu am avut nevoie de Python sau Ruby, iar pentru aplicatii cu interfata grafica pentru Windows C# este OK chiar daca nu am gasit interfetele create cu el la fel de responsive ca cele create cu widgeturi native win32, insa nu mi-a placut ca trebuie sa scri foarte mult cod in comparatie cu Perl, si dupa ce te obisnuiesti sa faci anumite lucruri super rapid, si mai poti folosi si diverse module facute de altii, si testate de multi altii, este un pic cam dezamagitor sa vezi ca trebuie sa scri o multime de linii de cod doar ca sa faci acelasi lucru...
Java nu prea mi-a placut fiindca desi poti crea pentru programele in Java fisiere executabile care sa ruleze sub Windows, totusi Java trebuie sa fie instalat, consuma cam multe resurse, nici de rulat programele nu rulau prea rapid, iar cand creezi programe cu o interfata grafica pe care deseori trebuie sa le pornesti si opresti... asta conteaza.
De multe ori insa de atunci Java a fost optimizat si ruleaza mai bine, si ma rog, poate conteaza si faptul ca acum am un computer mai rapid...
Asa ca pot spune ca folosesc Perl dintr-o intamplare. Poate ca daca ar fi functionat acel kit de PHP as fi reusit sa il instalez, si cum limbajul este simplu probabil ca mi-ar fi placut si as fi continuat cu el poate chiar fara sa mai incerc si Perl.
Asa ca vezi ca uneori e un mare avantaj cand nu reusesti sa instalezi un program .
Apropos de problema despre care spuneai ca ai intalnit-o in Autoit. Banuiesc ca era ceva de genul urmator:
my $x = 1;
if ( $x = 2 ) {
#do something
}
In Perl, poti crea programul urmator:
use strict;
use warnings;
my $x = 1;
if ( $x = 2 ) {
#do something
}
Iar el va afisa mesajul de avertizare:
Found = in conditional, should be == at D:\program.pl line 6.
Cred ca este destul de evident care este eroarea...
my $x = 1;
if ( $x = 2 ) {
#do something
}
In Perl, poti crea programul urmator:
use strict;
use warnings;
my $x = 1;
if ( $x = 2 ) {
#do something
}
Iar el va afisa mesajul de avertizare:
Found = in conditional, should be == at D:\program.pl line 6.
Cred ca este destul de evident care este eroarea...
Dar pe de alta parte, daca vrei totusi, poti sa folosesti egalitatea in if(), fara sa iti dea o eroare, atunci cand nu este o eroare, ca in exemplul:
use strict;
use warnings;
my $x = 1;
my $y = 2;
if ( $x = 2 == $y ) {
print "ok\n";
}
Va tipari "ok" fara nici un avertisment, fiindca nu exista nici o problema.
(De aceea am spus ca asta poate fi o facilitate)
use strict;
use warnings;
my $x = 1;
my $y = 2;
if ( $x = 2 == $y ) {
print "ok\n";
}
Va tipari "ok" fara nici un avertisment, fiindca nu exista nici o problema.
(De aceea am spus ca asta poate fi o facilitate)
- Manu
- General de divizie
- Mesaje: 4120
- Membru din: 02 Feb 2007, 01:15
- Localitate: Cluj-Napoca
- Contact:
Problema am avut-o mai mult in PHP, intr-adevar era de acest fel si nu stiu daca PHP are astfel de declaratii globale de scris in cod, nici nu stiam pe atunci ca ar fi posibil.IonPop scrie:Apropos de problema despre care spuneai ca ai intalnit-o in Autoit. Banuiesc ca era ceva de genul urmator:
my $x = 1;
if ( $x = 2 ) {
#do something
}
Am mai patit-o si cu faptul ca o variabila nu trebuie neaparat declarata, se poate crea direct in if, iar daca am avut o litera scrisa gresit, nu imi dadea nici o eroare, pur si simplu evaluarea era aceeasi indiferent de valoarea pe care o asignam variabilei pe care o verificam.
In Autoit exista posibilitatea sa scrii la inceput:
Opt(MustDeclareVars), in PHP nu stiu exact, nu am insistat, am devenit mai atent si atat.
In Autoit am patit ceva de genul:
Bazandu-ma ca intr-un limbaj dinamic isi da el seama ce tip de valoare este continuta, nu am mai utilizat functia Int() pentru a face o verificare intre doua variabile care contineau numere intregi.
Am facut o functie care verifica daca bazele de date cu intrebari ale jocului Pontes Millionaire este la zi, pentru asta avand local o constanta care contine un numar, iar pe server fiind un fisier care contine un alt numar.
Functia preia numarul de pe server, care este intr-adevar text si se verifica ceva de genul:
$localVer=9
$serverVer=GetVersionFromServer() ;aici se atribuia din fisier 10.
If $localVer < $serverVer Then
; actualizare...
EndIf
Ei bine, se intampla faptul ca nu imi dadea ca fiind adevarata aceasta evaluare nici chiar daca $localVer era egal cu 2, ci doar daca era egal cu 1, asa am dedus pana la urma ca nu stiu ce fel de comparatie face utilizand semnul de mai mic, dar parea mai mult alfabetica.
Pana la urma se rezolva usor scriind:
If Int($localVer) < Int($serverVer) Then
; actualizare...
EndIf
Nu mai conteaza, probabil nu voi mai folosi Autoit decat daca va trebui sa fac ceva foarte rapid.
Cat despre suportul pentru Unicode, Java are intr-adevar acest avantaj, este utilizat direct, implicit, din momentul in care incepi sa programezi poti utiliza orice caracter, cea ce este foarte avantajos.
Errare humanum est, sed perseverare diabolicum...
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
Aa, daca problema era in PHP, atunci probabil ca ea exista inca si in zilele noastre.
Intr-adevar, si in Perl poti scrie programe in care sa folosesti cod Unicode nu doar in stringuri, ci chiar si in numele subrutinelor si variabilelor. Evident, eu nu as scrie un astfel de cod, dar uite ca se poate si ruleaza fara probleme:
use utf8;
my $variabila_ţâţă_de_mâţă = 123;
subrutină_ţâţă_de_mâţă( $variabila_ţâţă_de_mâţă );
sub subrutină_ţâţă_de_mâţă {
my ( $ţâţă ) = @_;
print $ţâţă;
}
Si afiseaza 123.
Intr-adevar, si in Perl poti scrie programe in care sa folosesti cod Unicode nu doar in stringuri, ci chiar si in numele subrutinelor si variabilelor. Evident, eu nu as scrie un astfel de cod, dar uite ca se poate si ruleaza fara probleme:
use utf8;
my $variabila_ţâţă_de_mâţă = 123;
subrutină_ţâţă_de_mâţă( $variabila_ţâţă_de_mâţă );
sub subrutină_ţâţă_de_mâţă {
my ( $ţâţă ) = @_;
print $ţâţă;
}
Si afiseaza 123.
@Manu: Intr-adevar, asta ar fi trebuit sa fie un thread de utilizatori. Mereu cand vad afirmatii old school gen doar linia de comanda e buna, open source e superior, windows e naspa, limbajele stronglhy typed nu sunt bune etc, zic sa nu ma bag, si totusi nu rezist tentatiei.
IonPop: Mie afirmatia ta legata de visual studio nu mi s-a parut legata de discutia anterioara cu linia de comanda. Eu am raspuns strict legat de programarea grafica, aratand ca este posibila si utilizata atat de vazatori, cat si de nevazatori. de Cazurile de utilizare pe care le-ai mentionat nu am avut nevoie niciodata, asa ca nu pot vorbi despre ele.
Cazul tau cu sollo programmer este in minoritate, indraznesc sa afirm ca multi nevazatori pot fi interesati de programare pentru a avea o cariera intr-o firma, de aia am mentionat clar ca eu nu ma refer la costurile dezvoltarii personale, ci la programare in general, angajat sau acasa, fara restrictii. Strict tehnologie.
Se pare ca ori nu stiu eu sa ma exprim, ori tu nu ma intelegi. Oricare ar fi cazul, nu am de gand sa continui thread-ul asta. Ca sa nu zici, tu sau altcineva, ca folosesc asta ca o scuza, voi da exemple:
Tu zici:
"
Eu nu sunt firma nationala sau internationala care sa aiba fonduri mari pentru gazduire si nici nu am nevoie de un limbaj super standardizat pe care sa il poata intelege usor un incepator, ca sa nu am probleme cand vreau sa angajez noi membrii in echipa si sa imi fie usor sa ii gasesc, si ieftin, ci am nevoie de un limbaj in care pot programa cat de rapid posibil, eu singur si cu care sa pot crea programe a caror gazduire costa cat de putin posibil, iar Dotnet nici nu intra in discutie pentru asa
"
Eu iti zic ca afirmatiile tale cum ca doar firmele mari, alea internationale, cu fonduri, care au nevoie de limbaje standadizate, au nevoie de DotNet, sunt enormitati, iar tu vii si te comporti ca si cum eu, nu tu, as fi zis ca doar firmele mari au nevoie de DotNet, si iti alegi strategic firme mari care nu folosesc.
"
Poti enumera cateva limbaje din acestea... "multe"?
Bineinteles, in afara de PHP, despre care... mai bine sa nu vorbim.
"
)
Asta e tare. E ca si cum ai zice zi-mi si mie ce au facut nazistii rau, dar sa nu cumva sa imi pomenesti de tigani si evrei.
Php e principalul reprezentant al limbajelor astea dinamice, eel e cel mai important. Probabil e chiar cel mai folosit limbaj din lume, deci, statistic, oamenii au cea mai mare sansa sa se loveasca de problema asta la el. Asta e filosofia limbajelor dinamice, te lasam sa faci tu ce vrei, ca sa faci mai repede. Daca ai facut o tampenie, nasol tata, descurca-te.De acord, sunt jde mii de extensii si chestii care se pot folosi daca vrei sa ai un standard, dar problema e ca nu se folosesc. Si ai de lucrat cu codul unuia care a scris si stie el in capul lui ce se intapmla si cum, dar cand vezi codul nu intelegi nimic. La strong dyping nu o sa intalnesti niciodata asa ceva. Oricat ai vrea, nu poti obscura un program. Compilatorul te forteaza sa fii clar, ca sa inteleaga oricine ce ai vrut sa faci acolo.
Am scris cod in php, python si javascript, si in toate am avut o gramada de erori din cauza asta.
In Lua e la fel cu variabilele null, si nici javascript nu sta prea bine.
Singura chestie inaccesibila la visual studio express era form designer-ul, trebuia sa pui controalele calculand manual pozitiile, cum se face si in alte limbaje de programare.
Orice ar zice oricine, tu o tii pe a ta: perl e cel mai bun (chit ca are market share infim de 0.7%), interfetele grafice sunt ineficiente si profesionistii adevarati folosesc consola, windows e naspa ca sistem de hosting, doar linux e bun. Cand vine cineva si iti zice ca mai exista si altceva, ca unii prefera aia pentru ca x, tu arati de ce x e praf si, again, doar perl rules.
Cum am mai zis, singurul motiv din care ma contrazic cu tine pe aici e in caz ca vede cineva interesat si crede ca ai dreptate si chestiile astea old school sunt singurul mod de a programa pentru un nevazator. Adevarul e ca putem programa cam in orice, destul de eficient. Daca vreti sa alegeti o platorma, cititi, invatati despre ele, hotarati-va ce vreti sa faceti cu ele. Nu va bazati pe o singura opinie, ori a cui ar fi.
IonPop: Mie afirmatia ta legata de visual studio nu mi s-a parut legata de discutia anterioara cu linia de comanda. Eu am raspuns strict legat de programarea grafica, aratand ca este posibila si utilizata atat de vazatori, cat si de nevazatori. de Cazurile de utilizare pe care le-ai mentionat nu am avut nevoie niciodata, asa ca nu pot vorbi despre ele.
Cazul tau cu sollo programmer este in minoritate, indraznesc sa afirm ca multi nevazatori pot fi interesati de programare pentru a avea o cariera intr-o firma, de aia am mentionat clar ca eu nu ma refer la costurile dezvoltarii personale, ci la programare in general, angajat sau acasa, fara restrictii. Strict tehnologie.
Se pare ca ori nu stiu eu sa ma exprim, ori tu nu ma intelegi. Oricare ar fi cazul, nu am de gand sa continui thread-ul asta. Ca sa nu zici, tu sau altcineva, ca folosesc asta ca o scuza, voi da exemple:
Tu zici:
"
Eu nu sunt firma nationala sau internationala care sa aiba fonduri mari pentru gazduire si nici nu am nevoie de un limbaj super standardizat pe care sa il poata intelege usor un incepator, ca sa nu am probleme cand vreau sa angajez noi membrii in echipa si sa imi fie usor sa ii gasesc, si ieftin, ci am nevoie de un limbaj in care pot programa cat de rapid posibil, eu singur si cu care sa pot crea programe a caror gazduire costa cat de putin posibil, iar Dotnet nici nu intra in discutie pentru asa
"
Eu iti zic ca afirmatiile tale cum ca doar firmele mari, alea internationale, cu fonduri, care au nevoie de limbaje standadizate, au nevoie de DotNet, sunt enormitati, iar tu vii si te comporti ca si cum eu, nu tu, as fi zis ca doar firmele mari au nevoie de DotNet, si iti alegi strategic firme mari care nu folosesc.
"
Poti enumera cateva limbaje din acestea... "multe"?
Bineinteles, in afara de PHP, despre care... mai bine sa nu vorbim.
"
)
Asta e tare. E ca si cum ai zice zi-mi si mie ce au facut nazistii rau, dar sa nu cumva sa imi pomenesti de tigani si evrei.
Php e principalul reprezentant al limbajelor astea dinamice, eel e cel mai important. Probabil e chiar cel mai folosit limbaj din lume, deci, statistic, oamenii au cea mai mare sansa sa se loveasca de problema asta la el. Asta e filosofia limbajelor dinamice, te lasam sa faci tu ce vrei, ca sa faci mai repede. Daca ai facut o tampenie, nasol tata, descurca-te.De acord, sunt jde mii de extensii si chestii care se pot folosi daca vrei sa ai un standard, dar problema e ca nu se folosesc. Si ai de lucrat cu codul unuia care a scris si stie el in capul lui ce se intapmla si cum, dar cand vezi codul nu intelegi nimic. La strong dyping nu o sa intalnesti niciodata asa ceva. Oricat ai vrea, nu poti obscura un program. Compilatorul te forteaza sa fii clar, ca sa inteleaga oricine ce ai vrut sa faci acolo.
Am scris cod in php, python si javascript, si in toate am avut o gramada de erori din cauza asta.
In Lua e la fel cu variabilele null, si nici javascript nu sta prea bine.
Singura chestie inaccesibila la visual studio express era form designer-ul, trebuia sa pui controalele calculand manual pozitiile, cum se face si in alte limbaje de programare.
Orice ar zice oricine, tu o tii pe a ta: perl e cel mai bun (chit ca are market share infim de 0.7%), interfetele grafice sunt ineficiente si profesionistii adevarati folosesc consola, windows e naspa ca sistem de hosting, doar linux e bun. Cand vine cineva si iti zice ca mai exista si altceva, ca unii prefera aia pentru ca x, tu arati de ce x e praf si, again, doar perl rules.
Cum am mai zis, singurul motiv din care ma contrazic cu tine pe aici e in caz ca vede cineva interesat si crede ca ai dreptate si chestiile astea old school sunt singurul mod de a programa pentru un nevazator. Adevarul e ca putem programa cam in orice, destul de eficient. Daca vreti sa alegeti o platorma, cititi, invatati despre ele, hotarati-va ce vreti sa faceti cu ele. Nu va bazati pe o singura opinie, ori a cui ar fi.
Vortex Website
Maximum de confort, cu minimum de efort.
Maximum de confort, cu minimum de efort.
- Manu
- General de divizie
- Mesaje: 4120
- Membru din: 02 Feb 2007, 01:15
- Localitate: Cluj-Napoca
- Contact:
Pai nu cred ca neaparat trebuie inchis subiectul, pana la urma din el se pot si invata lucruri.
Daca IonPop sustine Perl... e ca si cum cei fani Apple sustin iPhone, nu cred ca isi vor lua toti iPhone, eu de exemplu nu imi cumpar.
Nu stiu nici de Perl daca ma voi apuca, dar conteaza ca cineva care il stie atat de bine sa ii prezinte avantajele, altfel ar fi fost destul de probabil sa treaca pe langa mine neobservat.
Sincer mi-ar placea un topic in care sa dam tot felul de exemple de cod, solutii etc, doar de pe forumuri se invata un procent destul de mare din ce tine de astfel de lucruri.
Daca IonPop sustine Perl... e ca si cum cei fani Apple sustin iPhone, nu cred ca isi vor lua toti iPhone, eu de exemplu nu imi cumpar.
Nu stiu nici de Perl daca ma voi apuca, dar conteaza ca cineva care il stie atat de bine sa ii prezinte avantajele, altfel ar fi fost destul de probabil sa treaca pe langa mine neobservat.
Sincer mi-ar placea un topic in care sa dam tot felul de exemple de cod, solutii etc, doar de pe forumuri se invata un procent destul de mare din ce tine de astfel de lucruri.
Errare humanum est, sed perseverare diabolicum...
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
"Intr-adevar, asta ar fi trebuit sa fie un thread de utilizatori. Mereu cand vad afirmatii old school gen doar linia de comanda e buna, open source e superior, windows e naspa, limbajele stronglhy typed nu sunt bune etc, zic sa nu ma bag, si totusi nu rezist tentatiei.".
Asta inseamna ca chiar nu ai inteles nimic din ce am discutat pana acum sau cu rea vointa spui ca eu am spus ceea ce nu am spus.
In primul rand nu am spus niciodata ca doar linia de comanda este buna.
Ba chiar dimpotriva, ti-am spus ca eu nu folosesc un editor in linia de comanda, ci programe cu interfata grafica, si inca sub Windows.
Ba chiar am spus si despre limbajele de programare, ca pentru anumite domenii sunt de preferat cele ca Java/C# si nu PHP/Perl/Ruby/Python.
Sau ma insel?
De asemenea, nu am spus niciodata ca open source este superior, fiindca ar fi o generalizare prosteasca.
Anumite programe open source sunt mai bune decat altele proprietare in anumite domenii si mai proaste in alte domenii, asa ca depinde de ceea ce ai nevoie.
Si cred ca nu ai inteles gresit asta, fiindca am spus de multe ori ca preferinta pentru un limbaj sau program depinde de nevoile fiecaruia.
Nu am spus nici ca Windows e nashpa in toate privintele, ci am aratat care sunt punctele lui slabe.
"IonPop: Mie afirmatia ta legata de visual studio nu mi s-a parut legata de discutia anterioara cu linia de comanda. Eu am raspuns strict legat de programarea grafica, aratand ca este posibila si utilizata atat de vazatori, cat si de nevazatori. de Cazurile de utilizare pe care le-ai mentionat nu am avut nevoie niciodata, asa ca nu pot vorbi despre ele.".
Atunci inseamna ca ai facut, probabil neintentionat, o greseala stupida care pe mine ma enerveaza intotdeauna, raspunzand la o problema de genul "este greu sa fac un program care sa faca cutare lucru" cu un raspuns de genul "pai atunci fa-te avocat".
Pe unele liste de discutii apare cateodata cineva care arata o bucata de cod si care spune ca nu ii functioneaza OK, ca are cutare probleme cu respectivul program, si apare cineva care ii spune ceva de genul "Aa, folosesti Windows? Pai ala e un sistem nashpa. Foloseste Linux si va functiona OK programul".
De parca asta chiar ar fi o solutie. Poate ca cel care a pus intrebarea are un intreg sistem din care acel program este doar o mica particica, si probabil ca el are cunostinte in lucrul sub Windows si cu respectivul limbaj pe care le-a dobandit in multi ani, si vine unul sa ii spuna ca exista o alta solutie, de a folosi Linux, doar fiindca a aparut o singura problema intr-un program.
Exact asta ai facut tu cand am aratat cateva din neajunsurile Windows-ului legate de linia de comanda, iar tu imi recomanzi sa folosesc un sistem bazat pe interfata grafica, de parca asta ar fi o solutie.
Si asta doar fiindca linia de comanda din Windows nu are atat de multe facilitati ca cea din Linux/Mac.
Ce sa fac cu un program care are interfata grafica daca el trebuie sa ruleze automat la anumite ore prestabilite, sa preia date dintr-o baza de date, sa le proceseze si sa le introduca intr-o alta baza de date si sa le trimita apoi spre un alt program care sa le proceseze din nou si sa le trimita prin email? Asta ca un exemplu, desi exista nevoi mult mai complexe de atat.
La ce ar folosi o interfata grafica? Cum ar trebui sa trimit parametrii automat catre program daca nu ca parametrii in linia de comanda?
Daca spui ca nu ai avut niciodata nevoie de cazurile despre care am spus, atunci cum poti sa sti ca pentru asa ceva utilizarea unor programe cu interfata grafica este o alternativa?
Nu este bine sa vorbesti si sa le recomanzi altora ceva despre care spui ca nu sti, fiindca ii induci in eroare.
"Cazul tau cu sollo programmer este in minoritate, indraznesc sa afirm ca multi nevazatori pot fi interesati de programare pentru a avea o cariera intr-o firma, de aia am mentionat clar ca eu nu ma refer la costurile dezvoltarii personale, ci la programare in general, angajat sau acasa, fara restrictii. Strict tehnologie.".
Cred ca e cam nonsens ce ai spus mai sus, sau nu am inteles eu bine?
Ai spus "nu ma refer la costurile dezvoltarii personale", dar apoi si "angajat sau acasa".
Pai daca exista si varianta "acasa" atunci ea se refera strict la o dezvoltare in scop cat se poate de personal, fiindca banuiesc ca nu te referi la dezvoltarea acasa, dar intr-o echipa.
Si imi pare ca faci si prezumtii fara sa fi in cunostinta de cauza.
Si eu lucrez intr-o firma unde folosesc tot Perl, si am creat cu Perl si programe care ruleaza automat fara o interfata grafica, si programe pe care le rulez in linia de comanda, si programe cu interfata grafica folosite de clienti, de colegii de la contabilitate, si doua site-uri web ale firmei.
Dar tot datorita posibilitatii de a rula programele in linia de comanda si de la distanta, am putut si sa lucrez o perioada de la distanta pentru o firma dintr-o alta tara, ceea ce nu ar fi fost posibil daca as fi putut folosi doar o interfata grafica.
Si tot datorita posibilitatii de a lucra in linia de comanda pot si sa administrez un site de la distanta, un site care nu costa la fel de mult ca unul pe care as rula Windows.
Deci posibilitatea de a lucra in linia de comanda si facilitatile oferite in acest sens de sistemul de operare sunt importante, fiindca interfata grafica nu este o solutie pentru toate cum vrei tu sa arati.
Este cat se poate de bine ca din August ai un job la Reea, si eu personal ma bucur ori de cate ori un programator orb isi gaseste de lucru in Romania, fiindca inseamna ca trendul este de acceptare a orbilor in acest domeniu, si este foarte bine ca acolo poti folosi DotNet, dar cred ca ar trebui sa ai o atitudine mai deschisa si sa nu consideri ca doar ce ai invatat tu la scoala este cool, iar restul nu este bun doar fiindca tu nu ai avut nevoie si nu ai lucrat cu altceva dupa cum ne-ai spus.
"Tu zici:
"
Eu nu sunt firma nationala sau internationala care sa aiba fonduri mari pentru gazduire si nici nu am nevoie de un limbaj super standardizat pe care sa il poata intelege usor un incepator, ca sa nu am probleme cand vreau sa angajez noi membrii in echipa si sa imi fie usor sa ii gasesc, si ieftin, ci am nevoie de un limbaj in care pot programa cat de rapid posibil, eu singur si cu care sa pot crea programe a caror gazduire costa cat de putin posibil, iar Dotnet nici nu intra in discutie pentru asa
"
Eu iti zic ca afirmatiile tale cum ca doar firmele mari, alea internationale, cu fonduri, care au nevoie de limbaje standadizate, au nevoie de DotNet, sunt enormitati, iar tu vii si te comporti ca si cum eu, nu tu, as fi zis ca doar firmele mari au nevoie de DotNet, si iti alegi strategic firme mari care nu folosesc.".
In primul rand tu ai spus: "Zici ca DotNet nu e solutie pentru ca nu e portabila sub Linux, iar gazduirea pe Windows nu e rentabila. Eu, si toate firmele nationale si internationale care fac hosting si development pe Windows, te contrazic."..
Iar eu ti-am spus ca eu nu sunt firma nationala sau internationala.
Mi-ar fi placut sa vad mai multe exemple de site-uri ale unor persoane fizice care folosesc DotNet, ca o dovada ca gazduirea sub Windows si cu DotNet este rentabila si pentru ele, fiindca altfel comparam mere cu pere.
Eu iti spun de ce consider ca Windows are o problema pentru mine personal, iar tu imi spui ca exista alte solutii folosite de firme nationale si multinationale.
Iar in al doilea rand, nu am ales strategic acele firme, ci am ales cele mai mari firme in domeniul iT, si se pare ca ele nu prea folosesc DotNet.
Insa tot nu ne-ai dat exemple de alte firme importante in domeniul iT care sa foloseasca DotNet...
"
Poti enumera cateva limbaje din acestea... "multe"?
Bineinteles, in afara de PHP, despre care... mai bine sa nu vorbim.
"
)
Asta e tare. E ca si cum ai zice zi-mi si mie ce au facut nazistii rau, dar sa nu cumva sa imi pomenesti de tigani si evrei.
Php e principalul reprezentant al limbajelor astea dinamice, eel e cel mai important. Probabil e chiar cel mai folosit limbaj din lume, deci, statistic, oamenii au cea mai mare sansa sa se loveasca de problema asta la el. Asta e filosofia limbajelor dinamice, te lasam sa faci tu ce vrei, ca sa faci mai repede. Daca ai facut o tampenie, nasol tata, descurca-te.De acord, sunt jde mii de extensii si chestii care se pot folosi daca vrei sa ai un standard, dar problema e ca nu se folosesc. Si ai de lucrat cu codul unuia care a scris si stie el in capul lui ce se intapmla si cum, dar cand vezi codul nu intelegi nimic. La strong dyping nu o sa intalnesti niciodata asa ceva. Oricat ai vrea, nu poti obscura un program. Compilatorul te forteaza sa fii clar, ca sa inteleaga oricine ce ai vrut sa faci acolo.
Am scris cod in php, python si javascript, si in toate am avut o gramada de erori din cauza asta.
In Lua e la fel cu variabilele null, si nici javascript nu sta prea bine.".
Inseamna ca nu ai avut de corectat prea mult cod in Java scris de altii, ca sa vezi cat de standard este...
Daca programul foloseste doar clase si metode din distributia standard a limbajului si cunosti bine limbajul, atunci exista sanse ca programul sa fie OK, mai ales daca si structura programului este una standard, doar ca cod in DotNet si Java se poate scrie si fara DotNet sau Eclipse, si programatorul isi poate structura cat de ciudat se poate programul.
Daca in schimb se folosesc si alte clase nestandard create de diverse firme, atunci poti sa ai si mai multe batai de cap.
Cu alte cuvinte, poti sa scri prost programe in orice limbaj, avand o importanta mica pentru intelegerea codului faptul de a defini sau nu tipul variabilelor.
Gandeste-te doar logic. Presupune ca ai un program in C#/Java in care toate variabilele sunt de acelasi tip, fiindca probabil ca doar de asa ceva ai nevoie, si ca programul e doar un test, ca nici nu preia date din afara si nici nu trimite data in alta parte.
Crezi ca daca ai cunoaste la fel de bine un limbaj dinamic si acel program ar fi scris in respectivul limbaj l-ai intelege mai greu, doar fiindca tipul variabilelor nu este definit, stiind totusi ca toate sunt de acelasi tip?
Iti spun eu care este diferenta. Problema este flexibilitatea. Limbajele dinamice sunt mult mai flexibile decat cele statice, si poti face mult mai usor lucruri mult mai complexe, intr-un tip mult mai scurt si cu mult mai putin cod.
Dar asta poate insemna bucati de cod miraculoase care chiar daca au doar 3 linii, pot sa te puna in incurcatura si sa foloseasca diverse smecherii pe care nu le sti ca incepator.
Cand cunosti insa suficient de bine limbajul, nu mai ai probleme in a le intelege, chiar daca ele folosesc diverse metode sau functii din alte module care nu sunt in distributia standard a limbajului.
Asa ca este pur si simplu o chestiune de preferinte. Unii prefera sa scrie o gramada de cod pana se plictisesc, dar acel cod sa fie cat se poate de standard, iar altii prefera sa poata scrie mai putin cod care sa faca mai multe lucruri.
Cand scri mai mult cod exista insa si sanse mai mari sa faci greseli, dar ambele preferinte sunt cat se poate de normale.
Dupa cum spuneam, cei care prefera matematica prefera de obicei ca totul sa fie cat se poate de clar si standard, si in multe facultati de informatica predau in primul rand profesori de matematica, si sunt urmate de studenti care au fost buni la matematica, asa ca este foarte normal ca multi programatori sa prefere acest stil.
Larry Wall, cel care a creat limbajul Perl nu a fost matematician, ci lingvist, deci probabil ca observi diferenta.
Nici eu nu am absolvit o facultate de informatica asa ca nu am fost ghidat sa prefer un limbaj sau altul, ci le-am testat si pe unele si pe altele, si am preferat productivitatea mai buna a limbajelor dinamice.
"Orice ar zice oricine, tu o tii pe a ta: perl e cel mai bun (chit ca are market share infim de 0.7%).".
Mda, se pare ca din nou spui ca as fi spus ceva ce eu nu am spus.
Am spus ca nici un limbaj nu este bun pentru orice si fiecare are avantajele si dezavantajele lui. Am ajuns sa enumeram limbajele doar fiindca tu ai inceput sa spui ca exista alternative pentru linia de comanda, ceea ce este o limitare, nu o alternativa. Si am amintit si am dat exemple despre cum se fac anumite lucruri in Perl pentru a arata ca anumite conceptii despre limbajele dinamice nu sunt adevarate.
Ba chiar am spus si pentru ce anume nu este bun Perl si alte limbaje dinamice.
Si in plus pot sa iti spun ca exista multe alte dezavantaje ale lui...
"interfetele grafice sunt ineficiente".
Depinde la ce te referi prin "ineficiente". Daca te referi la viteza de operare, atunci depinde de program.
Anumite programe, cum ar fi editoarele de text, jocurile, sunt mult mai potrivite pentru o interfata grafica. Exista si jocuri in linia de comanda, si editoare de text, dar cel putin mie nu imi plac, fiindca lucrez mai greu cu ele decat cu o interfata grafica.
In cazul altor programe, linia de comanda nu doar ca este mai buna, ca in cazul acelor scurte comenzi cu care poti inlocui didiverse texte in mai multe fisiere folosind regular expressions, fiindca in mod evident este mult mai rapid de facut decat sa creezi un program cu interfata grafica care sa faca asa ceva, dar si pentru a concatena mai multe programe care sa isi execute fiecare partea sa, dar in anumite cazuri este singura solutie ca in cazul programelor care trebuie sa ruleze fara nici o interfata, in mod automat, sau de la distanta etc.
Daca te referi la eficienta din punct de vedere financiar, atunci diferra in functie de cat trebuie sa platesti pentru ele.
"si profesionistii adevarati folosesc consola".
Este mai simplu de utilizat anumite comenzi decat sa faci acelasi lucru cu o interfata grafica, insa este mult mai dificil de invatat sa utilizezi programe in linia de comanda, fiindca trebuie sa ai multa experienta, sa sti la ce se folosesc fiecare, ce parametrii accepta, cum le poti combina etc.
Asa ca daca sti sa folosesti bine programele in linai de comanda inseamna in mod evident ca ai o experienta mult mai mare decat altcineva care stie sa foloseasca bine interfata grafica. Sau nu esti de acord?
"windows e naspa ca sistem de hosting".
Da, asta in mod evident este adevarat, fara nici o discutie.
Si nu stiu de ce mai insisti daca tu spui ca tu nu ai experienta in administrarea unui sistem de la distanta, ca sa poti sa iti dai seama de diferente.
Ti-am spus, ca si costurile financiare sunt mai mari, si accesibilitatea pentru orbi este mai redusa, si resursele consumate sunt mai mari care pot implica costuri in plus etc.
"doar linux e bun.".
Ca o afirmatie generala iar spui ce nu am spus. Deja pot spune ca minti cu nerusinare si cu rea vointa, si chiar nu prea cred ca este doar o neintelegere.
Linux este mai bun decat Windows daca costurile cu resursele si cu licentele sunt importante, si asta pentru servere web si de baze de date, dar in nici un caz pentru lucrul de zi cu zi.
Si am spus cred de cateva ori ca pentru lucrul de zi cu zi si eu folosesc Windows. Crezi ca as folosi Windows daca as crede ca "doar Linux este bun" cum pretinzi ca as fi spus?
Sau nu este voie sa aducem nici o invinuire sistemului de operare Windows in nici un domeniu nici chiar in partile lui slabe?
"Cand vine cineva si iti zice ca mai exista si altceva, ca unii prefera aia pentru ca x, tu arati de ce x e praf si, again, doar perl rules.".
Nu era vorba despre Perl, ci despre linia de comanda de sub Windows care e proasta, si este absolut neimportant ca mai exista si altii care prefera altceva fiindca ei au alte nevoi si ca preferintele lor sunt bune pentru nevoile lor, nu pentru ce au nevoie cei care folosesc linia de comanda.
Sau vrei sa spui ca toate bazele de date de la MySQL, PostgreSQL, SQLite, sunt niste prostii si ca toata lumea ar trebui sa foloseasca doar programele create de Microsoft?
Spun asta fiindca toate acele baze de date pot fi accesate in linia de comanda, iar variantele de a le accesa cu o interfata grafica implica probleme de accesibilitate pentru orbi, iar daca linia de comanda ar trebui inlocuita cu o interfata grafica ar implica sa nu le mai putem folosi.
Asa ca spun din nou ca este o prostie acest mod de a arata ca solutia pentru o problema este de a schimba total si sistemul de operare si limbajul de programare, si stilul de programare, doar fiindca crezi tu ca Windows si o interfata grafica este o solutie pentru toate, iar cand iti arat pentru ce anume nu este o solutie, spui ca tu nu sti ca cu asa ceva nu ai avut de a face.
"Cum am mai zis, singurul motiv din care ma contrazic cu tine pe aici e in caz ca vede cineva interesat si crede ca ai dreptate si chestiile astea old school sunt singurul mod de a programa pentru un nevazator.".
Sti tu ca exista o zicala "dialog al surzilor". Cred ca ceva de genul asta este si discutia noastra.
Ti-am pus cateva intrebari dar ai sarit peste toate.
Asa ca din nou... Am spus eu ca doar in modul in care programez eu se poate programa?
Am spus ca fiecare isi are nevoile lui, si nu orice nevoi pot fi rezolvate la fel de usor prin folosirea unei interfate grafice, iar altele nu pot fi rezolvate deloc de o interfata grafica. Cred ca daca s-ar fi putut, Microsoft ar fi renuntat la command.com, nu ar fi introdus si cmd.exe ba chiar si PowerShell.
"Adevarul e ca putem programa cam in orice, destul de eficient. Daca vreti sa alegeti o platorma, cititi, invatati despre ele, hotarati-va ce vreti sa faceti cu ele. Nu va bazati pe o singura opinie, ori a cui ar fi.".
Sigur ca da, de programat putem programa in aproape orice, insa de administrat programele respective este mai simplu in anumite feluri si mai complicat in altele, dar stiu, despre administrare nu vrei sa vorbim fiindca tu nu ai experienta in asa ceva.
Or daca tot vorbim despre linia de comanda, atunci ei bine ea nu are nimic de a face cu programarea efectiva, fiindca in linia de comanda poti rula si programe in C# si programe in Java, ci rularea unui program tine de partea de administrare, iar administrarea nu o poti face intotdeauna printr-o interfata grafica.
Unii orbi isi pot gasi de lucru la o firma, ca mine sau ca tine, dar si noi si altii putem sa lucram si altceva la care avem nevoie de acces de la distanta unde nu putem accesa o interfata grafica, si nu vad de ce ar trebui sa ne limitam posibilitatile de a lucra care si asa sunt putine.
@Manu: "Pai nu cred ca neaparat trebuie inchis subiectul, pana la urma din el se pot si invata lucruri.".
Cand eram incepator in Perl, aveam mult mai mult timp liber si obisnuiam sa pun intrebari pe listele de discutii din care ieseau adevarate razboaie.
Rezultatul era ca dupa asemenea discutii imi faceam multi dusmani virtuali, insa puteam afla o multime de lucruri foarte utile si interesante pe care nu le-as fi putut gasi nici citind 10 carti de Perl.
Asta fiindca expertii in Perl isi alocau timp sa explice pe larg anumite chestiuni mai ciudate doar cand ii rodeau nervii.
"Daca IonPop sustine Perl... e ca si cum cei fani Apple sustin iPhone, nu cred ca isi vor lua toti iPhone, eu de exemplu nu imi cumpar.".
Eu nu sustin Perl, ci doar am aratat cum se face cutare si cutare lucru in Perl ca sa elimin opiniile gresite despre limbajele dinamice, insa cred ca iti dai seama ca fiindca cunosc acest limbaj cel mai bine, despre el am mai multe nemultumiri decat despre alte limbaje.
Sti tu cum sunt intrebati copiii de adulti... "tie ce materie iti place?".
Ei bine, la scoala si in liceu si in facultate adevarul este ca mie nu imi placea nici o materie, asa pur si simplu.
Imi placeau anumite chestiuni de la o materie, altele de la alte materii etc. Evident, aveam anumite materii pe care le preferam ceva mai mult si altele pe care le uram ceva mai mult, dar nu am putut sa impart niciodata ceva doar in alb si negru, adica ca cutare lucru imi place, iar cutare nu.
In general imi placeau materiile la care nu trebuia sa invat, adica pe cele la care daca eram atent in clasa, era suficient si nu trebuia sa mai pierd timpul citind iar si iar acasa. Asta probabil fiindca nu am o memorie foarte buna, asa ca nu sunt bun la tocit, ci imi place acele lucruri pe care trebuie sa le judeci, nu sa le tii minte.
Poate de asta prefer acum si limbajele de programare care folosesc de obicei nume scurte pentru functii si clase, in care trebuie sa scri putin cod care face multe, fiindca nu e nevoie nici de prea multa memorie, si si de aceasta data nu trebuie sa pierd prea mult timp cu ele.
In domeniul iT cred ca e cam la fel, adica pot enumera dezavantaje si avantaje la toate sistemele de operare pe care le cunosc cat de cat, si la toate bazele de date, si la toate limbajele de programare cu care am lucrat cat de cat, asa ca nu pot sa recomand unul doar fiindca din intamplare eu il cunosc mai bine decat altele.
Dar ce imi pare mie o opinie de clasa intai este parerea ca trebuie sa folosim ce foloseste majoritatea, si asta in toate domeniile, nu doar in domeniul iT.
Imi pare de exemplu o stupizenie sa chiar crezi in povestile crestinesti doar fiindca locuiesti intr-o tara in care a fost impus crestinismul in mintea majoritatii, fara sa te gandesti cum ar fi fost daca ai fi fost infiat de o familie din India, sau China, sau Africa unde majoritare sunt cu totul alte religii. Oare si atunci ai fi avut aceeasi parere? Probabil ca nu, iar daca esti o persoana nascuta cu nevoia de a crede in divinitati, care are nevoia sa stie ca in lume totul este stabilit, ca exista un destin pentru fiecare, ca dupa moarte sigur trebuie sa existe ceva, atunci probabil ca ai fi aderat cu mare bucurie si incredere la una dintre religiile locale si poate nici nu ai fi auzit despre povestile crestinesti, si ai fi crezut in reincarnare si nu intr-o viata de apoi, ai fi crezut in karma si nu in destin etc.
Eu cred ca este mult mai normal sa consideram ca absolut tot ce exista pe pamant, bune sau rele din punctul nostru de vedere, sunt cat se poate de normale, iar daca citim istoria putem vedea ca asa a fost intotdeauna.
Nu exista un bine general sau un rau general, ci fiecare vede binele si raul in functie de nevoile personale, de mediul in care traieste si este cat se poate de normal sa acceptam ca nu exista o singura solutie pentru orice in niciun domeniu, evident, nici in domeniul iT, unde asta este chiar mai simplu de demonstrat.
"Nu stiu nici de Perl daca ma voi apuca, dar conteaza ca cineva care il stie atat de bine sa ii prezinte avantajele, altfel ar fi fost destul de probabil sa treaca pe langa mine neobservat.".
Perl ti-ar fi util daca ai avea de manipulat, filtrat, transformat volume mari de date, daca ai avea de facut multe treburi de administrare a sistemului de operare, in primul rand sub Mac/Linux, dar si sub Windows, si daca ai avea de creat site-uri web suficient de complexe pentru care ai avea nevoie de o mare flexibilitate, mai ales daca ai avea nevoie sa o faci pentru tine personal si nu ai face doar parte dintr-o echipa.
Alternative pentru acestea ar fi si Python si Ruby, cu unele avantaje in plus, dar si cu unele dezavantaje.
C#, Java, C/C++ ti-ar fi mult mai putin utile pentru asa ceva.
PHP ar fi util pentru creat pagini web, si daca il folosesti ca lumea, adica daca nu esti tipul de persoana caruia ii place sa il forteze compilerul sa scrie codul corect, poti crea si cu el programe destul de OK.
Cred ca poti banui ca programatorii de la Facebook sau Yahoo nu au intampinat problemele pe care le-a intampinat Vortex cu PHP-ul.
Insa cam atat poti face OK cu el, dar cu smuls par din cap uneori, pagini web. Daca ai nevoie si pentru altele enumerate mai sus, PHP nu este o solutie extraordinara.
Din ce programe am vazut ca ai creat tu, sincer ma indoiesc ca ai nevoie de Perl/Python/Ruby, asa ca cu siguranta ca nu ti le-as recomanda ca o alternativa.
"Sincer mi-ar placea un topic in care sa dam tot felul de exemple de cod, solutii etc, doar de pe forumuri se invata un procent destul de mare din ce tine de astfel de lucruri.".
Pe blindprogramming era o discutie cu multi ani in urma (am scris prima data "cu cativa ani", dar mi-am dat seama ca deja au trecut multi ani de atunci) in care Jamal Masrui a propus sa cream un program denumit "Fruits Basket" in diverse limbaje, in care sa existe un camp de editare in care trebuia sa scriem ceva, numele unui fruct de exemplu, sa existe o lista cu fructele adunate, si cu un buton "add" si unul "delete". Idea era simpla, trebuia sa adaugam si sa stergem elemente din acea lista.
S-au creat diverse variante, si in C++, si in Ruby, Python, ba chiar a creat cineva un programel interesant in assembly language. Ala in assembly era interesant, dar limbajul... cam nashpa dupa cum poti sa iti dai seama, desi assembly language putem spune ca vizual este cel mai elegant limbaj.
Ala in assembly avea doar vre-o 2kb daca imi aduc bine aminte.
Alea in limbajele dinamice aveau peste 1mb fiindca includeau si interpretorul, adica cam cum e cand trebuie sa incluzi si JVM in kitul de instalare pentru un program in Java, ca sa functioneze pe o masina pe care nu exista Java.
Eu am creat o versiune in Perl folosind biblioteca Win32::GUI si o alta versiune care folosea biblioteca grafica WxPerl. Si Jamal a mai creat o versiune cu WxPerl si au mai folosit altii si alte limbaje.
Eu am creat si o aplicatie web care facea acelasi lucru doar ca cu o interfata Web. Cineva a adunat apoi programele si le-a inclus pe un site pe undeva, poate se pot gasi daca cauti dupa "fruits basket", insa stiu ca unele dintre ele s-au pierdut intre timp si nu au mai fost adunate acolo.
Cred ca nici acea versiune in Perl cu interfata web nu a fost pusa acolo, fiindca cum publicul tinta era din orbi, din motive de accesibilitate ei erau interesati sa preia un program pe care sa il poata rula cu un enter, nu pe care sa il ruleze sub un server web.
Insa programele erau foarte simple, caci practic nu faceau mare lucru, ci doar manevrau vre-o doua trei elemente de interfata.
Pe de o parte ar putea fi utile ca sa iti dai seama cam cum arata un limbaj fiindca te poate atrage respectivul limbaj, dar pe de alta parte te poate induce in eroare fiindca daca un limbaj de programare sau o clasa grafica sunt bune pentru un program micut, nu inseamna ca este la fel de bun pentru unul mare.
De exemplu, programul pe care l-am facut eu cu clasa grafica Win32::GUI arata super fain si are un cod foarte clar si usor de inteles si de catre incepatori care nu stiu Perl deloc.
Este in mod evident mult mai frumos decat cel care foloseste clasa WxPerl. Insa problema este ca biblioteca Win32::GUI nu mai este intretinuta, nu suporta Unicode decat in anumite controale si doar cu un anumit hack, nu ofera la fel de multe controale ca WxPerl, si evident, poate rula doar sub Windows, in timp ce programul care foloseste WxPerl poate rula si sub Mac sau Linux.
Iar cand ai de facut chestiuni mai complicate, de exemplu un sistem complex de meniuri, sau o interfata in mai multe limbi, este mai bun WxPerl, care insa la prima vedere pare mai urat decat Win32::GUI.
Asa ca de asta este bine sa existe liste de discutii unde sa poti intreba specialistii si sa ii crezi cand spun ceva, fiindca sigur ei stiu cel mai bine.
Eu nu i-am crezut!
La inceput de exemplu nu am invatat sa folosesc un sistem de template-uri, si nici vorba de un web framework iar despre procesoare de formulare cred ca nici nu auzisem, desi existau si atunci. Asa ca am creat primul site web intr-un mod foarte low level, cam cum sunt create majoritatea site-urilor in PHP.
Doar ca nu mi-a placut, asa ca am testat cateva sisteme de templating, si am vazut ca folosirea lor era mai lenta decat simpla includere a unor variabile in codul html, asa ca m-am apucat si am creat propriul meu sistem de template-uri, care era mai rapid decat alte sisteme standard.
Doar ca pe masura ce imbunatateam acel site, ba lipsea una, ba alta din sistemul meu de templat-uri, si la modul simplist in care era gandit, nici nu se puteau adauga acele facilitati.
Asa ca m-am gandit ca poate ce scriu cartile si ce spun specialistii nu sunt totusi minciuni, asa ca m-am apucat sa invat complicatul sistem de template-uri Template-Toolkit.
Si m-am mirat cand am vazut ca nu mi-a trebuit decat o singura zi ca sa invat sa il folosesc, si ca de fapt din cat timp lua afisarea unei pagini, incluzand preluarea datelor din baza de date, munca pe care o facea sistemul de template-uri era oricum nesemnificativa, deci pierderea de viteza chiar nu era importanta, insa facilitatile oferite erau infinit mai multe iar codul mult mai elegant.
Apoi am descoperit ca cu un web framework este si mai simplu si mai elegant de lucrat, ca se pot folosi multe elemente standard etc.
Dar pot sa iti spun ca nu mi-a parut rau ca am apucat acea cale, creandu-mi propriul sistem de template-uri, fiindca intre timp am invatat foarte multe altele cu care nu prea ai de a face daca lucrezi doar cu elemente de nivel inalt.
Asta inseamna ca chiar nu ai inteles nimic din ce am discutat pana acum sau cu rea vointa spui ca eu am spus ceea ce nu am spus.
In primul rand nu am spus niciodata ca doar linia de comanda este buna.
Ba chiar dimpotriva, ti-am spus ca eu nu folosesc un editor in linia de comanda, ci programe cu interfata grafica, si inca sub Windows.
Ba chiar am spus si despre limbajele de programare, ca pentru anumite domenii sunt de preferat cele ca Java/C# si nu PHP/Perl/Ruby/Python.
Sau ma insel?
De asemenea, nu am spus niciodata ca open source este superior, fiindca ar fi o generalizare prosteasca.
Anumite programe open source sunt mai bune decat altele proprietare in anumite domenii si mai proaste in alte domenii, asa ca depinde de ceea ce ai nevoie.
Si cred ca nu ai inteles gresit asta, fiindca am spus de multe ori ca preferinta pentru un limbaj sau program depinde de nevoile fiecaruia.
Nu am spus nici ca Windows e nashpa in toate privintele, ci am aratat care sunt punctele lui slabe.
"IonPop: Mie afirmatia ta legata de visual studio nu mi s-a parut legata de discutia anterioara cu linia de comanda. Eu am raspuns strict legat de programarea grafica, aratand ca este posibila si utilizata atat de vazatori, cat si de nevazatori. de Cazurile de utilizare pe care le-ai mentionat nu am avut nevoie niciodata, asa ca nu pot vorbi despre ele.".
Atunci inseamna ca ai facut, probabil neintentionat, o greseala stupida care pe mine ma enerveaza intotdeauna, raspunzand la o problema de genul "este greu sa fac un program care sa faca cutare lucru" cu un raspuns de genul "pai atunci fa-te avocat".
Pe unele liste de discutii apare cateodata cineva care arata o bucata de cod si care spune ca nu ii functioneaza OK, ca are cutare probleme cu respectivul program, si apare cineva care ii spune ceva de genul "Aa, folosesti Windows? Pai ala e un sistem nashpa. Foloseste Linux si va functiona OK programul".
De parca asta chiar ar fi o solutie. Poate ca cel care a pus intrebarea are un intreg sistem din care acel program este doar o mica particica, si probabil ca el are cunostinte in lucrul sub Windows si cu respectivul limbaj pe care le-a dobandit in multi ani, si vine unul sa ii spuna ca exista o alta solutie, de a folosi Linux, doar fiindca a aparut o singura problema intr-un program.
Exact asta ai facut tu cand am aratat cateva din neajunsurile Windows-ului legate de linia de comanda, iar tu imi recomanzi sa folosesc un sistem bazat pe interfata grafica, de parca asta ar fi o solutie.
Si asta doar fiindca linia de comanda din Windows nu are atat de multe facilitati ca cea din Linux/Mac.
Ce sa fac cu un program care are interfata grafica daca el trebuie sa ruleze automat la anumite ore prestabilite, sa preia date dintr-o baza de date, sa le proceseze si sa le introduca intr-o alta baza de date si sa le trimita apoi spre un alt program care sa le proceseze din nou si sa le trimita prin email? Asta ca un exemplu, desi exista nevoi mult mai complexe de atat.
La ce ar folosi o interfata grafica? Cum ar trebui sa trimit parametrii automat catre program daca nu ca parametrii in linia de comanda?
Daca spui ca nu ai avut niciodata nevoie de cazurile despre care am spus, atunci cum poti sa sti ca pentru asa ceva utilizarea unor programe cu interfata grafica este o alternativa?
Nu este bine sa vorbesti si sa le recomanzi altora ceva despre care spui ca nu sti, fiindca ii induci in eroare.
"Cazul tau cu sollo programmer este in minoritate, indraznesc sa afirm ca multi nevazatori pot fi interesati de programare pentru a avea o cariera intr-o firma, de aia am mentionat clar ca eu nu ma refer la costurile dezvoltarii personale, ci la programare in general, angajat sau acasa, fara restrictii. Strict tehnologie.".
Cred ca e cam nonsens ce ai spus mai sus, sau nu am inteles eu bine?
Ai spus "nu ma refer la costurile dezvoltarii personale", dar apoi si "angajat sau acasa".
Pai daca exista si varianta "acasa" atunci ea se refera strict la o dezvoltare in scop cat se poate de personal, fiindca banuiesc ca nu te referi la dezvoltarea acasa, dar intr-o echipa.
Si imi pare ca faci si prezumtii fara sa fi in cunostinta de cauza.
Si eu lucrez intr-o firma unde folosesc tot Perl, si am creat cu Perl si programe care ruleaza automat fara o interfata grafica, si programe pe care le rulez in linia de comanda, si programe cu interfata grafica folosite de clienti, de colegii de la contabilitate, si doua site-uri web ale firmei.
Dar tot datorita posibilitatii de a rula programele in linia de comanda si de la distanta, am putut si sa lucrez o perioada de la distanta pentru o firma dintr-o alta tara, ceea ce nu ar fi fost posibil daca as fi putut folosi doar o interfata grafica.
Si tot datorita posibilitatii de a lucra in linia de comanda pot si sa administrez un site de la distanta, un site care nu costa la fel de mult ca unul pe care as rula Windows.
Deci posibilitatea de a lucra in linia de comanda si facilitatile oferite in acest sens de sistemul de operare sunt importante, fiindca interfata grafica nu este o solutie pentru toate cum vrei tu sa arati.
Este cat se poate de bine ca din August ai un job la Reea, si eu personal ma bucur ori de cate ori un programator orb isi gaseste de lucru in Romania, fiindca inseamna ca trendul este de acceptare a orbilor in acest domeniu, si este foarte bine ca acolo poti folosi DotNet, dar cred ca ar trebui sa ai o atitudine mai deschisa si sa nu consideri ca doar ce ai invatat tu la scoala este cool, iar restul nu este bun doar fiindca tu nu ai avut nevoie si nu ai lucrat cu altceva dupa cum ne-ai spus.
"Tu zici:
"
Eu nu sunt firma nationala sau internationala care sa aiba fonduri mari pentru gazduire si nici nu am nevoie de un limbaj super standardizat pe care sa il poata intelege usor un incepator, ca sa nu am probleme cand vreau sa angajez noi membrii in echipa si sa imi fie usor sa ii gasesc, si ieftin, ci am nevoie de un limbaj in care pot programa cat de rapid posibil, eu singur si cu care sa pot crea programe a caror gazduire costa cat de putin posibil, iar Dotnet nici nu intra in discutie pentru asa
"
Eu iti zic ca afirmatiile tale cum ca doar firmele mari, alea internationale, cu fonduri, care au nevoie de limbaje standadizate, au nevoie de DotNet, sunt enormitati, iar tu vii si te comporti ca si cum eu, nu tu, as fi zis ca doar firmele mari au nevoie de DotNet, si iti alegi strategic firme mari care nu folosesc.".
In primul rand tu ai spus: "Zici ca DotNet nu e solutie pentru ca nu e portabila sub Linux, iar gazduirea pe Windows nu e rentabila. Eu, si toate firmele nationale si internationale care fac hosting si development pe Windows, te contrazic."..
Iar eu ti-am spus ca eu nu sunt firma nationala sau internationala.
Mi-ar fi placut sa vad mai multe exemple de site-uri ale unor persoane fizice care folosesc DotNet, ca o dovada ca gazduirea sub Windows si cu DotNet este rentabila si pentru ele, fiindca altfel comparam mere cu pere.
Eu iti spun de ce consider ca Windows are o problema pentru mine personal, iar tu imi spui ca exista alte solutii folosite de firme nationale si multinationale.
Iar in al doilea rand, nu am ales strategic acele firme, ci am ales cele mai mari firme in domeniul iT, si se pare ca ele nu prea folosesc DotNet.
Insa tot nu ne-ai dat exemple de alte firme importante in domeniul iT care sa foloseasca DotNet...
"
Poti enumera cateva limbaje din acestea... "multe"?
Bineinteles, in afara de PHP, despre care... mai bine sa nu vorbim.
"
)
Asta e tare. E ca si cum ai zice zi-mi si mie ce au facut nazistii rau, dar sa nu cumva sa imi pomenesti de tigani si evrei.
Php e principalul reprezentant al limbajelor astea dinamice, eel e cel mai important. Probabil e chiar cel mai folosit limbaj din lume, deci, statistic, oamenii au cea mai mare sansa sa se loveasca de problema asta la el. Asta e filosofia limbajelor dinamice, te lasam sa faci tu ce vrei, ca sa faci mai repede. Daca ai facut o tampenie, nasol tata, descurca-te.De acord, sunt jde mii de extensii si chestii care se pot folosi daca vrei sa ai un standard, dar problema e ca nu se folosesc. Si ai de lucrat cu codul unuia care a scris si stie el in capul lui ce se intapmla si cum, dar cand vezi codul nu intelegi nimic. La strong dyping nu o sa intalnesti niciodata asa ceva. Oricat ai vrea, nu poti obscura un program. Compilatorul te forteaza sa fii clar, ca sa inteleaga oricine ce ai vrut sa faci acolo.
Am scris cod in php, python si javascript, si in toate am avut o gramada de erori din cauza asta.
In Lua e la fel cu variabilele null, si nici javascript nu sta prea bine.".
Inseamna ca nu ai avut de corectat prea mult cod in Java scris de altii, ca sa vezi cat de standard este...
Daca programul foloseste doar clase si metode din distributia standard a limbajului si cunosti bine limbajul, atunci exista sanse ca programul sa fie OK, mai ales daca si structura programului este una standard, doar ca cod in DotNet si Java se poate scrie si fara DotNet sau Eclipse, si programatorul isi poate structura cat de ciudat se poate programul.
Daca in schimb se folosesc si alte clase nestandard create de diverse firme, atunci poti sa ai si mai multe batai de cap.
Cu alte cuvinte, poti sa scri prost programe in orice limbaj, avand o importanta mica pentru intelegerea codului faptul de a defini sau nu tipul variabilelor.
Gandeste-te doar logic. Presupune ca ai un program in C#/Java in care toate variabilele sunt de acelasi tip, fiindca probabil ca doar de asa ceva ai nevoie, si ca programul e doar un test, ca nici nu preia date din afara si nici nu trimite data in alta parte.
Crezi ca daca ai cunoaste la fel de bine un limbaj dinamic si acel program ar fi scris in respectivul limbaj l-ai intelege mai greu, doar fiindca tipul variabilelor nu este definit, stiind totusi ca toate sunt de acelasi tip?
Iti spun eu care este diferenta. Problema este flexibilitatea. Limbajele dinamice sunt mult mai flexibile decat cele statice, si poti face mult mai usor lucruri mult mai complexe, intr-un tip mult mai scurt si cu mult mai putin cod.
Dar asta poate insemna bucati de cod miraculoase care chiar daca au doar 3 linii, pot sa te puna in incurcatura si sa foloseasca diverse smecherii pe care nu le sti ca incepator.
Cand cunosti insa suficient de bine limbajul, nu mai ai probleme in a le intelege, chiar daca ele folosesc diverse metode sau functii din alte module care nu sunt in distributia standard a limbajului.
Asa ca este pur si simplu o chestiune de preferinte. Unii prefera sa scrie o gramada de cod pana se plictisesc, dar acel cod sa fie cat se poate de standard, iar altii prefera sa poata scrie mai putin cod care sa faca mai multe lucruri.
Cand scri mai mult cod exista insa si sanse mai mari sa faci greseli, dar ambele preferinte sunt cat se poate de normale.
Dupa cum spuneam, cei care prefera matematica prefera de obicei ca totul sa fie cat se poate de clar si standard, si in multe facultati de informatica predau in primul rand profesori de matematica, si sunt urmate de studenti care au fost buni la matematica, asa ca este foarte normal ca multi programatori sa prefere acest stil.
Larry Wall, cel care a creat limbajul Perl nu a fost matematician, ci lingvist, deci probabil ca observi diferenta.
Nici eu nu am absolvit o facultate de informatica asa ca nu am fost ghidat sa prefer un limbaj sau altul, ci le-am testat si pe unele si pe altele, si am preferat productivitatea mai buna a limbajelor dinamice.
"Orice ar zice oricine, tu o tii pe a ta: perl e cel mai bun (chit ca are market share infim de 0.7%).".
Mda, se pare ca din nou spui ca as fi spus ceva ce eu nu am spus.
Am spus ca nici un limbaj nu este bun pentru orice si fiecare are avantajele si dezavantajele lui. Am ajuns sa enumeram limbajele doar fiindca tu ai inceput sa spui ca exista alternative pentru linia de comanda, ceea ce este o limitare, nu o alternativa. Si am amintit si am dat exemple despre cum se fac anumite lucruri in Perl pentru a arata ca anumite conceptii despre limbajele dinamice nu sunt adevarate.
Ba chiar am spus si pentru ce anume nu este bun Perl si alte limbaje dinamice.
Si in plus pot sa iti spun ca exista multe alte dezavantaje ale lui...
"interfetele grafice sunt ineficiente".
Depinde la ce te referi prin "ineficiente". Daca te referi la viteza de operare, atunci depinde de program.
Anumite programe, cum ar fi editoarele de text, jocurile, sunt mult mai potrivite pentru o interfata grafica. Exista si jocuri in linia de comanda, si editoare de text, dar cel putin mie nu imi plac, fiindca lucrez mai greu cu ele decat cu o interfata grafica.
In cazul altor programe, linia de comanda nu doar ca este mai buna, ca in cazul acelor scurte comenzi cu care poti inlocui didiverse texte in mai multe fisiere folosind regular expressions, fiindca in mod evident este mult mai rapid de facut decat sa creezi un program cu interfata grafica care sa faca asa ceva, dar si pentru a concatena mai multe programe care sa isi execute fiecare partea sa, dar in anumite cazuri este singura solutie ca in cazul programelor care trebuie sa ruleze fara nici o interfata, in mod automat, sau de la distanta etc.
Daca te referi la eficienta din punct de vedere financiar, atunci diferra in functie de cat trebuie sa platesti pentru ele.
"si profesionistii adevarati folosesc consola".
Este mai simplu de utilizat anumite comenzi decat sa faci acelasi lucru cu o interfata grafica, insa este mult mai dificil de invatat sa utilizezi programe in linia de comanda, fiindca trebuie sa ai multa experienta, sa sti la ce se folosesc fiecare, ce parametrii accepta, cum le poti combina etc.
Asa ca daca sti sa folosesti bine programele in linai de comanda inseamna in mod evident ca ai o experienta mult mai mare decat altcineva care stie sa foloseasca bine interfata grafica. Sau nu esti de acord?
"windows e naspa ca sistem de hosting".
Da, asta in mod evident este adevarat, fara nici o discutie.
Si nu stiu de ce mai insisti daca tu spui ca tu nu ai experienta in administrarea unui sistem de la distanta, ca sa poti sa iti dai seama de diferente.
Ti-am spus, ca si costurile financiare sunt mai mari, si accesibilitatea pentru orbi este mai redusa, si resursele consumate sunt mai mari care pot implica costuri in plus etc.
"doar linux e bun.".
Ca o afirmatie generala iar spui ce nu am spus. Deja pot spune ca minti cu nerusinare si cu rea vointa, si chiar nu prea cred ca este doar o neintelegere.
Linux este mai bun decat Windows daca costurile cu resursele si cu licentele sunt importante, si asta pentru servere web si de baze de date, dar in nici un caz pentru lucrul de zi cu zi.
Si am spus cred de cateva ori ca pentru lucrul de zi cu zi si eu folosesc Windows. Crezi ca as folosi Windows daca as crede ca "doar Linux este bun" cum pretinzi ca as fi spus?
Sau nu este voie sa aducem nici o invinuire sistemului de operare Windows in nici un domeniu nici chiar in partile lui slabe?
"Cand vine cineva si iti zice ca mai exista si altceva, ca unii prefera aia pentru ca x, tu arati de ce x e praf si, again, doar perl rules.".
Nu era vorba despre Perl, ci despre linia de comanda de sub Windows care e proasta, si este absolut neimportant ca mai exista si altii care prefera altceva fiindca ei au alte nevoi si ca preferintele lor sunt bune pentru nevoile lor, nu pentru ce au nevoie cei care folosesc linia de comanda.
Sau vrei sa spui ca toate bazele de date de la MySQL, PostgreSQL, SQLite, sunt niste prostii si ca toata lumea ar trebui sa foloseasca doar programele create de Microsoft?
Spun asta fiindca toate acele baze de date pot fi accesate in linia de comanda, iar variantele de a le accesa cu o interfata grafica implica probleme de accesibilitate pentru orbi, iar daca linia de comanda ar trebui inlocuita cu o interfata grafica ar implica sa nu le mai putem folosi.
Asa ca spun din nou ca este o prostie acest mod de a arata ca solutia pentru o problema este de a schimba total si sistemul de operare si limbajul de programare, si stilul de programare, doar fiindca crezi tu ca Windows si o interfata grafica este o solutie pentru toate, iar cand iti arat pentru ce anume nu este o solutie, spui ca tu nu sti ca cu asa ceva nu ai avut de a face.
"Cum am mai zis, singurul motiv din care ma contrazic cu tine pe aici e in caz ca vede cineva interesat si crede ca ai dreptate si chestiile astea old school sunt singurul mod de a programa pentru un nevazator.".
Sti tu ca exista o zicala "dialog al surzilor". Cred ca ceva de genul asta este si discutia noastra.
Ti-am pus cateva intrebari dar ai sarit peste toate.
Asa ca din nou... Am spus eu ca doar in modul in care programez eu se poate programa?
Am spus ca fiecare isi are nevoile lui, si nu orice nevoi pot fi rezolvate la fel de usor prin folosirea unei interfate grafice, iar altele nu pot fi rezolvate deloc de o interfata grafica. Cred ca daca s-ar fi putut, Microsoft ar fi renuntat la command.com, nu ar fi introdus si cmd.exe ba chiar si PowerShell.
"Adevarul e ca putem programa cam in orice, destul de eficient. Daca vreti sa alegeti o platorma, cititi, invatati despre ele, hotarati-va ce vreti sa faceti cu ele. Nu va bazati pe o singura opinie, ori a cui ar fi.".
Sigur ca da, de programat putem programa in aproape orice, insa de administrat programele respective este mai simplu in anumite feluri si mai complicat in altele, dar stiu, despre administrare nu vrei sa vorbim fiindca tu nu ai experienta in asa ceva.
Or daca tot vorbim despre linia de comanda, atunci ei bine ea nu are nimic de a face cu programarea efectiva, fiindca in linia de comanda poti rula si programe in C# si programe in Java, ci rularea unui program tine de partea de administrare, iar administrarea nu o poti face intotdeauna printr-o interfata grafica.
Unii orbi isi pot gasi de lucru la o firma, ca mine sau ca tine, dar si noi si altii putem sa lucram si altceva la care avem nevoie de acces de la distanta unde nu putem accesa o interfata grafica, si nu vad de ce ar trebui sa ne limitam posibilitatile de a lucra care si asa sunt putine.
@Manu: "Pai nu cred ca neaparat trebuie inchis subiectul, pana la urma din el se pot si invata lucruri.".
Cand eram incepator in Perl, aveam mult mai mult timp liber si obisnuiam sa pun intrebari pe listele de discutii din care ieseau adevarate razboaie.
Rezultatul era ca dupa asemenea discutii imi faceam multi dusmani virtuali, insa puteam afla o multime de lucruri foarte utile si interesante pe care nu le-as fi putut gasi nici citind 10 carti de Perl.
Asta fiindca expertii in Perl isi alocau timp sa explice pe larg anumite chestiuni mai ciudate doar cand ii rodeau nervii.
"Daca IonPop sustine Perl... e ca si cum cei fani Apple sustin iPhone, nu cred ca isi vor lua toti iPhone, eu de exemplu nu imi cumpar.".
Eu nu sustin Perl, ci doar am aratat cum se face cutare si cutare lucru in Perl ca sa elimin opiniile gresite despre limbajele dinamice, insa cred ca iti dai seama ca fiindca cunosc acest limbaj cel mai bine, despre el am mai multe nemultumiri decat despre alte limbaje.
Sti tu cum sunt intrebati copiii de adulti... "tie ce materie iti place?".
Ei bine, la scoala si in liceu si in facultate adevarul este ca mie nu imi placea nici o materie, asa pur si simplu.
Imi placeau anumite chestiuni de la o materie, altele de la alte materii etc. Evident, aveam anumite materii pe care le preferam ceva mai mult si altele pe care le uram ceva mai mult, dar nu am putut sa impart niciodata ceva doar in alb si negru, adica ca cutare lucru imi place, iar cutare nu.
In general imi placeau materiile la care nu trebuia sa invat, adica pe cele la care daca eram atent in clasa, era suficient si nu trebuia sa mai pierd timpul citind iar si iar acasa. Asta probabil fiindca nu am o memorie foarte buna, asa ca nu sunt bun la tocit, ci imi place acele lucruri pe care trebuie sa le judeci, nu sa le tii minte.
Poate de asta prefer acum si limbajele de programare care folosesc de obicei nume scurte pentru functii si clase, in care trebuie sa scri putin cod care face multe, fiindca nu e nevoie nici de prea multa memorie, si si de aceasta data nu trebuie sa pierd prea mult timp cu ele.
In domeniul iT cred ca e cam la fel, adica pot enumera dezavantaje si avantaje la toate sistemele de operare pe care le cunosc cat de cat, si la toate bazele de date, si la toate limbajele de programare cu care am lucrat cat de cat, asa ca nu pot sa recomand unul doar fiindca din intamplare eu il cunosc mai bine decat altele.
Dar ce imi pare mie o opinie de clasa intai este parerea ca trebuie sa folosim ce foloseste majoritatea, si asta in toate domeniile, nu doar in domeniul iT.
Imi pare de exemplu o stupizenie sa chiar crezi in povestile crestinesti doar fiindca locuiesti intr-o tara in care a fost impus crestinismul in mintea majoritatii, fara sa te gandesti cum ar fi fost daca ai fi fost infiat de o familie din India, sau China, sau Africa unde majoritare sunt cu totul alte religii. Oare si atunci ai fi avut aceeasi parere? Probabil ca nu, iar daca esti o persoana nascuta cu nevoia de a crede in divinitati, care are nevoia sa stie ca in lume totul este stabilit, ca exista un destin pentru fiecare, ca dupa moarte sigur trebuie sa existe ceva, atunci probabil ca ai fi aderat cu mare bucurie si incredere la una dintre religiile locale si poate nici nu ai fi auzit despre povestile crestinesti, si ai fi crezut in reincarnare si nu intr-o viata de apoi, ai fi crezut in karma si nu in destin etc.
Eu cred ca este mult mai normal sa consideram ca absolut tot ce exista pe pamant, bune sau rele din punctul nostru de vedere, sunt cat se poate de normale, iar daca citim istoria putem vedea ca asa a fost intotdeauna.
Nu exista un bine general sau un rau general, ci fiecare vede binele si raul in functie de nevoile personale, de mediul in care traieste si este cat se poate de normal sa acceptam ca nu exista o singura solutie pentru orice in niciun domeniu, evident, nici in domeniul iT, unde asta este chiar mai simplu de demonstrat.
"Nu stiu nici de Perl daca ma voi apuca, dar conteaza ca cineva care il stie atat de bine sa ii prezinte avantajele, altfel ar fi fost destul de probabil sa treaca pe langa mine neobservat.".
Perl ti-ar fi util daca ai avea de manipulat, filtrat, transformat volume mari de date, daca ai avea de facut multe treburi de administrare a sistemului de operare, in primul rand sub Mac/Linux, dar si sub Windows, si daca ai avea de creat site-uri web suficient de complexe pentru care ai avea nevoie de o mare flexibilitate, mai ales daca ai avea nevoie sa o faci pentru tine personal si nu ai face doar parte dintr-o echipa.
Alternative pentru acestea ar fi si Python si Ruby, cu unele avantaje in plus, dar si cu unele dezavantaje.
C#, Java, C/C++ ti-ar fi mult mai putin utile pentru asa ceva.
PHP ar fi util pentru creat pagini web, si daca il folosesti ca lumea, adica daca nu esti tipul de persoana caruia ii place sa il forteze compilerul sa scrie codul corect, poti crea si cu el programe destul de OK.
Cred ca poti banui ca programatorii de la Facebook sau Yahoo nu au intampinat problemele pe care le-a intampinat Vortex cu PHP-ul.
Insa cam atat poti face OK cu el, dar cu smuls par din cap uneori, pagini web. Daca ai nevoie si pentru altele enumerate mai sus, PHP nu este o solutie extraordinara.
Din ce programe am vazut ca ai creat tu, sincer ma indoiesc ca ai nevoie de Perl/Python/Ruby, asa ca cu siguranta ca nu ti le-as recomanda ca o alternativa.
"Sincer mi-ar placea un topic in care sa dam tot felul de exemple de cod, solutii etc, doar de pe forumuri se invata un procent destul de mare din ce tine de astfel de lucruri.".
Pe blindprogramming era o discutie cu multi ani in urma (am scris prima data "cu cativa ani", dar mi-am dat seama ca deja au trecut multi ani de atunci) in care Jamal Masrui a propus sa cream un program denumit "Fruits Basket" in diverse limbaje, in care sa existe un camp de editare in care trebuia sa scriem ceva, numele unui fruct de exemplu, sa existe o lista cu fructele adunate, si cu un buton "add" si unul "delete". Idea era simpla, trebuia sa adaugam si sa stergem elemente din acea lista.
S-au creat diverse variante, si in C++, si in Ruby, Python, ba chiar a creat cineva un programel interesant in assembly language. Ala in assembly era interesant, dar limbajul... cam nashpa dupa cum poti sa iti dai seama, desi assembly language putem spune ca vizual este cel mai elegant limbaj.
Ala in assembly avea doar vre-o 2kb daca imi aduc bine aminte.
Alea in limbajele dinamice aveau peste 1mb fiindca includeau si interpretorul, adica cam cum e cand trebuie sa incluzi si JVM in kitul de instalare pentru un program in Java, ca sa functioneze pe o masina pe care nu exista Java.
Eu am creat o versiune in Perl folosind biblioteca Win32::GUI si o alta versiune care folosea biblioteca grafica WxPerl. Si Jamal a mai creat o versiune cu WxPerl si au mai folosit altii si alte limbaje.
Eu am creat si o aplicatie web care facea acelasi lucru doar ca cu o interfata Web. Cineva a adunat apoi programele si le-a inclus pe un site pe undeva, poate se pot gasi daca cauti dupa "fruits basket", insa stiu ca unele dintre ele s-au pierdut intre timp si nu au mai fost adunate acolo.
Cred ca nici acea versiune in Perl cu interfata web nu a fost pusa acolo, fiindca cum publicul tinta era din orbi, din motive de accesibilitate ei erau interesati sa preia un program pe care sa il poata rula cu un enter, nu pe care sa il ruleze sub un server web.
Insa programele erau foarte simple, caci practic nu faceau mare lucru, ci doar manevrau vre-o doua trei elemente de interfata.
Pe de o parte ar putea fi utile ca sa iti dai seama cam cum arata un limbaj fiindca te poate atrage respectivul limbaj, dar pe de alta parte te poate induce in eroare fiindca daca un limbaj de programare sau o clasa grafica sunt bune pentru un program micut, nu inseamna ca este la fel de bun pentru unul mare.
De exemplu, programul pe care l-am facut eu cu clasa grafica Win32::GUI arata super fain si are un cod foarte clar si usor de inteles si de catre incepatori care nu stiu Perl deloc.
Este in mod evident mult mai frumos decat cel care foloseste clasa WxPerl. Insa problema este ca biblioteca Win32::GUI nu mai este intretinuta, nu suporta Unicode decat in anumite controale si doar cu un anumit hack, nu ofera la fel de multe controale ca WxPerl, si evident, poate rula doar sub Windows, in timp ce programul care foloseste WxPerl poate rula si sub Mac sau Linux.
Iar cand ai de facut chestiuni mai complicate, de exemplu un sistem complex de meniuri, sau o interfata in mai multe limbi, este mai bun WxPerl, care insa la prima vedere pare mai urat decat Win32::GUI.
Asa ca de asta este bine sa existe liste de discutii unde sa poti intreba specialistii si sa ii crezi cand spun ceva, fiindca sigur ei stiu cel mai bine.
Eu nu i-am crezut!
La inceput de exemplu nu am invatat sa folosesc un sistem de template-uri, si nici vorba de un web framework iar despre procesoare de formulare cred ca nici nu auzisem, desi existau si atunci. Asa ca am creat primul site web intr-un mod foarte low level, cam cum sunt create majoritatea site-urilor in PHP.
Doar ca nu mi-a placut, asa ca am testat cateva sisteme de templating, si am vazut ca folosirea lor era mai lenta decat simpla includere a unor variabile in codul html, asa ca m-am apucat si am creat propriul meu sistem de template-uri, care era mai rapid decat alte sisteme standard.
Doar ca pe masura ce imbunatateam acel site, ba lipsea una, ba alta din sistemul meu de templat-uri, si la modul simplist in care era gandit, nici nu se puteau adauga acele facilitati.
Asa ca m-am gandit ca poate ce scriu cartile si ce spun specialistii nu sunt totusi minciuni, asa ca m-am apucat sa invat complicatul sistem de template-uri Template-Toolkit.
Si m-am mirat cand am vazut ca nu mi-a trebuit decat o singura zi ca sa invat sa il folosesc, si ca de fapt din cat timp lua afisarea unei pagini, incluzand preluarea datelor din baza de date, munca pe care o facea sistemul de template-uri era oricum nesemnificativa, deci pierderea de viteza chiar nu era importanta, insa facilitatile oferite erau infinit mai multe iar codul mult mai elegant.
Apoi am descoperit ca cu un web framework este si mai simplu si mai elegant de lucrat, ca se pot folosi multe elemente standard etc.
Dar pot sa iti spun ca nu mi-a parut rau ca am apucat acea cale, creandu-mi propriul sistem de template-uri, fiindca intre timp am invatat foarte multe altele cu care nu prea ai de a face daca lucrezi doar cu elemente de nivel inalt.
- Manu
- General de divizie
- Mesaje: 4120
- Membru din: 02 Feb 2007, 01:15
- Localitate: Cluj-Napoca
- Contact:
Da, am vazut candva acea pagina cu exemplele Fruit Basket in diverse limbaje, printre ele si cel in Perl care era parca facut cu WX Widgets. Acela chiar rula standalone, am adaugat si am scos itemi din list view.
De asemenea am deschis chiar si codul din Assembly, si alte limbaje.
Imi pare rau ca nu mai este acea pagina, eu am vazut-o acum vreo 2 ani cand inca nu intelegeam anumite lucruri. Acum mi-ar fi placut sa vad daca nu era si un cod in Java cu Swing.
Continuu schimband putin subiectul, daca tot mergem inainte cu discutiile, poate Andreea care se pricepe mai bine la facut splituri de topicuri va muta de la un punct unde se rupe de Ce e nou in JAWS mesajele in alt subiect dedicat programarii.
Vreau sa ating o alta problema destul de delicata in legatura cu interfetele grafice.
Intre timp ma mai uit peste Java, incerc sa imi creez solutii cat mai convenabile pentru alinierea si apoi mutarea dintr-o data a butoanelor mai sus sau mai jos, mai la stanga sau mai la dreapta.
Sunt curios cam cat de eficienti ati fost voi cand ati creat o interfata grafica facand masuratori. Eu am tot facut si in general imi ieseau aliniate si incadrate butoanele, doar ca un ochi poate spune ca parca ar trebui mai sus sau mai jos un sir de butoane sa zicem.
Am ajuns la concluzia ca daca tot vreau sa zicem vreo 5 butoane unul sub altul care au de exemplu inaltimea de 40 si vreau sa las intre ele 20 pixeli, este mai usor sa pun la parametri care specifica in cazul de fata coordonata Y, valori dintr-un array umplut inainte cu coordonate y intr-un for.
Asta am vazut ca imi trebuie pentru ca intreb pe cineva: cum arata si imi spune: punele pe toate cu 20 de pixeli mai jos. Atunci repede sa ma apuc sa schimb la toate butoanele numarul adaugand 20.
Astfel, avand un array:
int[] yValues = new int[5];
Apoi avand variabila yValue=20, asta insemnand valoarea pentru primul buton, distanta de la top edge al ferestrei principale, am facut:
In urma rularii forului, array-ul va avea valorile:
20, 80, 140, 200, 260.
Astfel la parametru punem pentru primul buton:
yValues[0], pentru al doilea yValues[1] etc.
Vallorile sunt din 60 in 60 pentru ca butoanele sunt de 40 si am vrut 20 de pixeli intre ele.
Cand vreau repede ca toate butoanele sa se mute mai jos cu 10 pixeli, schimb prima valoare a lui yValue la 30 si se genereaza in array-ul pentru parametri ce tin de coordonata Y valorile 30, 90, 150, 210, 270.
De asemenea, daca as vrea brusc ca distanta intre butoane sa fie doar de 10 pixeli, as schimba doar randul yValue+=60 cu yValue+=50.
Mi se pare ca prin trucuri de felul acesta s-ar putea cumva usura munca pentru crearea interfetei de catre nevazatori, cel putin pentru a fi usor de modificat la finisaj alaturi de cineva care vede. Sa muti mai sus, mai jos, mai la stanga mai la dreapta schimband doar cate o valoare pe ici pe colo.
Nu stiu altfel cum se descurca nevazatorii, decat muncind enorm, schimband de zeci de ori numere la parametrii metodelor de genul setLocation()..
Daca ar fi o solutie de a utiliza un editor de interfata... ar fi altceva, dar nu prea vad cum pentru ca si cu acela tot ar trebui sa vina cineva sa confirme ca e totus ok, nu au fost omisiuni., oricate masuratori am face si oricat de solida ar fi logica si rigoarea, ceva tot poate scapa, cel putin faptul ca vizual distanta cutare intre buutoane pare ciudata.
Cred ca daca cineva ar scrie o carte cu titlul:
Practici, stiluri in aranjamentul elementelor GUI, ar fi super. Sa o scrie in genul:
Nu stiu cat au mai vorbit nevazatorii despre astfel de probleme in alte locuri, poate ca deja lucrurile sunt stabilite dupa discutii lungi, se stie ca trebuie munca si gata sau ca fiecare are metodele lui, dar totusi, din experienta altora se poate invata foarte mult.
De asemenea am deschis chiar si codul din Assembly, si alte limbaje.
Imi pare rau ca nu mai este acea pagina, eu am vazut-o acum vreo 2 ani cand inca nu intelegeam anumite lucruri. Acum mi-ar fi placut sa vad daca nu era si un cod in Java cu Swing.
Continuu schimband putin subiectul, daca tot mergem inainte cu discutiile, poate Andreea care se pricepe mai bine la facut splituri de topicuri va muta de la un punct unde se rupe de Ce e nou in JAWS mesajele in alt subiect dedicat programarii.
Vreau sa ating o alta problema destul de delicata in legatura cu interfetele grafice.
Intre timp ma mai uit peste Java, incerc sa imi creez solutii cat mai convenabile pentru alinierea si apoi mutarea dintr-o data a butoanelor mai sus sau mai jos, mai la stanga sau mai la dreapta.
Sunt curios cam cat de eficienti ati fost voi cand ati creat o interfata grafica facand masuratori. Eu am tot facut si in general imi ieseau aliniate si incadrate butoanele, doar ca un ochi poate spune ca parca ar trebui mai sus sau mai jos un sir de butoane sa zicem.
Am ajuns la concluzia ca daca tot vreau sa zicem vreo 5 butoane unul sub altul care au de exemplu inaltimea de 40 si vreau sa las intre ele 20 pixeli, este mai usor sa pun la parametri care specifica in cazul de fata coordonata Y, valori dintr-un array umplut inainte cu coordonate y intr-un for.
Asta am vazut ca imi trebuie pentru ca intreb pe cineva: cum arata si imi spune: punele pe toate cu 20 de pixeli mai jos. Atunci repede sa ma apuc sa schimb la toate butoanele numarul adaugand 20.
Astfel, avand un array:
int[] yValues = new int[5];
Apoi avand variabila yValue=20, asta insemnand valoarea pentru primul buton, distanta de la top edge al ferestrei principale, am facut:
Cod: Selectaţi tot
for(int i=0; i<yValues.length; i++) {
yValues[i]=yValue;
yValue+=60;
}
20, 80, 140, 200, 260.
Astfel la parametru punem pentru primul buton:
yValues[0], pentru al doilea yValues[1] etc.
Vallorile sunt din 60 in 60 pentru ca butoanele sunt de 40 si am vrut 20 de pixeli intre ele.
Cand vreau repede ca toate butoanele sa se mute mai jos cu 10 pixeli, schimb prima valoare a lui yValue la 30 si se genereaza in array-ul pentru parametri ce tin de coordonata Y valorile 30, 90, 150, 210, 270.
De asemenea, daca as vrea brusc ca distanta intre butoane sa fie doar de 10 pixeli, as schimba doar randul yValue+=60 cu yValue+=50.
Mi se pare ca prin trucuri de felul acesta s-ar putea cumva usura munca pentru crearea interfetei de catre nevazatori, cel putin pentru a fi usor de modificat la finisaj alaturi de cineva care vede. Sa muti mai sus, mai jos, mai la stanga mai la dreapta schimband doar cate o valoare pe ici pe colo.
Nu stiu altfel cum se descurca nevazatorii, decat muncind enorm, schimband de zeci de ori numere la parametrii metodelor de genul setLocation()..
Daca ar fi o solutie de a utiliza un editor de interfata... ar fi altceva, dar nu prea vad cum pentru ca si cu acela tot ar trebui sa vina cineva sa confirme ca e totus ok, nu au fost omisiuni., oricate masuratori am face si oricat de solida ar fi logica si rigoarea, ceva tot poate scapa, cel putin faptul ca vizual distanta cutare intre buutoane pare ciudata.
Cred ca daca cineva ar scrie o carte cu titlul:
Practici, stiluri in aranjamentul elementelor GUI, ar fi super. Sa o scrie in genul:
Am dat un exemplu la intamplare, probabil ca si arata destul de urat asa, de aceea am creat posibilitatea sa modific usor, cel putin dedicat pentru codul la care lucrez acum in Java cu Swing.Pentru o aplicatie simpla cu 4 butoane, care face convertiri de text, o interfata in regula ar fi cu o fereastra principala de 400 pe 300 pixeli, butoanele fiind aranjate in linie, orizontal, la 20 de pixeli fata de top edge. Un buton arata in regula daca are marimea 80 pe 40 si distanta intre ele este de 20.
Nu stiu cat au mai vorbit nevazatorii despre astfel de probleme in alte locuri, poate ca deja lucrurile sunt stabilite dupa discutii lungi, se stie ca trebuie munca si gata sau ca fiecare are metodele lui, dar totusi, din experienta altora se poate invata foarte mult.
Ultima oară modificat 12 Sep 2013, 23:47 de către Manu, modificat 1 dată în total.
Errare humanum est, sed perseverare diabolicum...
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
Banuiesc ca te referi la crearea unei interfete grafice in care butoanele si celelalte elemente ale interfetei sa fie repozitionate si eventual redimensionate automat in momentul in care utilizatorul redimensioneaza fereastra activa. Sau am inteles gresit?
Facilitatile pentru asta depind de biblioteca grafica folosita pentru crearea interfetei. Bineinteles, poti face si calcule manuale, si sa calculezi pozitii in functie de marimea ferestrei, dar este mult de muncit, si poti gresi, si nu are rost din moment ce se poate altfel mai simplu.
Pentru programele create cu biblioteca grafica Win32::GUI, exista modulul Win32::GUI::GridLayout cu care toate elementele din formular pot fi pozitionate intr-un grid, care apoi in functie de atributele cu care este creat se poate redimensiona dupa dorinta.
Pentru programele create cu interfata WxPerl exista suport pentru mai multi asa numiti "sizers", care sunt niste layout managers, cel mai simplu dar cu care poti face tot ce vrei fiind cel numit BoxSizer.
Pe langa el mai sunt si altii, inclusiv unul numit GridSizer dar eu m-am multumit cu cel mai simplu si am putut face tot ce am vrut.
Idea folosirii lui este ceva in genul: Poti defini un sizer vertical care sa includa apoi in el alte sizere orizontale, iar fiecare sizer orizontal poate include in el unul sau mai multe elemente grafice. Sau poti folosi un sizer orizontal care sa includa in el mai multe sizere verticale care includ in ele unul sau mai multe elemente care apar unul sub altul.
Sau daca pur si simplu sa zicem ca ai doar o lista cu 5 butoane care apar unul sub altul, poti folosi doar un singur sizer vertical incluzand in el cele 5 butoane.
In functie de setarile fiecarui sizer poti face ca un anumit element sa isi mute pozitia cand formularul isi modifica dimensiunile, sau sa ramana fix, poti seta ca un anumit element sa isi modifice dimensiunile sau nu, iar daca si le modifica cu cat anume, adica poti face ca toate elementele sa se redimensioneze la fel sau unul mai mult decat altul, sau unul sa ramana fix etc.
De exemplu, daca ai un element eticheta in prima celula a unui sizer orizontal, iar in a doua celula ai un camp text pentru acea eticheta, s-ar putea sa vrei ca atunci cand se redimensioneaza fereastra campul cu eticheta sa ramana la fel de mare, dar campul text sa se mareasca, insa doar pe orizontala, nu si sa creasca in inaltime.
Insa in alta parte s-ar putea sa ai niste butone care sa vrei sa creasca si pe inaltime si pe latime cand creste formularul (desi nu prea se face asa ceva, ci de obicei doar li se schimba pozitia).
E mai mult de povestit decat de muncit, fiindca codul pentru crearea acelor sizere este foarte mic, insa nu cred ca te ajuta daca caut un astfel de cod si il pun aici, fiindca iti va fi absolut inutil in alte aplicatii care nu folosesc wxWidgets. Este asemanator doar intr-o aplicatie cu WxPerl, WxPython sau WxRuby, si evident, intr-una in C++ cu wxWidgets.
Cu aceste sizere se pot seta si diverse dimensiuni pentru margini goale, se pot seta ca anumite celule sa fie aliniate la stanga, dreapta, sus/jos etc.
De exemplu, daca ai un sizer orizontal cu o eticheta si cu un camp de text, s-ar putea sa vrei ca eticheta sa fie aliniata la stanga pentru ca indiferent cum se modifica formularul, partea ei dreapta sa fie intotdeauna langa marginea din stanga a campului de text.
Iar daca un sizer de nivel mai inalt include alte sizere, atunci el va manipula si aranja acele sizere ca si cum ele ar fi elemente grafice pe care le poate alinia la centru, sau la stanga, dreapta, etc.
Deci in concluzie nu trebuie sa faci nici un fel de calcule manuale fiindca le va aranja sizerul pe toate cum trebuie.
Sigur exista layout managers si pentru SWING, asa ca ar trebui sa cauti cu Google dupa swing layout managers.
Ca in orice domeniu ar putea parea mai complicat la inceput decat calculele manuale, si ai putea crede ca cu acele calcule vei pozitiona fix unde vrei tu controalele, insa cred ca totusi nu ar fi rau sa incerci.
Facilitatile pentru asta depind de biblioteca grafica folosita pentru crearea interfetei. Bineinteles, poti face si calcule manuale, si sa calculezi pozitii in functie de marimea ferestrei, dar este mult de muncit, si poti gresi, si nu are rost din moment ce se poate altfel mai simplu.
Pentru programele create cu biblioteca grafica Win32::GUI, exista modulul Win32::GUI::GridLayout cu care toate elementele din formular pot fi pozitionate intr-un grid, care apoi in functie de atributele cu care este creat se poate redimensiona dupa dorinta.
Pentru programele create cu interfata WxPerl exista suport pentru mai multi asa numiti "sizers", care sunt niste layout managers, cel mai simplu dar cu care poti face tot ce vrei fiind cel numit BoxSizer.
Pe langa el mai sunt si altii, inclusiv unul numit GridSizer dar eu m-am multumit cu cel mai simplu si am putut face tot ce am vrut.
Idea folosirii lui este ceva in genul: Poti defini un sizer vertical care sa includa apoi in el alte sizere orizontale, iar fiecare sizer orizontal poate include in el unul sau mai multe elemente grafice. Sau poti folosi un sizer orizontal care sa includa in el mai multe sizere verticale care includ in ele unul sau mai multe elemente care apar unul sub altul.
Sau daca pur si simplu sa zicem ca ai doar o lista cu 5 butoane care apar unul sub altul, poti folosi doar un singur sizer vertical incluzand in el cele 5 butoane.
In functie de setarile fiecarui sizer poti face ca un anumit element sa isi mute pozitia cand formularul isi modifica dimensiunile, sau sa ramana fix, poti seta ca un anumit element sa isi modifice dimensiunile sau nu, iar daca si le modifica cu cat anume, adica poti face ca toate elementele sa se redimensioneze la fel sau unul mai mult decat altul, sau unul sa ramana fix etc.
De exemplu, daca ai un element eticheta in prima celula a unui sizer orizontal, iar in a doua celula ai un camp text pentru acea eticheta, s-ar putea sa vrei ca atunci cand se redimensioneaza fereastra campul cu eticheta sa ramana la fel de mare, dar campul text sa se mareasca, insa doar pe orizontala, nu si sa creasca in inaltime.
Insa in alta parte s-ar putea sa ai niste butone care sa vrei sa creasca si pe inaltime si pe latime cand creste formularul (desi nu prea se face asa ceva, ci de obicei doar li se schimba pozitia).
E mai mult de povestit decat de muncit, fiindca codul pentru crearea acelor sizere este foarte mic, insa nu cred ca te ajuta daca caut un astfel de cod si il pun aici, fiindca iti va fi absolut inutil in alte aplicatii care nu folosesc wxWidgets. Este asemanator doar intr-o aplicatie cu WxPerl, WxPython sau WxRuby, si evident, intr-una in C++ cu wxWidgets.
Cu aceste sizere se pot seta si diverse dimensiuni pentru margini goale, se pot seta ca anumite celule sa fie aliniate la stanga, dreapta, sus/jos etc.
De exemplu, daca ai un sizer orizontal cu o eticheta si cu un camp de text, s-ar putea sa vrei ca eticheta sa fie aliniata la stanga pentru ca indiferent cum se modifica formularul, partea ei dreapta sa fie intotdeauna langa marginea din stanga a campului de text.
Iar daca un sizer de nivel mai inalt include alte sizere, atunci el va manipula si aranja acele sizere ca si cum ele ar fi elemente grafice pe care le poate alinia la centru, sau la stanga, dreapta, etc.
Deci in concluzie nu trebuie sa faci nici un fel de calcule manuale fiindca le va aranja sizerul pe toate cum trebuie.
Sigur exista layout managers si pentru SWING, asa ca ar trebui sa cauti cu Google dupa swing layout managers.
Ca in orice domeniu ar putea parea mai complicat la inceput decat calculele manuale, si ai putea crede ca cu acele calcule vei pozitiona fix unde vrei tu controalele, insa cred ca totusi nu ar fi rau sa incerci.
Apropos de site-ul FruitsBasket, poti descarca de la adresa urmatoare o arhiva cu acel site:
http://www.quantummyst.com/
Nu stiu al cui este acest site, dar apare acolo o poza cu numele de Sina, asa ca banuiesc ca este al lui Sina Bahram.
Nu stiu daca nu cumva chiar el a creat programul in Java cu SWING.
http://www.quantummyst.com/
Nu stiu al cui este acest site, dar apare acolo o poza cu numele de Sina, asa ca banuiesc ca este al lui Sina Bahram.
Nu stiu daca nu cumva chiar el a creat programul in Java cu SWING.
- Manu
- General de divizie
- Mesaje: 4120
- Membru din: 02 Feb 2007, 01:15
- Localitate: Cluj-Napoca
- Contact:
Multumesc pentru link am descarcat. Vad ca e totusi Java cu SWT, nu cu Swing.
Cat despre layouts, intr-adevar exista si in Swing.
Trebuie sa studiez problema, intr-adevar astfel se pot alinia altfel lucrurile, eu am mers pe setLayout(null), astfel incat se lucra cu pozitii absolute si in postul meu anterior ma refeream la modul in care scrii pozitii absolute si te bazezi ca fereastra va fi tot timpul utilizata la dimensiunea intentionata.
Intr-adevar, asta nu prea e o solutie, va trebui sa vad cu care e mai eficient, exista: FlowLayout, GridBagLayout, GroupLayout, SpringLayout. Am vazut ca se pot specifica pozitii cu parametri constante cu valori ca "north", "east", "south", "west" in GridBagLayout.
Trebuie sa vad exact ce si cum se intampla.
Pentru Pontes Millionaire a creat interfata cu editor Campus cu pozitii absolute, iar pe Quick Reading care era cu Windows API l-am facut doar cu meniu si casete de dialog, fiind un convertor nu era nevoie de butoane plasate in fereastra principala, asadar, chiar nu prea stiu cum stau lucrurile, care sunt cele mai eficiente, care sunt cele mai avantajoase practici pentru ceea ce imi trebuie.
Cat despre layouts, intr-adevar exista si in Swing.
Trebuie sa studiez problema, intr-adevar astfel se pot alinia altfel lucrurile, eu am mers pe setLayout(null), astfel incat se lucra cu pozitii absolute si in postul meu anterior ma refeream la modul in care scrii pozitii absolute si te bazezi ca fereastra va fi tot timpul utilizata la dimensiunea intentionata.
Intr-adevar, asta nu prea e o solutie, va trebui sa vad cu care e mai eficient, exista: FlowLayout, GridBagLayout, GroupLayout, SpringLayout. Am vazut ca se pot specifica pozitii cu parametri constante cu valori ca "north", "east", "south", "west" in GridBagLayout.
Trebuie sa vad exact ce si cum se intampla.
Pentru Pontes Millionaire a creat interfata cu editor Campus cu pozitii absolute, iar pe Quick Reading care era cu Windows API l-am facut doar cu meniu si casete de dialog, fiind un convertor nu era nevoie de butoane plasate in fereastra principala, asadar, chiar nu prea stiu cum stau lucrurile, care sunt cele mai eficiente, care sunt cele mai avantajoase practici pentru ceea ce imi trebuie.
Errare humanum est, sed perseverare diabolicum...
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
Eu cand am nevoie sa fac un programel mic cu scopuri limitate, de obicei nu ca mi-ar trebui mie, fiindca ce face acel program pot sa fac si cu un program care ruleaza in linia de comanda, si treaba se rezolva muuult mai rapid si mai flexibil fiindca pot adauga super rapid noi parametrii in linia de comanda, fara sa trebuiasca sa modific interfete etc, dar cand trebuie sa il foloseasca neprofesionisti, creez o fereastra de tip dialog care nu poate fi redimensionata, si atunci daca fereastra tot ramane fixa, nu am nevoie ca elementele grafice sa se poata muta automat si le pun dimensiunile si pozitiile hard-coded.
Folosesc de obicei campuri de text si etichete inalte de 20 de puncte si cu lungimi in functie de nevoi, in etichete verific ca marimea elementului grafic sa fie cat mai apropiata de cea a textului (ma rog, exista si multe exceptii), si gata.
Vezi ca in acea arhiva exista si un cod pentru FruitsBasket care foloseste SWING.
Sau cel putin incepe cu:
import javax.swing.DefaultListModel;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JList;
import javax.swing.JPanel;
import javax.swing.JTextField;
Folosesc de obicei campuri de text si etichete inalte de 20 de puncte si cu lungimi in functie de nevoi, in etichete verific ca marimea elementului grafic sa fie cat mai apropiata de cea a textului (ma rog, exista si multe exceptii), si gata.
Vezi ca in acea arhiva exista si un cod pentru FruitsBasket care foloseste SWING.
Sau cel putin incepe cu:
import javax.swing.DefaultListModel;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JList;
import javax.swing.JPanel;
import javax.swing.JTextField;
- Manu
- General de divizie
- Mesaje: 4120
- Membru din: 02 Feb 2007, 01:15
- Localitate: Cluj-Napoca
- Contact:
Intr-adevar l-am gasit cu greu, doar intr-un fisier EML.
Da este exact ceea ce imi trebuia. Sa vad cum a aranjat campul de editare, lista si cele doua butoane.
Vad ca a facut cu JPanels, a creat un panel la North, in el fiind edit-ul la East si lista la West.
La fel intr-un panel pus la sud a pus cele doua butoane la East, respectiv West.
Foarte logic si simplu cod, cred ca nu ar putea fi scris in altceva ca sa fie atat de clar la o simpla lectura.
In Windows API a durat la mine mult pana am inteles cum se creaza fereastra principala goala pentru care au fost necesare foarte multe randuri.
Swing-ul asta suna ca si cum ai scrie instructiuni cuiva cum sa deseneze treaba, iar utilizarea unor constante precum North, East etc ma uimeste, ma asteptam sa fie folositi parametri cu un sunet mai matematic, nu atat de textual.
Da este exact ceea ce imi trebuia. Sa vad cum a aranjat campul de editare, lista si cele doua butoane.
Vad ca a facut cu JPanels, a creat un panel la North, in el fiind edit-ul la East si lista la West.
La fel intr-un panel pus la sud a pus cele doua butoane la East, respectiv West.
Foarte logic si simplu cod, cred ca nu ar putea fi scris in altceva ca sa fie atat de clar la o simpla lectura.
In Windows API a durat la mine mult pana am inteles cum se creaza fereastra principala goala pentru care au fost necesare foarte multe randuri.
Swing-ul asta suna ca si cum ai scrie instructiuni cuiva cum sa deseneze treaba, iar utilizarea unor constante precum North, East etc ma uimeste, ma asteptam sa fie folositi parametri cu un sunet mai matematic, nu atat de textual.
Errare humanum est, sed perseverare diabolicum...
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
In forum linguae Latinae venite! (via est: www.limbalatina.ro)