[hfall-list] Limbajul in care programam "caderea ciocanului"

[Vlad Dogaru]

mihai maruseac wrote:
> M-am gandit perioada asta si am ajuns la o intrebare: "Ce limbaj de 
> programare vom folosi ca sa facem jocul?"
> 
> Dupa o perioada lunga de cugetare am ajuns la urmatoarele aspecte:
> 
> 1.Ne trebuie neaparat un limbaj de programare in care sa putem lucra pe 
> clase.
> Astfel avem variantele C++, Java sau C#. 

Sau Python. Sau multe altele...

> Tinand cont ca Java = C# 

Java = open source. C# nu. Conteaza? Eu zic ca da.

> din majoritatea aspectelor putem elimina Java mai ales ca C# devine tot mai 
> popular si ca putini vor sa-si instaleze masina virtuala Java dar mediul
> .NET se instaleaza de cat mai multi oameni. Avem .NET si pe Linux deci 
> nu putem spune ca a folosi C# e ceva not open source: DotGNU 
> (http://www.gnu.org/projects/dotgnu/) sau 
> Mono(http://www.mono-project.com/Main_Page).

Nicio implementare alternativa de .NET nu e inca stabila. Nici macar
pentru lucruri triviale, daramite pentru engine-uri 3D. Si ultima oara
cand m-am interesat (acum multa vreme si lipsit de detalii), era neclar
daca licenta Microsoft pentru .NET poate face posibila o implementare cu
adevarat FLOSS a runtime-ului. But that could have been just FUD.

> 2.Ne trebuie un limbaj care sa permita scrierea de cod modular si usor 
> de documentat. Aici cred ca facilitatea /// a C#-ului este foarte utila 
> (daca functioneaza si in Mono sau DotGNU) pentru ca permite generarea 
> documentitei foarte rapid si real-time uneori. Plus ca in C# nu trebuie 
> sa ne batem capul cu de-alocarea pointerilor si modul cum ii folosim 
> pentru ca se poate lucra in C# fara a-i utiliza.

`Facilitatea' similara se numeste Javadoc si exista lucruri asemanatoare
(noi am folosit Doxygen, care e multi-limbaj -- C, C++, Java, PHP
printre altele). Python are ceva care imi scapa si Haskell are Haddock.
Cam fiecare limbaj nou are o facilitate de autodocumentare.

> 3.Nu as vrea sa ne complicam cu cate doua fisiere pentru acelasi obiect. 
> Ma refer aici la organizarea fisierelor clasa din C++: .h si .cpp. In C# 
> totul e simplu, in acelasi fisier sunt si declaratii si cod.

E o chestie de gust, dar mie imi place sa fie antetele si/sau
documentatia separate de codu' stufos. Astfel cand scrii ceva _peste_ un
anumit strat, ii vezi numai API-ul, nu si implementarea.

> 4.In C++ cu OpenGL s-au mai scris jocuri, lumea evolueaza si se va 
> ajunge in curand la C#. Hai sa incepem si noi cu ceva nou.

De acord, C# e nou. Dar e Microsoft, e mare, e greoi.

> Cam atat am avut de spus despre limbajul in care vom programa engine-ul 
> si main-frame-ul jocului. Haskell nu stiu inca (daca exista vreo 
> sugestie pentru asa ceva), C++ pare depasit desi e instrumentul de 
> dezvoltare folosit traditional. Si pentru C# exista totusi dezavantaje:
> 
> 1.Daca vom scrie in C# numai cei care vor avea .NET, Mono sau DotGNU vor 
> putea rula jocul. Cred ca aici nu e o problema din moment ce Vista chiar 
> vine cu .NET preinstalat (daca stiu bine)

Exista 3 versiuni major de .NET. Asta ii cam anuleaza omniprezenta.

> 2.C# nu genereaza cod direct ci cod intermediar care e usor de spart. Va 
> trebui sa lucram putin si in codul intermediar ca sa blocam orice 
> reverse engineering (daca va fi nevoie). Daca e nevoie de asa ceva, e 
> mult mai usor de lucrat in cod intermediar decat in asembly.

De ce am bloca reverse engineering? E open source. Oricum, problema asta
apare si pentru Java, si pentru Python. Si, mai nou, am citit ca si Perl
adopta modelul cu masina virtuala incepand cu Perl 6 / Parrot.

> 3.Cu C# cam nu ne putem atinge de asembly.

Eu speram sa nu fie nevoie.

> 4.Exista zvonuri potrivita carora C# e mai putin performant ca timp de 
> executie. Am teta asta recent cu urmatorul program simplu: am generat in 
> 3 cicluri for numere pana la 100000, le-am inmultit si apoi am folosit 
> cate o rutina sa le descompuna in factori primi si sa calculeze radacina 
> patrata a numarului utilizand metoda newton. Diferenta intre C# si 
> standard C++ (not managed) a fost (in windows) de mai putin de 0,1% in 
> favoarea lui C#.
> Nu stiu de ce dar C++-ul a ramas in urma pe acest test.

Mi se pare ca testul asta nu e foarte graitor. Nu stiu de ce, dar
probabil diferentele se arata in alta parte. Cel putin pentru aplicatii
grafice (lucrurile pentru care a fost conceput C# IMO), tot ce merge
peste .NET mai mult sta decat merge.

> Deci, eu as prefera C#.
> 
> Un alt aspect care va veni mai tarziu dar trebuie luat acum in seama 
> este acesta: vom avea nevoie si de un fel de exteriorizare a codului ca 
> sa putem face profiling sau sa dezvoltam mai multe module de AI. Aici va 
> trebui sa folosim Python sau Lua dar nici unul din ele nu are inca 
> exemple in C#. 

Lua e super din punct de vedere al ideii, dar am citit ca exista mari
diferente intre API-urile versiunilor apropiate. Ceva in genul: 5.0 si
5.1 difera cam ca doua major-uri.

> La chestia cu exemplele nici cartile de game design sau 
> opengl nu au exemple in C#. Daca ramanem pe C# va trebui sa le portam. 
> Eu totusi prefer un mic overhead cauzat de portare decat zile si nopti 
> pierdute cautand o eroare mica din cauza unui pointer neinitializat cum 
> trebuie.
> 
> Concluzia: Prefer C# dar daca doriti altceva nu-i nici o problema. Cat 
> nu se ajunge la Fortran sau altele mai vechi accept orice. Voi invata si 
> Haskell daca vreti sa programati in asta.

Atitudinea e admirabila! Eu, de exemplu, doar imi dau cu parerea la
proiectul asta (deci ignorati fara frica tot ce am zis) tocmai pentru ca
nu vreau sa imi pierd timpul si nervii invatand un limbaj defect (ma
refer la C++, dar nici C# nu cred ca e prea departe).

Vlad

PS: Mihai, sper ca nu mi-o iei in nume de rau ca ti-am disecat post-ul.
Faptul ca nu sunt de acord cu cam tot ce ai spus nu inseamna ca te tai
cand te prind. Dar te tai >:)

PS2: Trimis a doua oară pentru că eu nu mă împac cu lista, se pare.