C ispred Jave po popularnosti?

Ovde je reč o elektrotehničarima (sa 2+2 časa programiranja nedeljno) a ne o matematičkoj gimnaziji. Oni takve stvari ne rade čak ni na takmičenjima.

Osim toga, probaj takav stav da izneseš u realnosti. Zaposli se ui školi, pa i u matematičkoj gimnaziji. I javi nam kako si prošao.

Na kraju poznavanje grafova (pa i Ojlerovog algoritma) ne povlači poznavanje bilo kojeg programskog jezika.

Ja ne pričam o školama u kojima se nešto uči samo da bi se učilo, nego o nekome ko hoće jednog dana da bude softerski inženjer.

A ovo oko grafova je totalno mašenje poente. No, od takih se više ne može očekivati.

Sposobnost da se Ojlerov algoritam, koji je dat, implementira u nekom programskom jeziku, polači poznavanje tog programskog jezika. Baš da vidim kako će bez dobrog znanja nekog programskog jezika neko da implementira u tom jeziku Ojlerov algoritam. Nigde nisam pominjao ni poznavanje grafova, ni Ojlerovog algoritma, već umenje implementacije, kada je on dat.

---

Pročitaj nastavne planove i programe pa nas obavesti kako i u kojoj školi ćeš implementirati Ojlerov algoritam.

O školama uopšte ne pričam, a Ojlerov algoritam je vrlo lako objasniti. Taj program bi se mogao raditi u bilo kojoj školi ili bilo gde drugde, pod uslovom da je nastava nekog programskog jezika ozbiljna. U moje vreme je nastava programiranja u srednjim školama bila ozbiljna. Odavno više nije ni u matematičkoj gimnaziji. Rade se banalne stvari uvijene u oblande.

---

uzmem pistolj i pucam sebi u nogu, greska je u mojoj glavi ne u nacinu na koji funkcionise pistolj.
c/c++ ti daju mnooogo ozbiljnije nacine da se upucas u nogu od i=i++;




krajnji nivo te automatizacije je sistem koji trosi 2-200 puta vise resursa nego sto je potrebno i radi 30 do 300000% sporije nego sto bi mogao samo zato da bi u slucaju pucanja sebi u nogu sistem to prepoznao i promasio nogu (i obicno napravio stetu na prozoru, ruci, ili komsiskom detetu posto taj ko zeli da se upuca u nogu ma koliko ga ti zatvarao u neki sandbox on ce naci nacin da napravi stetu).




mnogo ces lakse da "definises" koda koji masina moze da "razume" u jeziku nizeg nivoa. u jeziku viseg nivoa, posebno u raznim virtualnim kala... ti ne objasnjavas nista "masini" vec koristis stvari koje je vec neko objasnio (opet u C ili C++ a ne u tim virtualnim....) a pritom si ti vec deklarisan kao retardiran pa ti nije dozvoljeno da sam objasnis masini sta hoces nego si limitiran da koristis gotova resenja.


inace sto se ucenja programiranja tice ja lupam glavu time vec 6 godina radeci na jednom privatnom projektu .. vec sam 4-5 puta promenio misljenje .. logo, prolog, pascal/modula2 i nesto poput scratch-a .. trenutno mi je logo favorit i projekat ide u tom pravcu ali kao sto rekoh vec promenih misljenje vise puta .. no sad moram da ubrzam, klinac vec pregurao 9 meseci...

---

Po ovome se vidi da se bas i ne razumemo. Skocis sa zgrade i greska je u tvojoj glavi, ne u zgradi :) Recmo, ekvivalent bi bio, programiras aplikaciju kao photoshop, i namestis neki cache na FS i kada hoces da oslobodis cache, ti pozoves "format c:" :) Opet, greska je u tvojoj glavi, ne u "format c:". Ne znam da li primecujes, ali zar ne vidis koliko je neprimeren ovaj primer, posto o tome ja nisam sigurno govorio, posto ne mozes automatizovati sve a da nemas sve informacije. Automatizacija o kojoj ja pricam je ona kao recimo automatska kapija, stisnes dugme (ili senzor, zavisi od konteksta) ona se otvori, a ne da stalno izlazis iz auta, otvoris, zatvoris, ako bas hoces, habas i auto svaki put dodatno... O tome pricam, automatizujes tamo gde ima smisla, ne tamo gde je skoro ne moguce automatizovati jer je context veoma sirok, i za to ti treba strong Ai.




Prvo, kad trosi? Compile time li runtime? S tim, sto ovo compile time shvati malo sire, posto nije samo kompajler taj koji treba da radi, nego recimo i gomilu ostalih alata mozes tu da ubrojis koji spremaju code. Moje licno iskustvo upravo suprotno govori, vise automatizacije, bolji rezultati.

Drugo, moramo i razjasniti sta je automatizacija - za mene je to sve, bilo koji deo programa koji alat preuzima sa mene i na osnovu informacija koje ima i algoritma po kojem radi moze da odluci brze, bolje i preciznije od mene.

Trece, opet ne znam na sta ciljas kada kazes sporije, da li mislis samo na jezik? Jer ako jeste, onda se opet ne mogu sloziti a da ne kazes pre toga sta se resava, koje vrste aplikacje se pisu? Iz sveta desktop aplikacija (posto tu najvise radim) mogu ti reci da ako nesto lose radi nema veze sa jezikom per-se, nego isklucivo sa raznim nepotrebnim slojevima, API-ma, koji dolaze od samog/ih autora programa. To nema veze sa tim koji si programski jezik izabrao.




Na nizem nivou ne mozes nista da objasnis u vezi code-a. Jedino sto mozes da koristis za objasnjavanje code-a je type-system. I tu su ti manje-vise svi jezici koji imaju staticku analizu (samim tim i tipove) prilicno jednaki medju sobom.

Mislim da je stvar u kvantiteti i kvaliteti informacija koje dajes automatizaciji, na low levelu ima vise informacija koje su specificnije, na high levelu mnogo se stvari pretpostavlja i informacije su manje specificne.

Pazi, sada kada kazes tako, ja niti mogu reci da, niti ne. Sta ti je konkretno high level, a sta low level i koji domen resavas? Da li je assembler dovoljno low level i da li ti je bitno da bi izracunao procenat vlage u silosu u nekom biznis modelu to sto mozes da se igras sa Instruction Pointerom i premestas egzekuciju po volji?

Kapiram ja da treba da se automatizuju stvari koje ima smisla automatizovati. Međutim, ovde se pisalo o neemu sasvim drugom - da radnik ne treba ništa da zna, tj. da njega treba automatizovati.

Naravno da je poenta automatizacije u tome da mašina odmeni čoveka u nečemu, međutim, onda čovek radi druge stvari, koje se još ne mogu automatizovati, pa je ljudski rad u tom pogledu vremenom sve kreativniji i samim tim treba znati sve više, a nikako se manje. Ko hoće da radi na pokretnoj traci, treba da zna da takvih traka koje zahtevaju prisustvo čoveka ima sve manje.

---

ocigledno, ti si kao primer dao i=i++; i "koji persun postoji", ja na to kazem sto pucas sebi u nogu, meni je to odlicno poredjenje sa i=i++;




obzirom da je prica oko c-a ja mislim na runtime, sto se compile time tice nemam nikakav problem da kompajler potrosi malo vise vremena kada mu se upale sve optimizacije da bi napravio bolji kod. kod nekih jit kompajlera compile time moze da ima znacaj no iskreno ne koristim nista sa jit kompajlerom pa me ne tangira previse


ti si uveo taj termin i mislim da je pogresan u ovom kontekstu. svaka funkcija ili procedura ti je "automatizacija". realno svaka stvar tu mora posebno da se razmatra, kada je korisno da imas GC a kada nije (a ako hoces mozes da ga imas i u C-u nije nikakav problem) etc etc ... ono protiv cega se ja bunim je restrikcija programera zato sto se apriori ide sa tim da je programer retard. nemam ja problem da mi ti das funkciju za alokaciju memorije koja ce da na koji god nacin radi mem management i cisti zamnom i da ja nikad ne moram da radim free(), ali ako mi zabranis da ja mogu da radim free - hebo jezik ... ako ja znam da mi ova instanca vise ne treba, da mi vise nikad nece trebati nemoj me prcas da moram da cekam da gc dodje na red izbroji svoje potrosi cudo mudo cpu-a i opet odluci da izbaci iz rama nesto drugo a ovo ostavi za sledeci put ..



desktop aplikacije su uglavnom spore same po sebi, sporo se desavaju stvari, zavise previse od inputa pojedinacnog korisnika .. tu se razni ti problemi slabo vide, osim kada trcis na baterije, tada vrlo brzo primetis da neke aplikacije trose vise struje i vrlo brzo primetis sta je .not aplikacija a sta je native

---

Ne ja nisam nista navodio kao primer, nego je to odgovor na tvoj opasku:


Posto, ne pisu ljudi samo namerno tako nesto, nego i slucajno, i ja stvarno nemam nameru da za sve stvari koje znam da su lose se bavim analizom code-a kada to moze da radi kompjuter mesto mene. Naravno, svestan sam da ne mogu sve stvari da automatizujem, ali sto vise to bolje :)
Drugo, moj odgovor je ujedno bio generalan, ne samo na ovaj primer koji je ne znam ko naveo, za sve te stvari se uvek svodi na isto, ako znas kako nesto da automatizujes, tim bolje, nego da se smaras i ucis bespotrebne gluposti i sto je najgore, vecina tih stvari nema veze sa problemom koji resavas.




Ali ko ovde prica o C-u? Ti si stavio naglasak na "druge" jezike. Valjda su to svi osim C i C++-a. Tako da moje pitanje i jeste upuceno onda u tom contextu. Gde su ti jezici spori, compile ili runtime? Posto i mene bas briga za compile time, bitan je runtime. U runtime, ta usporenja o kojima pricas, kao sto sam vise puta rekao, mogu da dodju samo od losih resenja.

Samo da razjasnim, posto vidim da se vec par puta na tu stranu naginje, ja licno nisam dovodio u pitanje C++ (C je vec drugo, on je apsolutni sh*t, osim za sistemsko programirnanje) i da li je dobro imati vecu kontrolu (osim sto sporim da je ta kontrola sasvim nepotrebna za odredjene vrste aplikacije), nego se ne slazem sa tim stavom da su ostala resenja losa, kao sto nisu, nedostaci nisu u opste nedostaci zato sto to C++ ima a drugi jezici nemaju, jer bas to sto nemaju i jeste ciljano da nemaju kako bi uprostili resavanja domena za koji su namesteni.


Za drugi termin ne znam. Naravno da je i funkcija automatizacija, sve compile time greske su ti automatizacija.


Ne, nije to zato sto je programer retard, nego njegovo vreme kosta. I ti opet ne vidis siru sliku, ja sam vec naveo primer u saobracaju, lepo je to sto ti vidis kada tebi instanca ne treba i kada znas zasigurno, ali sta je kada ne znas? Tvoje vreme da ispratis gde se kad koja instanca koristi je skupo, i umesto da resavas biznis model, ti pocinjes da trosis resurse na nesto sto moze da se automatizuje i sto u opste nema tako lose performanse o kojima govoris.

Ne znam kako ne vidis to, ali zasto svi masovno ne predju na C++? Po tebi je to zasigurno zasto sto su svi retardi, sto je naravno daleko od istine. Razlog upravo lezi u trzistu, nece tebe niko cekati da ti namestis idealano optimizovan program ako neko ponudi program pre tebe koji radi. Vreme kosta, cije god da je.

nexygo,

Ja nemam ništa protiv pajtona/džave/.neta, već samo protiv lošeg programiranja i stava da je stručnost nepotrebna jer je "problem sortiranja rešen". Biblioteke rešavajz softverske probleme, koliko i kalkulator matematičke.

---

http://www.joelonsoftware.com/articles/APIWar.html


Automatic Transmissions Win the Day

Don't get me wrong... I think .NET is a great development environment and Avalon with XAML is a
tremendous advance over the old way of writing GUI apps for Windows. The biggest advantage of .NET
is the fact that it has automatic memory management.

A lot of us thought in the 1990s that the big battle would be between procedural and object
oriented programming, and we thought that object oriented programming would provide a big boost in
programmer productivity. I thought that, too. Some people still think that. It turns out we were
wrong. Object oriented programming is handy dandy, but it's not really the productivity booster
that was promised. The real significant productivity advance we've had in programming has been from
languages which manage memory for you automatically. It can be with reference counting or garbage
collection; it can be Java, Lisp, Visual Basic (even 1.0), Smalltalk, or any of a number of
scripting languages. If your programming language allows you to grab a chunk of memory without
thinking about how it's going to be released when you're done with it, you're using a
managed-memory language, and you are going to be much more efficient than someone using a language
in which you have to explicitly manage memory. Whenever you hear someone bragging about how
productive their language is, they're probably getting most of that productivity from the automated
memory management, even if they misattribute it.

Racing car aficionados will probably send me hate mail for this, but my experience has been that
there is only one case, in normal driving, where a good automatic transmission is inferior to a
manual transmission. Similarly in software development: in almost every case, automatic memory
management is superior to manual memory management and results in far greater programmer
productivity.

If you were developing desktop applications in the early years of Windows, Microsoft offered you
two ways to do it: writing C code which calls the Windows API directly and managing your own
memory, or using Visual Basic and getting your memory managed for you. These are the two
development environments I have used the most, personally, over the last 13 years or so, and I know
them inside-out, and my experience has been that Visual Basic is significantly more productive.
Often I've written the same code, once in C++ calling the Windows API and once in Visual Basic, and
C++ always took three or four times as much work. Why? Memory management. The easiest way to see
why is to look at the documentation for any Windows API function that needs to return a string.
Look closely at how much discussion there is around the concept of who allocates the memory for the
string, and how you negotiate how much memory will be needed. Typically, you have to call the
function twice—on the first call, you tell it that you've allocated zero bytes, and it fails with a
"not enough memory allocated" message and conveniently also tells you how much memory you need to
allocate. That's if you're lucky enough not to be calling a function which returns a list of
strings or a whole variable-length structure. In any case, simple operations like opening a file,
writing a string, and closing it using the raw Windows API can take a page of code. In Visual Basic
similar operations can take three lines.

So, you've got these two programming worlds. Everyone has pretty much decided that the world of
managed code is far superior to the world of unmanaged code. Visual Basic was (and probably
remains) the number one bestselling language product of all time and developers preferred it over C
or C++ for Windows development, although the fact that "Basic" was in the name of the product made
hardcore programmers shun it even though it was a fairly modern language with a handful of
object-oriented features and very little leftover gunk (line numbers and the LET statement having
gone the way of the hula hoop). The other problem with VB was that deployment required shipping a
VB runtime, which was a big deal for shareware distributed over modems, and, worse, let other
programmers see that your application was developed in (the shame!) Visual Basic.

Sidebar
Why does automatic memory management make you so much more productive? 1) Because you can write
f(g(x)) without worrying about how to free the return value from g, which means you can use
functions which return interesting complex data types and functions which transform interesting
complex data types, in turn allowing you to work at a higher level of abstraction. 2) Because you
don't have to spend any time writing code to free memory or tracking down memory leaks. 3) Because
you don't have to carefully coordinate the exit points from your functions to make sure things are
cleaned up properly.

Nedeljko,

Moj stav je naravno da je vise znanja bolje, ali kada se uzme u obzir kontekst gde se sta resava, onda se moram sloziti sa prethodnicima, nije potrebno da znas sta se desava ispod haube, posto ne resavas taj problem, recimo sortiranja nego resavas neki drugi problem gde je sortiranje samo deo resenja tog problema.

Ceveno: GC ne osobađa programera od razmišljanja o oslobađanju memorije. Samo ti drži statički pokazivač na objekat koji ti nije više potreban i nikakav GC ti ga neće uništiti. Problem upravljanja memorijom je za sada rešen samo delimično. GC ne pravi razliku između potrebnih i nepotrebnih objekata, već između dostupnih (tj. onih kojima se može pristupiti) i nedostupnih. Programiranjem bez razmišljanja se lako može postići da nikad nijedan objekat ne bude uništen, koliko god da je nepotreban.

Plavo: U deimično rešenje spada i stek, koji je implementiran i u C, pa nije prednost .Net-a.

---

Memory management je dosta kompleksan problem i za opsti slucaj neresev.

Slazem se, zato ga ne treba ni koristiti! Nema veze što nudi resenje za 99.99% slucajeva.

U slučaju lošeg programiranja on može vrlo lako da obriše 0% nepotrebnih objekata, a u slučaju dobrog programiranja, može da obriše 100% nepotrebnih objekata.

Knjige u kojima piše da programer sa GC-om ne mora više da brine o upravljanju memorijom su loše. U dobroj knjizi će pisati da on značajno olakšava posao čoveka smanjujući broj slučajeva u kojima se mora ručno intervenisati, ali da nikako nije čarobno rešenje za problem curenja memorije i navešće slučajeve koje treba uzeti u obzir.

Čuj, citiraš lika po kome OOP ne podiže produktivnost u pravljenju "desktop aplikacija" (koja može biti PhotoShop, AutoCAD, Maya...) jer nije čuo da postoji nešto iznad GUI programiranja.

---

GC je, kao i mnogo toga u našoj branši, mač sa dve oštrice, što kaže Nedeljko. Ima dobrih strana, kao što su closures (nisam siguran da neki jezik bez GC-a može ovo elegantno da implementira - ako može, pišite), circular references (što može biti rešeno i kroz shared i weak ptr, ali je fakat da je ovo lakše), ali ima i groznih strana kao što je moguće napisati program gde ništa nije dealocirano, a da misliš da jeste, ili u nekim jezicima gde GC nije na .NET-ovom nivou, može zaista ubiti performanse, pa većinu vremena moraš kodirati tako da ga što manje pokrećeš (u nekim jezicima se on pokreće u tačno određenim trenucima, npr. pri alokaciji objekta operatorom new), pa treba biti umeren prilikom davanja suda.

Međutim, Nedeljko mi je dao hint sa stekom i sad sam se zapitao - u "user interface" delu aplikacije na kojoj radim (C), ne sećam se da sam u poslednjih godinu dana i jednom napisao malloc/free - takve aplikacije je moguće pisati bez ikakve manuelne alokacije.

ne slazem se.
nemam ja problem za milion utl biblioteka koje nesto pomazu, trilion alata koji pomazu i ubrzavaju posao ... da sam imao valgrind pre 25 godina .. danas ne mogu da zamislim razvoj bez istog .. ne pricam ja o tome, ja pricam o tome da mi zabranis nesto zato sto ja time mogu da se upucam u nogu. meni je to idiotski, to je apriori posmatranje programera kao retarda... dakle nemam ja problem sa viskom funkcionalnosti, ja imam problem sa manjkom

---