Interesuje me koji bih programski jezik morao da naucim ako zelim da napisem program za racunovodstvo, koji radi u Windouzu, ima liniju komandi kao Exel, sa padajucim listama komandi. Normalno radi matemaicke operacije, sortira.

Java, C#...
nije za script jezike

ne razumem ovo sta je linaja komandi kao Excel


za AoP

Zasto? Ima odlicnih programa za knjigovodstvo napisanih skript jezicima.

pctel, na forum se odnosilo, ne na jezike..malo sam razbacao, desava se
ja sam predlozio C# ili Java-u obzirom da oce da radi na Windows-u

Ako bi postojali odlicni programi za knjigovodjstvo napisani u Assebly-u, da li bi to znacilo da je on dobar jezik za tu vrstu programa?

To sto oni postoje govori da je u skript jezicima moguce praviti ih, ne da su skript jezici obavezno i dobri za to.

za malu aplikaciju Access i VBA. za nešto ozbiljnije pretpostavljam .net ili Java uz neki DBMS.

Veb aplikacija za knjigovodstvo više uopšte nije loša ideja. A tu su skript jezici u najmanju ruku ravnopravni sa Javom i .NET-om.

web nije baš idealna platforma za knjigovodstvene aplikacije. razmisli
samo kako bi napravio funkcionalan interfejs u browseru i koliko bi
javascript-a trebalo za tako nešto.

Ne znam kako ti zamisljas "funkcionalan interfejs" za knjigovodstvo, ali tu nema nista izuzev polja za unos teksta, a to moze da se uradi maltene bez imalo skripta. Ovaj sajt elitesecurity ima otprilike slicnu strukturu i elemente kakve treba da ima knjigovodstvena aplikacija.

Danas u Srbiji nema vece kompjuterske firme koja u manjoj ili vecoj meri nema knjigovodstvenu aplikaciju uradjenu u nekom od skript jezika. To meni sada omogucuje da odem na sajt nekog od svojih dobavljaca, da vidim koliko kosta komponenta koja mi treba i koliko komada je raspolozivo, da narucim, da se automatski skinu sa stanja, da se meni proveri jesam li izmirio sva prethodna dugovanja, da mi se generise predracun i da mi se isti posalje na email. Takodje, obicno mogu da vidim sta mi je sa reklamacijama i koliko jos imam garancije na kupljene uredjaje. To bez skript jezika tesko da moze da se napravi. Upravo o tome pricam, to je buducnost koja ce iz kompjuterskih firmi stici i u sve ostale firme. Ako neko u to ne veruju i nece to da prihvati, to je u redu, svako ima puno pravo da sam bira svoju buducnost, ali, kad dodje pocetnik zainteresovan za knjigovodstveni softver, ja se osecam obaveznim da ga upoznam sa trendovima u toj oblasti i da ga upozorim da ne uzima zdravo za gotovo izjave tamo nekih da su script jezici bezveze i da mu to u zivotu nece trebati. Moj savet je upravo suprotan, oni koji imaju iskustva sa pisanjem aplikativnog softvera mogu da ostanu na tome, moci ce jos relativno dugo da se zivi od toga, a oni koji tek pocinju bi trebalo najozbiljnije da razmisle o usmeravanju ka skript jezicima - to je brze i lakse, a verovatno vec u ovom trenutku potrebnije, o buducnosti da i ne govorimo.

Evo razmišljam... I još malo razmišljam... I opet tvrdim da je sasvim ok.

Razvoj veb aplikacija je u poslednjih par godina strašno napredovao, JS biblioteke su standardizovane, ima dosta dobrih frejmvorka, broadband se raširio, itd itd.

Ilustracije radi, pogledajte tutorijal o korišćenju AJAX-a iz Railsa:

http://www.onlamp.com/pub/a/onlamp/2005/06/09/rails_ajax.html

Ni red javascripta. A tutorijal od pre 3 godine.

da li su skript jezici bezveze ili ne, nije ovde tema. uostalom, ja to
nisam ni rekao.

taj primer koji navodi pctel je webshop, ne računovodstveni program.
računovodstveni (i knjigovodstveni) programi ipak imaju drugačiji
model unosa podataka, jer se mnogo više stvari mora uneti tastaturom,
a ne preko hiperlinkova. često se podaci unose u tabelarne forme sa
master-detail vezama, interfejs je složeniji itd. sve je to moguće
napraviti i u JS-u. ali koliko vremena treba da se napravi, na primer,
forma za unos faktura i stavki u HTML/JS, a koliko u Javi ili čak
Access-u? dodaj na to toolbar-ove, popup menije, povezane forme, MDI
interfejs i zakopaćeš se u JavaScript-u. ako za primer web aplikacije
koja omogućava lak unos u tabelarne forme uzmemo Google Spreadsheets
(dajte i druge primere), nisam baš siguran da će neko ko razvija
računovodstveni program želeti da se bakće sa JavaScript-om potrebnim
da se takva aplikacija potera. da ne pričam o brzini izvršavanja koda
u browseru naspram stand alone (klijent) aplikacije koja ni na
modernim računarima nije zanemarljiva.

sve je to moguće napraviti u JS-u da radi, ali mislim da rezultat nije
vredan utrošenog vremena.

Ne bih se slozio. Bilo kako bilo, jasno ti je da bi napravio takav softverski proizvod MORAS poznavati baze podataka i skript jezike, a ako znas jos nesto onda to MOZES da primenis. Znaci, to sto ti kazes webshop je jedno a knjigovodstvena aplikacija drugo, to je sada sve sada jedna celina. Mislim, prodaju se jos uvek knjigovodstvene aplikacije u fortranu, maloj prodavnici u nekom selu moci ces bez problema da prodas aplikaciju u C++ za 20 godina, ali, za firmu koja hoce da ima poslovnu jedinicu u svakom gradu, koaj hoce da omoguci kupovinu putem web interfejsa a u perspektivi hoce potpunu funkciopnalnost za svakog radnika putem mobilnog telefona, resenje se namece samo. Sve to sto ja pricam sada deluje kao vrhunska tehnologija koju ce se mali broj firmi usuditi da trazi, ali, razmislite da li je tako i da li ce jos dugo biti tako.


Ne razumem primedbu o utrosenom vremenu. Recimo, ti si programer, utrosis mnogo vremena za nesto i onda, sta, postajes astronaut i nista od rezultata prethodnog rada ne mozes da primenis u svom novom zanimanju? Za bilo koju tehnologiju covek da se opredeli u pocetku ce trositi mnogo vremena a kako vreme bude prolazilo sve manje i manje. Izuzev, naravno, ako mu je posao programera privremeni a krajnji cilj mu je da postane astronaut.

Eto, svako je naveo prednosti jedne i druge tehnologije, koje evidentno postoje. Jasno je - sto manja firma, to je za nju pogodnija standalone aplikacija, sto veca, to su pogodnija skript resenja. Sada svako moze da sedne i razmisli kakve ce te firme biti ovde za 10 godina. Sto se mene tice, ovih manjih je iz godine u godinu manje. Nema vise malih prodavnica, tu su hipermarketi a ako je poneka i ostala, opet je deo velikog sistema. Nema vise malih kompjuterskih firmi, nekadasnje su ili postale deo velikih lanaca, ili pokazuju tendencije ka gasenju. One male kioske, agencije i slicno ne racunamo, oni nemaju obavezu vodjenja knjiga.

Nekada su standalone aplikacije bile nesto sto se podrazumeva, danas su skript resenja i standalone aplikacije otprilike podjednako zastupljene, a kako ce biti u buducnosti, svako neka sam pretpostavi.

Jos da cujem da se script jezici zameniti i ERP resenja, pa da idem u penziju :-). Salim se, mozda bi mogao preko scripta da se napravi program za neku malu STR, ali za ozbiljnu kompaniju to ne dolazi u obzir.

već sam napisao: razmisli malo koliko sati treba utrošiti za razvoj
pomenutog intefejsa u JavaScriptu, a koliko u Javi, .Net ili čak
Access-u. mislim da ta razlika vremena može i pametnije da se
iskoristi nego na budženje JS-a. takođe, nisu script jezici jedina
alternativa stand alone aplikacijama. klijent/server može da se pravi
i u pomenutim jezicima (između ostalih).

uostalom, daj mi primere knjigovodstvenih/računovodstvenih aplikacija
čiji je interfejs pisan u HTML/JS, pa da vidimo na šta to liči.

Po mom misljenju, za takve aplikacije je bitniji RAD nego izbor samog jezika.

.Net ili pak stari dobri VCL ...

Ma ono oko cega se vi sporite su web i destop applikacije. Sasvim je svejedno u cemu su pisane. Vremenom ce na kraju vecina data centric aplikacija da postane web orijentisana, upravo ovo sto pctel prica, dal' ce to biti skript jezici ili nesto drugo manje je bitno, bitno je za programere a za korisnike ne. Trziste ce na kraju zahtevati da iole ozbiljniji (danasnji desktop) program postane "web aware". To se vec polako radi i u buducnosti ce biti sve veca tendencija, pa cak i ERP, samo sto ce trebati vremena

mile75, sta podrazumevas pod linijom komandi kao u Excelu?


dosta framework-ova/biblioteka/API-ja/sta-god ima AJAX i web fazone koji dosta olaksavaju izradu web resenja + moguce je praviti viseslojna resenja :D
vec sada ERP-ovi imaju web mogucnosti (npr, na sap.com se spominje nesto za CRM http://www.sap.com/smallbusiness/solutions/overview/features.epx ) ili npr http://en.wikipedia.org/wiki/SAP_Web_Application_Server)


_{[Ovu poruku je menjao momsab dana 23.04.2008. u 23:50 GMT+1]}

I MVC je RAD.

a sta to, sem obima, razlikuje STR od ozbiljne kompanije? koji to deo ERP-a jedne velike kompanije ne bi mogao da se realizuje istom tehnologijom kojom bi se to uradilo za STR?

kao sto je ves receno, pored svih sad vec zrelih biblioteka i okruzenja, ja ne vidim problem.

sta bi rekao pre par godina kad bi ti neko pomenuo spreadsheet na web-u? a eto njega tu...

Pricamo o tehnologiji a ne o interfejsu. Kao sto rekoh, ERP-ovi rade preko WEB interfejsa, ali nisu uradjeni u script jezicima. Pretpostavljam da su ljudi koji su radili na razvoju tih sistema, razmisljali o problemima komunikacije, sinhronizacije i jos mnogo cemu pa su se odlucili da ipak ne koriste script jezike. Kao sto je neko pomenuo, ako ces imati pristup sistemu iz 15 razlicitih gradova, neka promena u poslovnim procesima ne bi mogla brzo i efikasno da se odradi preko script jezika. Moglo bi ukoliko neko misli da je dovoljno imati jedan web server i samo promeniti taj deo, ali u praksi to nije tako.

Hoćeš da kažeš da je pravljenje izmene lakše kad, pored deploymenta, imaš i dodatni korak bildovanja?

I tvrdiš da skript rešenja ne mogu da se distribuiraju na više veb servera?

:D

Upravo suprotno - kad se koriste skript jezici sve promene su trenutne i to je jedna od bitnih prednosti.


Nije sporno, ali ja bih ipak bacio pogled par godina unapred. Danas je neka prosecna internet veza u Srbiji 128kbps, a za 3 godine ocekujem da to bude reda velicine 50x brze. Upravo je to trenutak kada ce se sa nekih softverskih resenja masovno preci na neka druga. To su moje pretpostavke zasnovane na iskustvu i podacima. Neko ce iskopati ovu temu tamo 2011 godine pa nek napise jesam li bio u pravu. Nema potrebe da se sad ubedjujemo da li ce biti tako ili nece, dovoljno je da oni koji prave prve programerske korake budu svesni te mogucnosti.

Pa napolju vec postoji broadband tog opsega pa ljudi ne trce masovno na web aplikacije, mada ima izuzetaka. Mislim, zakacili ste se oko potpuno pogresne rasprave i mnogo ste iskljucivi, svi odreda. Programerske tehnike i tehnologije su toliko uznapredovale da apsolutno nema potrebe za tom iskljucivoscu, i resenje treba da se odabere shodno primeni u odgovarajucem scenariju. U krajnjoj liniji nigde ne postoji prepreka da se napravi vise opcija i standalone i web kanal koji idu na zajednicki business/data layer i primenjuju se na razlicite segmente kompanije.

Ako se ne varam ovo je treca iteracija "push"-a ka web based biznis aplikacijama od kad je web nastao, i ovaj put nema apsolutno nikakve veze sa tehnologijom koliko ima sa "poslovnom politikom". Ceo IT governance je sad u rukama tehnicki polupismenih ljudi koji sebe nazivaju "Risk managment" grupa i danas dobiti od te grupe odobrenje da instaliras standalone aplikaciju na citiram "managed desktop" u firmi zahteva monumentalno epohalni proces. Primera radi u banci u kojoj smo radili razvoj neke benigne aplikacije koja i nema veze sa njihovim core poslovanjem (aplikacija prati stock opcije i splitove radnika za HR), CIO i njegova banda su nam dali da popunimo "Risk registar", maleni papirni dokument od 150 Letter stranica. A posto za web aplikaciju i opet citiram "deployment URL-a na managed desktop" bio potreban Risk registar od samo 50 stranica mi smo aplikaciju uradili kao intranet web aplikaciju da se be bi smarali sa birokratama. Znaci jezik i platforma nisu imali nikakve veze sa tom odlukom. I to ce sad tako ici i funkcionisati dok otpor RMu ne postane mainstream i onda ce nova zamena na desktop aplikacije, pa ce onda malo kasnije opet na web, i tako u krug. Ako niste primetili to se desava vec godinama .

Pa može da upotrebi Adobe AIR ili Flex
U firmi za kojoj radim, razvija se komplikovan CRM i to baš u Flex

I ti ga pretera. Čovek pita za računovodstvene aplikacije, verovatno poput milion postojećih za mala i srednja preduzeća na domaćem tržištu. To (srećom) nije ni čulo za risk menadžment.

A drugo, rasprava i nije veb vs. desktop rešenje, već da li je veb (skripting) rešenje uopšte izvodljivo za tu namenu, a mi neki tvrdimo da jeste.

Naravno da jeste, samo je pctel naveo skroz pogresan razlog za to.

Ako nije web vs desktop, onda script jezici nemaju sta da traze u ovoj prici. Voleo bi da vidim koja su to resenja u script jezicima koja mogu da pariraju ostalim resenjima. Script jezici se uglavnom koriste za web resenja, bar koliko je meni poznato, za desktop tu su kompajleri i gomile biblioteka i tu script jezici skoro da nemaju sta da traze.

Hm, zar su biblioteke ograničene samo za kompajlirane programske jezike? :)

Nisu, ali su kvalitetnije za kompajlere, iz prostog razloga sto su biblioteke za kompajlere "blize" samom sistemu na kome se izvrsavaju, sto znaci da ces imati brzi odziv i bolju kontrolu.

Pa to što pričaš se ne odnosi samo na biblioteke već generalno na kod, a sa današnjim performansama hardvera taj odziv je i po malo diskutabilna stvar :) bilo nekad, sad se pripoveda :) ovo za bolju kontrolu mi s druge strane baš nije jasno :)

Nisi me razumeo. Hteo sam da kažem da ja ne zagovaram jedno naspram drugog, već zagovaram tezu da obe platforme ravnopravno mogu da se koriste za izradu rač. aplikacija, svaka ima svoje prednosti, ali se prevlast lagano seli na veb.

BTW, biblioteke za kompajlere su kvalitetnije zato što su bliže hardveru? Šta sve neću čuti...

Pre nego sto nastavimo diskusiju trebalo bi konkretno da se napise koji su to script jezici na koje se odnosi. Ja sam prvenstveno mislio na javascript. Ti u javasricptu ne mozes da pustis neki proces na novi thread (bar ja ne znam) i tako dobijes bolji odziv aplikacije, na ovu vrstu kontrole sam mislio, isto tako i memorija, u .NET imas GC koji je zaduzen za ciscenje, ali imas i kontrolu koji objekat treba da "zivi" a koji ne, tako sto ces se pridrzavati dispose patterna i cistiti objekte za sobom a za C++ da ne pricam. Uglavnom, kontrola resursa je sto se ide ka nekim "visljim jezicima" manja, dok u ovim "nizim" veca.

ja mislim da niko zdrav ne bi ni pomislio da radi tako nesto u JS.

pricamo o server-side skript jezicima - php, ruby, perl... a JS bi tu mogao da bude element koji bi doprinosio vecoj funkcionalnosti interfejsa.

Ovo za BTW - OK, trebao sam staviti navodnike. Mislio sam kvalitetnije u smislu jer imas vecu kontrolu, ne da li su bolje pisane i sta li vec...

Sto se tice teme, jasno mi je sta hoces da kazes, ali moja poenta je upravo ta da u svetu desktop aplikacija script jezici nemaju sta da traze jer isto to sa kompajliranim jezcima ce se lakse namestiti ako ne lakse, onda bar kavalitetnije iz razloga koje sam vec naveo.

Pa, opet netačno...

Što se kaže, "odma, da ne gledam" mogu da ti navedem desktop aplikaciju urađenu u skript jeziku (python) koju koristim bukvalno svakodnevno - mp3 plejer Exaile. A siguran sam da koristim još par njih bez da sam provalio da nisu kompajlirane aplikacije.

Ajde da ne zamajavamo narod, proguglaj malo šta se od biblioteka nudi za skript jezike tipa Perla, Pythona i Ruby-ja.

wxWindows (preko SPE ili Boa Constructor RAD alata) + SQLAlchemy + PostgreSQL + Python je sveta četvorka :)
Tu bi jedan skript jezik odvalio sve ostale po svim stavkama.

@jablan

OK, u pravu si, ja sam ciljao na ove script jezike koji se koriste u web resenjima, (vbscript, javascript, PHP) to mi je bila prva asocijacija i verujem da je vecina na to mislila. Sto se tice ovih script jezika koje si naveo (inace mislim da je "skript jezici" nesrecan naziv, bolje bi bilo static i dynamic u zavisnosti sta je) moguce je u njima raditi sasvim kvalitetno, ali tu dolazimo do one price dynamic i static jezici, koja je vec bila vodjena negde na .NET forumu. Ja cu uvek biti zagovornik static ideje, jer mislim da su razlike izmedju dinamickih i statickih jezika u tome da dinamicki jezici nisu dovoljno "razvijeni", u smislu da one mogucnosti koje pruzaju su u sadasnjem vremenu tesko implementirajuce na statickom nivou, dok neke osobine nece nikad moci biti implementirane, a to je onaj "nedeterminizam", gde ti mozes upisati bilo sta nad jednim objektom i ako to nesto postoji onda se to izvrsi, a ako ne onda da dobijes runtime gresku.



Ne znam, taj pojam script mi je nejasan, sta se sve pod tim podrazumeva i to bi trebalo prodiskutovati. Da li su script jezici podpadaju pod General Purpose Languages ili Domain Specific Languages, ili dynamic ili static type system, kako ih prepoznati?

Pretpostavljam da vecina ovde pod skript jezikom podrazumeva onaj koji se interpretrira.

Upravo ono sto treba uraditi je izbeci formiranje ovako uskih gledista kod novih korisnika. Prvo, jasno je da se obe tehnologije uspesno koriste, pa meni ustvari nije jasno zasto se ta cinjenica tako uporno pokusava sakriti. Drugo je pitanje kakve su nase vizije razvoja situacije. Trece, jasno je da nema ostalih resenja koja mogu da pariraju skript jezicima u nekim oblastima primene. Cetvrto, knjigovodstvo je prestalo da bude desktop aplikacija i to je ono oko cega se izgleda razilazimo. Knjigovodstvo podrazumeva uglavnom razmenu podataka izmedju banaka, kupaca, dobavljaca, poreskih institucija i razlicitih sektora preduzeca. To se nekada radilo tako sto jedan ukuca podatke u racunar, pa odstampa, pa spakuje u kovertu, pa posalje drugom, pa drugi ukuca u racunar, pa snimi. Vecim delom se to jos uvek radi tako, ali ne verujem da ce jos decenijama moci tako. Razliciti informacioni sistemi ce sve vise morati da komuniciraju, a ja stvarno ne vidim mogucnost da se to brze i bolje uradi nego primenom skript resenja.

Jedna od vecih domacih kompjuterskih firmi ima informacioni sistem potpuno uradjen u PHP-u. Taj informacioni sistem funkcionise vec nekoliko godina i evoluira iz dana u dan a da korisnici nikada nisu imali pauzu u radu zbog instalacije necega. Sve sto im treba je bilo kakav kompjuter sa bilo kakvim operativnim sistemom koji ima web browser. Za mene ce prva sledeca velika stvar u softverskoj industriji biti kada imam neki problem sa kompjuterom, ja samo donesem novi, ukljucim i nastavim gde sam stao, a kad odem sa radnog mesta i setim se da nesto nisam uradio, uzmem mobilni telefon pa to zavrsim. Sada takvih resenja nema, ali to je pitanje vremena. A, kada ih bude, sta mislite koliko ce biti korisnika koji ce reci "sta ce to meni, ja volim da sednem, instaliram aplikaciju, pola sata podesavam parametre pa tek onda pocnem sa radom"? Po mom misljenju, jako malo. Mislim, nebitno, mozda ce ih biti i mnogo, ali, nek svako ko pocinje sa programiranjem bude svestan svih eventualnih razvoja situacije, razmisli o tome pa nek donese sopstveni zakljucak.

Nista od ovoga ne bih napisao da neko na pocetku nije rekao "script jezici nemaju tu sta da traze". Trebalo bi svima da bude jasno da imaju, to je sve.

Kojim oblastima primene?

pctel to sto pises ja sam se cak i u prvoj poruci na ovoj temi slozio, ali onog momenta kada je Jablan spomenuo da ovo nije poenta izmedju web i desktop resenja ja se nisam slozio. Jer to sto ti ocekujes je onda "web" resenje i meni je to jasno i cak sta vise sam ubedjen da je to buducnosti i skript jezici su tu nasli primenu i danas se zovu "script jezici" a za nekoliko godina tu funkcionalnost (da upravo tu gde spominjes zamenu starog za novim kompjuterom i sve isto) ce mozda obavljati bas staticki kompajlirani jezici, ili interpreteri (tek ovo sto je diskutabilno). To sam zeleo da istaknem da to sto ti trazis nema veze u cemu je implementirano, jer to je odredjena vrsta funkcionalnosti, a to da li je skript ili nesto trece je stvar implementacije u kojoj se pravi ta funkcionalnost.

@Shadowed
.NET bi mogao da nazoves interpreter, jer se ne izvrsava na masinskom jeziku nego preko IL-a se kompajlira u assembler pa iz assemblera na masinski jezik, mada to vec znas, tako da je i interpretacija sirok pojam.

Oblastima primene koje zahtevaju razmenu informacija sa velikim brojem korisnika i/ili velikim brojem razlicitih informacionih sistema.


Pa to. Nadam se da mozemo da se slozimo - mozda ce biti ovako, mozda onako, treba ukazati na sve aspekte i mogucnosti a ne da se jedna tehnologija tek tako otpise kako je ucinjeno na pocetku teme.

negyxo, a htedoh reci "interpretira iz izvornog koda", al' skratih :)

pctel, a da batalis stvari u koje se ne razumes? Ili bar pitaj umesto da tvrdis. To sto ti pricas je web vs. desktop ne script vs. kompajliran program. Kapiras? Web != script jezik.

Ovo meni bode oci, mada jasno mi je sta hoces da kazes i tvoj stav kao korisnika je sasvim opravdan. Ja prvo polazim od sebe, recimo, ne treba mi banka koja ne moze da mi obezbedi online uvid mojih primanja, neke transakcije itd. Mene kao korisnika treba da zanima to, znaci funkcionalnost, a ne tehnologija kako je to implementirano, ako je funkcionalnost bitna, a jeste, onda se bira sve sto ce moci da zadovolji tu funkcionalnost, znaci nije bitna tehnologija. Ako u onom slucaju gde je Jablan rekao da ovo nema veze sa web i desktop aplikacijama, onda to znaci da ostaju desktop aplikacije, jer nije bitna ta funkcionalonst da li ti mozes online nesto da obavis ili ne, nego da je bitna tehnologija, gde se ja ne mogu sloziti, i to samo ako su script jezici dynamic jezici u kombinaciji sa (DSL)Domain Specific jezicima jer za velike projekte bi bas voleo da vidim kako se to radi u dynamic jezicima, gde jedna pogresna rec moze da izazove glavobolju od tri neispavane noci ili ako u slucaju da DSL onda ne mozes da uradis odredjenu funkcinalnost jer je to ipak domenski jezik, tj. skript. Ali o ovome tek kad raspravimo sta je to skript jezik. Inace kos dodatni razlog zasto ne verujem zasto mogu sadasnji skript jezici da zamene tek tako kompajliranje jezike jer ne verujem da je pola industrije neobavesteno, jer koliko vidim ipak ih je vise koji rade sa statickim kompajliranim jezicima za iole malo veci program.

Access, vb, Delphi, .Net, Java, FoxPro, Clipper, (Cobol???)

Ništa mi niste jasni sa tim "skript jezicima za desktop", može li par primera i koja gotova rešenja postoje.
Nešto sumnjam da su "pogodna", barem ne sledećih 5-10 godina.

Evo ERP-ova u Python-u (koji JESTE skipt jezik): http://www.tinyerp.org/ i http://www.stoq.com.br/index.php?lang=en

Python: pyRacerz
:D

pctel, sto se tice tog povezivanja razlicitih ISova i tako to, za tako nesto se koriste web servisi (mnogo dobra stvar)
ja vise volim web resenja ko su dobro podrzana u vecini aktuelnih browsera
inace prednost dajem web resenju, ma konzolnoj, sao da ne mora da se posebno instalira

Eh sad.. Ako se radi o ozbiljnijem softveru, valjda postoje testovi koji ce svakako otkriti ovakvu gresku, tako da.. A ako nemamo testove, onda smo sjebani svakako, pa ti neće mnogo pomoći ovaj ili onaj jezik.

I da, čini mi se da će C# u sledećoj verziji (4.0) još dalje da ode sa preuzimanjem fazona iz dinamičkih jezika pa će biti moguće napisati i kod kao ovaj gore, ako se dobro sećam šta sam nedavno čitao..

Degojs, ima to public, sta ce biti (bi trebalo biti) u sledecem C#/VB.NET-u?

Nešto možeš da vidiš ovde http://blogs.msdn.com/charlie/...e/2008/01/25/future-focus.aspx

Da ne bude zabune, obrati pažnju da kažu da "the team is currently considering adding the keyword dynamic to the language.."

Vidim ja opet cemo doci do price static i dynamic.

@degojs
Za C# mi je dosta jasan "future direction", bar mislim, i ono sto je odlika C# je da je i dalje static type a da ima dinamicne osobine, o ovome, kao sto sam vec rekao, je bilo reci na .NET forumu, tako da ne bi mnogo da ponavljam. To "dynamic" se misli na osobine koje poseduju dynamic jezici ali i dalje je static type sistem upitanju. Uostalom, onda bi mogli da kazemo da je C# 3.0 skript jezik, ima dinamicke osobine (recimo lambda, type infirence, anonymous types.. sve to cini da je jezik "dinamicniji") a i prevodi se u IL, koji se interpretira, doduse preko JIT samo jednom tokom izvrsavanja i to u blokovima.

I da, to za testove je jako interesantno, ako ti budes pisao toliko testova, onda si napisao i sam program samo kroz testove i plus sam program sto je jos vise informacija, to je fakin informaciona entropija, protiv koje se ne moze. Probacu da nadjem article na Joel on Software, on je to veoma lepo napisao.

Evo ga http://www.joelonsoftware.com/items/2007/12/03.html

Kako tece diskusija nisam siguran da je covek dobio odgovor na svoje pitanje.

Za pocetak pogledaj Access, imas knjiga i literature koliko hoces. Sledece ti je Delfi, mozda i bolje, ali ne tako rasireno.

Zasto Access?. U knjigovodstvu imas mnogo podataka pa je osnova za to neka baza. Tamo imas sve elemente, kreiranje i odzavanje tabela, forme za unos, report za izvestaje, lako se kreira meni. A naucices SQL koji je danas standard za baze.

IL se ne interpretira, tacka. Da ne zalazimo mnogo u to, interpretacija se zasniva na direktnom izvrsavanju meta DOMa (koji je nastao parsiranjem skript jezika) kroz blokove koda samog interpretera. Iako je teorijski moguce interpretirati IL, .NET to ne radi i IL se prevodi u native code platforme na kojoj se izvrsava. Jedina razlika izmedju recimo C++ i C# u tom pogledu je da se c# aplikacija bukvalno kompajlira dva puta pre izvrsavanja.

Dynamic u C# nije nista novo i sasvim je ocekivano i zapravo nije nista drugo do late binding-a, kao sto negyxo rece, rezultovani IL je i dalje strong typed samo sto pozivi idu kroz reflection kompajlerskom magijom (slicno kao sto se LINQ svodi na pozivanje prefabrikovanih ekstenzija nad IEnumerable<T>). Nema tu nista scriptable, jedina slicnost je sto ces sad i u C# moci da ne platis na mostu nego kasnije na cupriji kroz runtime type errors.


U principu nemam nista protiv script jezika, niti interpretacije, ako je ista tacno to je da performanse zaista vise ne igraju kriticnu ulogu u izradi ERP resenja sa svim ovim novim shiny hardverom koji danas moze da se kupi. Dakle, ja se slazem da je moguce i izvodljivo raditi ERP u skript jezicima, samo sto to nikad ne bih radio u praksi iz prostog razloga nedostatka strong typinga. Trebalo je dosta vremena da prodje da strong typing evoluira do te mere da mozes da ga koristis u praksi bez da budes C++ guru i ja sam sasvim zadovoljan onim sto imam kroz .NET i iskreno mi se ne vraca nazad na vreme skrivenih runtime gresaka koji nemaju veze sa poslovnom logikom. Naravno, nivo tolerancije je razlicit kod razlicitih ljudi i neki ljudi vole da debaguju skript jezike trazeci te greske (neki cak u tome vide job security), ali kad dodjes u poziciju da shefujes ekipici programera od kojih nisu svi seniori onda uzimas svaku pomoc koja ti je na raspolaganju, izmedju ostalog mogucnost strong typed kompajlera da spreci te greske tokom samog razvoja. Testiranje je naravno i dalje potrebno, ali je sad fokusirano na testiranje poslovne logike a ne testiranje toga da li je programer A promenio svoju klasu C bez da programer B to zna.

Ajde da se i ja ukljucim. Ja sam takav program odradio u VB5, koji je naravno prvazidjen odavno, em sto su kontrole ruzne, em sto je jako nestabilan: moras da stvoris naviku da snimas program svakih pet minuta, inace stalno pises iz pocetka sto je bas frustrirajuce. Inace, mislim da ne mozes mnogo da pogresis koji god jezik da izaberes, ali moras raditi. Ja sam definitivno odlucio da predjem na python

Ma da, mogu sad i ja da kazem da ako ti za svaku promenjivu pises kog je tipa i slicno, to je takodje konfuzija i slicno. Mislim - za svaku promenjivu moras da "pratis" kog je tipa, itd?? :D

Osim toga, TDD (test driven dev) je, po meni, sasvim OK, sigurno imamo razlicita iskustva.

Pricas o nekoj sigurnosti koju strongly typed jezici pruzaju i kako je to bolje za ozbiljan softver, a onda kao - kome trebaju testovi? Eh.



Pa necemo bas ni da pisemo test za to. Ali ce test to indirekto da proveri, itd.

_{[Ovu poruku je menjao degojs dana 25.04.2008. u 15:09 GMT+1]}

@mmix
Sve se slazem sem ovog prvog. Nije da sam cepidlaka, ali sam hteo reci da ni .NET kompajleri ne prozvode masinski kode, stoga kao sto ti rece, kompajlira se dva puta, ja sam tu podvukao paralelu sa onim sto recimo javascript radi, znam da nije isto ali na kraju da bi pokrenuo i jedan i drugi kod treba ti neki "kompajler" koji ce to da prebaci. Moracu da pogledam definicuju intrpretera.

Nisam ni rekao drugacije (da nije static type u pitanju). Ali ocigledno da ima sve vise osobina dynamic jezika, pa sad.. neka zakljuci ko sta hoce.

Pa s obzirom da sad imas type inference ne moras da vodis racuna, na prvi pogled bice to odlicno, dok jednom posle 200 klasa ne skontas da je tip koji si dobio u jednoj kljucnoj promenljivi float a tebi trebao decimal.

Isto, TDD je OK, ali da ne ulazimo u tu pricu. Mislim da nisi shvatio ponetu onoga sto je Joel napisao.

Kako rekoh, testiranje resava te probleme, a ljudi koriste jezike kao Python i slične bez problema tako da jednostavno ne vidim tu ni najmanji problem iz prostog razloga što testovi hvataju takve greške indirektno. Osim toga, to bi bio problem sa C#, a ne verujem da bi Python imao problem tog tipa (evo float, a ja očekujem decimal, šta ćemo sad?).

(Da se razumemo, ja nisam nešto velika pristalica tog što rade sa C#.)



Nisam ni čitao to što si linkovao. Isto tako mislim da ti nisi shvatio moju poentu vezano za testiranje, pa da ti ponovim: testovi hvataju sve takve greške, a ti ako ne pišeš testove onda se svakako za***avaš, bez obzira koristiš li Python ili Javu.

E samo ovo da odgovorim



Shame on you

Inace ja jesam pristalica toga sto rade sa C#, jer ce mnoge stvari moci mocnije da se urade ako znas kako sa njima da baratas. Recimo, cak sam uveren da ovo sto se radi sa LINQ-om ima da zameni SQL negde u buducnosti, jedino ako MS u medjuvremenu ne pukne

I da jos ovo, ako krenes od samog pocetka da vodis racuna o tipovima onda si izbacio potrebu za pisanjem takvih testova, zato, procitaj onaj link

Ajd i ja za kraj:



Čekaj malo, pa što onda kažeš malopre da:

Prvo kudiš nešto, a onda si pristalica?


Dalje,



Jbga, a ti pročitaj ono što ja pišem na ovoj temi već 5-ti put: testovi tog tipa nisu ni potrebni. Normalni testovi će indirektno, naravno da hoće, da uhvate i takve greške.

Privremeno se iskljucujem iz diskusije, pa u utorak mozemo nastaviti.

Degojs, u tome i jeste zackoljica, sto ti izgleda brkas type system i dinamicke osobine (feature) dinamickih jezika. Te feature se ubacuju strongly typed jezike, sto znaci da je sve isto samo sto su neke jezicke konstrukcije sad mocnije. Evo ti LINQ za primer, recimo zelis nad nekim objektima da dobijes rezultat ali ne u onom obliku u kojem se vec nalazi definicija objekta, nego sasvim neki novi output

Recimo




Bez ovih "dinamickih" osobina ti bi morao da napises negde tvoj novi tip podatka koji bi se sadrzao c.Name, p.Name i p.ID i ovaj where uslov bi morao da napises verovatno preko neke f-je kako bi filtrirarao podatke. Ovde mozes sve add hoc da uradis, ali ce kompajler uraditi potrebnu "logiku" kako ti ne bi to rucno kucao.

Reci mi da se salis. To sto linq ima SQL-like sintaksu ne znaci da ce zameniti SQL. Stavise LINQ uopste nije CLR core .NET tehnologija, to je samo kompajlerska konstrukcija. Probaj da dekompajliras bilo koji metod koji koristi LINQ i videces da LINQ-a tu vise nema i sve se svodi na pozive extension metoda nad IEnumerable interfejsom i isntanciranje anonymous tipova. Jednom recju LINQ je fatamorgana




Ja nesto ocigledno propustam ovde, kako ce izgledati ti tvoji testovi ako u script jeziku ne testiras direktno type validation vec samo poslovnu logiku? Pretpostavljas da ce pozivar da zna koji tip da prosledi i da nikad od toga nece odstupiti? Nece npr ubaciti string sa float brojem u netipizirani prametar metode u kome ocekujes int? To je bas VELIKA pretpostavka. Ti tako mozes samo da istestiras metod pod "pretpostavkom" da ce biti pozvan sa tipom koji ti ocekujes, a znas sta se kaze za "pretpostavke" (doduse na engleskom ), "assumption is the mother of all screwups"

Sa druge strane ako ces da testiras type safety metoda, onda moras da pozoves metod iz testa sa svim mogucim kombinacijama tipova sto je prakticno nemoguce u potpunosti pokriti.

Da se odmah razumemo, ja sam koristio TDD i iako ima nekih zanimljivih aspekata, nisam "kupljen" idejom testiranja kao drajvera razvoja. Kao prvo, TDD zahteva da programeri pisu adekvatne testove i ne prave "krivine" u istim, sto je realan problem u timovima koji imaju tight deadline, kada se prave gomile nedokumentovanih "pretpostavki" o tome sta se "sigurno nikad nece desiti" i eto belaja, prave se nekompletan i nesiguran kod koji prolazi test ali ne radi kad te nepisane pretpostavke nisu zadovoljene i developera za to boli uvo jer je njegov kod prosao njegov sopstveni test. TDD takodje "pretpostavlja" da si ti vec resio type safety problem, sto sa scripted jezicima nije situacija. Samim tim ti testovi ladno prelaze u green fazu iako je testirani kod felerican sa aspekta tipova.

Ne brkam ja ništa. Lepo se vrati na onaj prvi primer koda koji si dao. Hajde da razgovaramo o jednoj stvari, pa kad se dogovorimo da je ovako ili onako onda prelazimo na sledeću. Ovakvo skakanje svaki čas na nešto deseto me baš i ne interesuje, jer više ostavlja utisak da ti izvlačiš nešto drugo svaki put samo ne bi li bio u pravu, a ja više pojma nemam kakve to sad veze ima sa onim na početku, itd.



Pa evo zašto mislim da nije problem, a ti me ispravi ako grešim:

Zašto bi bio problem ako mi proslediš string koji sadrži float umesto int? Pretpostavka je da jezik sam ume da uradi konverziju (string -> broj) ako je potrebno te će pasti na testu jer će rezultat biti pogrešan, a ako ne ume da vrši konverziju (ili je uradi u pogrešnom smeru npr. int -> string pa uradi lepljenje teksta umesto sabiranja), test će da padne još pre ili opet na kraju.

Niti takvo razmišljanje ima smisla.. jednostavno ne mogu ja da napišem sve moguće testove za sve moguće tipove podataka - pa ti možeš uvek da napraviš neki svoj tip i proslediš to kao ulazni parametar. Ali ti ćeš onda da imaš i takav test za svoj kod, koji će onda da padne (jer je moja funkcija pala), itd.

Što se TDDa i testova generealno tiče, sve se slažem, ne kažem da su garant da će sve biti OK, ali šta -- type safe jezici garantuju da će sve biti OK, i to bez ikakvih testova, kako je kolega nešto 'teo da kaže? Ma sigurno. Ne znam samo otkud onoliko test alati i za npr. Javu i C#.. I to još pominje nekakve stotine klasa. Pa lepo bez testova, samo napred, pa da vidimo šta će biti kad se malo ljudstvo na projektu menja i slično. Osim toga, testovi se valjda pišu i iz razloga da bi kasnije neko deseti mogao da uradi izmene negde, potera testove i uveri se da nije polomio nešto drugo usput.


_{[Ovu poruku je menjao degojs dana 25.04.2008. u 22:57 GMT+1]}

Ovo je pitanje koje sam i ja sebi postavljao. Probao novotarije i ostao na kliperu. Brz, jednostavan ne treba mi šestium i radi na 100% sigurnom OS-u. Volim ja ovaj game boy od vindoza, ali to je za igre, net i elektronsko plaćanje... Šalu na stranu, mislim da je web budućnost. Takodje mislim i da je linux i gpl budućnost (možda daleka). http://www.ledgersmb.org/ ili http://www.sql-ledger.com/ Ako pogledamo sa stanovišta kompletne instalacije, gpl knjigovodstveni softver+linux+postgres+perl+apach+net košta mnogo manje od .net+windows+server+++. A radi u svakom browseru, win, lin, mac, dos... Možda treba malo da se pomučiš da ga prilagodiš, ali to je cena besplatnog softvera. Mislim da bi to mogao da bude veliki plus za linux na ovim prostorima u poslovnoj upotrebi. Ja pokušavam.
p.s. Ima li koga voljnog da pripomogne?

Ok, osnovni primer (banalan ali dobar kao primer)



Metod je "validan", test je green, i svi su happy, a Multi(3.5, 3.6) je neispravno. Recimo da je a kolicina prodatog artikla, b cena po artiklu. U bazu ode 3.5 komada sa neizvesnim upisom (mozda ce DB da ga flooruje na 3 ili zaokruzi na 4, sto ne mozes da znas bez da znas kako baza funkcionise i sta DB.Insert radi sa svojim parametrima), u svakom slucaju zapisani iznos a*b nece biti ispravan niti u skladu sa logikom metoda. Naravno, sto kompleksniji metod to kompleksnija i logika i to vise potencijalnih rupa po osnovu type unsafe.



Type safe jezici naravno ne garantuju ispravnost logike kode, ali garantuju ispravnost komunikacije izmedju pozivnog i pozvanog koda, tj preventivno deluju protiv gomile potencijalnih bagova izazvanih nepaznjom i hvataju ih tokom samog kompajliranja. Jedini nacin da u skript jezicima to uradis je da radis validaciju parametara na pocetku metoda, a ako to vec radis, sto jednostavno ne bi koristio type-safe jezik

Inace, mislim da si pomesao moje postove sa negyxovim, ja sam veliki poklonik testiranja i definitivno nisam negirao njegovu korist, samo ne kupujem pricu o TDD, tj o drugom slovu ovog akronima (D - Driven). Testiranje je odlican instrument za ranu detekciju logickih bagova i backward kompatibilnost koda da neko deseti ne bi pokrljao kod, ali testiranje definitivno po meni nije centralni aspekt koji treba da upravlja razvojem i definitivno mi skripi taj "minimalisticki" pristup testovima gde se kod steluje samo da bi prosao test bez obzira na sve ostalo. Pored toga, testiranje odredjenog dela koda treba da radi drugi tim ljudi koji kako bi se izbegao konflik interesa i slabljenje test koda.

Niko ovde ne pomenu Visual FoxPro. Vecina se uhvatila za .NET kao da je resenje za sve. Bice, ali za jedno 2 iteracije kada stigne zadnju verziju Fox-a.
Zasto Fox? Pa on je jedini "Data Centric" programski jezik koji ima svoj lokalni "Cursor" engine, ima svoju bazu podataka, lako se povezuje sa bilo kojom bazom putem vise tehnologija (remote views, cusros adapters, SQL passthrou), RAD je, ima svoj ReportEngine, ima makro substituciju, oop (nasledivanje kao u c-u), vizuelni je alat ...
Covek hoce da pravi knjigovodstveni program a zato mu treba : baza podataka, programski jezik koji ce to najlakse da odradi i omoguci mu najlaksu manipulaciju sa podacima. Nemam nameru da kudim neki drugi jezik ali za to od Fox-a nema boljeg i brzeg. Evo primer, koliko treba linija koda u C# da se povezes sa MSSQL serverom, iscitas tabelu i prikazes je korisniku? Necete verovati a u Fox-u je to 3 linije koda. Dalje vidim da se ovde spominje LINQ kao neko cudo a Fox ga ima skoro od svog pocetka.
NET je super stvar i verovatno je u njemu buducnost ali trenutno, kada su u pitanju baze podataka, ne moze niko da me ubedi da moze da parira Fox-u.

Pozdrav.

@mmix

Hehehe, to sa tipovima podataka u bazi jeste problem - čak sam to i sam napomenuo na jednoj sličnoj raspravi na DPT-u da postoji taj problem sa skript jezicima i bazama :) U takvom slučaju mora da se obrati pažnja, ne sporim.

Evo našao sam:


Mada.. ako znamo da ne znamo :) šta će baza ili DB.Insert tačno da urade, onda ćemo da svoj kod prilagodimo toj situaciji tipa:

DB.Insert( floor(a), b );
return floor(a)*b;

A nisam siguran da to nisu više kao teoretske situacije, pošto se podaci ionako češće proveravaju prilikom unosa, isčitavanja i slično, nego ne.



Inače, takođe da se razumemo, ja preferiram strongly typed jezike, ali ako se koristi testiranje, ne vidim veći problem sa upotrebom ovih drugih.



_{[Ovu poruku je menjao degojs dana 26.04.2008. u 01:46 GMT+1]}

Tebi treba dobar code generator pre nego jezik. U davna vremena clarion je bio najnapredniji
DOS alat za generisanje poslovnih aplikacija ne znam kako je sada. Quick search mi je kazao da
ovaj alat nudi vise opcija za razvoj, (.net win32 exe web/desktop valjda generise i php itd)
a secam se da je aplikacija tog tipa mogla da se napravi bukvalno bez programiranja.
Link sa gugleta : http://www.softvelocity.com/

Pozzz!

Ovo meni zvuci kao "pretpostavka", ona koja preklapa dve kategorije: "ovo ce neko drugi da obezbedi" i "ovo se nikad nece desiti"

Realno, ti si upravo ispravio bug u kodu Multi() metode, ali to je bug koji ti nisi otkrio testiranjem, testovi su prosli ok. Ti si ovaj bug ispravio nakon sto je aplikacija usla u QA fazu ili jos grdje nakon deploymenta kad je metod bio pozvan sa non-int parametrom u simuliranim ili jos grdje proizvodnim uslovima. U tome je problem sa TDDom i skript jezicima, sama type unsafe priroda script jezika ubija TDD.

FoxPro je odličan ali mrtav jezik, zadnja verzija je 9 SP2 i - NEMA DALJE.



Probao sam one ERP-ove od Python-a ali to meni liči kao da se neko dete igralo sa kockicama, bez uvrede.

Ne znam, možda grešim ali koliko je Python skript jezik toliko su i Access i FoxPro (dBase itd.) skript jezici. Mada ih ja nikada nisam tako zvao.

Ako to nisu skript jezici onda: može DEO programa (vezan za Web recimo) da bude urađen u skript jezicima ali za iole ozbiljan program potreban je efikasniji programski jezik, još uvek.

Imam nekoliko godina iskustva u odrzavanju i razvoju knjigovodstvenih aplikacija (Clipper, VB + Access, PHP + MySQL, C# + MSSQL), pa evo nekih mojih iskustava:

1. Knjigovodstvenu aplikaciju tesko mozes napraviti bez baze podataka. Znaci, nauci sto vise mozes o bazama podataka.

2. Svaka aplikacija bi se u grubo mogla razdvojiti na tri sloja - korisnicki interfejs, engine (obrada podataka) i baza podataka; trebao bi da tezis tome da najpre razvijes engine, i da ga sto vise moguce odvojis od interfejsa i baze podataka, odnosno da budu sto nezavisniji, jer ce ti to olaksati sve buduce izmene u aplikaciji, u protivnom na primer jedna sitna izmena u dizajnu interfejsa moze da znaci sate ceprkanja po kodu. Objektno orjentiasni jezici su idealno za to, pitanje je samo koliko je tebi lako da ih naucis i primenis prakticno.

3. Knjigovodje uglavnom koriste numericku tastaturu za unos podataka - ako mozes izbegni upotrebu misa, i smesti sto vise kontrola mozes na numericku tastaturu i u njenu blizinu; ako operater moze jednom rukom bez puno setanja da manipulise celom aplikacijom, a drugom rukom drzi telefonsku slusalicu/soljicu sa kafom/puter kiflicu/novine/itd., moze tvoja aplikacija imati najskrnaviji graficki dizajn i manjak nekih opcija, pa ce opet korisnici teze odabrati neki novi ultra/mega/giga/turbo sljasteci knjigovodstveni sistem, tako da ces godinama lako zadrzati postojece klijente uz sebe. Najbolja preporuka je da izdvojis neko vreme i sedis uz operatere dok rade na unosu podataka, i posmatras ih kako to rade. Tako ces biti siguran da si napravio nesto sto je njima po meri (sto ih manje teras da se prilagodjavaju interfejsu, a sto vise prilagodjavas interfejs njima, to ce oni biti zadovoljniji - naravno, treba uvek imati neku granicu).

4. Prosecan operater unese oko 400 stavki dnevno, sto na godisnjem nivou (uz sve godisnje odmore, drzavne praznike i sl.) iznosi oko 100.000. Ako pravis taj program za nekoga ko na godisnjem nivou ima mnogo manje stavki, mozes ga praviti prakticno u bilo kom programskom jeziku jer je dovoljno da radi na samo jednom racunaru. Naravno, treba da imas na umu i buduce potrebe, odnosno uvecanje obima posla, pa da predvidis na vreme da li ce toj firmi biti potrebno mozda dva ili vise racunara za unos podataka (naravno, na svakih 100.000 stavki racunas po jednog vise operatera odnosno po jedan vise racunar). U tom slucaju treba da se preorjentises na programske jezike koji olaksavaju razvoj mreznih aplikacija (baza "trci" na jednom racunaru, a po jedna kopija tvog programa se instalira na svaki racunar za unos i preko mreze pristupa bazi).

5. Matricni stampaci su jos uvek zakon u knjigovodstvu, a veliki broj novijih laserskih i ink-jet stampaca dolaze iskljucivo sa USB konektorima. Matricni stampaci su prilicno brzi ako im saljes "suv" tekst ("raw data" format), ali ocajno stampaju grafiku, a prednost im je beskonacni papir i virmani na beskonacnom papiru. Neki stariji programski jezici mogu da rade samo sa printerima koji su direktno prikaceni na taj racunar, pa onda moras koristiti razne trikove da bi prevario tvoj softver i naterao ga da koristi mrezni printer. Ako je klijentima bitno da imaju logo firme i slicne kerefeke, onda je tu bolje upotrebiti laserski printer, ali neki stariji programski jezici imaju prilicno losu (ili nikakvu) podrsku za USB, a kod mnogih jeftinih USB printera se tesko softverski kontrolise stampa u "raw data" formatu (ne mogu im se direktno slati komande za promenu velicine fonta, prelom reda i sl.) tako da i o ovome moras voditi racuna prilikom odabira odgovarajuce tehnologije za programiranje.

Ovo su samo neke od stvari na koje treba da obratis paznju, ima naravno jos mnogo toga o cemu ces da saznas kad se konacno bacis na izradu te aplikacije. U ovoj zemlji ima na hiljade programera koji se bave razvojem knjigovodstvenih aplikacija, sto samo po sebi znaci da nije nikakav problem napisati nesto sto moze da odradi taj posao.

Kako to mislis mrtav? Ima zvanicnu podrsku do 2014 god. Nego nece biti verzije 10 sto ne znaci da je mrtav! Drugo a sta je to sto bi verzija 10 mogla da donese u Fox a da on nema ili da ne moze vec da se uradi. Dalje Fox je ono sto se kaze "mature product" znaci kada su u pitanju podaci nema sta ne moze da se uradi u nekoliko linija koda dok u svim ostalim M$ jezicima treba daleko daleko vise.
Stvar je malo drugacija nego sto izgleda. M$ ima svoj "flagship product" kada su u pitanju baze a to je MSSQL server, dalje M$ je firma koja zaraduje novac; iz cega sledi zasto bi M$ gurao Fox kada se na njemu zaraduje mnogo manje para nego na MSSQL serveru (Fox platis 650 dolara i mozes da distriburas bazu koliko god hoces na koliko racunara god hoces, MSSQL se prodaje po licencama). M$ interesuje samo profit. Nigde u M$ neces naci da ce se C# razvijati u narednih 20 godina (recimo), jednostavno ako donosi profit ima perspektivu ako ne donosi ode u penziju.

Ovo je apsolutno tacno i ne samo u knjigovodstvu nego i u proizvodnji. Uzmimo primer Ikarbus-a gde je njima sastavnica : 1 Autobus, a on ima preko 5000 pozicija. Kada se taj nalog lansira i treba da stampa svaki laser bi se zapalio, dok matricni to kulturno odstampa bez problema. Ali kada je u pitanju ostala stampa samo laser (u fox-u imas odlican reportengine, mogucnost dodavanja samog koda u svaki segment stampe ...)

Pa pazi, i Cobol je mature product pa ga ne bih koristio
A i poredjenje sa MSSQLom ti nije dobro rezonski. Za potrebu koja matchuje i prevazilazi FoxPro, MSSQL Express moze da se koristi i ne kosta nista. Nije MSSQL taj koji je konkurencija Foxu, Access je konkurencija Fox-u i zbog Access-a MS ubija Fox.


Al kad vec pomenuste raw printing na matricne stampace, gde je tu sad scriptable web resenje bas me interesuje kako bi izbacili raw paket podataka na loklani LPT port korisnika iz javascript-a u html strani bez instalacije pomocnog COM objekta.

Mali offtopic, Laseri vise nisu tako "smotani" ko pre, postoje sasvim OK continous form printeri.
Google: "Continuous Form Laser Printers"

Samo da dodam, matricni stampaci se i dalje primarno koriste kod nas najvise zbog "drugog primerka" posto matricni primenjuje |silu" nad karbonizovanim papirom sto laser nikad nece moci da postigne.

Upravo. Matrični štampači su nezamenljivi ne samo zbog "drugog" nego i "šestog" primerka. Postoje izvanredno brzi matrični štampači koji i nemaju neki drugi mod sem DRAFTa i jedini cilj im je brzina štampe i otiskivanje u više primeraka odjednom.

Jednom sam probao da odštampam jednu EXCEL stranicu tim štampačem, što je uzelo celih 11 minuta (jedanaest minuta) uz užasne zvuke i cepanje trake (ribona).

Pazi da ne dobijes "mig na levo oko"

Sto se tice Cobol-a bas si preterao jer danas odraditi nesto u Cobolu ...... necu da komentarisem da se neko nebi nasao uvreden.
Gde moze Access da bude konkurencija Fox-u? Ti ocigledno nisi nesto radio sa Fox-om kada tako nesto mozes da tvrdis. Access je samo mala bazica ciji page-ovi rasu eksponencijalno. Ako hoces nesto da odradis moras da koristis VBA sto se ne moze smatrati nimalo ozbiljno zar ne? Dalje MSSQL Express (ali i Oracle Express) je nastao kao posledica ekspanzije opensource SQL servera tipa : PostgreSQL, MySQL ... a sta reci za MSDE 2000 koji je nuden kao free varijanta MSSQL-a?
Mnogo tehnologija za MSSQL je prvo razvijeno u Fox-u pa prebaceno u MSSQL. Dalje TSQL i nije neki mocan DB jezik (o postovanju standarda da ne pricam) naspram PL/SQL ili PgPL/SQL ... U Fox-u (v9) imas preko 400 ugradenih funkcija i preko 160 naredbi za rad sa podacima, mozes da pravis COM objekta, app module ... (sad vidis da tvoja usporedba nije rezonska)

Pa poredjenje sa Cobolom u ovom kontekstu je ispravno, oba su umiruca i samim tim diskutabilna kao preporuka novim programerima da utrose vreme i trud da ih nauce.

Nisam ja bas toliko mlad i koristio sam FoxPro i pre njega Clipper i dBaseIV (doduse nisam novije verzije FoxProa) i secam se dobro toga, ali to je i dalje u ovom kontekstu nevazno, kao i mogucnost da pises COM objekte u FOXu (koliko si ih ti napisao za ekternu uportebu?). Za "ubijanje" Fox-a nije presudno to sto u Accessu moras da koristis VBA i sto moras da uradis vise manuelnih koraka, presudno je to sto je glavno trziste FoxPro-a "RAD desktop database", sto je ujedno i trziste Access-a koji vec ima duboku integraciju sa ostatkom njihovog flagship proizvoda zvanog Office, dakle FoxPro gubi. Neke dobre stvari koje Fox ima su preuzete i ubacene u .NET platformu (LINQ koncept je jedna od njih), ali generalno Fox umire i to zapravo 2010 (2014 vazi samo za one koji pljunu lovu za dodatni support).

Inace, nemoj da se zanosimo da je sve to sto si naveo pocelo od Fox-a , to je vec previse. Fox je veci deo svoje funkcionalosti "pokrao" od dBASE-a. Na kraju krajeva, svi danasnji derivati SQLa ukljucujuci i TSQL i PL(gp)SQL su pokrali koncepte od IBM-ovog DB2. Poredjenje TSQL-a i PL/SQL-a je deplasirano jer oba sluze svojoj svrsi u okviru relacionih baza u kojima se koriste i niko ne place mnogo zbog nedostatka standardizacije, kad ni same ralcione baze nisu standardizovane, niti je i sam PL/SQL standardizovan u poredjenju sa "orignilanim" DB2 SQLom. Sam MSSQL je core svoje funkcionalnosti pokrao iz Sybase-a (i TSQL je zapravo Sybase-ova izmisljotina) i Fox nema nikakve veze sa njim, a ti mi daj konkretan primer, sta je to sto je Fox doneo novo u RDBS sto je MSSQL uzeo od njih?


PS: MSDE2000 i SQL2005 Express ne mogu da se porede jer je MSDE2000 osakacen funkcionalno za workgroup okruzenje, SQL2005 Express nije. Zasluga za to zaista i lezi u konkurenciji opensource resenja, ali to ne menja cinjenicu da je express potpuno funkcionalan i besplatan i veoma upotrebljiv za gomilu LAN resenja, ukljucjuci i multiuser finansijku bazu. Pitanje je samo sta koristiti za biznis/GUI layer.

Ti ERP-ovi su samo primer. Nešto sam gledao free ERP standalone pa sam zapamtio ta dva u Pythonu.

Ali i dalje tvrdim da sve što se radi za neki donji i srednji sloj tržišta (mala i srednja preduzeća) može da se uradi u Pythonu, čak i efikasnije nego u C# ili Javi. Python je dovoljno razvijen, dovoljno poznat (po Tiobe indeksu ispred C#), dovoljno brz (a uvek se može ubrzati sa Psyco), izuzetno lagan, sa gomilom biblioteka. Gui može da bude u blilo kojoj biblioteci (uključujući Swing, i ono što win koristi ako se koriste jython ili ironpython). Za ORM se može koristiti SQLAlchemy koji je u nekim stvarima napredniji od JPA sa TopLink implementacijom. I IBM pravi SQLAlchemy adaptere za DB2 i Informix. Kao bazu ništa jače i bolje od PostgreSQL-a tim preduzećima ne treba. Postoji i ReportLab biblioteka za pravljenje izveštaja.

Da, ali je i realna, ukoliko se ne radi o velikom projektu.



Ni slučajno. I ja i ti smo videli problem pri radu sa bazom pre nego što smo napisali jednu liniju koda. Ne vidim onda kako bi takava stvar obavezno promakla i prilikom kodiranja i testiranja, kad je problem poznat za takve situacije.



Ne bih se složio, tj. ne vidim neki veći problem.

_{[Ovu poruku je menjao degojs dana 26.04.2008. u 17:50 GMT+1]}

Microsoft je odustao od Fox-a, samim tim veliki broj programera traži alternative, novi programeri se ne odlučuju za rad sa njim.
Nije bukvalno mrtav, nisam tako ni mislio, ali svakako nema perspektivu. Sedna kao projekat prilagođavanja Fox-a .NET tehnologiji jeste interesantan ali samo odlaže neminovno (odnosno i nastao je da prebaci Fox programere na .NET).
I sam sam ga neko vreme koristio i mislim da su u njega ugrađene odlične ideje ali se pokazalo da ga je Microsoft kupio samo zbog rushmore tehnologije - i zaboravio. Čudo je i što je toliko opstao.


Python jeste vrlo interesantan ali...
Bavi li se neko na našim prostorima razvojem programa za knjigovodstvo u Python-u?
Baš bih voleo da vidim neki konkretan ali uporediv primer.

E da, u pitanju nije bilo navedeno za koju vrsta knjigovodstva se pise ta aplikacija - robno, materijalno, finansijsko, obracun zarada, osnovna sredstva, PDV, normativi, vodjenje KEPU i slicnih knjiga, izrada bilansa stanja i zavrsnih racuna, obracun zateznih kamata, kursnih razlika, carinskih stopa, itd. Pa su tu i varijante direktnog povezivanja na POS terminal i stampa na fiskalnom stampacu, pa izvoz podataka u elektronskoj formi za potrebe boniteta, poreske uprave, socijalnog & zdravstvenog osiguranja, pa specijalizovane statistike za odeljenje plana i analize i finansijskog direktora, razni izvestaji i nalozi za komercijalu i proizvodni sektor itd. Moze tu jos puno toga da se nabraja, sve zavisi od toga sta hoces da taj tvoj program radi.

Znaci, da li zelis da pises aplikaciju za neko najprostije knjigovodstvo sa najelementarnijim izvestajima, ili bi hteo da napravis objedinjeni alat za sve moguce primene u knjigovodstvu? U sustini, za neku najosnovniju varijantu, ako zelis da lici na Excel, "radi" matematicke operacije i sortira, mozes napraviti par makroa u Excelu i cuvati sve podatke u sheetovima. I to ce savrseno raditi posao za nekoga ko ima tri fakture mesecno i jednog zaposlenog. Ako zelis da pravis nesto kompleksnije, onda je potrebno da znas malo vise sta hoces od programa, osim da lici na Excel, racuna i sortira, pa samim tim mozes dobiti i konkretnije odgovore. Ja jos nisam cuo za programski jezik koji abnormalno radi matematicke operacije i u kojem nije moguce odraditi sortiranje, tako da nemoj da se cudis ako na ovom forumu ne dobijes odgovor koji si ocekivao.

Diskusija oko nacina implementacije korisnickog interfejsa nema smisla.

Prvo napravi srednji sloj/ aplikacionu logiku koja ce cucati na serveru, a onda napravi razlicite korisnicke interfejse - desktop, pda, web itd
Sve to moze da se zapakuje i u jedinstvenu desktop aplikaciju ako je takav korisnicki zahtev.

Rasprostranjena je varijanta - Java na serveru, sa JSP web interfejsom (Tomcat) ili .Net (C#) desktop klijentima.


_{[Ovu poruku je menjao cikaIvan dana 27.04.2008. u 17:24 GMT+1]}

Ako neko vec ima .NET programere koji rade desktop aplikaciju, zasto ne bi i serverska strana bila u .net-u? Ili obrnuto, ako ima Java programere, zasto ne napraviti i Java desktop stranu.

Zaista, sto da ne?
To je vec stvar licnih preferencijala.
Ako koristis Linux server, Java je verovatno logicniji izbor.
.Net klijent za desktop je verovatno lakse napisati u C# nego u Swingu i on ce se izvrsavati nesto brze na korisnikovoj Windows masini.

Mislim na liniju komandi File, Edit,View... sa padajucim listama ispod
naslovne linije u Excelu samo su to u ovom programu delovi programa,
izvestaji,.... Mislim na program koji ce obavljati sve knigovodstveno,
racunovodstveno, finansijske poslove na vise umrezenih kompjutera(robno,
materijalno, finansijsko, obracun zarada, osnovna sredstva, PDV, normativi,
vodjenje KEPU i slicnih knjiga, izrada bilansa stanja i zavrsnih racuna,
obracun zateznih kamata, kursnih razlika, carinskih stopa, itd. )
Pri unosenju podataka naprimer kontiranju u glavnoj knjizi konta se unose na
pocetku u koloni do kolone i sve se odvija u jednom redu (kao u Dnevniku -
ko se razume u knjigovodstvo) a kolone gde se unose podaci su kao u
Excelovom listu.

@mmix


Ne salim se. Zaista to mislim. Samo ce vreme pokazati da li ce tako biti. Uostalom, i sam si odgovorio zasto LINQ imas sanse, ta "SQL like" sintaksa jedino i moze da natera developere da ga probaju, da imaju bar jedan dobar deo sto imaju i sa SQL-om i jos plus nesto novo, a to novo ce biti static type checking i model podataka (naravno ovo ce ici preko nekog ORM alata), no da ne sirim pricu o ovome, posle ce neko reci da se samo izvlacim, uglavnom ovo je moje vidjanje, a da li ce biti tacno to ce vreme prosuditi.

@degojs


Izvni degojs ali brkas. Dao sam ti primer iz kojeg se vidi da brkas. Type sistem je jedno a osobine jezika drugo, i to sto je tebi kontradiktorno ne znaci i da jeste. Ako hoces i tvojim jezikom, onda bi to bilo ovako, "kudim" non static type sistem ali "hvalim" osobine "dinamickih" jezika, jer konstrukcije koje se sa njima mogu postici su zaista "mocne", i ja jesam pobornik spajanja ta dva sveta, u stvari to ti govore i ljudi poput Stroustrupa, Hejlsberg, cuces nesto poput "multiparadigm".

Ima tu jos elemenata...

Na primer, da li se aplikacija pravi od nule, ili se preradjuje par meseci ili par godina stara postojeca aplikacija? U prvom slucaju, lakse je odabrati najrazumniju opciju (da li je to .NET, Fox ili nesto deseto), dok u drugom slucaju treba ipak manje vremena da se aplikacija renovira unutar iste tehnologije (recimo sa Visual Fox Pro 7 na 8). problem sa dosta aplikacija sa kojima sam se sretao a koje su pisane u Fox-u (dos ili Windows), je taj sto su prve verzije tih aplikacija napisane u nekim slucajevima i pre vise od 10 godina, a od tada pa do danas su povremeno (ili konstantno) unapredjivane, ali na jednoj te istoj ili vrlo slicnoj platformi. U pocetku bese dBase, pa onda Clipper, pa zatim Fox, pa Visual Fox. Recimo u hotelu za koji radim vrti se aplikacija za hotelsko poslovanje, koja je napisana i Visual Fox Pro, sa klasicnim DBF fajlovima za bazu podataka. Ceo sistem bi bio mnogo efikasniji da je baza podataka na nekoj od SQL Server varijanti, ali ljudi koji su aplikaciju radili poceli su razvoj pre dosta godina, u medjuvremenu prodali izmedju 150 i 250 instalacija, i njima se ne isplati portovati sve na neku .NET + SQL platformu...

Ja sam upravo sada na pola puta da kompletiram portiovanje svih mojih aplikacija na VB.NET 2008 a koje su ranije bile pisane u VB6, dok je baza od samog pocetka uvek bila MS SQL. Dobit je visestruka (ocistio sam aplikaciju maksimalno od stvari sto planiram odavno a sto ne bih NIKAD uradio da sam ostao na VB6, povadio dosta bagova, optimizovao neke procedure tako da sada rade i preko 10x brze), jedino sto je potreban za nijansu jaci hardver. Da promena tehnologije nije bila tako velika (stari VB6 i .NET), dosta toga se ne bi desilo u skorije vreme, jer bih vrsio samo zaista neophodne izmene).

(p.s. Ja sam poceo sa clipper 5.0x, pa VB 3, 4, 5, 6, 2005, 2008)

Pa svako bi trebalo da ume da uporedi vreme i živce koje bi potrošio ako i ako ne uradi rewrite na boljoj platformi. Ako se radi kako treba, upgrade postojeće aplikacije, ma u čemu da je pisana, mogla bi da se svodi na "nekst, nekst".

Pogodnih ima mnogo.
Za desktop varijantu npr:

Borland C++ Builder (ili delphi) + access ili SQL server
ili
VB ( VB.NET ili C# ) + access ili SQL Server

Za web:

Oracle Forms + Oracle reports + Oracle

Čisto mi je čudno da se nije javio ni jedan programer u Clarionu. Oni jako vole svoj jezik i brane ga ognjem i mačem ako treba. Foxpro je htio to netko priznati ili ne mrtav no još upotrebljiv. Koliko će to dugo biti vidjet će njegovi developeri. Mrtav je i Clipper pa se još uvijek ponegdje prodaje. U prilog tome, mi smo u firmi prije 6 mjeseci bacili masu licenci, instalacija, raznih 3-party libraryja, Clipper 5.2, Foxpro za DOs i windoze, VisualFoxPro, Ultimade, dBsee... zadržali smo Delphi 7.

Koliko god recimo ja obožavao Delphi, i iako on ima podršku za sve moguće tehnologije (win32, .net, podrška za SOAP, CORBA, MIDAS, COM, WERBSNAP, INTRAWEB) vidim da lagano ugiba. Čak i unatoč stalnoj podršci, novim verzijama, novim mogućnostima. A njime se može raditi sve što poželiš, i bilo kojim pristupom. Od web-based alikacija, n-tiered programa, servisa... što god ti na pamet padne.

Meni je smislen i budućnosti okrenuta najviše Java. To je odavno i dokazano i pokazano. Tko nije shvatio - ni neće. Na žalost tu je pitanje isplativosti jave. J2EE je divna stvar, po meni je to "prava stvar" u svim pogledima, osim kad staviš na papir koliko ti treba resursa za razvoj. Kad zbrojiš koliko ti treba vremena, koliko ti treba ljudi, koliko ti treba za održavanje, i što je vrlo bitno - koliko to uopće možeš prodati i po kojoj cijeni. tu pomalo pada u vodu i onda mi se opet nameće Delphi koji može puno toga, a znatno brže i preciznije nego u drugim jezicima.

Što se tiče knj. programa osnova je brza i pouzdana baza + interface, ili ako je ikako moguće baza + aplikacijski sloj + client. i tu se sve svodi na Javu, na .net, na Delphi u nekom od njegovih oblika.

Vidio sam stvari bazirane na ajaxu, tj. spregi ssi+csi jezika i zaključih da ne nude ništa bolje riješenje nego što se to može napraviti Javom ili Delphijem.

Ako se koristi Internet bez VPN-a. tj. nekih extranet riješenja, ne treba zaboraviti ni na ranjivost sadržaja i količini prometa koja je kod SOAP-a, a da ne govorim SSI+CSI itekako izražena.

Pa da rezimiram: tko ima resursa tu je platformski neovisna, jaka, pouzdana i vječna: Java. Kome se žuri i hoće naplatiti sve što stvori tu je Delphi i njemu slični jezici.

A, ovaj, na osnovu čega tvrdiš da je Delfi efikasniji od Jave (sem na osnovu toga što si ti radio u istom)?

A zasto ne flex ili AIR + webOrb i neka baza ?

Na osnovi toga što radim u Delphiju godinama, a imam i dobro iskustvo u C-u. Recimo da sam učio programirati i uživao u poslasticama tipa TSR programa i upravljanja periferijom i kontorlerima iz Turbo C-a. 2 još u doba DOS-a. Javu sam načeo prije par mjeseci i malo testirao što i kako.

Spomenut ću banalnu situaciju, za nešto vrlo jednostavno i efikasno mada izbjegavam takav pristup: Odabereš samo jednu od nekoliko metoda pristupa nekoj od baza, postaviš komponentu za connection, za transakcije, provider, datasetprovider, clientdataset, neki query, povežeš ga na datagrid i gotovo. Eventi okidaju, većina toga se odvija automatski i stvar je uglavnom riješena. A to napraviti u Javi? Ne znaš hoće li ti trebati više vremena da napraviš nešto upotrebljivo u Swingu što će ispravno hvatati kojekakve evente tj. signale ili ćeš krotiti JvTable. Ili ćeš se pak baciti na neki framework tipa Springa, Hibernatea i sl. A ako hoćeš punu snagu i moć Jave, baciš se na izradu zrna za aplikacijski server tipa Glasfisha ili Tomcata, pa onda još razvijaš i nekakvo web ili GUI sučelje i to sve ide sporije u odnosu na Delphi. Pogrešno si me razumio, ja kažem da je Java fantastična stvar i definitivno jedan od igrača budućnosti, no nije za one-man-band programiranje i nešto gdje treba brzo pokazati rezultate. Ja u Delphiju u par popodneva mogu stvoriti itekako efikasan program, za što će ti u Javi trebati znatno više. A moje je skromno mišljenje da će se i native kod uvijek brže izvršavati od raznih među-kodova kao što su Java ili .net . I kao što sam već spomenuo, objeručke bi prigrlio javu kad bi njom idući tjedan mogao uspješno zaraditi svojem djetetu za hranu jednako vješto kao i Delphijem. Smatram da je najbolji jezik onaj koji najbolje poznaješ. Tako sam ja u Delphiju koristio BDE i IBX. Sad se evo selim na nešto ozbiljnije i perspektivnije pa ćeš i naći na nekom od ovih podforuma moje bedasto početničko pitanje o radu s DBX jer sam u toj tehnologiji zbilja početnik. Slično tome je i Java. Ne tvrdim da je sporija, meni je sporija jer nemam za nju razvijene sisteme, rutine, štoseve i trikove koje mogu brzo iskorisiti.

@negyxo: apsolutno si u pravu!

@lukeguy: ne znam koji je tvoj razlog za odbijanje apsolutno nepobitne cinjenice a to je da su desktop aplikacije vec uveliko pocele da evoluiraju u web aplikacije i da ce u veoma skoroj buducnosti desktop aplikacije biti dinosaorusi u svetu kompjutera. Ne samo Zoho i Google Docs vec sam negde procitao i da je Photoshop vec izasao kao beta web aplikacija samo ne mogu da se setim gde je taj clanak. A uskoro ce i dial-up biti nesto sto sluzi za nedajboze jer ce brzi internet biti u svakom domacinstvu kao sto je sad telefon.

Ako sam ja sam uspeo da napravim da Preferans (http://www.preff.net) u AJAX-u, i to bez ikakvog iskustva sa JavaScriptom, zasto neko ne bi mogao jedan knjigovodstveni program u kome je em interaktivnost drasticno manja em nema potrebe za nekakvim kolaborativnim azuriranjem, a i to bi moglo bez problema.

U svakom slucaju, sada vec postoje JS editori ili JS plugin za Eclipse i slicno i vreme potrebno da se nesto uradi je sasvim uporedivo sa drugim programskim jezicima.

I GOTOVO??? Pa meni u Java treba 5 minuta da sve to odradim i to sa Hibernate??? A ovo sto si ti napisao ja bih skocio kroz prozor da moram da uradim, svega mi!



Idi??? A u Java eventi spavaju ili su na odmoru pa moras da ih tuzis da bi odradili svoj posao???



Pa sve ionako ide na web tako da ne vidim sta hoces da kazes??? I ne znam zasto rec "nekakvo"??? Nego posalji ti jedan mail Google-u i eBay-u da ne znaju sta rade i da batale Java zbog radi Delphi-ja... Stvarno ti je ceo ovaj deo vise nego bezveze, uvredljiv za sve Java programere i po meni za programere uopste. Neosnovano napadas nesto sto si i sam u pocetku napisao da ne poznajes!



APSOLUTNO NETACNO jer ja mogu u Java da napravim isti program za manje od par popodneva. http://www.kvizolino.com sam ceo napravio za dva tri popodneva, koliko bi ti trebalo za to u Delphiju???



Da, pa? Program pisan u Assembly-ju radi brze od drugih, u Masincu jos brze, pa? Da batalimo sve jezike i vratimo se na kartice? Postoji razlika izmedju "brze" ili cak "mnogo brze" i "zanemarivo brze". To sto kompjuterski moze da se izmeri da nesto radi 1000 puta brze nije uopste bitno ako je ljudima i ta sporija varijanta prebrza. Drugim recima, ako je nesto prebrzo ili "dovoljno brzo" sve sto je brze je "zanemarivo brze".



E, napokon se apsolutno slazemo! Ali ako tako smatras onda sve ovo gore napisano nema osnova. Jer mozda je tebi licno tesko nesto napraviti u Java ali si se raspisao i iznapadao Java kao da je to univerzalna istina a ne tvoje licno iskustvo ili problem. Ja recimo imam identican problem sa Delphijem, i najverovatnije ga necu nikada ni uciti kako treba, ali sigurno necu nikada reci da je apsolutno lakse, brze ili bolje programirati u Java ili da Delphi ne valja po bilo kojoj osnovi!!!

_{[Ovu poruku je menjao preff.net dana 01.05.2008. u 11:36 GMT+1]}

Za malo da zaboravim, kad vec spominjes Hibernate: sa Hibernate-om ne moras da poznajes SQL ili DB2 ili PostgreSQL ili bilo koji drugu DB sintaksu!!! Sve se radi sa klasama i metodama kao i ostatak Java programa! Drugim recima ne treba ti provider, datasetprovider, clientdataset, neki query i datagrid... U jednoj klasi podesis parametre za konekciju i "Vozi Misko"...

.net (VB.net , C#)
prednosti - brza izrade projekta
mana - rad samo na windowsima

Java
prednost - rad na više Os-ova sa manjim modifikacijama
mana - duža izrada projekta


Python

prednsot - jednostavnost, radi na više Os-ova
mana - nepostojanje kvalitetnog GUI-a kao što je VS, ako bi se pisalo ručno, duža izrada projekta

može se integrirati u VS, ali opet radi onda samo na win.


ako misliš koristiti aplikaciju samo na windowsima, onda preporučam C# + mysql.

_{[Ovu poruku je menjao MarkoBalkan dana 01.05.2008. u 12:36 GMT+1]}

Hm, ne postoji prebrza aplikacija.

Na primer, stara aplikacija (VB6+MS SQL 2000) za obradu plata koju prodajem vec nekih 4-5 godina radila je na prosecnom P4/256Mb/40Gb racunaru izmedju 5 i 10 zaposlenih u sekundi. Nova aplikacija na VB.NET 2008 + SQL 2005 radi na istom racunaru izmedju 20 i 90 zaposlenih u sekundi. Da li je to zbog nove i bolje tehnologije, ili zbog toga sto sam radi rewrite cele aplikacije od nule, ne znam. Za radnu okolinu sa 50 ili 100 zaposlenih i jedna i druga aplikacija su savrseno upotrebljive. Medjutim, sada pregovaram sa jednom drzavnom ustanovom koja ima izmedju 30 i 35,000 zaposlenih, i ti je ubrzanje izmedju 300% i 1000% i te kako znacajno.

sada pregovaram sa jednom drzavnom ustanovom koja ima izmedju 30 i 35,000 zaposlenih, jel to neka Omladinska Zadruga :)



30 ili 35.000

hahahha

Pazi, LINQ je mocna stvar, LINQ for SQL jos mocnija (ukljucuje i taj famozni ORM u 1:1 obliku da bi preneo relevantnu DB shemu u aplikacioni domen), ali LINQ nikad nece istisnuti SQL jer jednostavno nije niti ce ikad biti toliko "mocan" kao (T)SQL. I koji god ORM da izaberes (EntityModel, LLBLGen, XPO, etc) svi oni tvoje operacije na kraju svode na SQL instrukcije, cak i sam LINQ for SQL u stvari prepevava tvoj LINQ query u SQL query. Nista to ne donosi fundamentalno novo, samo dopunjuje SQL u toj meri da (kao sto si rekao) daje strong type checking slican onom koji dobijas kroz typed dataset i omogucava lakse ucitavanje i/ili offline pretrazivanje objektnog modela (sto je samo po sebi ql i meni dovoljan razlog da ga koristim). Ako pod zamenom podrazumevas to da developeri nece morati da pisu SQL kod, onda si to vec imao kroz DataSet-ove (prevuces tabelu u dataset i visual studio ti izgenerise sve CRUD skripte), znaci opet nista novo samo malo "ispeglanije".

Iako LINQ for SQL ima svojih problema (npr sa subquery-em, server side funkcijama, forsiranjem query lock hintova, itd), i ja mislim da ce evoluirati dalje (sledeci korak bi bio podrska za sql2005 CLR i mogucnost koriscenja domenskih metoda u linq query-ima), ali stvarno ne vidim smrt SQL-a kroz LINQ. Maksimum sto ce se desiti je da pored SQL na serveru zazivi neka vrste remotinga koji ce marshalovati semu baze i primati IQueryable i vracati server site entity objekte tako sto ce IQueryable objekat odmah upucati u query execution engine cime ce se zaobici SQL kao jezik. Medjutim, toliko postoji trenutnih primena za SQL da ce se u najboljem slucaju server side LINQ i SQL naci rame uz rame. A od toga smo jos podosta godina.

@preff.net , pogrešno shvaćaš moje posteve i krivo tumačiš njihovu bit. Ne napadam Javu, čitaš li pažljivije vidjet ćeš da vrlo cijenim Javu, sve njene mogućnost i osobito njenu budućnost. Istovremeno govorim zašto je MENI npr. Delphi bolji od Jave za stvari koje ja trebam (bilo poznavanje jezika, bilo naplativosti, orpavdanosti...). Hibernate dovoljno poznajem da o njemu mogu donjeti svoju prosudbu no ni ne želim je napisati jer će opet biti da Javu dočekujem na nož; u svakom slučaju više cijenim native pristup bazama.

Rekao bi da ovo nema veze sa VB6 i VB.NET, vec sa SQL upitima.
Znaci ili si optimizovao SQL upite ili je MSSQL2005 deset puta brzi od SQL2000.

PHP uopste vise nije toliko labav da se iskoristi za taj tip web aplikacije ;)

Mozes da koristis kao bazu mysql bez da se brines.

A kao alat koji je jako dobar za taj tip aplikacije koristi ATK www.achievo.org/atk

Poseduje sve sto je bitno za rad sa bazom, pritom ti pruza veliku mogucnost da manipulises tabelama plus je vrlo lako napraviti CRUD u njemu za celu bazu.
Sa svega par linija koda imas totalno funkcionalan sistem.
Uostalom pogledaj njihov demo i sve ce ti se samo kasti ;)

Em je free, em ti netreba nista osim apache servera i php-a ;)
Plus sve java scripte su vec odradjene kao i java podrska.

Moj savet ako hoces tako nesto da pravis je da obavezno pogledas ATK.

Ne bih da ulazim u diskusiju koji je programski jezik bolji jer mislim da svaki ima svoje prednosti u određenoj oblasti primene, pa bih ti recimo preporučio Clarion (koji je koliko sam primetio tek jednom malo pomenut).
Isključivi razlog je što ga pominjem je što ga u praktičnoj upotrebi poznajem mnogo bolje od nekih drugih koje koristim i naravno, što na osnovu toga mislim da je za primenu u knjigovodstveno-računovodstvene namene odličan izbor.
On nije sada ni najmoderniji ni najefikasniji u mnogim aspektima ali omogućava prilično korisnih stvari:
- vrlo brzu izradu aplikacije (predstavlja pravi RAD alat u svakom pogledu)
- potpuno je objektno orijentisan odavno a naročito od ver 6.x
- sa veliko većinom RDBMS sistema se povezuje kroz native drajvere, a sa ostalima preko ODBC
- radi samo pod Windowsom ali na svim verzijama bez značajnih problema
i naravno što u isto vreme može da se napravi i desktop i web aplikacija iz istog IDE okruženja
Matematičke, statističke i neke druge mogućnosti u vezi sa optimizacijama i kompajliranjem koda ne bih posebno navodio obzirom da na današnjem hardveru skoro sve radi dovoljno brzo za knjigovodstvo bez posebnih zahteva jer je u većini slučajeva za ovakve aplikacije glavno ograničenje brzina rada operatera što nikakve veze nema ni sa programima i računarima.
Neko je ovde naveo i neke brojke koliko stavki operater u fakture i slično može da unese u program i to je verovatno tačno (nisam nikad merio). Ja bih samo pitao da li u jednom dobro projektovanom sisitemu za automatizaciju poslovanja neke firme neki operater uopšte treba da unosi takve podatke (osim možda ako je to firma koja se bavi pružanjem knjigovodstvenih usluga).

Taman kad ga naučiš shvatićeš da si usput naučio ključne elemente iz većine danas aktuelinih programskih jezika od widows sistemskih fukcija, asemblera C++ pa do .Net varijacija i jave.

Hajde sad reci da si se salio... :)

@mmix
Da, SQL nece jos dugo umreti kao takav ali ocekujem da ce se promeniti njegova direktna upotreba, tj. "front end" ce biti LINQ za developere a posle ko zna.


Ja mislim da ce upravo tako nesto slicno da urade, lepo dobave "expression tree" od developera koji napise LINQ "against" EF modela (gde ce lepota biti sto nece biti kao LINQ to SQL 1:1 nego apstrakcioni model) i to se posalje execution engine-u koji ce znati kako izgleda EF model posto ce sam EF model biti ono sto su sada tabele na SQL Server-u (i vise) tj. ugradjen na SQL serveru, naravno ovo je sve po nekoj vizij MS-a, a do ovoga ce trebati dosta vremena.

Ovo ce sve znaciti da imamo model, model koji se na jednom mestu menja, static type checking prilikom query-ovanja tog modela i samim tim sve dosadasnje stvari koje izgledaju samo jedan korak vise ce nestati, tipa, kada izmenim schemu baze ne zelim da isto to prepravljam i nad DataSetovima, kada izmenim schemu baze ne zelim da ponovo trcim kroz sve qyueriju da vidim da li su validni, kada pisem neku f-ju koja mi treba u programu i identicna funkcionalnost mi treba i u SQL-u ja treba da je napisem u T-SQL ili da je importujem preko CLR integracije itd. ubudjen sam da ce jos hiljade drugih razloga proizici zato ce ovo biti dobro, _{kao i zato ce biti lose :)}

Mislim da je najbolje za tebe da taj program pises u COBOLu.
Zasto ?
Zato sto ga ja super znam.

za***i MVC, visenivojske arhitekture, reusability, sva ta inzenjerska sranja. To ti nista ne treba.
Ja nemam bas mnogo skole, ali imam mnogo godina iskustva s COBOLom. Poslusaj zato moj savet.
COBOL!

@MarkoBalkan:
Java
prednost - rad na više Os-ova sa manjim modifikacijama
mana - duža izrada projekta

Šta ste se navrli na Javu toliko??? Kao prvo ne znam na kakve modifikacijame mislis? Nisam do sada morao da bilo sta modifikujem da bi radilo na Linux-u ili Mac-u? Programiram u Javi i startujem na bilo kom OS-u.

I opet šta znači "duža izrada projekta"? Ne postoji jezik u kome ću brže da izprogramiram malte ne bilo ta nego u Javi! Pa opet ne tvrdim da je u Javi najkraća izrada samo zato što to jeste slučaj kod mene. Svako ima svoje viđenje i svoje mišljenje ali reći da je GENERALNO duža izrada u Javi je glupost i dovodi samo do zbunjivanja onog ko je pitanje postavio. Dakle nije tačno da je u Javi uopšte duža izrada nekog projekta, već je naprotiv kraća!



Pa to je sve OK, imaš svoje mišljenje o Hibernate i imaš svoje mišljenje o Javi, ali ona dva posta na koja sam ja komentarisao su, isto kao i MarkoBalkan iznad, zvučali generlano i apsolutno. To što ti, ili bilo ko drugi, više voliš ili ti je lakše da koristiš neki drugi programski jezik to je super i ja to cenim! Ali ja neću nikad reći da PHP ne valja ili nešto drugo loše zbog toga što ga ja ne koristim i što više volim JSP... Nije ni bitno, reagovao sam jer su postovi, barem meni, delovali kao da izjavljuju isto što i MarkoBalkan, neku generalnu izjavu koja je u suštini samo njegovo lično iskustvo...

kolko redova ti treba za čitanje iz jedne tablice iz baze i prikazivanje u datagridu?

kod jave moraš posebno učitati kolone i redove, dok recimo kod .net-a ne moraš.

kod jave moraš staviti u nekim situacijama try-catch blok dok kod .net-a programer određuje.

itd....
istina svatko je onoliko brz koliko zna!

ja sam program za knjigovodstvo radio u PHP-u, ne razumem zasto ne moze script jezici da se koriste

Oracle definitivno najbolji.Po mom misljenju ima najrazvijeniji interfejs.

kad se kaze Oracle misli se na bazu podataka
inace, sam Oracle (preduzece, ne baza) gura Javu

znaci, ti predlazes Java kao jezik i Oracle kao bazu?

Ne od uvek, JDeveloper je u sklopu Oracle Developer Suit-a tek od skoro, skoro sve legacy Oracle aplikacije su radjene u pretecama ODSa koji su se zvali SQL*Forms i SQL*Reports, sto se uglavnom u skorije vreme dopeglalo u Oracle Forms i Oracle Reports, svejedno Jave tu nigde nije bilo. Funkcionalno najblize ovom konceptu je recimo Fox.

Malo sam off sto se oracla tiche, ali JDeveloper postoji vec sigurno 7-8 godina, a koliko znam Forms i Reports su na Javi od verzije 9 (baze)... ali moguce da nesto nisam shvatio dobro.

Priznajem da je "tek od skoro&q