Ruby?

archaic, negribu. RoR popularitātes izaugsme ir apstājusies. RoR bija vienīgais iemesls, lai apgūtu ruby.

Akdies, kad es readerī spiedu uz šo title, nelasot lead, es zināju ka man ir viedoklis, jo es nevaru izlemt starp - spāņu, itāļu vai franču! Bet atveros šoe ierakstu, ar domu man ir viedoklis! Irādījās ka tas vis ir pavisamm par citu tēmu! :D :D :D Sakiet lūdzu vēl kāds ka bija tā pat! :)

Es piedāvātu XSLT. Tā ir pietiekami nopietna nišas valoda, kuras iespējas līdz šim ir novērtētas par zemu. Pieņemu, tāpēc, ka, neiepazīstoties ar visām valodas iespējām, izstrādātājs no paraugiem kaut ko puslīdz strādājošu saķepina, paziņo, ka "redz, kur ir risinājums, bet nu tas XSLT ..."

Kriš, XSLT ir tik tiešām nišas valoda. Pārāk šaura pielietojuma. XML vairs nav dominējošais datu formāts.

Tieši tāpat, krisha. :D

Laacz, ko es esmu palaidis garām? Domā JSON?

Node.js, CouchDB - Javascript to rule 'em all :) Bez tā, ka kopumā tas ir tehniski baigi jaudīgs, fleksibls un mērogojams risinājums, man arī ļoti patīk doma, ka, Javascript ir visur - gan klienta, gan servera galā, pat datu bāzēs (couchdb). Pats ap šīm tehnoloģijām bakstos, klāt pieliekot GeoCouch, un esmu baigā sajūsmā.

Kriš, arī JSON kā datu apmaiņas veids (gan stream veidā, gan REST arhitektūras ietvaros). HTML arī vairs nav SGML/XML (as of HTML5). Uz XML bāzētie protokoli (paldies dievam, ieskaitot nejēdzīgi samuhļīto SOAPu), mirst lēnā un dabiskā nāvē.

Mārtiņ, jā, forši, ka JavaScript parāda savas stiprās puses, taču NodeJS ir savs pielietojums (ne universāls). Tas pats attiecas uz CouchDB (<del datetime="2011-04-27T20:05:30+00:00">viewu</del> <ins datetime="2011-04-27T20:05:30+00:00">dokumentu</ins> koncepts ir spēcīgs, bet prasa daudz upuru). Man nepatīk, kad NodeJS un NoSQL met visur, kur vien var iemest. Jebkura tehnoloģija jāpielieto ar mēru un pareizajās vietās.

Man ar likās ka būs kāda franču vai itāļu ... bet vīlos :)

Java. Vienkārši nevaru iedomāties vēl kādu, kas nav nosaukta.

KAC, no way.

laacz, labi, mans pirmais teikums bija pārāk pretenciozs :)

Protams, Tev taisnība - nekas nav universāls. Mans galvenais "points" vairāk bija tieši par Javascript kā valodu, kurā potenciāli varētu uzrakstīt vesalu aplikāciju - gan klienta, gan servera pusē. Pieņemu, ka nenoliegsi, ka tas varētu būt ja ne noderīgi, tad vismaz interesanti.

Cita tehnoloģija, kur varētu panākt to pašu? Java + GWT? Kā jau KAC teici, "no way" :)

Martinsb, rakstīt var, protams, bet vai tas ir optimālākais variants? :) Es pats diezgan aktīvi ņemos ar vienu node+mongo+redis+html5canvas projektiņu. Nav ne vainas.

Pēdējā gada laikā atkal/pirmoreiz paliek populāras šitās -
salīdzinoši jaunā "Lua", superklasika "Lisp", un super stabīlā 'mission critical' risinājumiem paredzētā "Ada". Nu un veel var uzmest aci uz "Tcl"

nu tas tā lai ir varianti ko apsvērt :)

Erlang ir visai zimpātisks ar savu message modeli - ideāls variants distributīvai programmierēšanai. Un, protams, esot no funkcionālo valodu saimes, lieliski noder patrennēties paraudzīties uz programmēšanu no nedaudz cita skata. Pēcāk tas ļoti palīdz kodējot "parastos" kodus - visādos tur PHP un kurās zemā līmeņa valodās tik vēl ne :) Pēc tāda Erlang, man daudz-kas daleca arī no JavaScript, kas kļuva no visnīstākās valodās, kurās programmēts par naudām, par vienu no top top valodām.

Tākā - ķeries tik klāt Lispiem, Haskell (nepatika - pilnīgi bez pamatojuma - nosliecos par labu Erlang), Cložūrām, Skalām un kas tur vēl bija no tās saimes.

kāpēc ne javu? ljoti praktiski pielietojama.

Negribas izpelnīties pelavas, bet kāpēc neviens nepiemin Actionscript? Manuprāt tīri interesanta laika nosišana taisot foršās flash spēlītes, jeb arī kādas citas interesantas aplikācijas. Jā, javascript un html5 lēnām grūž ārā flashu no sava augstā lauciņa, bet vēl tik traki jau nav, jebšu kļūdos?

p.s. - arī Jura piedāvātā java ir forša lieta. Vienīgi no viņas nav ko mācīties - ja pārzini PHP un patīk OOP tad Java rakstīties vēl vieglāk par pašu PHP.

Ja gribi pabakstīt un paskatīties, kā "smird" (vai smaržo), tad tādas, kas ir no citas kategorijas, nekā ikdienā (funkcionālās, ezotēriskās). Ja gribi kaut ko praktisku, tad ņem kādu un kodē, tur nav ko daudz mācīties.

Man TOLEARN augšgalā ir OMeta http://www.moserware.com/2008/06/ometa-who-what-when-where-why.html (tour de force - uzrakstīt perētājsistēmu un GUI un bezkaunību 20000 rindiņās)

Haskell, jā, bet tīrās funkcionālās valodas laikam vēl aizvien cieš no neparedzamas neātrdarbības Jebkādi Lispi, jā, droši vien labi ierakstās "lieto" kategorijā Eiffel - design by contract Smalltalk - tuvāk OOP un MVC saknēm Coq - teorēmu pierādīšanas rīks, bet pārsteidz, cik ļoti var spārdīt brutāls spēks Ur http://www.impredicative.com/ur/ uz līdzīgas nots - pierādāma drošība pret injekcijām

haXe: http://haxe.org/doc/why

cilvēki samācās visādās skolās sporta pēc visādus bakalaurus, bet ikdienā no tā visa neko nepielieto, nedarbojas attiecīgajā nozarē. cilvēki samācās/zin dažādas sarunvalodas, bet ar ikdienā tāpatās runā 1 valodā un pārējās ir plauktā tik noliktas. neredzu nekādu jēgu apgūt kautkādas mītiskas programmēšanas valodas ja tam visam apakšā nav kāds izdevīgums, nav kāds biznesa plāns apakšā, nav kāda nākotnes darba vide kur tas viss var noderēt. ja nav gaisams tuneļa galā, tad tas ir tīrs sadomazohisms, es pat teiktu šizofrēnija (ne tiešā veidā, bet tomēr). ja ir mēŗķis apgūt visas iespējamās programmēšanas valodas, ok, tad tik uz priekšu! aizvedīsim Tev fruktus uz Tvaika4 kad vajadzēs.

Assembleru! Vēlams ne-x86, bet kādu retāk sastopamu - MIPS, PPC, vai pat to pašu ARM. Pie attiecīga zināšanu līmeņa tādas prasmes ļoti noderēs.

Cimperlējas kā tāda vecmeita, gribu, gribu, bet tā vienkārši neatdošos... ;) Ko tu īsti gribi?? Kādiem mērķiem? Tā arī nesapratu.

Mans ieteikums - Java. Pamatus viegli iemācīties, labi dokumentēta, plašs pielietojums. Šobrīd ir "forši" taisīt Android programmas. Tomēr arī programmētāji ar 5 gadu stāžu nezina visas Java nianses un smalkumus - ir kur augt un attīstīties.

Dadzis, kā ar āmuru pa galvu, kā ar sirpi pa olām...

No sākuma nodomāju, ka man nav ko ieteikt, jo domāju, ka vērts ir apgūt kaut ko ko vēlāk būs arī jālieto, bet kad ievēroju vienu pieminam XSLT atcērējos par XUL. Tajā var XMLiski arpakstīt formas, darbojās laikam tikai uz firefox. Bija doma kādreiz veidot webiskas sistēmas, kuru interfeiss būtu aprakstīts XMLā un līdz ar to tas varētu samazināt bremzes sajūtu, kas parasti ir webisko sistēmu obligāta sastāvdaļa. Diemžēl, škiet pārāk niecīgais atbalsts un tamlīdzīgi faktori nolēmuši šo projektu aizmirstībai. Bet tur laikam pat bija tāda fīča, ka aplikāciju varēja atvērt bez pārlūka (respektīvi nerādās pārlūka logs, bet tāda kā formiņa).

Laacz, protams tā īsti nav šitā bloga tēma, bet ar XML nāvi tu gan biku pār strīpu šauj.

Par dažnedažāda izmēra jauniem Web projektiem nemāku spriest, bet ja Tu kā šamās jomas speciālists saki ka XML tajos aizstājās ar JSON vai ko citu, tad varu tam ticēt un piekrist.

Savukārt ar industriju kopumā nu gan tā nebūt nav un nekur XMLs kā datu apmaiņas standards nepazudīs. Pirmārt jau kā starp sistēmu apmaiņas standards. Tas JSON (vai jebkāda cita šobrīd esoša alternatīva) nav un nebūs tik populāra n-tajās dažādās vidēs kā XML. Bet tam ir nozīme, kad uzņēmumi un industrijas izvēlas datu apmaiņas standartus iekš savām "software landscape". Rezultātā gan sistēmu integrācija, gan arī dažāda veida arhivācijas un meklēšanas risinājumi dominēošā apjomā tiek būvēti vienīgi uz XML.

Un tas pats SOAP atbalsts n-tajās vidēs atkal jau spēlē savu lomu. JSON'am vispār kautkas +/- līdzvērtīgs un plaši atbalstīts ir?

Dadzi, iespējams neizteicos gana skaidri, lai Tu saprastu. Tātad. Es vēlos apgūt papildus programmēšanas valodu nejau tāpēc, lai ievilktu ķeksīti. Mans mērķis ir paplašināt skatupunktu. Ja cilvēks beidz meklēt vietas, no kurām uz ierasto pasauli argumentēti paskatīties no cita skatu punkta, tad viņš ir nolemts iekšējai stagnācijai. Tas ir nereti novērojams vecos cilvēkos, kas nespēj paskatīties uz lietām plašāk. Tas pats attiecas uz izstrādes pasauli - tā aug un attīstās, ļoti daudz citās valodās iestrādātie principi ir svētīgi, domāšanu mainoši un noderīgi.

Rezumējot - es šai "jaunas valodas mācīšanās procesā" izdevīgumu redzu ikurāt individuālajā izaugsmē, nevis kaut kādā čungurā vai mistiskā gaismā tuneļa galā.

Reini, JSON nav tikai Web sistēmām. Savukārt, ja runā par XML, tad tas visur tagad velkas līdzi tāpēc, ka ir milzums legacy sistēmas. Un, labi, vakar vakarā stipri emocionāli piegāju komentāra rakstīšanai. XMLs neizmirst, bet lielākajā daļā gadījumu tas (tāpat kā SOAPs) nav nepieciešams.

Man XML nekad nav paticis. Pirmām kārtām tā diezgan sarežģītās apstrādes dēļ. Otrām kārtām - liekvārdības (liekbaitības) dēļ. XML galu galā nav tik vienkāršs, kā gribētos (XML, XSD, XSLT, utt).

Applescript, xcode & co...

Smic, <a href="http://www.urbandictionary.com/define.php?term=tl%3Bdr" title="Urban Dictionary: tl;dr" rel="nofollow">tl;dr</a>?

Principā, nāk prātā 2 lietas (kuras gribētos pašam apgūt, protams. :D)

1. ir assemblers. Konkrētāk, x86 assemblers, no paša sākuma (16 bitu real mode u.c. eksotikas), līdz pat SSE3 un x64. Ar domu - lai saprastu, kas tad <i>patiešām</i> lācītim ir vēderā, un kā tas viss strādā. Pa ceļam varētu uztaisīt savu mini-OS.

2. C++. No vienas puses itkā ir sajūta, ka taču to valodu jau apguvu pašā sākumā, un nekā diža tur nav. No otras puses, kad palasās C++ jautājumus iekš StackOverflow, kļūst skaidrs, ka īstenībā es no tās valodas labi ja 10% saprotu. Pie tam - C++ arī nav stāvējis uz vietas un pēdējās desmitgades laikā ir ieguvis daudz jaunu fīču (closures, anyone?) Tāpat arī ir uzradušās spēcīgas bibliotēkas (boost, anyone?), kuras radikāli izmaina to, kā es stādos priekšā darbu ar C++. Un beigu beigās, palasoties mazliet par to, ko tik cilvēki tur nav izdarījuši, kļūst skaidrs, ka patiesībā tā ir <b>ārkārtīgi</b> spēcīga valoda, ar <b>ļoti</b> plašām izteiksmes iespējām, kurai tādas Javas vai C# ne tuvu nestāv līdzi. Kā sacīt saka - <i>Feel the <b>power</b> of the Dark Side!</i>.

Piekrītu BigUgga argumentiem par erlang. Vēl arī ASM vai C/C++ būtu labs, ja tu paņemtos zemākā līmenī; tiešām kustinātu bitiņus. ASMs IMHO pārāk liela ķēpa, bet varbūt ir kāds dīvaiss, kas tev interesē un ko gribi pahakot? tur ledusskapis vai tosteris, nezinu kas tev mājās ir programmējams. :)

Java, tad Clojure. Brīvajos brīžos Brainfuck (tā arī saucās).

PL/SQL Tev arri lieto "parasti piezemēti cilvēķeļi savos mazajos projektiņos un uzņēmumiņos"? :) pie sii komplektaa Java prasaas. sugubo IMHO. Erlang? neir slikt idej un fiics, bet skatoties nesen, kaads sekss iraid tam vidi piekurbuleet vienaa vai otraa FreeBSD- danunafig.

Vilx@ C/C++ iraid baig labaa liet, tikai man neir nekas zinaams par to, kaa tajaa rakstiitaam pergaam, kas izpildaas klienta pusee, uz naakoso reizi apdeitot viss instalaacijs uz klientu taarpstacijaam bez biistamaam iespeejaam failsisteems permisijaas. nu, taads admina skats, vot. webappzi sho probleem atrisin vienkaars.

Pievienojos tiem kas saka "Java". Protams. Ļoti populāra, plašs pielietojums, miljons gatavu bibliotēku, platformu utt.

Esmu mēģinājis mācīties gan perl, gan python, gan ruby, lai paplašinātu redzesloku, bet nekas no tā nav aizķēries, ja vien python tabošana. Rezultātā ir aizķēries tikai C# un nedaudz Java, jo tas ir nepieciešams darbā. Tobiš, ieteiktu sākt ar to, ko tu vēlies uztaisīt, piemēram, robotu - alus atnesēju, un tikai tad meklētu tam piemērotus rīkus - lodāmuru, arduino un moš assambleri!

Bet, ja tā teorētiski, tad domāju, ka Erlang vai Haskell, vai OCaml - vismaz no citas operas!

Lai veicas! :)

C#/XAML

Zinot XAML, var veidot vizuāli bagātas (piem., textbox ar 10px rāmi un rāmim pildījums ir nevis viena krāsa vai krāsu pāreja, bet dzīvs video, un šim textbox ir atspulgs, kas darbojas arī tad, kad tajā raksta tekstu u.tml. lietas. ja ir mūžu strādāts ar HTML/CSS, tad var paskatīties, kāda izaugsme ir Microsoft frontē) applikācijas telefoniem (WP7), pārlūkam (Silverlight) un darbastacijām (WPF). Silverlight strādā arī uz Mac OS X un Linux (saucas Moonlight).

C# kā valoda ir ļoti feina. Tā ir OOP valoda ar funkcionālas programmēšanas valodas elementiem, tai ir anonīmās funkcijas, closures/delegates/lambdas, eventi, extension methods (tā kā prototype javascriptā), dinamiskie mainīgie tipi (ja negribas norādīt tipu, tā kā python). Ja nav dzirdēts par LINQ (SQL atslēgvārdi iebūvēti valodā), tad par to būs patīkams pārsteigums (kā kaut kas tāds nav PHP, kur tas būtu visvairāk lietojams?!). C# 5.0 ļauj rakstīt asinhronas programmas, kas izskatās gandrīz uz mata kā sinhronas (bez callbacku ellēm). Task Parallel Library kopš .NET 4.0 ļauj nežēlīgi vienkārši rakstīt multi-threadodas applikācijas, kas prot izmantot visas procesora cores. Vajag paralizēt for/foreach ciklu? Nomaini vienu rindiņu un gatavs! WCF ļauj rakstīt elegantu kodu, kas paslēpj visu neglīto SOAP, turklāt ar pāris rindiņām var uzstādīt, lai izmanto JSON pa HTTP nevis XML (vai arī sūta bināri ar TCP vai arī Named Pipes u.c.), nemainot pašu kodu. Aizmirsti par WebForms, ASP.NET MVC ir atvērtā koda bibliotēka no Microsoft. Ļauj izmantot visas C# burvības, piem, linkus skatos var taisīt šādi bez maģiskiem stringiem: Html.ActionLink(c => c.Indx(page: 5)); Oops, nepareizi uzrakstījis HomeController vai Index? F2 un Visual Studio atradīs un izlabos visās vietās!

Mono ir C#/.NET vide priekš Linux/Mac OS X. Gandrīz visas (WPF nē, tikai daļēji WCF) tehnoloģijas var lietot ar Mono. Ar MonoTouch var taisīt programmiņas Android telefoniem.

Pēc tam, kad iepazīts ar .NET, var pamācīties F# (funkcionāla programmēšanas valoda). Turklāt C# un F# var lietot vienlaicīgi, piemēram, viena klase C# otra F# vai arī visa klase C# un viena funkcija F#.

TL;DR iesaku C#/.NET, lai paskatītos, kāds progress ir Microsoft frontē.

Ja C# nē, tad varbūt Go?

The Go programming language. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines. It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language.

ņem atkal paskāli vai C++ :D

Pats šobrīd pētu MQL (tā ir valoda iekš MetaTrader - valūtu tirgotāju platforma) - mans primārais mērķis ir izveidot pelnošu valūtu tirgošanas robotu/spekulantu. Valodai ir C like sintakse, bet specifiskas funkcijas, piemēram, iMACD(). Šeit ir milzīgas iespējas pielietot dažādus mākslīgā intelekta paņēmienus (mākslīgais intelekts tagad rullē - es tagad mācos un esmu sapratis ka IT studentiem tā ir top lieta). Ja man būs lepnums ar savu bakalaura darbu, tad publicēšu to priekš tiem, kas grib palasīties koncentrētu informāciju par to kā uzsākt MQL programmēšanu. Varbūt veiksmes gadījumā, kāds sāks ar to pelnīt naudu, bet mani līdzšinējie novērojumi liek domāt, ka šis robots nav jāprogrammē pēc kādie noteiktiem tirdzniecības principiem, bet gan jāiemāca tas mācīties un tad jau miljons rokā. Respektīvi, programmēt MQL ir gan motivējoši, gan milzīgas iespējas noslogot savu intelektu. Uzmanību! Spekulanti - karstās zupas strēbēji var nonākt milzīgos parādos! Mkay?

pirmā doma arī bija par kādu svešvalodu papildus angļu, krievu utt.

Bet ja par tēmu, piem., LaTex. Tā gan nav īsti nosaucama par programmēšanas valodu, bet PDF dokumentu veidošanu gan vienkāršo. Sporta pēc LU laikā vienu no kursa darbiem rakstīju tieši tā. Varbūt ir vērts pabakstīt.

Eksotikai - pamēģini loģisko programmēšanas valodu Prolog :) Tīrās izvirtības.

Brīvdienās skrienot Mežparkā viena kundze man teica - būtu labāk lapas grābis.

Uzgūglēju kas ir erlang, haskell un nopriecājos, ka ar mani vēl nav tik traki.

jā, man tāpat bija

Valodu vienu pašu ir neinteresanti mācīties. Cita lieta, ja ir pielietojums padomā, tad mācīšanās ir ar mērķi.

Sagādā BeagleBoard, PandoraBoard vai taml. --būs kāre/nepieciešamība mācīties assembleru Sarūpē Android telefonu --būs motivācija ienirt Javā, un varbūt beigās nemaz tik briesmīgi neizrādīsies ;-) Nosapņo next-big-thing MMO tīmekļprojektu --Node vai Erlang mācīšanās uz reizi būs ar jēgu

Ā, reku saite ar interesantām lietiņām iedvesmai: http://www.viget.com/extend/around-hello-world-in-30-days/

Es ar kādu laiku īsti nevarēju izlemt par labu erlang vai haskell. Nesen vajadzēja izdomāt risinājumu distributed aplikācijai un tagad buros cauri erlangam. Erlangs ir krietni vienkāršāks un domāju, ka tas varētu būt labs variants, ko apgūt pirms Haskell.

valoda ir tikai rīks mērķa sasniegšanai. moš labāk domāt mērķi? :) redzesloka paplašināšanai der pamācīties programmēšanas tehniku/metodes. apgūstot visu šo gūzmu ar valodām ir kautkas aizķēries? nav pārāk daudz enerģijas aizgājis jaunu (iespējams, nekad nenoderējušu) lietu apgūšanai?

laacz, apgūsti Actionscript un Flex. Varēsi webiskas aplikācijas turpināt rakstīt un arī telefoniem attīstība notiek. Un pie reizes varēsi paņemt pie dziesmas forumu flash.lv, kurš šobrīd ir nomiris.

Pirms pāris nedēļām palasīju to Go aprakstu. Nuina. Yet-another-c-java-you-name-it klona valoda izpušķota ar nelielām fīčām.

Interesanta štelle ir http://www.arduino.cc/

Un vispār mikrokontrolieru programmēšana. Var diezgan vienkāršā veidā sataisīt visādus gadžetus - sākot no robotiem līdz pat mājas automatizācijas iekārtām. Varēs ne tikai paplašināt zināšanu loku bet arī ko noderīgu izveidot!

Piekrītu viedoklim ka nav jēgas mācīties valodu, ja tai reāli nebūs pielietojuma.

Es arī piekrītu, ka vajag zināt mērķi: kas ir jāuzbūvē un tad var ieteikt valodas un vides kurās tās realizēt. Taču, ja mērķis ir vienkārši redzesloka paplašināšana, tad derēs jebkura vēl nezināma valoda, jo mērķis tiks sasniegts ar jebkuru.

@ZBH Piekrītu, ir grūtāk nekā web appās, bet, ja pareizi visu izdara, tad arī to var risināt. Un ne visām appām tā ir problēma. Kā sacīt saka - <i>the right tool for the right job</i>. C++ nav universāla panaceja visām situācijām, un webappas arī nē. Katrai savas priekšrocības un savi trūkumi.

Starp citu - mani vienmēr ir arī interesējusi iespēja web appas rakstīt iekš C++. ;)

@#54. Vilx- Vari jau iekš C++ rakstīt CGI moduļus webam - nav jau nekā tāda, vnk. outputs pareizi jāsaformē. Tiesa, nevarēsi tik labi cache izmantot un pie katras web lapas izsaukšanas vajadzēs reāli to failu no diska nolasīt, lai izpildītu.

No finansiālā viedokļa - noteikti Java. Šķiet, pašreizējāis akcents no "modernām" valodām uz virtuālās mašīnas ir uz Scala - to varētu pamācīties, lai apvārsni paplašinātu. Par pārējo - ir alerģija pret C#, taču C un C++ vēl arvien ir ļoti daudz pielietojumu. Pārējās visas, ja ir reāli akadēmiska interese.

@e-remit: Nu, tur jau tas joks, ka pliks CGI nav īpaši foršs webam. Vajag freimworkus; iespējams Fast-CGI; utml. Tur ir mazliet zinātnes apakšā. :)

@Girst - cik esmu redzējis un salīdzinājis C# un Javu, fundamentālas atšķirības tur nav. Vairāk gaumes un pieraduma jautājums. Un Microsoft-fobija nav arguments. Tāpat arī no finansiālā viedokļa .NET no Javas neko neatpaliek.

Vilx-, cpp MVC freimworks: <a href="http://www.webtoolkit.eu/wt" title="Wt, C++ Web Toolkit" rel="nofollow">Wt, C++ Web Toolkit</a>

SAP :)

@laacz - :)

Es ar ieteiktu ActionScript un C#.

Kā jau te iepriekš minēja AS tiek lēnām gāzts no troņa ar HTML5 un JS paplasinājumiem - ar Canvas programmēšanu, WebGL, Mozillas jaunais jājamzirdziņš, kuru vēlos ietestēt - audio sintēzi rakstot samplu buferī (aizmirsu kā tur tas viss kopā saucās), bet es uzskatu, ka AS3 vēl kādu laiku būs power, it sevišķi, ja paņem rokā Flex SDK (bez maksas) un FlashDevelop (bez maksas) - var taisīt brīnumu lietas pure AS3, pat neatverot Flash vai Flex Editor (alja design mode).

Un jā C#, ja ir bijusi saskarsme ar visām Java sintakses un namespace/package pasaulēm, tad nebūs grūti iebraukt. Izlasīju 1/3 no C# For Dummies un sāku bliezt. Protams paliek vēl jautājums par "best practices" jeb "tā labāk nē, labāk šitā", bet tas jau katrai valodai atkarīgs no vides/kompilera/virtuālas mašīnas.

Vilx@ a man uz IBM Power dzelzhiem tas .NET ies? :)

Tev derētu iemācīties kādu advancētāku valodu, ar šo te varētu sākt: http://en.wikipedia.org/wiki/Brainfuck

Sorry laacz, neredzēju, ka to jau pieminēji tekstā

@ZBH - nu labi, vienmēr varēs piemeklēt platformu, uz kuras Tava izvēlētā valoda nav piejama. Un, jā, atzīstu, ka Java ir noportēta uz vairāk platformām nekā .NET. Bet tas neko nepasaka par pašu valodu.

Ai, whatever. Izskatās, ka laacz dzēš Java vs .NET fleimu enīvei, un man arī šobrīd nav iekšā kārtējo reizi plēsties.

Viss, ko es gribu pateikt ir - nekad nesaki nekad. Nav labas vai sliktas valodas/vides, un it sevišķi jau nu ne .NET vai Java. Katrai ir savas vietas, kur tās der labāk, un kur ne tik labi. Un daudzviet izvēli nosaka tikai gaume.

#49 Pilnīgi piekrītu. Ja nu pavisam nav ko darīt, tad var laiku aizpildīt ar daudz interesantākām nodarbēm. Labu laiku atpakaļ, kad apguvu Python, jo biju iedomājies, ka tas man noderēs praktiski visur (t.sk. darbā) nu vienvārdsakot ūbervaloda - kaut kur atradu viena censoņa Perl kodu, kur viņš emulēja CS 1.6 serveri un php kodu, kas emulējot CS 1.6 klientu izmantoja vienu gļuku, lai nogāztu serveri. Tad nu es visu šito pašu izdarīju tikko iemācītajā pitonā, izbūros cauri arī dokumentācijai, kā viņi tur komunicē + par soketiem un UDP paketēm. Izmēģināju visu ko. Tā bija laba pieredze. Realitātē man visa sajūsma pārgāja, kad sāku taisīt kaut ko no GUI iekš Tcl/Tk. Kaut kāds atstojs, ne UI, man būtu kauns kādam tādu rādīt. :D Un lai vēl krāmētos ar interpretatora esamību/neesamību uz citu datoriem. Pats tagad skatos Pascal virzienā, jo tas atbilst maniem šībrīža mērķiem. Īsāk sakot - atrodi kādu real-life problēmu (jeb iespēju) - un uz priekšu.

P.S. No pēdējā laikā redzētā pozitīvu iespaidu atstāja šitais, labi ir izbūries cauri tēmai http://rvelthuis.de/articles/articles-cobjs.html

Valodai nav nozīmes. Slāpes uzvar http://en.wikipedia.org/wiki/Category:Software_design_patterns

Interesanti, ka kāds pieminēja TeX :) Līdzīgā veidā varu piedāvāt R (http://www.r-project.org/), kas protams arī nav īsta programmēšanas valoda. R šobrīd ir populārākā valoda statistiķu vidē, kas liek lielajiem komerciālajiem softiem (SPSS, SAS) pastāvēt kaktiņā un pamācīties ;)

Pirms kāda laika, kad kārtējo reizi biju iestājies darba meklētājos, man kāds cilvēks ieteica apgūt [ja atmiņa neviļ] WinCC - sak', to izkodīsi, par bezdarbu varēsi aizmirst līdz pat mūža galam. Tas gan vairāk ir produkts/vide, nevis valoda. Mājasdarbos tam, protams, pielietojumu diez vai sanāks atrast, bet ja tēmē uz ko vairāk par "pasēdēju vakarā istabas stūrī ar vienu roku zem galda", tad varbūt ir vērts?

Seven languages in seven weeks? : http://pragprog.com/titles/btlang/seven-languages-in-seven-weeks

#3 Aha! Gribēju pajokot, iesakot Esperanto! :D Ja no programmēšanas valodām, tad "sī šārp" :)

Pirmkārt, nevajag gudri d**t:

<q>Kriš, XSLT ir tik tiešām nišas valoda. Pārāk šaura pielietojuma. XML vairs nav dominējošais datu formāts.</q>

Kam nav, kam ir. Finanšu (pat pie mums), zinātniskajās, arhīvu, ..., īsi sakot, veselā kaudzē ar industrijām, kas darbojas ar sarežģītākiem datu formātiem par pliku masīvu, XML ir un vēl ilgi būs glue-format. Teju visu industriju datu standarti, kur vien nav specifiski nepieciešama augsts datu blīvums (jo "liekvārdīgs" XML tiešām mēdz būt) vai pēc iespējas samazināms datu apjoms, jaunākās versijās vai nu jau ir pārgājuši vai pāriet uz XML.

Grāmatvedības programmas dzen ārā un iekšā XML, Bankas savstarpēji apmainās ar messidžiem XML formātā, ofisa dokumenti tagad ir zipoti XMLi, un tā tālāk un tā joprojām.

<q>Man XML nekad nav paticis. Pirmām kārtām tā diezgan sarežģītās apstrādes dēļ. </q>

Šis viedoklis neizbrīna, jo ir tipisks procedurāli orientētu valodu speciālistam. Mums te darbā ir tāds relikts, kas ir darbojies tikai ar C. Viņam iebraukt XMLā neizdodas -- iespējams gadi vairs nav tie. Iemācījās Python, bet darbojas ar XML joprojām no C/python procedurālā viedokļa. Tev ir izdevies apgūt XML apstrādi, bet izskatās, ka tikai "pirmajā līmenī": ar XML darboties var, bet tas ir sarežģīti.

Protams, ja ikdienas darbs saistīts ar maziem vai lieliem, bet atsevišķiem websaitiem, kuriem nav jāsaņem vai jāiedod standartizēta informācija citām aplikācijām, tad nav brīnums, ka XML/XSLT tiešām nav ikdienā vajadzīgs. Bet tieši tā drīzāk ir nišiņa, nekā viss lielais dažādo industriju apjoms, kur kāreiz XML ir cieņā, gadījumos, kad dati ir jāpārvieto no vienas sistēmas otrā.

Ja proti XSLT un īpaši XPath, tad visa sarežgītība pazūd, un ekstraktējot/pārveidojot kaut ko XMLā var simtiem rindu procedurālas valodas koda aizstāt ar desmitiem rindiņu XSLT faila, ko var izlaist cauri standartizētam xslt procesoram (kaut vai komandrindas, gan MS ir izveidojis, gan uz Linuxa tādi ir, gan visur citur).

Tas man drusku atgādina, kā piedalījos FIDAVISTA (bija tāds Latvijas banku XML standarts) darba grupā kkad vēl 2002/2003. Sanāca vecie banku IT buki un sāka klārēt, kāpēc esošie formāti ir labāki, jo redz line-based un fixed-length formātus vienkāršāk apstrādāt. Ar C/C++ noteikti, kur tev ir tikai strpos() un citi stringu brīnumi. Bet jau tad bija tas pats nelaimīgais XSLT, ar kuru varēja šķaidīt multiple-value, variable-length un sub-fieldus kā riekstus.

Tiktāl par uzbraukšanu XML/XSLT, kas, man izskatās, sakņojas nezināšanā. Palabo, ja kļūdos (lai arī neesmu ievērojis, ka tu kādreiz te atbildētu kādam, kas kritizē tavu viedokli, bet tas varbūt vnk tāpēc, ka nelasu tevi bieži).

Otrkārt, par valodu paša izaugsmei.

Ja spēsi apgūt haskell vai kādu no citām funkcionālajām valodām, enormous respect! Man šādam vingrojumam pietrūka matemātiskās domāšanas, mācoties haskellu visu laiku bija jāmēģina atsaukt atmiņā dažādas LU lekcijas matemātikā -- nevis formulu dēļ, bet domāšanas veida dēļ.

Grr, es tomēr pastāvu uz to, ka XML velkas līdzi tikai dēļ tā "dziļajām saknēm" legacy sistēmās. Kādreiz bija tendence visu universalizēt, centralizēt un sistematizēt. XML ir spilgts tādas domāšanas paraugs. Moderni, manuprāt, ir izmantot pareizos rīkus pareizajiem mērķiem, nevelkot līdzi lieku overheadu.

Protams, fiksēta garuma rindiņu kolekcijas iekš teksta faila ir daudz sāpīgāk par XML. Ja jāizvēlās starp tiem diviem, tad, protams, lai tas ir XML. Tie, kas sadarbojas ar to pašu Itella, var par tādiem failiem, kas tiek pārsūtīti pa SFTP/FTP, priecāties ik dienas.

Failu sūtīšana šurpu turpu mūsu onlaina laikmetā ir neloģiski un pārāk oldskūlīgi. Serviss vēršas pie servisa caur API, nevis pārsūta failus caur FTP vai e-pastu. Un API var būt tas pats bezbožnijs SOAP, XML-RPC, REST, da kaut jauns uz TCP/IP bāzēts protokols.

Taču, vēlos norādīt, ka XML formāts lielākajā vairumā gadījumu tiek izmantots lieki. Tas varētu būt iemesls, kāpēc man pret to ir nepatika - tas tiek uzstādīts kā pilnvērtīgas zāles jebkam.

XML ir ierobežojošs. To uzskatāmi nodemonstrēja HTML -> XHTML -> HTML5 transfērs. Un tur nav pie vainas slinkie vai riebīgie izstrādātāji.

Vēl diezgan labs (lai arī globālāks un ne tik strikti XMLu raksturojošs) piemērs ir SOAPs ar MIME attachmentiem. Kad XML, HTTP un MIME tiek samesti vienā maisā. Ja neskaita javu (un, kā par milzīgu brīnumu, PHP), tad diez ko viegli nav iespējams atrast bibliotēkas, kuras korekti spētu strādāt ar 100% implementāciju. Kāda var būt runa par standartu un interoperability, ja situācija ar pieejamajām bibliotēkām ir tāda?

Par procedurālo un OOP gan nepiekritīšu. XPath un XSLT ir vienādiņ izmantojams kā procedurāli, tā objektorientēti.

P.S. Par to atbildēšanu - tik tiešām neesi ievērojis, jo neesi lasījis.

Un atkal sākās php'čniku gudrības, kuri domā, ka XML tikai ar rociņām jāparsē. Tomēr uzprasīšu - kāda problēma ir SOAP? Protams, mazajos projektiņos, kur jāpārsūta saraksts ar pieciem string tipa atribūtiem, SOAP būs overkill un pietiks ar JSON servisu. Taču situācija radikāli mainās lielākos projektos.

Lielajos projektos tehnoloģijas izvēlē viens no primārajiem kritērijiem ir rīku atbalsts. Un grozies kā gribi - XML formātam un tā tehnoloģijām tas šobrīd ir vislabākais. Piemērs - uzbūvējam objektu struktūru Javā ar NetBeans, kādu klasi ar anotāciju nodefinējam par web servisu, tad MS Visual Studio no WSDL faila noģenerējam servisa klientu ar visu objektu struktūru un iekš C# izsaucam servisa operāciju kā parastu metodi.

Un ja netiek izmantiots SOAP, bet kaut kāds paštaisīts XML ziņojumu formāts, to arī nav jāparsē ar rociņām, Javas gadījumā ar JAXB vai kādu citu OXM freimvorku no XSD shēmas noģenerējam atbilstošu objektu struktūru, un ar vienas metodes izsaukumu varam XML ziņojumu pārkonvertēt par šo objektu struktūru.

Raimond, iespējams, ka Tev ir taisnība. Iespējams, ka manus aizspriedumus ir radījuši Java/MS* un citu atbilstošo lielo tehnoloģiju cilvēki (ar retiem izņēmumiem), ar kuriem ir nācies strādāt. Iespējams, ka lielākā XML, Java, utt problēma ir tās pielietotāji.

Tie, kam ir nācies ar mani sadarboties kā izstrādātājam ar izstrādātāju, domāju, piekritīs, ka tas nav bijis grūti. Izdomājam, vienojamies, un, ja izdodas, uztaisām. Bet, ja pretīm ir gadījušies cilvēki no Javas vai citas "lielās" enterprise pasaules, gandrīz vai nekad nav nācies pieredzēt efektīvu sadarbību.

Ir gan bijuši divi sadarbības partneris, ar kuru šādas problēmas nebija, bet tā ir adata siena kaudzē.

Tā kā, visticamākais, tie ir aizspriedumi, kuriem patiesā vieta ir ezeros un upēs.

2012.gads tuvojas. Jāapgūst ieroči un praktiskas lietas. Programmēšana nākamos 50 gadus nebūs īpaši vajadzīga

C# .NET vai Mono. Derīga valoda "man ātri vajag izveidot ..." projektiem.

Piekrītu, ka XML nav cilvēkiem tas saprotamākais formāts, bet jau no sākuma tas ir veids, kā aprakstīt priekš mašīnām. Es nedomāju, ka projektam ir jābūt obligāti lielam, lai XML lietošana būtu nepieciešama. Tagad iekš Java un C# datu serializācija uz / no XML ir standartizēta, un, kā jau te arī atzīmēja, ir gatavas bibliotēkas, kas to visu izdara - programmētājam tās parasti ir dažas rindas plus anotācijas objekta klasē.

Bet tā jau ir gaumes lieta - kas vienam patīk, tas citam ne.

Ja ir interese par lispiem, tad no personīgās pieredzes varu rekomendēt lispa pasaules smagsvaru Common Lisp. Tā kā līdz tam biju vairāk vai mazāk bijis pazīstams tikai ar ASM, C un Java veidīgajām valodām, tika atvērti diezgan pamatīgi horizonti, par kuriem līdz tam nebija bijis ne jausmas.

Uz ātru roku noskaitīšu fīčas kuras tobrīd šķita bezmaz vai revolucionāras: vienkāršotā sintakse (haters gonna hate, bet man tā šķiet eleganta - code as data); first class functions; anonymous functions; lexical + dynamic variable scoping; closures; macros (rakstīti tajā pašā valodā, kurā tos izmanto); reader macros; multiple return values; multiple dispatch

Ja izlem šamam pieķerties, ir pa brīvu lasāma diezgan laba grāmata - Practical Common Lisp (http://www.gigamonkeys.com/book/)

laacz, kādu lēmumu beigās ta pieņēmi?

e-remit, beigās pabakstīju gan haskeli, gan erlangu. Uztaisīju pāris tipiskākos Project Euler problēmu risinājumus vienā, mazu distributētu uzdevumu veicēju (fīdu parsētājiņš) otrā.

Beigās nolēmu, ka labākais būtu dziļāk apgūt zināmās valodas. Tās lietas - kuras esmu līdz šim atlicis. Un tādu ir sakrājies daudz. Ņemot vērā, ka ikdienā izmantoju diezgan daudz dažādu valodu un tehnoloģiju, izpētes lauks ir plašs. Paitonā vien ir kaudze ar lietām, par kurām man nojausma ir virspusēja.

Papildus tam, neskatoties uz to, ka man derdz rūbijs, esmu nolēmis mazliet arī apgīt to, jo ir pāris reizes, kad nepieciešams saprast un palabot esošu tā kodu.

Pa punktiem.

1. <q>Grr, es tomēr pastāvu uz to, ka XML velkas līdzi tikai dēļ tā “dziļajām saknēm” legacy sistēmās. Kādreiz bija tendence visu universalizēt, centralizēt un sistematizēt. XML ir spilgts tādas domāšanas paraugs. Moderni, manuprāt, ir izmantot pareizos rīkus pareizajiem mērķiem, nevelkot līdzi lieku overheadu.</q>

Nu, par šo nevaru īsti atbildēt, jo te ir tikai tavi spriedumi bez kaut kādas faktiskas argumentācijas. Par legacy sistēmām XML sakarā gan gribētos saprast, ko tu ar to domā, ņemot vērā, ka XML ir jaunāks par kaut vai to pašu PHP. Ko tad, viss, kas darbojas ar PHP, ir tad jau vispār legacy of legacies?

2. <q>Failu sūtīšana šurpu turpu mūsu onlaina laikmetā ir neloģiski un pārāk oldskūlīgi. Serviss vēršas pie servisa caur API, nevis pārsūta failus caur FTP vai e-pastu. Un API var būt tas pats bezbožnijs SOAP, XML-RPC, REST, da kaut jauns uz TCP/IP bāzēts protokols.</q>

Redzi, te ir vairāki aspekti.

Pirmkārt, servisiem ir sava vieta. Un šī vieta ir sinhronā datu apmaiņā ar tipiski nelielu transakciju skaitu vai datu apjomu sekundē. Tiklīdz mēs par to aizmirstam un sākam bāzt servisus tur, kur tie nav nepieciešami, mēs nonākam pie pirmajām trim no Fallacies of Distributed Computing (http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing), konkrēti:

1. The network is reliable.
2. Latency is zero.
3. Bandwidth is infinite.

Tas tā nav. Un tieši tāpēc, tur, kur nav nepieciešamības pēc servisa, to nevajag bāzt. Un arī tāpēc kaudzēm sistēmu (kas ir sarežģītākas par tipisku online veikalu) pastāv datu imports/eksports. Kas, paldies dievam, nu jau bieži vien ir XML-balstīts. Kas savukārt nozīmē, ka pretstatā uz servisiem balstītai arhitektūrai, ja tev ir viena aplikācija, kas gāž ārā XML un otra, kas lasa citu XML, tad lai dabūtu pirmās datus formā, kas saprotama otrai, tev nav nepieciešams līst iekšā nevienas no sistēmām kodā un kodēt jaunus servisus, bet vienkārši jāuzraksta XSLT transformācijas fails, ko var laist vispār neatkarīgi ne no vienas no sistēmām.

Otrkārt, pats jēdziens "oldskūlīgi" ir, atvainojos, bet gana tizls. Man kā programmatūras pasūtītājam ir svarīgi, lai tā atbilst noteiktām vajadzībām. Vai programmētāja vēlmes darīt kaut ko "modernu" dēļ man būs tagad jāskrien viņam pakaļ uz katru nākošo programmēšanas valodu/fadu? Lika nedaudz pagaidīt. Lai viņš to dara no darba brīvajā laikā par savu naudu, vai pierāda man, kā šādai sistēmai būs mazākas uzturēšanas izmaksas un citi benefiti.

3. <q>Taču, vēlos norādīt, ka XML formāts lielākajā vairumā gadījumu tiek izmantots lieki. Tas varētu būt iemesls, kāpēc man pret to ir nepatika – tas tiek uzstādīts kā pilnvērtīgas zāles jebkam.</q>

Tas varētu tā būt, varētu arī nebūt. Es tev varu neskatoties nosaukt uzreiz 3 aplikācijas konkrētā aplikāciju domēnā, kuras lielā mērā spēj labi darboties tieši XML dēļ. Ja tu vari kaut kā iezīmēt "lielāko vairumu gadījumu", tad varam par to runāt tālāk.

4. <q>XML ir ierobežojošs. To uzskatāmi nodemonstrēja HTML -> XHTML -> HTML5 transfērs. Un tur nav pie vainas slinkie vai riebīgie izstrādātāji.</q>

Ticu uz vārda par HTML, lai arī nesaprotu, ar ko tieši XML ierobežo HTMLu. Jāsaka gan, ka HTML ir viens ārkārtīgi niecīgs XML paveids, kas darbojas vienā konkrētā niecīgā domēnā: web lapas. Līdz ar to, ja tas bija tas, ko tu domāji ar "vairākumu gadījumu", tad, piedod, nepiekrītu.

4. <q>Vēl diezgan labs (lai arī globālāks un ne tik strikti XMLu raksturojošs) piemērs ir SOAPs ar MIME attachmentiem. Kad XML, HTTP un MIME tiek samesti vienā maisā. </q>

Te nu es varu piekrist, vismaz tajā ziņā, ka XMLs ir domāts pārsvarā metadatiem, nevis bināriem datiem. Tipiski normāls XML izmantojums tur, kur jādarbojas ar bināriem datiem ir: (1) binārais fails + (2) xml metadati ==> programmatūra, kas tos spēj salikt kopā.

5. <q>Par procedurālo un OOP gan nepiekritīšu. XPath un XSLT ir vienādiņ izmantojams kā procedurāli, tā objektorientēti.</q>

Eh? Protams, ka XSLT & XPath var izmantot gan ar procedurālajās, gan OO valodās, taču XSLT pati par sevi ir deklaratīva valoda, kas ir zināms learning curve pretstatā (tradicionālajām) programmēšanas valodām.

<q>P.S. Par to atbildēšanu – tik tiešām neesi ievērojis, jo neesi lasījis.</q> Tiešām prieks, ka tā.

Grr, tad atvainojos. Man nav bijusi taisnība.

A par deklaratīvā vs tradicionālo programmēšanas valodu - neredzu problēmas apgūt kā vienu, tā otru. Vismaz man tādu nav bijis. Nepiekrītu tam, ka pie vainas ir tas, ka, pieņemot vienu valodu, citas kļūst grūtāk apgūstamas. Pat, ja esmu pieradis pie tā paša PHP, tas nekad nav traucējis apgūt pythonu, XML/XSLT/XPath uzdevumam nepieciešamajā līmenī, tagad pamatus erlangā un haskelā, utt.

Man vairāk gribētos ticēt, ka problēma (abās frontēs) ir aizspriedumi un nevēlēšanās saprast, ka vieta uz pasaules ir abām.

Vēlreiz atvainojos par nekonstruktīvismu.

Es ieteiktu apgūt Java un Groovy. Argumentācija - šīs valodas tev var noderēt reālajā biznesā, bet ja godīgi - ja neesi gatavs Javai veltīt ļoti ilgu laiku, tad, iespējams, pat nav vērts, jo Java spēks ir, kad izmanto tās dažādās tehnoloģijas, tai skaitā Oracle piedāvātās. Bet vispār ieteiktu apgūt spāņu, sengrieķu, romiešu un arābu valodas, lai bagātinātu savu intelektu. Un vēl ieteiktu atpūsties svaigā gaisā un izvēdināt galvu, nevis lūrēt visu laiku četrstūrainā ekrāna, neatkarīgi, vai tas būtu datora, pda, mobilā vai tv ekrāns...

<b>laacz</b>, es tev ieteiktu tomēr argumentēt, kad tu saki, ka viena valoda ir garām, viena mirst, otra plaukst - kāpēc? Kur ir argumenti taviem apgalvojumiem? Un kāpēc tu gribi mācīties programmēšanas valodu, atklāj savus slēptos mērķus. Lai aizpildītu kādu savu zināšanu robu? Tad kur ir robi?

Par javu - cik nu ir bijusi saskarsme (kādu gadu, sakarā ar vienas sistēmas uzturēšanu / bugfixiem / uzlabošanu), ir radies iespaids, ka tā valoda ir no sērijas "viegli iemācīties, grūti būt profesionālim". Ja ir pāris dienas/nedēļas laika, ko veltīt, bet nav īpašas vajadzības - tas nav tā vērts, tāpat ja gadīsies kāds projekts, kuru nedaudz jāpielabo, to bez lielām grūtībām ar nelielu devu googles/dokumentācijas varēs izdarīt. Ja ir mēneši/gadi (apņēmība un vēlme), lai ne tikai virspusēji apgūtu, bet arī izkostu to visu drusku dziļākā līmenī, tad gan ir vērts. Vienīgais, kā dēļ varētu būt vērts veltīt javai pāris nedēļas - koda strukturēšana/organizēšana kopumā, atsevišķu tehnoloģiju aplūkošana, bet tas viss vairāk tāpēc, lai smeltos idejas, ko varētu pielietot citās valodās/projektos, nevis lai apgūtu javu... Un to tad būtu vērts darīt arī tad, ja java principiāli riebjas.

Ģirt, subjektīvie novērojumi gan paziņu lokā, gan internetos. Ja man būtu argumenti, es tos uzrādītu. Neredzu iemeslu argumentēt, ja es to nevēlos. Ļauj, lūdzu, man dažos jautājumos būt arī subjektīvam.

Ja runājam par maniem mērķiem - tie ir aprakstīti augstāk. Ja tie būtu slēpt, es tos neatklātu, ne tā? Un manuprāt diezgan skaidri ir uzrakstīts "paplašināt redzesloku". Ko vēl vēlies, Ģirt?

Iemācies beidzot Pascālu 1.0

Vienīgais, ko vēlos, ir piedalīties diskusijā. :) Es pats programmēju Javā un Oracle tehnoloģijās (visas te nenosaukt). Ko es varu pateikt - galva nav caurs spainis, kurā var liet un liet iekšā visādas samazgas. Tas nosēdīsies zemapziņā tik un tā. Es ieteiktu pasēdēt un pārdomāt, ko īsti vēlies sasniegt. Paplašināt redzesloku, bet priekš kam? Tikpat labi vari paplašināt redzesloku, apgūstot atomfiziku. Redzesloka paplašināšanai ieteiktu skatīties uz populārākajām valodām, jo tajās likumsakarīgi būs vairāk moderni rīki gan pielietošanā, gan risinājumos. Pats teici, ka neinteresē nekas arhaisks. Lūdzu, varu pateikt, ka Java nav nekas arhaisks, kā reiz, tagad Oracle virza tirgū miljoniem vērtu Java superprojektu - Oracle Fusion Middleware, kas sastāv no daudziem moderniem, stipri advancētiem rīkiem. Vari pasmelties idejas tur. Bet tas būs viss biznesa sfēras programmatūras izstrāde. Ja neinteresē biznesa sfēra, programmē spēles uz C? Ja neinteresē spēles, programmē zinātnisko aprēķinu programmas arī uz to pašu C/C++ vai kādu citu valodu? Izdomā, KO tu gribi radīt un tad domā KĀ (kādu programmēšanas valodu).

<b>laacz</b> - vai šo sarakstu biji jau izskatījis, pirms rakstīji šo rakstu? http://en.wikipedia.org/wiki/Comparison_of_programming_languages

Starp citu, par to JSON un XML - tās visas ir tukšas runas. XML ir standartizēta deklaratīva valoda, kas ir apaudzētas ar visādām "fīčām". Protams, tur ir liekvārdība, bet lai valoda būtu aprakstoša, bez liekvārdības neiztikt? JSON webam ir labāka izvēle par XML, uzskatu, ka web applikācijās browser->server->browser komunikācijā un "browser" galā XML praktiski nekur nav vajadzīgs, bet kā jau te rakstīja - XML ir meta-dati, aprakstoša valoda, kas ir der gan sistēmām, gan izstrādātājam. Nevajag taisīt daudzmiljonu ierakstu datubāzes XML formātā, tad liekvārdība sāpes neizraisīs! Pie tam atbalsts un apaudzētās tehnoloģijas XML ir visplašākais.

Visi šitie strīdi ap valodām kā "tā valoda ir galīgi garām, es zinu daudz krutāku valodu", vai "es protu assembler, tāpēc jūsu visi pārējie esat lūzeri", vai "man riebjas Java un XML, tāpēc es to nemācīšos" ir sausas runas. Reāli dzīvē priekš kam tās valodas ir izdomātas? Lai varētu rakstīt programmas. Priekš kam vajadzīgas programmas? Lai automatizētu procesus. Kam vajag automatizēt procesus? Lai ietaupītu izmaksas. Tātad - nopelnītu naudu! Un šeit nu uzvar grandi, tie kuriem ir resursi, lai tās tehnoloģijas attīstītu un tie, kuru programmatūru izmanto pasaules bagātākie uzņēmumi. Kas tie šobrīd ir par "grandiem"? Cik man zināms, galvenokārt, Oracle, IBM un Microsoft. Google un Yahoo! ir vairāk uz web development specializējušies. Bet šis viss attiecas uz biznesa programmatūru. Kā jau teicu, var nodarboties arī ar spēļu programmēšanu vai datorzinātni, veidojot ūbersarežģītus algoritmus utt.

Ģirt, tieši šo arī gaidīju. Ne sūda :) Biznesu var realizēt gan uz X gan uz Y platformas - lai kāds tas būtu. Jautājums ir par stratēģiju. Pārbaudītas tehnoloģijas no grandiem, <strong>ja veiksmīgi pielietotas</strong>, ar supportu samazina potenciālos riskus. Jauni, ne-grandu, vai pilnībā custom risinājumi, <strong>ja veiksmīgi pielietoti</strong>, samazina izmaksas, bet nereti palielina riskus.

Un tas, ka Google ir specializējies uz web developmentu, starp citu, ir diezgan liels mīts. Viņi ir specializējušies uz inovācijām backendā, tehnoloģiskiem jaunievedumiem, acquisitioningu, kā arī dažādu risinājumu developmentu, kas ne vienmēr iet kopā ar webu. Pie kam, pēdējās investīcijas "nākotnes" projektos (alternatīvā enerģija, pašbraucošie transportlīdzekļi), ielīšana kartogrāfijas lauciņā un atteikšanās no karšu pirkšanas pateicoties crowdsourcing, androīds, utt. Protams - daudz kam no tā ir weba daļa, bet vēl vairāk ir zem tās - tur ar webu nav ne mazākā sakara.

No otras puses - praktiski jebkas mūsdienās ir ar weba komponenti. Ja nav, tad tas ir kaut kas šauri specializēts vai arī nolemts nāvei :)

Ģirt, mums mūsu mazajā, khm, kantorītī, kurš (pēc mājas lapā atrodamās infas) darbojas 10 valstīs un apkalpo 250 štukas klientu un pusmiljonu iekārtu, tādas java, oracle, ms & co tehnoloģijas ir visai sekundāras. OK, IDE ir no MS, java kaut kādiem servisiem arī it kā tiek pielietota, pat PHP ir sava vieta atrasta, bet nu tās visas tehnoloģijas ir kaut kādā mērā sekundāras. Ja ir jāpamanās iebāzt softu ierīcē ar uz vienas rokas skaitāmiem MB lietojamas atmiņas, tad neviens to softu nerakstīs javā, lai arī cik liels, bagāts un kruts būtu Oracle Corporation. Es, protams, nesaku, ka tiem lielajiem grandiem nav savas vietas pasaulē (ne velti viņi ir lieli, bagāti, vareni pielūgsmes objekti), bet nu tas ir baigi atkarīgs no jomas.

<b>binary</b> strādā Point Transaction Systems? Kā tur ir, kā iet? Te tāda vairāk vai mazāk pļāpāšana sanākusi. :) Pamatā jau visu virzību biznesa IT sfērā nosaka lielo grandu un lielo klientu tendences, jo viss ir vienkārši - vairāk resursu, vairāk iespējas, vairāk darbu, vairāk kļūdu, vairāk veiksmīgu risinājumu, vairāk rezultātu! :D Tikai atsevišķi eksemplāri no mazajiem dalībniekiem spēj izcelties ar nepārspējamu ģenialitāti. :)

Ģirt, pēc gada redzēšu, kā ir.

<b>binary</b> - pat ja tikko esi uzsācis strādāt, maksimums pēc pusgada tev lielos vilcienos ir skaidrs viss par uzņēmumu. Kāds vēl gads?

Te izskatās, ka aizgāja standarta fleims "php'čniki vs javisti". Tik man šķiet, ka te cilvēki ir palaiduši garām Javas "vieglo" open source freimvorku eksistenci. Piemēram, šobrīd populārākais no tiem - Spring, kopā ar Hibernate ORM bibliotēku zināmā mērā ir vainojams pie RoR pielūdzēju skaita krituma.

<b>Raimonds</b> - ne tikai Spring, bet jāatzīst jā - Spring ir spēks. Godīgi sakot, phpisti caur Zend Framework mēģina taisīt kaut kādus trikus - tā valoda nav tam domāta, tai nav tāda īpašības, lai veidotu tik organizētu OOP! Domāju, ka daudzi piekritīs, ka Java struktūra ir daudz sakārtotāka par php...

Esam galīgi pilnā abi šovakar! Kur te var iedzert šņabi? Un par ko ir diskusija? OPSIDRALALALĀĀĀ!!! SVINA CŪKAS TĀDI!!!

Brīnos, ka neviens nepiemin klasiku - Cobol, ASM/370 , ņemot vērā cik koda uz tā griežas un ka vecie buki izmirst (tiešā nozīmē) tās jau šobrīd ir finanisāli ļoti lietderīgas zināšanas (ne LV, protams). Protams indieši cenšas šo trūkumu aizvietots, tapēc arī kaut kas no senajiem OS būtu jāzina.

A ja gribas ko interesantu - uzraksti kādas pašizdomātas valodas kompilātoru :)

Cilvēks pajautāja pēc ieteikumiem a jūs uzreiz sākat kašķi par to kas ir un kas nav pielietojams reālajā dzīvē. Ir tūkstošiem valodu un katru no viņām kāds lieto, un katram no lietotājiem ir vismaz kādas valodas kas nepatīk, un tur nav nepieciešami nekādi paskaidrojumi.

Man arī nekad nav patikusi Java dēļ sava smagnējuma un dēļ tā ka viņai joprojām nav multi core atbalsta un dēļ tā ka vienkārši nepatīk. Tajā pat laikā ar lielu interesi skatos uz Scala kas darbojas uz tās pašas java mašīnas, un viņa man patīk , tāpēc ka vienkārši patīk. Tas viss ir gaumes jautājums un par gaumi nestrīdās.

Xml problēma ir viena vienīga - cilvēki nesaprot ka xml nav datubāze un viņu nav paredzēts izmantot kā datubāzi. Diemžēl 80% xml ir pielietots tieši tur kur būtu jāpielieto datubāze (vienalga kura). Un kad tu 10to reizi labo kodu kur kāds gudrīts ir izdomājis glabāt XMLā(jo principiāli tic ka xml ir dievs) nepārtraukti mainīgu ierakstu informāciju, kuru ir reālajā laikā nepārtraukti jāmaina/jādzēš/jāpievieno/jāsortē/jāmeklē un pieprasījumi uz to nāk no dažādiem punktiem, tad jau izdzirdot xml paliek slikti. XML nav paredzēts bieži mainīgai un reālajā laikā apstrādājamai informācijai un punkts. Jo neviens parseris nespēj pārdesmit megabaitu xml failu noparsēt un noeditēt lielā ātrumā. Priekš tā ir izveidotas datubāzes ar simple tabulām.

arnico, javai nav multi core atbalsta? Kā tas bija domāts? Par to, ka XML nav paredzēts bieži mainīgai infai - imho ir, un kā vēl ir! Tiesa, nevis mainīgas informācijas uzglabāšanai, bet tās transportam.

binary,

1. Java - domāju normālu multi core procesoru atbalstu (datori jau sen nāk ar 2 corem, jeb nu jau pedejos 2 gadus ar 4) Iespejams kludos un tagad jau ir ieviests atbalsts.

2. XML - ar bieži mainīgu infu es domāju tādu kas mainās 100 reizes sekundē. Neviens parsētājs nespēj to izdarīt pietiekamā ātrumā. Runa protams iet par diezgan lieliem datu apjomiem.

3. transports - lūk šeit es piekrītu - xml ir transportam, jau sen sevi ir pierādijis šajā ziņā un neko īpaši sliktu par to arī nevar pateikt. Īstenībā jau ir ļoti maz citu alternatīvu kā veikt transportēšanu.

Sāpe ir tā ka no 100 vietām kur ir izmantots xml , tikai 2 ir transports, un pārējās 98 ir datu glabāšana un apstrāde.

Protams resume sanāk tāds ka xml slavu grauj tie 98% pielietotāju kuriem nav sajēgas priekš kā viņš ir domāts un priekš kā nav.

Es uz visu skatos no web viedokla, jo tagad jau tāpat viss palēnām tiek pārtransferēts uz webu.

arnico, nu es zinu, ka sen jau ir pieejami multi-core CPU, un ne tikai ar 2 un 4 corēm (nu jau vairāk kā gadu vecais 12-core Opetron, anyone?). Bet nu neviens tak neliedz javā izmantot threadus, to pat skolās jau vairākus gadus māca (RTU bakalaurs, piemēram). Un jau vismaz gadus 3-4 atpakaļ netā klīda raksti par javas iespējām izmantot vairākas cores. Tāpēc arī nobrīnījos par Tavu apgalvojumu. Sāku domāt, vai Sun/Oracle tiešām būtu tik stulbi, lai nespētu ļaut dažādiem threadiem vienas JVM ietvaros izmantot dažādas CPU cores?

Un nevajag tik ļoti celt to webu slavas saulītē. Nu netiek viss pārnests uz webu. Ir, protams, nozares, kuras vairāk vai mazāk veiksmīgi tiek pārnestas uz webu (webam tiešām ir savi plusi, ja runājam par daudzlietotāju sistēmām), bet nu lai arī cik lieliski būtu uzrakstīta webiska sistēma, webam tomēr ir kaudze trūkumu (gan UI, gan dzelžu veiktspēja, gan datu drošība, gan nepieciešamība pēc stabila, turklāt publiska tīkla - tas tā, lai neteiktu, ka svaidos ar nepamatotām frāzēm).

@Ģirts - pie lielajiem grandiem aizmirsi pielikt veel vienu grandu - Siemens. shitaa kantor perdukts neredz kurs katrs ofis planktons, bet iistniibaa tie iraid gandriiz visur.

@Maaris - cik nu iru redzeejs, Cobol pilliig noteikt neir tas, ko pamaaciities aiz neko dariit paraleel kaukam citam. IMHO domaasan vins pras iipatneej (ar graamatvezhiem irat sadzeerushi?), un attieciig arri mozgas iepravii taa, ka uz C stilu apakal tik viegl nepaaries.

@binary - eto kuraa RTU bakalaura kursa prieksmetaa Tev threadus maaca? pie Ratnieka izveels kursaa "Java smth"? AFAIK, ne katru gadu tur grupu izdods nokomplekteet, neder. citur? kur?

ZBH, nu man pāris gadus atpakaļ vienu semestri bija tāds priekšmets kā "paralēlā programmēšana" (izvēles priekšmets; otrs variants bija kaut kas par "lielo sistēmu izstrādo"). Lielākā daļa lekciju bija ADA, bet pāris lekcijas tika veltītas arī javai. Priekšmets, jāatzīst, bija diezgan nepopulārs - vairums izvēlējās lielās sistēmas. Pasniedzēja vārdu, uzvārdu neatminos (zinu, ka agrāk ortusā kaut ko varēja paskatīties, bet tagad ortus izskatās pēc kaut kādas ziņu lapales ar forumu), bet nu bija samērā jauns īpatnēja paskata tips, kurš, kā no malas likās, tēmu pārzina pat ļoti labi, nevis tikai ķeksīša pēc pasniedzēja līmenī.

ZBH, atausa atmiņā, ka Ratnieks ar javu arī laikam bija, bet uz viņa lekcijām man nebija jāstaigā - bija toreiz 1-2 nedēļu pieredze ar javu. Pirmās lekcijas vidū (ministrapbrīdī) sarunāju ar viņu, ka uzrakstīšu nākamajās pāris dienās kaut kādu nelielu client-server softu un būs automātiskā ieskaite. Tagad tā miglaini atceros, ka bija vēl kaut kāds priekšmets, kur vajadzēja kaut kādā pirmā stāva kabinetā javā rakstīt klientu un serveri un darbināt uz Solaris(?), bet arī tajā priekšmetā par threadiem nekā nebija... Pat neatceros, kas tas bija par priekšmetu.

#100. Šitā tēma kak raz ir aktuāla, jo pašam vajadzēja .h uz .pas pārtulkot. Fascinēja tas, ka ASM veco kodu cilvēki tonnām grūž caur Program transformation softu. Visu konvertē no ASM uz C un Cobol. FermaT, piemēram ir spēcīgs rīks piedevām bezmaksas (GPL). Bet nu savām vajadzībām ātrāk ir iemācīties vairākas jaunas valodas un vienkārši pārtulkot + perl vai python skripti, nekā burties tādā sistēmā.

<b>binary</b> - muļķības, viss TIEK pārnests uz webu. Netiek pārnests tikai tas, kam tur nevajadzētu būt, pieņemu, ka tavā darbavietā SIA Point Transaction Systems, kas atrodas Krasta iela 105a, LV- 1019 Rīga, Latvija - tur droši vien ir maksājumu termināļu tīkli, kas neatrodas webā (neko nezinu par šo biznesu, bet pieņemu). Protams, web tas ir http, https protokoli, tās ir weblapas, kuras tiek attēlots uz "web browser" dažādās sistēmās. Web pārlūkprogrammā tev vienmēr būs tikai "client tier" daļa - "User interface". Visa loģika, dati, validācija tad tev glabāsies citur. Ko tad tu saproti ar drošību, jautājums? Un kāda vēl dzelžu veiktspēja, mūsdienās, kad katram sevi cienošam datorlietotājam mājās ir vismaz Core i3 ? Vai skaties to pēc knauzeriem, kas hostē web aplikāciju uz Celeron? Tā ir viņu problēma, ja viņi dzīvo 8 gadus vecā pagātnē... Servera pusē ir iespējami dažādi risinājumi un ne visi prasa nenormāli daudz resursus. Bet dzelžus pat nav jāpērk dārgākos, var salikt no lētiem dzelžiem web aplikācijas hostu un klasterēt.

Ģirt, tieši tā - uz webu pārnests tiek TIKAI tas, kam web ir ērtāka vide. Vismaz tā vajadzētu būt. Cik tādu jomu ir? Daudz. Ļoti daudz. Bet šis "ļoti daudz" ir dikti tālu no "viss".

Par veiktspēju - ir atšķirība, vai 100'000 lietotāju dati tiek apstrādāti centralizēti uz dažiem sasodīti redundantiem serveriem ar milzīgiem backup apjomiem (tas viss, tb gan redundance, gan backupi, ir "must-have" centralizētām sistēmām) vai tomēr uz 100'000 lietotāju datoriem. Webiskās sistēmās, grozies kā gribi, bet viss smagais process notiek centralizēti. Vai tas ir vajadzīgs? Daudzlietotāju sistēmām/procesiem - jā. Individuāliem procesiem - waste of resources.

Par drošību - atver acis, ibio! HTTPS vien neko daudz nenodrošina. OK, tas kaut kādā mērā nodrošina drošu datu transportu, bet tas arī viss - neko vairāk no drošības viedokļa tas nedod! Tai pašai googlei u.c. "mākoņservisu" gigantiem pēdējā gada laikā vien ir bijušas vairākas nozīmīgas ķibeles - gan dzelžu, gan cilvēciskā faktora dēļ, nemaz nerunājot par hakeru "uzbrukumiem", kuru dēļ mums aktuālajā reģionā (tb Latvijā) šādi tādi sensitīvi dati vēl nesen bija pat ļoti brīvi pieejami.

p.s. Ģirt, programmēšana ir ne tikai "par manu kaķi" tipa mājas lapu izstrāde, un pat ne korporatīvu mājas lapu izstrāde. Pat ja tam visam pieliekam CRM, grāmatvežu, uzskaites u.c. sistēmas - ar to viss neaprobežojas. Ir arī industriālo iekārtu vadības software, telefonu software, auto kompju software, GPS iekārtu software utt utjp - ļooooti daudz jomu, kur ir jāprogrammē un kur webs var būt tikai kā papildinājums, nevis kā pamatvide, kurā softam strādāt.

arnico,binary: Puiši, jūs laikam vellu dzenat par Java un JVM daudzprocessoru/kodolu atbalstu ? Tur viss ir labākajā kārtībā. Java valoda jau izsenis satur Threadu programmēšanas iespējas un komplektā ar references Sun virtuālo mašīnu vairāk nekā lieliski tiek galā ar resursiem, ko OS un dators tai sniedz ? Iesaku iestudēt šito lappeli http://www.spec.org/jbb2005/results/jbb2005.html ar reāliem JVM testiem. Tur ir minēti gan CPU, gan kodolu skaiti katram konkrētam dzelzim. Mīlīgākais tajā sarakstā ir "Azul Compute Appliance 7380B" dzelzis uz kura tika darbināta 1 JVM, kuras rīcībā bija 860 kodoli.

<b>binary</b> - protams, web browser pusē nekādas drošības nav, jo tur darbojas tikai atvērtie formāti un tur var ielīst jebkur. Bet tas ir tikai UI, dati jau tur nekādi neglabājas. Tiek nosūtīti un atsūtīti dati caur https, kas ir it kā drošs, cik man zināms, servera pusē, kas notiek, tas jau vairs nav tikai web drošība. Atkal sanāk kaut kāda murmulēšana par drošību bez konkrētiem faktiem. :) Tas ka ir visādas software nav nekāds jaunums. Neviens jau neaizliedz arī web aplikāciju implementēt atsevišķi citām iekārtām.

juzi, that's what I said.

Ģirt, kurā vietā es kaut ko minēju par klienta gala drošību? Un kurā vietā es kaut ko minēju par kaut kādu nebūt "web drošību" (tas par "tas jau vairs nav tikai web drošība" piebildi)? Runāju par drošību kopumā.

Un "web aplikāciju implementēt atsevišķi citām iekārtām" var tikai tad, ja web aplikācija kā tāda pastāv. Nu nav nepieciešams monitora darbību regulējošu softu rakstīt kā web aplikāciju, lai pēc tam viņu pārtaisītu par "ne web aplikāciju", turklāt darīt to visu caur vienu vietu tikai tāpēc, ka, redz, "viss tiek pārnests uz webu" un "staigāju ar diviem pirkstiem gaisā". Web ir specifiska niša, specifiska vide, kurā nevar bāzt visu kas pagadās.

<b>binary</b> - tev acīmredzot ir šaurs skatpunkts, sēdot tik šaurā nišā kā maksājumu kartes, specializējies dikti šauri un sanāk tāds šaurs skatījums. :) Tātad, ir arī tādi web servisi, kas nodrošina datu pārraidi starp dažādiem servisiem un pat dažādām aplikācijām. Painteresējies par "multi-tier architecture". Tā joma nav šaura, tā ir plaša joma, jautājums, par ko runā - tikai par web UI vai visu web infrastruktūru un aplikācijām? Tas, ka tu redzi tikai web pārlūkprogrammā lietotāja interfeisu un spried pēc tā, nenozīmē, ka tur apakšā nav milzīgi, pat sarežģīti softi. Tieši web aplikācijas ir sarežģītas, jo tur drošības jautājumu risina dažādos līmeņos. Ja tev vajag superdrošību, tad vispār nogriez internetu un taisi visu lokāli, lai neviens no ārienes pat teorētiski netiek klāt, kā arī ieslēdz visus dzelžus milzīgā seifā. Un vēlreiz, tu saki - "Web ir specifiska niša, specifiska vide". Tad man ir jautājums, specifiska cik plašā mērogā? Ja skatāmies biznesa programmatūras vispārējo mērogu, tad tā ir viena no galvenajām pamata sfērām. Drīzāk tu tagad runā par specifiskām lietām - augstākās slepenības pakāpes datiem - pin kodi, paroles, liecības un dokumenti par NLO, Osamas Bin Ladena pēcnāves foto ar Obamas parakstu utt. Un vispār - kas traucē caur web transportēt droši šos datus? Tunelis tiek uztaisīts, SSL (vai arī tu gudriniek esi jau uzlauzis SSL vai pazīstu kādu tādu?), lietotājs savus datus zin, tātad, no viņa paša tie nav jāslēpj, varētu vienīgi apkārt klaviatūrai uztaisīt žogu kā maksājumu karšu termināļiem, lai kāds no malas neredz, ko spaidi ar pirkstiem. Tad arī tas kā servera galā tiek apstrādāts aplikācijā - tas jau ir jautājums cits un daudz vispārīgāks. Web nav nekas specifisks, tā ir mūsdienu realitāte, mūsdienās aizvien vairāk biznesi pārceļ savas sistēmas uz web, kaut vai iekšējo web, reti kuram nopietnam biznesam nav savas aplikācijas, specifiskas drošības prasības web jomā jau gadiem tiek risinātas...

Ģirt, kļūdies par mani. Es maksājumu karšu nišā esmu mazāk par pusgadu (turklāt arī pienākumi tādi, ka nevarētu apgalvot, ka tiešām esmu maksājumu karšu nišā), bet programmēšanā kopumā (gan sava prieka pēc, gan darba tirgū kopā ņemot) - nu jau 10 gadus. Laiks pagājis pietiekami ilgs, lai būtu paguvis aptaustīt dažāda tipa aplikācijas, tā ka par skatpunkta šaurību es nevarētu sūdzēties. Kā reiz šķiet, ka visi tie, kas apgalvo, ka "viss notiek tikai tā un nekā citādāk", dzīvē redzējuši/izstrādājuši tikai viena tipa sistēmas.

Par multi-tier arhitektūru - tai, protams, ir sava vieta webā, taču pa lielam arhitektūra ir pielietojama jebkurai client-server tipa sistēmai. Un "client-server" vēl nebūt nenozīmē "web". Savukārt "programmēšana" nenozīmē "client-server sistēmas".

IMHO nav jēgas te turpināt spamot par šo tēmu. Katram savs viedoklis, katram sava pseudo-patiesība. Komentāri, protams, arī tiek lasīti pa diagonāli - "šito teikumu gribu lasīt, bet šito nē - tas ir pret maniem principiem, tāpēc izlasīšu to pa savam". Atslēdzos.

@Ģirts "protams, web browser pusē nekādas drošības nav, jo tur darbojas tikai atvērtie formāti un tur var ielīst jebkur"

kas tas bija? security through obscurity?

"ir arī tādi web servisi, kas nodrošina datu pārraidi starp dažādiem servisiem un pat dažādām aplikācijām"

tikai taapee, ka caur HTTP var aatr salipinaat no kaad cit gatavajiem kluciisiem vispaar kaukaa ejosh prototip. web - da neviens browseris lietotaaj izpratnee tur nepiedalaas, taa ka jautaajums, cik pareiz iraid attiecinaat terminu "web" uz taad pielietojum. plus veel taadiem risinaajumiem bagaazhaa naak overheadi ar aiztureem. tehnisk garantij, ka kaukas notiks x milisekundees, neir nekaad.

ZBH - vai tava vārda akronīmu atšifrējums gadījumā nav "ZajeBal Huj"? Kaut kā dīvaini tu izsakies, katrā ziņā... Uzraksti labāk saprotami.

<b>binary</b> - protams, katrs uztver pa savam, bet tu te kaut kā saki, ka "web esot specifiska joma" un tas ir no tavas puses šaurs skatījums. Redz, ja web var būt gan biznesa aplikācijas, gan spēles, gan - nu jau pat parādās visādas grafiskās apstrādes aplikācijas, kā arī mākslas projekti, tad tu kļūdies saukdams web par "šauru sfēru". Paskaties uz to lietu objektīvi. Protams, web user interfeisā jeb tajā, ko redzi iekš web pārlūkprogrammas varbūt ir 5 pogas un 3 dažādi atvērumi pa lielam, bet apakšā varbūt klasterēti serveri, efektīva daudzmiljonierakstu datubāze un n-tie web servisi un tas viss vēl darbojas ātri? Tāpēc nav ko te tukši spriedelēt, kas ir "šauri", kas "plaši". Kā jau teicu, tikpat labi var apgalvot, ka tava karšu maksājumu sfēra ir "ļoti šaura".

Ģirts, dļa osoby "es neprotu lasīt" cilvjiem - maksājumu karšu sfēra nav mana.

Ģirts, dļa osoby “es neprotu lasīt” cilvjiem #2 – es nevienā komentārā neesmu minējis, ka web būtu šaura sfēra (te nu pierādās minētais "šito teikumu gribu lasīt, bet šito nē – tas ir pret maniem principiem, tāpēc izlasīšu to pa savam").

@Ģirts - taisnvirzien domaasan detected

ZBH - tu neesi gadījumā ta Šulcs (shulcs.lv) ? Lai gan viņš izsakās stilīgāk...

scheme, tāpēc ka lieliski mācību materiāli, kas jau kļuvuši par klasiku grāmata: http://mitpress.mit.edu/sicp/ lekcijas: http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/

Vispār es ieteiktu <b>laacz</b> izlasīt visas "The Art of Computer programming grāmatas": https://www.amazon.co.uk/Computer-Programming-Volumes-1-4A-Boxed/dp/0321751043/ref=sr_1_2?s=books&amp;ie=UTF8&amp;qid=1304695998&amp;sr=1-2 Un pēc tam zīmēties, ka viņš grib iemācīties jaunas programmēšanas valodas! :D

Paldies par atbildi, ceru, ka nebiju pārāk skarbs. :)

>A par deklaratīvā vs tradicionālo programmēšanas valodu – neredzu problēmas apgūt kā vienu, tā otru. Vismaz man tādu nav bijis. Nepiekrītu tam, ka pie vainas ir tas, ka, pieņemot vienu valodu, citas kļūst grūtāk apgūstamas. Pat, ja esmu pieradis pie tā paša PHP, tas nekad nav traucējis apgūt pythonu, XML/XSLT/XPath uzdevumam nepieciešamajā līmenī, tagad pamatus erlangā un haskelā, utt.

Un tev ir pilnīga taisnība. Es vairāk par to, ka ir tāda kvalitatīva atšķirība starp to kādā veidā efektīvi realizēt uzdevumu valodā, kas būvēta pēc procedurāliem (OOP vai bez) principiem un kā efektīvi sasniegt to pašu mērķi funkcionālā vai deklaratīvā valodā. Nu, vecs piemērs, bet te Paul Graham par to, kāpēc bija vērts rakstīt online veikalu LISPā: http://paulgraham.com/avg.html . Man pašam nekad nav izdevies sajust to, kā efektīvi risināt uzdevumus tai pašā haskelā, nepārvēršot savu kodu par vēl vienu procedurālas valodas klonu, tāpēc visu cieņu tev par spēju pielietot abu tipu principus.

> Man vairāk gribētos ticēt, ka problēma (abās frontēs) ir aizspriedumi un nevēlēšanās saprast, ka vieta uz pasaules ir abām.

Āmen! :)

Iesaku iečekot šo lapu: http://99-bottles-of-beer.net/abc.html Tur pie reizes arī varēsi novērtēt sintaksi utt. Tikai tur ir arī čupiņa ezoterisko (kaut gan, daļai no tiem ezoteriskiem ir arī puslīdz strādājošās realizācijas, piemēram, http://en.wikipedia.org/wiki/Piet_%28programming_language%29).

Lua

atrisini 5 zvaigžņu uzdevumus - http://www.lio.lv/olimps/uzdevumi.php?sortby=d&amp;sort=desc

COBOL - ja gribaas pikji daudz un dikti kaast no vecaam sisteemaam (veel chupaam taadu ir pasaulee un vel gadus 20 vismaz buus)

Java - ja gribaas kautko lielaaku uztaisiit par paarsmits tuukstoshu lietotaaju sisteemu. Riiku atbalsts ir burtiski neizmeeraams. Plashi pieejami serveri ar iebuuveetu klasterizaaciju, J2EE atbalstu un vel ljoti daudz ko citu (pat mazais purkshkjis Jetty ir gana njiprs, lai pavilktu pusmiljonu lietotaaju uz attieciigas aparatuuras, nerunaajot par Tomcat, JBoss u.c.). Viss amazones clouds griezhaas uz Javas. Vizuaalajam var kabinaat klaat ko vien sirds veelas.

SQL optimizaacija - te vareetu arii pielikt klaat pashas DBMS sisteemas optimizaaciju. It sevishkji ja runaajam par palielaam datu noliktavaam ar faktu tabulaam, kuru ierakstu skaiti meeraas miljardos un uz augshu. Arii tranzakciju sisteemaam ir jaazin kaa taas lietas salikt pareizi pa plauktiem, lai viss grieztos daudzmaz optimaali (piemeeram, nelikt uz Oracle baazes taisiitu reportu sisteemu uz NFS, savaadaak TEMP tablespace izaugs neredzeetos lielumos, pat visu NFS masiivu (4TB) var aizkakaat). Ir cilveeki, kam shitais ir pamatdarbs.

Bash, sed, awk, gawk - un visi paareejie *nix skriptinji. Vel neesmu sastapies ar nevienu cilveeciiga izmeera sisteemu, kuraa shitais nebuutu bijis vajadziigs un noderiigs. Ljoti daudzaam BI sisteemaam tieshi ETL procesi ir taisiiti ar bash+sed scriptiem. Varbuut mazaakaam sisteemaam (logi prieksh ETL liidz 5GB dienaa) pitoni un citi modernie skriptoshanas riiki buus aatraaki/eertaaki/izdeviigaaki.

Izskataas, ka peereejais jau taka buutu diezgan labi nokomplekteets :)

Patikaas komentaars par Java un kodolu atbalstiem :) njemot veeraa visu veeraa njemamo, bet tas ir SUN ultra sparc T1-T3 procesoru esamiibu saakot no 2005 (T1), saakot ar 4 koreem un beidzot ar 16 (T3) diez vai vinji buus tupi seedeejushi un skatiijushies kaa vinju lolojums (java) nespeej pilnveertiigi izmantot vinju otra lolojjuma (T1-T3) potenciaalu.