 |
|
Eestlaste OSS veebiraamistik
postitas mauri edukas-tartu-firma-punkt-eu osak. 15:32 13. aprill, 2006
Tundmatu Sõdur kirjutab: "Eestlaste tehtud Javal põhinev veebiraamistik Aranea Web Framework. Tegemist hierarhilise MVC kontrolleriga, millel kaasas ka HTML vaba JSP 'tag library'. Süsteem lubab lihtsalt luua ja hallata mitmetasandilisi voogusid, ehitada keerulisi kasutajaliideseid. Ausalt öeldes seal on välja toodud veel imelikke plusse, mida ma ei suuda tõlkida. Uurige ise. Aranea veebiraamistik. Andsin juba oma panuse: Digg it!
< Mälupulgad ja relvajõud
| Varssavi pakti saladused >
| |
| | |
|
Eestlaste OSS veebiraamistik
|
Logi sisse/tee kasutajakonto
| Top
| 44 kommentaari
| otsi arutelust
|
|
|
|
peenes kirjas:
Järgmised kommentaarid kuuluvad nende autoritele.
Meie ei vastuta nende eest kuidagi.
|
Eestlasi ei paista tegijate hulgas just eriti olevat, aga see selleks.
Mainimist väärinuks aga, et tegu on AS Webmedia poolt kergitatava asjaga.
|
|
|
[ vasta sellele | artikkel
]
|
|
Mismõttes? Ma uurisin toda lehte ja leidsin sealt 5 WebMediaga seotud nime. Ja Eesti keelt peaks nad kõik rääkima.
Igastahes tundub olevat WebMedia poolt enda tarbeks arendatud veebiframeworkiga ning keegi arvas, et on mõttekas see avalikustada. Et, kui OSS siis saab seda arendada tasuta. Kui asi on hea, siis võidavad ju tegelikult kõik. Aga...
Lugesin dokumentatsiooni... vaatasin presentatsiooni .... tutooriale... aga ikkagi tundub asi kahtlaselt kohmakas, nagu kõikidele Java veebiframeworkidele kombeks. Liiga palju konfimist ja müra.
|
|
|
[ vasta sellele | artikkel
]
|
|
|
tegu ei olegi m6ne wiki v6i cms-ga et viskad serverisse kolme hiireklikiga ja ongi valmis :)
|
|
|
[ vasta sellele | artikkel
]
|
|
|
Tõepoolest Javas see on kombeks, kuid kui sul on 3-aastane projekt, kus osalevad 30 inimest, siis mis vahe on selles kas konfigureerimisele algusel läheb 15 mintsi või 2 päeva?
|
|
|
[ vasta sellele | artikkel
]
|
|
Vaata, Javas on teil kombeks jah 3-aastased projektid, kus osalevad 30 inimest...
;)
|
|
|
[ vasta sellele | artikkel
]
|
|
Ülemise kommentaari autor on tõenäoliselt Webmedia töötaja...
Seega ütleme otse välja mis vahe on. 2 päeva on mingi 16 töötundi. See 16 programmeerija töötundi läheb kliendile maksma 16000 krooni.
15 minutit maksab "natukene" vähem.
Aga, noh, jah, programmeerijal on pohhui. Tema saab kätte 50 eeku tunnist ju. Tal pole tõesti vahet.
|
|
|
[ vasta sellele | artikkel
]
|
|
Esiteks, keegi eestis ei maksa 1000 eeku tunnist
Ja teiseks, mingi kolmemillise projekti juures on 16000 köömes. Kohvi toomise ja kusemise peale kulub juba 100000.
|
|
|
[ vasta sellele | artikkel
]
|
|
|
Imho sellise konfihulgaga frameworki puhul on konfimisele kuluv aeg seoses projekti pikkusega. Ütleks, et konfile kuluv aeg on startup konfimine(2-4 päeva) pluss umbes 1% projektiajast. Ja sellise pideva kümne konfifaili haldamisega kaasneva frustratsiooni hinda ei taha hinnatagi.
|
|
|
[ vasta sellele | artikkel
]
|
|
|
|
Miks peaks üks normaalne, terve mõistusega ja tugev Eesti mees Javaga veebi tegema?
|
|
|
[ vasta sellele | artikkel
]
|
|
Sesmõttes, et põhimõtteliselt on ka mul sama küsimus. Ise kriban praegu kahte projekti RoR'ga ( http://www.rubyonrails.org/ ). 5 päeva nädalas teen veebiäppe ka ASP.NET + C# keskkonnas (noh enterprise/scalable/business/support bla-bla you-know). Ja mulle tundub, et isegi selles on veebi teha märkimisväärselt mugavam, kui Javas. Olgugi, et tegu on Microsofti vaimusünnitisega.
Selle 3a 30 inimese kohta, et võibolla saaks asja valmis 2a ja 20 inimesega, kui kasutataks mõnda sobilikumat keskkonda/frameworki?
|
|
|
[ vasta sellele | artikkel
]
|
|
ja kuidas see müügile kasuks tuleb ? :) progejatel ju vaja kõhud täita ja riided selga teenida. lisaks serverite ja muu nänni müügi pealt boonus otsa ja ongi olemas.
lihtne poiss teeks asja poole aastaga php's valmis ja rahu majas.
|
|
|
[ vasta sellele | artikkel
]
|
|
Milliseseid Java web frameworke oled kasutanud?
Ehk viitsiksid panna kirja RoR, ASP.NET, ning Java plussid ja miinused?
|
|
|
[ vasta sellele | artikkel
]
|
|
ega jah eestis ongi ju enamus "programeerijad" suvalised PHP mäkerdajad. ei saagi oodata et nad oskaks või saaks aru kuidas javas või mõne muu keerukama keelega veebi teha.
aga noh alati on ju kõige lihtsam kohe tundmatu asi maatasa teha.
Üldiselt kui ei tea Java veebivõimaluste kohta midagi, siis pole mõtet ka eriti paukuda.
|
|
|
[ vasta sellele | artikkel
]
|
|
Jah, väga paljud "põlve otsas tegijad" teevad PHPga ja nende teadmised piirduvad tavaliselt selle (küllaltki võimsa) keelega.
Samas, keskmine suurfirmas töötav Java neeger ongi Java neeger -- ka tema pole muuga kui Javaga kokku puutunud.
Seega mõttetu hüppamine on siin mõlemal poolel võimalik. PHP neeger kiidab PHPd ja Java neeger kiidab Javat. Nii ta ongi.
Samas juhin tähelepanu, et eelpool mainiti C# ja .NET'i ja RoR'i jmt. Nii et tegu ei ole ei PHP ega Java neegriga :)
|
|
|
[ vasta sellele | artikkel
]
|
|
[flame]
mina olen n.o. keskmine javaneeger suurfirmas, ja mul on kogemused paljudes keeltes, v6ix isegi 8elda, et suured kogemused. n2itex php's, v2hemal m22ral C++'s ja javascriptis (etc. etc. etc.) ja mind ei k6iguta yldse see, kui mul j2rsku k2stakse teha midagi mingis uues keeles. sest olgem ausad, php, C, Java, C# on k6ik sugulased ja vahe on ainult syntaksis (v2hemal m22ral) ja API-s.
kui ma midagi kardaks, siis tegu oleks funktsionaalsete ja loogiliste programmeerimiskeeltega, st. keeltega, kus on vajalik hoopis teistsugune m6tlemisviis.
kui ma millegip2rast peaksin jaavat kiitma, siis ainult sellep2rast, et PHP on vigane ja C# on java pealt maha ahvitud.
aga tegelikult on see k6ik maitse asi ja maitse yle ei vaielda vaid kakeldakse.
[/flame]
ja muide, enamustest "p6lve otsas nikerdajatest" v6ivad saada korralikud inimesed. minuga v2hemalt juhtus nii. keegi ei synni programmeerijaks, selleks 6pitakse.
|
|
|
[ vasta sellele | artikkel
]
|
|
No ma ei tea. Kuigi ka mulle ei meeldi PHP mäkerdajad siis sinumoodi tüübid on sama "ohtlikud".
Alati te vabandate asju mis on mõttetult keerukad ja egotripite selle peal, et lasete endale halva tehnoloogia poolt p-sse panna. Täiesti arusaamatu.
Kogu sellest teemas pole oluline, mis on parim kas Java, PHP, Rails. Point on selles, et enamik vanu Javamehi hakkavad sinumoodi enterprise möga ajama. Asi on suhtumises mitte keeles.
Rails on arhitektuurilt väga sarnane j2ee'le. Ainuke vahe on selles, et kus ühes on konfiguratisioon on teises konventsioonid + vajadusel konf.
Ehk selle asemel, et siduda läbi 3 xml'i näiteks EditController.java ja Edit.jsp, saab Rails sellega ise hakkama. Mõttetute konfifailide vältimisega tuleb mitu plussi. Esiteks tööd on vähem, mistõttu saab rakenduse varem valmis. Teiseks kuna konventsioonid aitavad lihtsamalt probleemi lahendada ja ei leidu progejat kes hakkaks omaloomingut tegema kuna see eeldaks käsitsi konfimist. Kolmandaks, kui progejad ei pea konfimise ajun***iga tegelema on neil parem tuju ja nad suudavad teha kvaliteetsemat koodi ja kirjutada teste(kusjuures testide kirjutamine on railsis läbimõeldud ja hästi toetatud, erinevalt j2ee frameworkidest ).
Ja kõik see jutt ei ole Railsi kiituseks ja Java laimamiseks. Ma arvan, Javas saaks enamik asju peaaegu sama lihtsaks teha, kui oleks ainult soov ja puuduks tüübid kes hakkaks keerukuse peal egotrippima. Ruby dünaamilisus ja metaprogemise võimalus ei anna Railsile nii suurt eelist kui Railsimeeste suhtumine.
Ahjaa, olen kuulnud ka Java frameworkidest kus on arendajale mõeldud aga kuna ma pole neid ühtegi kasutanud siis tõin võrdluseks Railsi.
Ja, infoks, osa minu päevatööst on igasugu j2ee frameworkide peal rakenduste loomine. Ja ma olen õnnelik, et see pole mu põhitöö, enamik tööd on puhtas Java's.
Ehk siis, Java pole süüdi, et Java frameworkid sitad on. Süüdi on mehed kes neid propageerivad ja loovad.
|
|
|
[ vasta sellele | artikkel
]
|
|
|
Sellele võiks vastata vastuküsimus(t)ega. Miks ei võiks veebi Javaga teha? Milles siis veel veebi teha kui mitte javas? Ma pean silmas profi tasemel tegemisest...
|
|
|
[ vasta sellele | artikkel
]
|
|
Esimesele küsimusele vastaks, et Java on liiga kohmakas ja Javas veebi arendamine võtab liiga palju aega.
Java oli tore keel nii 90ndatel umbes kui polnud sama võimsaid alternatiive kusagilt võtta. Tänapäeval on tohutu hunnik igasuguseid alternatiivseid, lihtsamaid ja võimsamaid keeli ja frameworke peale tulnud.
Milles siis veebi teha kui mitte Javas? No võta kasvõi Zope ette. Võimas Pythoni põhine framework. Või siis Ruby on Rails näiteks.
Sa pead silmas profi tasemel tegemist...? Kes on proff? Inimene, kes on Javas arendanud juba aastaid? Tema on Java programmeerija. Ta on Java professionaal. Ta elab oma maailmas.
"Profi tasemel" tegemine on säärane tegemine, mis suudab lõpptoote valmistada kiiremalt, lihtsamalt ja elegantsemalt kui teised. Seejuures on lõpptoode vastupidavam kui teistel.
Javaga sa ei tee kiiremalt, sest overheadi on liiga palju:
1) Vaata ülespoole kus üks inimene väitis, et konfimiseks läheb kaks päeva mitte 15 minutit. Märksõnaks siin Agile, kui tahad buzzworde külge kruvida.
2) Omast kogemusest: ülikoolis sai Javaga Point of Sale süsteemi aretatud mingite imevidinatega. Vist kokku üle 10k rea koodi ja terve semester väikses grupis. Teise otstarbega aga umbes sama keeruka vidina aretasin töö juurde Pythoni ja ~600 rea koodiga, mis tekkisid ühel nädalavahetusel. Kusjuures kasutasin asju mida ma polnud varem näppinud.
Javaga sa ei tee lihtsamalt, sest koodi hulk tähendab juba tohutut keerulisuse kasvu. Lühemalt on võimalik sama asi kirja panna. Ja tunduvalt hoomatavamalt.
Java on üks pirakas dinosaurus. Palju paremaid, kaasaegseid alternatiive on olemas.
Javaga sa ei tee "profi tasemel" -- see et sa käid iga päev kontoris ja oled seal käinud juba paar aastat ei tee sinust "professionaali", see teeb sinust heal juhul Java professionaali.
"Profina" veebi tegemine tähendab heade tulemuste saavutamist lihtsalt ja kiirelt. Java ei ole selleks kaugeltki mitte optimaalne keel.
|
|
|
[ vasta sellele | artikkel
]
|
|
Tere,
Ehk oskaksid esile tuua konkreetsemad põhjused?
Dünaamiline tüüpimine? Kompileerimisfaasi puudumine? Funktsionaalprogemise elemendid (list comprehension, lambda)?
Millest tuleb see kuni 10x võit? Veebikihis? Ärikihis?
Ehk räägiksid detailsemalt 10 KLOC Java/POS ning 600 LOC Python/? rakenduste funktsionaalsusest?
Kas tekkinud koodi sai hallata? Kas sellist lähenemist saab rakendada suuremas meeskonnas (5+)?
|
|
|
[ vasta sellele | artikkel
]
|
|
Sinu postitus meenutas mulle niiväga järgnevat lõiku mingi USA ajalehe arvamusküljelt:
"The theory of evolution does not and cannot explain so much about the universe that we know. For instance, when and how did water evolve? How does it happen that gravity can hold us to the Earth, and at the same time allow us to step up without any trouble? How did it happen that the Earth is spinning at the exact rate that keeps us from feeling that movement?
I find it much easier to believe that Genesis tells us the truth of the creation when we know from God's own Word that nothing is impossible for him to do."
|
|
|
[ vasta sellele | artikkel
]
|
|
|
|
Suht mannetu diskussioon käib siin. Küsimus on, et miks peaks seda freimworki eelistama teiste olemasolevate ees.
|
|
|
[ vasta sellele | artikkel
]
|
|
See pealkiri tollel Digg'i lool tundus mulle väga imelik. Et nagu, siiamaani progesid Webmeedikud veebi goto-lausetega? (Uuu? 21 sajand on saabunud!)
Aga noh, tore ju, et enam ei pea mõned inimesed goto'dega veebi progema... Kuni IT-neeger avastas hämmastava tõsiasja [wordpress.com]!!!!11~
|
|
|
[ vasta sellele | artikkel
]
|
| |
|
web tehakse enamjaolt milleks ? ... klientide jaoks, kel on sügavalt ükskõik, millist frameworki või vmspajebennteadmisi sa selle jaoks kasutasid, eksju ? inimene teeb, milles tal on mugavam, klient kasutab, mis on kiirem... ja tehnoloogilise blablaa üle võivad #insenerid# omavahel jahuma jäädagi.
|
|
|
[ vasta sellele | artikkel
]
|
|
|
Pealiskaudsel vaatlusel võib see nii tunduda, aga keegi peab selle ka valmis tegema ja kui on vähegi keerulisem tükk, siis on ülioluline, mis raamvärgi või süsteemi peale asi on rajatud. Arenduse kiirus (ja kulud) sõltuvad sellest väga otseselt.
|
|
|
[ vasta sellele | artikkel
]
|
|
|
|
Tüüpiline. Kohe läks lahti flame war teemal, kas parem on Java või Python... Alustada võiks mu meelest sellest, et endale selgeks teha, mida tähanedab Java ja mida J2EE... Aga noh, mis nüüd mul, lihtsal inimesel, ka gurudele öelda on :)
|
|
|
[ vasta sellele | artikkel
]
|
| |
Tundub et iga vend kiidab siin seda tehnoloogiat, millega kõige rohkem tegeleb, mida rohkem lühendeid ühte lausesse kokku suudetakse pritsida seda kõrgemale pilve peale ego tõuseb.
Selles huvitavas diskusioonis on märkimata jäetud see, et lõpptulemus ükskõik mis keeles veebi programmeerides on sama - HTML (võibolla ka natuke JS ja CSS-i).
Mina ei oleks nõus arendama 6 kuud mingit vidinat mingis X tehnoloogias kui väljundiks on seesama HTML, mille suudaks tehnoloogiliselt kirjutada valmis 3 päevaga miksides tavalist algaja-stiilis HTML-i ja PHP-d. Kvaliteet muidugi omaette teema, a kui ma ütlen kliendile vidina hinnaks 100k või 1M, siis kardan et klient valib siiski 100k maksva jubina.
Põhimõtteliselt võiks ju kirjutada 50 aastat 100mehelise meeskonnaga mingi frameworki asmis valmis, täiesti võimalik ju saab n korda kiirema vidina kui java tehnoloogia eales olla saab.
|
|
|
[ vasta sellele | artikkel
]
|
|
|
Kõik oleneb projekti mastaapidest. Suvalist poekest ja B2B marketplace'i veavad erinevad tehnoloogiad.
|
|
|
[ vasta sellele | artikkel
]
|
|
Jaa jaa - jälle see "skaleeruvuse" argument. Ma tõesti ei mäleta, mitu korda kuus ma seda kuulen.
Tüüpnäited (reaalsed): Alguses on kellegil üleval pool (või kliendil) mingisugune ülioptimistlik visioon, et mida junn võiks tulevikus teha ja mida kõike võiks sinna hiljem veel külge "integreerida" (see süsteem ja see süsteem ja see funktsioon jne). Liiga palju "what if" olukordi. Valitaksegi siis mõni selline "sobiv" tehnoloogia: J2EE / ASP.NET (tegelikult suvaline framework/keel kombo, mille taga on mõni suurfirma ning millel on ka ropult pappi, et promo/haipi teha). Suure vaevaga tehakse kohmakas jupp valmis ja siis jääb arendus põhimõtteliselt soiku. Kliendi poolelt hakkab asi venima. Nad leiavad, et seda ja toda polegi neile lähemal ajal vaja. Näiteks kirjutatakse asi mitmekeelseks (see hea muidugi), aga praktikas ei tõlgita mitte kunagi seda teise keelde. Asi kirjutatakse andmebaasist sõltumatuks (see hea muidugi), aga reaalsuses ei muudeta andmebaasi tarkvara selle junni kasutusajal kordagi. Ja tihti pole need isegi kliendi nõudmised vaid arendajad ise mõtlevad, et nii saaks nad tulevikus oma elu kergemaks teha. Samuti aetakse lahendus keeruliseks mingite keeruliste template'de jms, et hiljem oleks kujundust kergem muuta (ei mõtle siin lihtsalt CSS failide muutmist). Reaalsuses ei muudeta jällegi lehe kujundust kaua kaua ja kui kord peaks ka see aeg kätte jõudma, siis ikkagi on kogu backend pool niivõrd kasutajaliidesega seotud, et vaja kõik uuesti ringi kirjutada (+ see võib sisaldada väga palju obsolite kräppi, mistõttu on lihtsam nullist uuesti kirjutada). Ja siis lisatakse veel mitu layerit abstraktsiooni, et asi veelgi keerulisem (aeglasem) oleks. Kliendi raha muidugi.
|
|
|
[ vasta sellele | artikkel
]
|
|
miks troll?
võibolla liiga kibestunud toon, aga täiesti õige jutt. olen täpselt samasuguseid situatsioone ja "projekti elutsükleid" üle elanud.
|
|
|
[ vasta sellele | artikkel
]
|
|
|
Vägagi, sest antud juhul tundus olevat väide stiilis: LAMP on nuuparitele ja põlve otsas nikerdajatele ning J2EE on "tõsisemate" asjade tegemiseks.
|
|
|
[ vasta sellele | artikkel
]
|
|
|
Seda, et klient ei tea, mida ta saada tahab ja mõlemapoolsete jõupingutustega projekt p...sse keeratakse, tuleb ette mistahes arendusvahendit kasutades. Seega ei puutu vastav nutt & hala, kuitahes reaalne see ka poleks, antud juhul IMHO tõepoolest asjasse. Minu väide on, et pankadele ei kirjutata softi samamoodi ja samade vahenditega nagu miskile kasutatud raamatute www-poele. Kas Sa ei ole sellega nõus?
|
|
|
[ vasta sellele | artikkel
]
|
|
|
On kindlasti võimalik, aga siis kukub lõpuks nii välja, et kirjutad tollessamas php-s kõigepealt framework'i ja middleware'i ja siis "softi"...
|
|
|
[ vasta sellele | artikkel
]
|
|
|
Odot. Kas sulle ei tundu, et see on mingi stamparhitektuur? Kas tõesti peab nii tegema? Ole hea ja põhjenda, muidu kõlab see ikka nii, et j2ee on meestele ja Rails poistele.
|
|
|
[ vasta sellele | artikkel
]
|
|
Tegelikult on ka vastupidine stsenaarium suhteliselt levinud. Ma mõtlen seda, et veebirakendus kasvab tunduvalt suuremaks ja keerulisemaks kui esialgu planeeriti. Sisuliselt *kõik* veebirakendused mis saavutavad populaarsuse laienevad pidurdamatult suurteks ja keerulisteks programmideks. Pidevalt lisatakse uut funktsionaalsust, refaktooritakse olemasolevat jne. Ilma ei saa populaarsust säilitada ja uusi kasutajaid võita. Sellepärast ongi kasulik kohe alguses kasutatada hästi skaleeruvat ja paindlikku tehnoloogiat nagu Java (hea refaktoorida, omab häid vahendeid selleks) ja korrektseid (objektorienteeritd) disainimustreid kasutada.
Java on vägagi OK veebiarendamise platvorm muide.
|
|
|
[ vasta sellele | artikkel
]
|
|
|
Asi ei ole mitte niivõrd keskkondades, kui arhitektuurilistes lahendustes ja selles, kui palju kulub aega mingi arhitektuurilise lahenduse implementeerimiseks. Assembleris saad sa ka lõppude lõpuks ju kõik need asjad valmis kirjutada. Aga jah, suured ja ärikriitilised rakendused kipuvad tõepoolest reeglina olema õige mitme kihilised, standardiseeritud liidestusega ja nii edasi ja nii edasi. On rida tehnoloogiaid, kus selliste asjade arendajale on poolele teele vastu tuldud ning J2EE on üks neist.
|
|
|
[ vasta sellele | artikkel
]
|
|
|
Kui sa küsid kliendi käest 100k asja eest, mille eest teised küsivad 1M, siis klient sind küll ei vali. Suurfirmad viskavad tihtipeale 3 kõige odavamat pakkumist kohe prügarisse. Mina küll suurfirmat ei esinda, aga mina ka ei võtaks sind tööalaselt ainult hinna alusel jutule.
|
|
|
[ vasta sellele | artikkel
]
|
|
|
Et siis, mina aga arvan, et Ruby, C++, Python, Java erinevad üksteisest ainult dokumentatsiooni ja teekide poolest. C++ korral tuleb ise tükid kokku otsida, Javas ja RoR-is on ilusti kokku käivad jupid ilusti ühtselt dokumenteeritult ja ühest kohast vabalt võtta, samas, kui enda poolt välja valitud, alla laetud, C++ jupid(sõltumata nende vormist, näiteks teegid) ei pruugi ilusti, lihtsalt kokku sobida ja võivad olla ebameeldiva dokumentatsiooniga.
Jah, tõepoolest, on küll Java üles ehitatud konkreetsele turvamudelile ja puha, Javat ja C++ tuleb kompileerida, jne. aga seda kõike annab minu meelest ju vastavalt vajadusele korraldada ja arendusele kuluva töömahu ja aja suhtes ma ei näe erilist erinevust.
Mina hindan programmeerimiskeelt küll põhiliselt ainult 4 tunnuse alusel:
z) sõltumatus mingist konkreetsest opsüsteemist või ettevõttest(näiteks, Microsoft, Sun)
z) valmis rakenduse töökiirus ja seda jooksutavale riistvarale esitatavad nõuded
z) "ehitusklotside"(näiteks igasugu teekide) olemasolu, lihtne kokku-ühendatavus, hea dokumentatsioon
z) keele süntaks, keele võimalused ilma "overhead-ita" ilusat, inimese jaoks lihtsasti loetavat, süntaksit kasutusele võtta, DSL(domain specific language) kasutuselevõtu võimalused(näiteks C++ korral mallid(templates), Rubys ...Ruby ise, jne.). Näiteks, Fortranis ma hetkel ei oska ilusat süntaksit kasutada, kuid kui Fortrani mitte-objektorjenteeritus, suur hulk koledaid, ajaloolisi krutskeid, jne. kõrvale jätta, on ta täiesti tavaline protseduurorjenteeritud keel, nagu iga teinegi(näiteks Pascal).
Ma väidan, et eri töövahenditel on erinevad omadused, aga üldkokkuvõttes määrab tulemuse kvaliteedi ikkagi PROGRAMMEERIJA OSKUSED, mitte keel. Ja vastupidi, hea töövahend oskamatuid ei päästa.
(Et kellelgi ei oleks ütlemist: olen küll progreja, kuid ei pea ennast ilgeks profiks, ning arvan, et mul on veel häid tulemusi andvate töövõtete omandamisel palju ruumi areneda.)
|
|
|
[ vasta sellele | artikkel
]
|
|
|
|
|
|
