Vyšel FreeBASIC 0.16

... ze existuje 32 bit kompilator, spis me prekvapilo, ze v tom nekdo jeste programuje:) ... je sice pravda vysledek: neni zavisly na vybranem programovacim jazyku, ale tu implementaci si uz dnes bez objektu, dedicnosti, apod neumim predstavit(!) ... a to si ty osmibity pamatuju a aktivne jsem basic pouzival, ale tenkrat se ty skutecne projekty stejne vytvareli primo v assembleru :) pamatujete jeste nekdo na uzasny programovaci nastroj prometheus od soft. 602 na ZX Spectru?

no to teda, prometheus bola pekna hracka.. vtedy... :-)

Nic ve zlem, ale predstavit si program bez objektu neumi pouze omezenec.
Ono se vubec kolem objektu vytvorila obrovska spousta mytu. Nejhorsi je ten, ktery pravi, ze bez nich nejdou delat velke projekty. Samozrejme jdou a vysledkem byva daleko efektivnejsi kod. Jenze to na tom musi delat programatori a ne lepici. Ziji dnes jeste vubec Programatori ? Snad ano. Koneckoncu jadro Linuxu je typickym prikladem velkeho projektu bez objektu.

Souhlasim, ze programovat bez objektu je mozne. Na druhou stranu objektove programovani, krome programovani samotneho s sebou prinasi i vyuziti CASE nastroju se kterymi je mozne mnohem efektivneji "napsat" univerzalni kod u ktereho pak programator jen pridava logiku k jiz vymyslenym objektum. Ty nastroje nebudou prilis prakticke pro software psany "do supliku", ale rozhodne je to silny nastroj pro predvadeni jeste nehotoveho produktu zakaznikovi.
Je jasne, ze vysledny kod nebude tak efektivni, jako kdyz se vse napise primo, nicmene mnohem snadneji se spravuji jednotlive casti programu, nehlede na to, ze programator dostava primo podklady k tomu, co ma vlastne programovat a nemusi se zabyvat otazkami typu co ma vlastne ten program delat.

myslim, ze sa unix programatori nehrnuli do OOP napriek osialu co kedysi okolo toho vznikol. ja si odjakziva chovam tiez urcitu nechut k OOP (viac ci menej racionalnu). a to ze sa lahsie spravuju jednotlive casti programu je hlupost. zly kod je zly kod, je jedno ci OOP alebo nie.

nie som ziaden expert cez OOP, ale podla toho co som cital, tak bolo racionalnymi argumentami podlozene, ze OOP ma len v niekolkych oblastiach zasadny naskok. vacsinou to je jedno, ci dokonca to moze projekt skomplikovat...

Omg, vsak treba spravne nastroje na spravne projekty. Niekde sa da pomocou oop usetrit kopec riadkov kodu, ked clovek trochu porozmysla. Niekde zasa treba objekty nasilu vymyslat.
Ked mam unixovu kniznicu, ktora sa velmi pohodlne pouziva a netreba okolo nej vela vymyslat, tak objekty su zbytocne. Niekde je nizkourovnovost velmi vyhodna.

Projekt v paradigme OOP sa zasa da stranu velmi krasne vizualizuvat. Ci uz pomocou CASE nastrojov, alebo v Duchu si predstavit program ako tovaren na susienky, ktore sa mozu rozvazat dodavkou, posielat na pase. Mozu byt cokoladove, vanilkove atd ... OOP mi prijde take viac hrave ale treba pri nom viacej predstavivosti a vediet lepsie pomenovat niektore veci. Co je niekedy dost narocne ... No dokaze dost vela manualneho kodenia usetrit.

Programujem v C, Jave a Pythone. Kazdy z nich ma svoje krasne a skarede vlasnosti.
Treba pouzit ten jazyk, ktory sa momentalne viac hodi, podla toho ci chceme sa menej namakat, vacsiu efektivitu, alebo podla toho, co kolega lepsie ovlada ...(Alebo co sa viacej paci sefovi :) )

Absolutni souhlas !

Uz dlouhou dobu vedu s jednim dis drsnou debatu na tema OOP. A ten clovek nejak nedokaze pochopit ze
1) objektovy kod v soucasne dobe stejne kompilator prevadi na neobektovy, nebot stale nemame OOP procesory ze :D
2) neveri obektovosti GTK+ - coz je krasny priklad takoveho objektoveho neobjektoveho programovani ;)
3) nechape ze pro nekoho je dulezitejsi efektivita kodu a ne .. ehmm prehlednost, resp. si nedokaze predstavit ze by kod mohl byt prehledny a snadno spravovatelny i bez OOP.

Na druhou stranu muj odpor ke splacanemu kodu uz zacina otupovat, kdyz vidim jak i tam, kde by se melo ladit na co nejvyssi vykon, se to proste dozene zelezem ;(

Nesouhlas souhlasu;-)

Dlouhou dobu jsem programoval čistě v C, ale v C++ mám prostě více možností. Nepoužívám RTTI ani exceptions a chápu tento jazyk jako jazyk s nativní podporou objektů, který je stejně efektivní jako C.

ad 1)
- to máte pravdu, objekt je vlastně jen struktura která _může_ mít tabulku virtualních funkcí.

ad 2, 3)
- Myslím že se stačí podívat do zdrojáků GTK+ a zjistíte, že GTK+ není vůbec psané pro rychlost. Říct, že píšu efektivně pod GTK+ je podle mě nesmysl.

Pokud bude C++ použito jako vrstva nad C kódem, tak souhlasím, že efektifita výsledku bude menší (viz třeba GTK+ a GTKmm), ale pokud udělám nativní kód přímo v C++, tak to nelze tvrdit.

Takže na závěr bych jen napsal, že efektivita kódu záleží na člověku, který jej píše...

Ještě na druhý závěr jsem se zamyslel a troufnu si napsat, že efektivně je napsané třeba WinAPI. Nemám pravdu? (no flame)

Dobry clanok :) lol

Omyl, Prometheus je od firmy Proxima. Dodnes ho pouzivam, ked neco na Spektraci kodujem.

Prometheus rozhodně nebyl od Soft. 602. Prometheus prodávala Proxima v.o.s. a napsal ho Universum.

Viz. manuál a programátorská příručka
http://ci5.speccy.cz/docs/prometheus.php
http://softhouse.speccy.cz/docs/ASMaZXS1.htm
http://softhouse.speccy.cz/docs/ASMaZXS2.htm

tie knizky boli v tom case bibliou rovnako ako je teraz Stevens...

Prometheus jsem používal. Neudělal ho Soft602, ale Proxima.

Ukládal zdrojový kód ve zkomprimovaném tvaru. A měl geniální debugger, který uměl emulovat instrukce a kontrolovat, zda nepřistupují do nedovolené paměti --- takže pak programy místo zatuhnutí padaly na segfault :)

A to na procesoru, který nemá žádnou správu paměti.

Když už BASIC, tak jedině a pouze Blitz Basic - http://www.blitzbasic.com/

Takový projekt přece spotřebovává nemalé množství úsilí, tak nevím, zda je to k něčemu dobré...
...není to plýtvání časem šikovných vývojářů?

Jakejch vyvojaru ? Myslis ty prasata co kodujou vistu ?