Php ca prim limbaj de programare?

[ozzy]

Rog scuzati-mi offtopicu' da' php-ul nu e un punct bun de pornire daca am chef sa ma apuc de programare ?

[~Empathy~]

Nu.

[tcalexander]

Începi cu Pascal. Perl, Python, Ruby?

[~Empathy~]

C/C++.

[Praetor]

Daca vrei sa faci doar hobby (si am banuiala ca asta vrei) php e ok. Daca vrei sa inveti ceva mai mult dar trebuie sa studiezi serios te poti baga pe .NET, C# .

[Federals]

Cam asta recomand si eu. Desi se spune ca C/C++ ar fi cel mai recomandat pt incepatori (desi e f ugly), parca mai usor de invatat e un limbaj ca C# spre exemplu. E mai clean la prima vedere. Mai ales ca ajuta foarte mult framework-ul. Cauta niste carti pe torrente si fa niste comparatii. Si nu te uita la primele pagini, acolo pana si COBOL arata bine

[~Empathy~]

C#... .NET... bleah -- ma duc sa vomit si sa ma sinucid.

[Federals]

De ce esti tu asa "suparat" pe limbajul sau framework-ul asta? Baga niste dezavantaje

ozzy, vezi si ce am scris aici. reclama la chip

[LNT]

Mie mi se pare mult mai usor sa pornesti cu C#.NET decat cu C/C++.

[Federals]

Same here. Faptul ca e mai urat (C/C++) nu inseamna neaparat ca iti satisface toate nevoile de programare. Daca vrei sa dezvolti ceva RAD, C# e foarte bun. Plus ca iti duci softul foarte usor pe Web prin ASP.NET. Dar asta e doar un vs. intre limbajele de programare. El trebuie sa invete intai conceptele, ideile, samd. Dupa aia sa se axeze pe un limbaj pe care sa il invete foarte bine.

[~Empathy~]

Mie mi se pare mult mai usor sa pornesti cu C#.NET decat cu C/C++.

Mi se pare mult mai usor sa faci o prostie decat un lucru destep, sa lenevesti decat sa muncesti, sa te sinucizi decat sa traiesti etc, dar asta nu inseamna ca e si mai bine. De obicei orice lucru care are ca prin argument de "advocacy" faptul ca este simplu, este un lucru prost si mediocru.

O data ce stii sa faci lucruri complicate iti permiti sa faci si lucruri simple, invers insa -- nu.

[LNT]

Ei lasa ca nu-i chiar asa. In cazul asta orice bun programator ar trebui sa stapaneasca bine asm, ca doar e mai complicat si deci se va pricepe si la ceva mai simplu.
E parerea mea, dupa ce m-am chinuit sa invat c++ impins de amenintarea ca nu trec laboratorul (si l-am luat, dar nu pe merit 100%) iar cand a trebuit sa fac un proiect am ales singur C# pentru ca mi s-a parut a fi un limbaj mult mai lizibil si usor de folosit. Probabil ca sunt si putin subiectivist, insa cunostintele acumulate anterior erau minime.
Ce mi s-a parut absurd, ca in multe tutoriale/carti, gasesti foarte multe informatii despre cum sa faci lucruri complicate, dar descrieri extrem de succinte si incomplete pentru lucruri simple. MSND-ul e bun, dar nu se compara cu tutorialele de pe code project sau c-sharpcorner.

[Federals]

Pai de ce spui ca C# e prost sau mediocru? Intreb de curiozitate, nu e nicio ironie.
Sa zic cateva avantaje:
- Portabil cu ajutorul lui Mono si pe alte platforme;
- Portabil pe Web prin ASP.NET
- Usor de invatat (desi nu e chiar usor...se pot face lucruri si foarte complicate cu el, am sa iti dau exemple cand termin cartea )
- Poti folosi si pointeri la nevoie, deci nu e un limbaj limitat
- Indirect il dezvolta foarte mult .NET Framework, cu fiecare versiune care apare (adica poti cu acelasi limbaj sa faci din ce in ce mai multe si sa target-ezi multe tehnologii)
- E type safe si pur OO (zic pur pt ca totul se mosteneste din System.Object)
- Poate sa interactioneze foarte usor cu celelalte limbaje .NET
- E din ce in ce mai cautat pe piata, iar Microsoft a "simtit" asta si il va dezvolta mai departe (practic asta va fi viitorul programarii Windows in urmatorii ani, pana se descopera/face ceva mai bun)
- Se aseamana foarte mult la sintaxa cu Java si C++, deci cei cu background in asa ceva migreaza usor catre C#

Dezavantaje:
- Aparent e mai lent (desi Jitter isi face treaba bine si chiar optimizeaza), pt ca e managed, decat programele scrise in C/C++
- Ca sa iti ruleze aplicatiile scrise in .NET iti trebuie framework-ul, care e maricel, dar oricum deja in Vista e inclus. Chiar si pe XP sunt putini care nu il au instalat.

Deocamdata atat, revin cu detalii in caz ca mai gasesc avantaje/dezavantaje.

[LNT]

Avantajele enumerate nu prea conteaza (deloc) la cerinta data (un prim limbaj...).
Bine, o singura exceptie. 

- Usor de invatat (desi nu e chiar usor...se pot face lucruri si foarte complicate cu el, am sa iti dau exemple cand termin cartea )

[~Empathy~]

Aici nu discutam despre limbajul X vs. Y, ci despre limbajul X vs. Y ca prim limbaj pentru invatarea programarii. Oricum sa discuti despre X vs. Y in general e cam lame, si inutil.

Ideea cu ASM-ul nu este deloc adevarata -- a invata ASM este cam acelasi lucru cu a invata BASIC, doar seamana atat de mult... (vorbesc de BASIC, nu de Visual Basic si alte alea) ASM-ul are aplicabilitate extrem de limitata si este o tampenie sa incepi cu asa ceva.

Orice viitor code monkey stie sa implementeze un algoritm oarecare intr-un limbaj oarecare. In schimb programarea nu inseamna implementari de algoritmi, programarea inseamna gandire out of the box, programarea inseamna mai mult a stii sa citesti cod, decat sa scrii cod, inseamna code reuse, inseamna sa stii sa faci arhitectura la o componenta, deoarece oricine e in stare sa construiasca dupa un blueprint, programarea inseamna sa stii sa faci sisteme scalabile, programarea inseamna sa intelegi totdeauna ce se intampla in spate si de ce, programarea inseamna sa stii sa lucrezi in echipa, sa stii sa folosesti un SCM, sa scrii cod elegant in loc de cod scurt, programarea inseamna 80% external tools si doar 20% scris cod, deci trebuie sa iti stii toolurile, trebuie sa fi in stare sa iti scrii scripturi, trebuie sa fi in stare sa-ti implementezi un sistem de debug al aplicatiei, trebuie sa faci pentru fiecare aplicatie o suita de teste self-run (care fac parte din procesul de build) pentru certificare si pentru a testa todeauna aplicatia in orice conditie, trebuie sa stii sa faci deployment la aplicatie, trebuie sa stii mai degraba sa integrezi aplicatii existente intr-un mod inteligent in loc de a scrie aplicati noi etc, etc, etc. Astea sunt doar cateva.

Si atentie -- e o mare diferenta intre un programator, si un om care stie programare. Raportul e undeva pe la 1:10.

A incepe cu un limbaj OOP e o tampenie pentru ca trebuie sa intelegi runtime-ul din spate.

A incepe cu un limbaj interpretat e o tampenie pentru ca nu stii ce e aia compilare si cu ce se mananca ea in real life.

A incepe cu un limbaj cu referinte si pointeri inteligenti e o tampenie pentru ca nu o sa stii niciodata ce sunt aia pointeri, cum se folosesc si care e utilitatea lor.

A incepe cu un limbaj cu garbage collector e cea mai mare si trista tampenie pentru ca inseamna ca nu o sa stii niciodata si nici nu o sa intelegi de ce e nevoie de memory management intr-un limbaj care nu are asa ceva, si habar nu o sa ai ce e e aia stiva, heap la procesor -- nu o sa stii ce e aia securitate etc. A da, am uitat de securitate cand am zis de programatori.

A incepe cu un limbaj high level e o tampenie, daca stii un limbaj LL, poti oricand sa folosesti un limbaj HL, si stii tot ce presupune asta. Invers, nu. Eu pot sa ma apuc sa scriu cod Java in secunda 2 (nu stiu deloc Java), si o sa scriu cod foarte bun si profi, cineva care invata intai C# o sa fie totdeauna un programator C cel mult mediocru.

A scrie programe de 3 linii si lame, nu o sa va face niciodata programatori -- de fapt, puteti scrie orice -- nu o sa ajungeti programatori. Ca sa ajungeti programatori trebuie sa stiti sa cititi cod, si sa lucrati la un proiect deja existent. De exemplu la un proiect OSS. Si ca sa vedeti, majoritatea softului din ziua de azi e scris in C (nu C++), urmeaza C++, apoi Java, si abia apoi aberatii gen C# unde operatorul de rezolutie de de aparteneta sunt acelasi lucru. Cum poti sa inveti pe cineva asa o atrocitate? Un programator C++ va intelege totdeauna ca se face cod mai simplu in defavoarea codului confuz, dar un programator C# nu va stii niciodata ca de fapt sunt 2 chestii diferite si nu va intelege de ce in C++ e altfel si mai complicat decat cum stiau eu, cand de fapt asa e normal...

Sfaturi gratuite si filosofii nu ajuta nimanui. Scrieti cod.

[adilehanceanu]

[offtopic]
Man, eşti prea stresat, mai ia şi tu de pe net nişte supărări noi, ascultă-le, releaxează-te şi nu mai speria copiii 
[/offtopic]

[ozzy]

M-am apucat in graba de C++. Probabil dupa primele 3k linii de cod trec pe altceva, ca o sa vreau sa fac soafte care sa "dea" mai bine pe LCD

[Federals]

Ca sa iti faci o idee despre cele mai folosite limbaje sau tehnologii:

Life As a C/Win32 API Programmer
Traditionally speaking, developing software for the Windows family of operating systems involved
using the C programming language in conjunction with the Windows application programming
interface (API). While it is true that numerous applications have been successfully created using this
time-honored approach, few of us would disagree that building applications using the raw API is a
complex undertaking.The first obvious problem is that C is a very terse language. C developers are forced to contend
with manual memory management, ugly pointer arithmetic, and ugly syntactical constructs. Furthermore,
given that C is a structured language, it lacks the benefits provided by the object-oriented
approach (can anyone say spaghetti code?). When you combine the thousands of global functions
and data types defined by the Win32 API to an already formidable language, it is little wonder that
there are so many buggy applications floating around today.

Life As a C++/MFC Programmer
One vast improvement over raw C/API development is the use of the C++ programming language.
In many ways, C++ can be thought of as an object-oriented layer on top of C. Thus, even though
C++ programmers benefit from the famed "pillars of OOP" (encapsulation, inheritance, and polymorphism),
they are still at the mercy of the painful aspects of the C language (e.g., manual memory
management, ugly pointer arithmetic, and ugly syntactical constructs).
Despite its complexity, many C++ frameworks exist today. For example, the Microsoft Foundation
Classes (MFC) provide the developer with a set of C++ classes that facilitate the construction of
Win32 applications. The main role of MFC is to wrap a "sane subset" of the raw Win32 API behind a
number of classes, magic macros, and numerous code-generation tools (a.k.a. wizards). Regardless
of the helpful assistance offered by the MFC framework (as well as many other C++-based windowing
toolkits), the fact of the matter is that C++ programming remains a difficult and error-prone
experience, given its historical roots in C.

Life As a Visual Basic 6.0 Programmer
Due to a heartfelt desire to enjoy a simpler lifestyle, many programmers have shifted away from the
world of C(++)-based frameworks to kinder, gentler languages such as Visual Basic 6.0 (VB6). VB6 is
popular due to its ability to build complex user interfaces, code libraries (e.g., COM servers), and
data access logic with minimal fuss and bother. Even more than MFC, VB6 hides the complexities
of the raw Win32 API from view using a number of integrated code wizards, intrinsic data types,
classes, and VB-specific functions.
The major downfall of VB6 (which has been rectified given the advent of the .NET platform) is
that it is not a fully object-oriented language; rather, it is "object aware." For example, VB6 does not
allow the programmer to establish "is-a" relationships between types (i.e., no classical inheritance)
and has no intrinsic support for parameterized class construction. Moreover, VB6 doesn't provide
the ability to build multithreaded applications unless you are willing to drop down to low-level
Win32 API calls (which is complex at best and dangerous at worst).

Life As a Java/J2EE Programmer
Enter Java. Java is an object-oriented programming language that has its syntactic roots in C++. As
many of you are aware, Java's strengths are far greater than its support for platform independence.
Java (as a language) cleans up many unsavory syntactical aspects of C++. Java (as a platform)
provides programmers with a large number of predefined "packages" that contain various type
definitions. Using these types, Java programmers are able to build "100% Pure Java" applications
complete with database connectivity, messaging support, web-enabled front ends, and a rich
desktop user interface.
Although Java is a very elegant language, one potential problem is that using Java typically
means that you must use Java front-to-back during the development cycle. In effect, Java offers little
hope of language integration, as this goes against the grain of Java's primary goal (a single programming
language for every need). In reality, however, there are millions of lines of existing code out there in the world that would ideally like to commingle with newer Java code. Sadly, Java makes this
task problematic. While Java does provide a limited ability to access non-Java APIs, there is little
support for true cross-language integration.

Life As a COM Developer
The Component Object Model (COM) was Microsoft's previous application development framework.
COM is an architecture that says in effect, "If you build your classes in accordance with the
rules of COM, you end up with a block of reusable binary code."
The beauty of a binary COM server is that it can be accessed in a language-independent manner.
Thus, C++ programmers can build COM classes that can be used by VB6. Delphi programmers
can use COM classes built using C, and so forth. However, as you may be aware, COM's language
independence is somewhat limited. For example, there is no way to derive a new COM class using
an existing COM class (as COM has no support for classical inheritance). Rather, you must make use
of the more cumbersome "has-a" relationship to reuse COM class types.
Another benefit of COM is its location-transparent nature. Using constructs such as application
identifiers (AppIDs), stubs, proxies, and the COM runtime environment, programmers can
avoid the need to work with raw sockets, RPC calls, and other low-level details. For example, consider
the following VB6 COM client code:
' The MyCOMClass type could be written in
' any COM-aware language, and may be located anywhere
' on the network (including your local machine).
Dim obj as MyCOMClass
Set obj = New MyCOMClass ' Location resolved using AppID.
obj.DoSomeWork
Although COM can be considered a very successful object model, it is extremely complex
under the hood (at least until you have spent many months exploring its plumbing—especially if
you happen to be a C++ programmer). To help simplify the development of COM binaries, numerous
COM-aware frameworks have come into existence. For example, the Active Template Library
(ATL) provides another set of C++ classes, templates, and macros to ease the creation of COM types.
Many other languages also hide a good part of the COM infrastructure from view. However,
language support alone is not enough to hide the complexity of COM. Even when you choose a
relatively simply COM-aware language such as VB6, you are still forced to contend with fragile registration
entries and numerous deployment-related issues (collectively, and somewhat comically,
termed DLL hell).