Jump to content

Java kā pirmā valoda programmētājam?


Guest wersa
 Share

Recommended Posts

Mezavecis

Viss ir pat ļoti loģiski. Ja neesi samaksājis par testēšanu, parakstīji PN par gļukainu softu, tad kod pirkstos. Biznesa aplikācijās pilnīgi visu nosaka nauda. Nav naudas, nav kvalitātes. Dažu entuziastu aplikācijas ir ārpus kritērijiem, jo dara aiz savas vislabākās gribas.

 

Nav jau tā, ka visi programmēšanas kantoros lauž luni un taisa sūdīgu softu, bet ja pie softa strādā n cilvēki, tad kļūdu iespēja līdz ar iesaistīto cilvēku skaitu palielinās, jo neviens nevar paredzēt visus scenārijus, ja to skaits sasniedz tūkstošus. Dzirdu tekstu, ka vajag algot visuprofesionālākos programmētājus un gļuku nebūs. Bet kāds būs rezultāts - šie profesionāļi būs pārslogoti, softs taps gadiem vai maksās tik daudz, ka neviens klients par to nemaksās. 

 

Tā kā "welcome to real world" :) Lai cik tas dīvaini nebūtu, digitālā laikmetā, kad 5-gadīgs sīcis A-Z prot ar datoru strādāt, programmētāji no mācību iestādēm nav daudzkāršojušies, bet pieprasījums pēc aplikācijām, webiem un citiem sūdiem tikai pieaug, līdz ar to likumsakarīgi, ka krīt kvalitāte it visā.

 

 

Binzess diriģe visu. Kas attiecas uz progresu. Man vienalga. Man svarīgi lai strādā nevis karās un sopports saka tu pats esi stulbs un tā nedrīkst darīt, jo tā nav loģiski pareizi. A dzīvē ne viss vienmēr ir loģiski.
 
Link to comment
Share on other sites

  • Replies 289
  • Created
  • Last Reply

Top Posters In This Topic

  • Vilx-

    55

  • binary

    38

  • Inspektors Caps

    38

  • JDat

    26

Top Posters In This Topic

Kvalitate noteikti būtiski paliek sūnaināka tieši programmatūrai, kas tiek ražota Latvijas tirgum, un tas ir loģiski, jo tirgus neaug, tas ir NENORMĀLI nabadzīgs, bet konkurence piegaug, jo lielās Pasaules korporācijas šeit piedāvā konkurējošus produktus, kuru izstrādes budžeti īpaši neatpaliek no mūsu valsts IKP, bet, savukārt, cenas nav būtiski augstākas.

 

Es domāju, ka, lai Latvijā būtu kāds IT veiksmes stāsts (Latvijas NOKIA) , tad cilvēkiem, kuriem pieder IT biznesi te (ir darbaspēks&nauda) UN/VAI cilvēkiem, kuriem ir ļoti liela pieredze UN galva uz pleciem, vajadzētu beigt koncentrēties uz divām lietām  "valsts pasūtījumi", "latvijas tirgus".

Nav būtiski vai tur kaut kāda grāmatības programmele, vai kas cits.

Darot tā, tas faktiski nozīmē - lai citi pelna naudu, mēs paveģetēsim uz mūsu jau nabagās valsts.

Pirktspēja Latvijā samazinās!!

Arī Baltijas tirgus nebūs glābējs, jo tas, pirmkāŗt, ir mazs, otrkārt, ļoti, ļoti, ļoti nabadzīgs.

 

Patiesība ir tāda, ka ļoti labi Programmētāji Latvijā pelna nedaudz vairāk kā melnstrādnieki R-Eiropā, un tas ir ļoti skumji. Naudā tie varētu būt 2-2.5 tūkstoši. (Principā tikko ārā no nabadzības)

 

 

Īsumā: Nav jabūt doktora grādam ekonomikā, lai saparstu, ka Latvijai ir jāražo programmatūra globāliem tirgiem (ļoti kvalitatīva), jāpārdod tur, bet pašiem jāpērk no viņiem, ko viņi pārdod par relatīvi kapeikām.

Citi ceļi ved uz vēl lielāku nabadzību un attiecīgi sūdīgāku softu. ;)



Ja kāds domā, ka viņš šeit labi dzīvo... un lepojas, ka ar 500 latiem viņam visam pietiek....

Dažās nozarēs GB praktikantiem maksā 4-5 tūkstošus.

Nemaz nerunājot par augsta ranga speciālistiem vai amatpersonām.

Labots - shark
  • Patīk 1
Link to comment
Share on other sites

 

 

Pirmais "lielais" kursadarbs (čats + failu pārsūtīšana + klienta-servera sesijas + multicast) ar Win32 API + WinSock IMVHO bija reāli zemē nomests laiks, jo ne ta tas kods ir labi uzturams (tu esi piesiets pie window loop), ne efektīvi tiek izmantots programmētāja laiks. C# to visu varētu daudz smukāk un efektīvāk realizēt.

Ja to uzskati par zemē nomestu laiku, tad varu teikt tikai vienu - vai nu neesi saskāries ar piņķerīgām problēmām, vai arī vienkārši jau zini, kā tās risināt (rezultātā priekš tevis tās nav problēmas).

Pats sāku ar Delphi Visual Basic, par kuru jau paspēju aizmirst :) Pēc ~pusgada no kursabiedra / klasesbiedra dabūju uz Delphi, kas tad arī ilgu laiku bija "mana valoda / vide". Kaut kādā brīdī sāku kost WinAPI. Pa starpai aktīvi darbojos www.experts-exchange.com - kā atbildētājs, nevis kā jautātājs (kad man bija jautājumi, uz tiem tipiski neviens nespēja atbildēt - ne delfi.lv #coders, ne kur citur :D). Tur varēja ļoti labi novērot, ar kādām problēmām saskaras "programmētāji - klucīšu bīdītāji". Nēnu es nesaku, ka viņi slikti programmē. Saku tik, ka viņi nezina, how stuff works, un tas viņiem sagādā milzu problēmas, piemēram, nedēļu mēģina saprast, kāpēc trayā pazūd ikoniņa, kad logam nomaina BorderStyle (reāls gadījums). Ja esi kodis WinAPI, tad to atkost un novērst ir max pusstunda, pa starpai aizejot līdz virtuvei sataisīt tēju. Protams, tādā gadījumā pat nepamani, ka ir bijusi problēma, jo gluži vienkārši neesi notriecis nedēļu uz tādu sīkumu.

Nu? Vai pēc šāda stāsta (iz reālas pieredzes) vēl joprojām uzskati to laiku par zemē nomestu?

 

 

P.S. Ja tagad būtu jāizvēlas, sāktu ar C++ :) Kaut kādā brīdī veltītu laiku arī ASM. Ak jā, noteikti paķertu arī kādu atmegu, diodes, displejus, sensorus utt, ar ko spēlēties. Toreiz tam laika būtu pieticis… Tagad - pāris brīvi vakari atrodas, lai ko pasāktu, bet tad atsākas ikdiena…

 

 

 

Globāli ņemot: mūstienās vairs neviens nedomā par veiktspēju. Visiem ir pofig. ka tik strādā.

Nevajag globalizēt :) Ja tomēr gribas globalizēt, tad nevis neviens nedomā par veiktspēju, bet visi izvēlas kompromisa variantu starp ātrdarbību un ieguldīto darbu. Izpratne par to, kur ir tas kompromiss, atkarīga no konkrētiem apstākļiem.

Link to comment
Share on other sites

binary: man nācās iet pa web uzskaites sistēmu taciņu iztikai un WinAPI faktiski nebija nekāda pielietojuma darba tirgū, tāpēc arī saku, ka nenoderēja prast uztaisīt minimālistiskas lietas. Maksimums - kaut kādiem saviem privātajiem traineriem, malvārēm utml hobijprojektiem. Un epizodiski darbā, bet arī ne jau nu tādus hakus industriālos projektos, bet tur, kur tiešām hakus vajag, līdz neatrodas labāks risinājums.

 Pieredze ir ļoti vērtīga un unikāla un tā, bet karjeras ziņā neredzēju un joprojām neredzu iespēju pielietot. Tāpēc noliku putekļainā plauktiņā un kopš tā laika neesmu cilājis. Tikai kā ķeksis CV, jo šito + programmu krakošanu reti kurš ir darījis. Un arī pluss tikai tādu "hardcore" programmētāju acīs, kas zina, kas tas vispār ir.  :) 

 

BorderStyle - es pētītu ar WinSpy++, vai tas logs TIEŠĀM ir tas pats un vai nevajag vēlreiz Shell_NotifyIcon saukt. C# tas laikam noreducējas uz +1 kontrolu "NotifyIcon" un piekrītu, ka ir forši zināt, kā tas vispār notiek zemākā līmenī. 

Labots - usver
Link to comment
Share on other sites

Guest wersa

shark

Jā, atzīmēju gudru viedokli - pirktspēja Baltijā samazinās un tas ir taisnība. Ienākumi neaug tik strauji kā vispārējo izdevum izmaksas, mazāk atliek t.s it kā brīvas naudas.

Precīzi, nabadzīgs tirgus, ļoti MAZS tirgus. Vienā topikā vēl vienotrs brīnījās, kā tā, pakalpojum sniedzējs vai sīkuzņēmējs darbojas vairākās jomās lai savilktu kopā galus. Mazs tirgus, maz iedzīvotāju utt.

 

Īsti korekti nevarētu programmētāju salīdzināt ar  pilnīgi nekvalificētu ļoti vienkāršu darbu strādnieku vai pat darba galdu iestatītāju un pat ķīmiķi – tehnologu utt.

Programmētājs var arī bez darba devēja uztaisīt programmu, darbiņu, ko parādīt :) . Darbagalda iestatītājam tas būtu grūtāk, tāpat kā ķīmiķim- tehnologam ( nerunājam par ZPI laboratorijās strādājošiem, bet tā – macījies, pie sevis uztaisīji un ir ko atrādīt, kaut ko oriģinālāku).

Pārcels ražotni citur, kur strādās rūpnīcas speciālists? Brauks uz ārzemēm, citu pilsētu? IT tomēr vismaz ko vienkāršāku var padarīt, kamēr sameklē jaunus  darbiņus. :)

Link to comment
Share on other sites

Inspektors Caps

 

 

Likās kaut kā tizli GAN atstāt case WM_CLOSE: .. case WM_CREATE: .. garos tekstus karājamies, GAN taisīt katram savu freimvorku/vrapperi, lai to uzrakstītu smukāk .. un kam tas vajadzīgs?

Man pat īsti nepielec par kādiem tekstiem Tu runā.. Nu, ja Tu gribi apstrādāt programmas aizvēršanu vai kādu citu gadījumu, tad Tu tam raksti kodu. Vai to atstāt vienā WindowProc blāķī, vai iznest atsevišķā funkcijā, tā jau ir tā māksla programmēt. C# dara to pašu - uztaisa jaunu funkciju, kur Tu ieraksti kodu. Kur ir tā lielā atšķirība? Tas, ka ar roku jāpieraksta tas viens messages case? Es piekrītu, ka native kodam ir vairāk teksta plus vēl C# daļu koda ģenerē pati IDE, bet vai tas ir tas supervērtīgais ieguvums dēļ kura upurēt to, ka softs zaudē lielāko daļu performances un vēl pusi funkcionalitātes? (jo idejas, kam .NET nav gatavu klašu, 99% gadījumu vienkārši tiks svītrotas un netiks implementētas vispār)

 

 

 

cik regulāras piegādes?

Tā ir tāda ierobežota uztvere, jo visi nedejo pasūtītāju diedziņos...

 

 

 

WinSock arī pats visu raksti ar roku vai arī abstrakcijas tam veido? Un ja jā - kāda mārrutka pēc?

Ko rakstu ar roku? Nu, ir funkcija send(). Sūtu ar to datus. Ja virs TCP vai UDP izmantoju savu protokolu, tad protams tas protokola formēšanas un atpazīšanas kods man pašam vien ir jāuzraksta un priekš tā būs funkciju komplekts, kas ar to nodarbojas. Tieši tā pat .NET būs ar NetworkStream.Write() metodi. Gan tur, gan tur varam to darīt arī asinhroni. Kur ir tas milzu .NET ieguvums?

 

 

 

kur tieši ir java pudeles kakli un kur nav

Tu pats par to Java samudīji, iepinot nevietā web serverus, jo biedrs teica, ka tā bremzē, tikai nebija piebildis, ka runa ir par programmām datorā, kas gan topika ietvaros tāpat ir skaidrs. Bet Tu iemeti servera lietas, kur performance ir jāsalīdzina ar PHP interpretatoru un ar to it kā pamatoji, ka Java esot ātra. OK, tur varbūt ir, bet tas šeit nav par tēmu, jo runa ta bija par programmām, kuras salīdzina ar C# un C/C++ sniegumu... Un gan Java, gan .NET uz I/O operācijām pakāš, jo tiem ir liekas un diezgan laikietilpīgas abstrakcijas. Native kodam tādu vienkārši nav.

 

 

 

ir kaudze sistēmu, kas arī uz izstrādes darbstacijām smuki un ātri darbojas

Es gan apkārt redzu tieši pretējo - ir KAUDZE (99%) sistēmu, kas velkas kā nāve un bonusā vēl tad atļaujas gļukot un vispār nepildīt no tām prasīto! Visādas web sistēmas iekšējā LAN tīklā veras vaļā n-tās sekundes un ilgāk. Visādas Java drazas uz i3 palaižas atkal n-tās sekundes. Kad tie hlami ir atvērušies, tad skrollēšanas pa gariem sarakstiem notiek ar redzamu aizturi un ekrāna informācijas pārzīmēšanu. Kad ieslēdz kādus filtrus, tad filtrēšana notiek absurdi lēni. Turpināt? Saproti - uz šodienas dzelžiem (pat uz lētāko vienkodola Celeron) tās lietas VAR lidot vienkārši zibenīgi!

 

 

 

Piemēram, sūda Pascal, kas kas tā arī nav ticis tālāk par apmācības kursu sastāvdaļu ... Pascal nevienam nevajag un neko praktisku izdarīt nevar.

O-ho-hoo! Par Delphi neesi piemirsis? Lūk, Blumentals Software - mūsu pašu puiši ar kvalitatīviem produktiem, kas izstrādāti ar Delphi. Un tad jau vēl ir tāds nepopulārs un nepraktisks, tikai nabadzīgus ~10 miljardus (nesajaucu) USD nopelnījis softs kā Skype, kam user interfeiss arī ir izstrādāts ar Delphi. Starpcitu, tā summa pārsniedz Igaunijas valsts gada budžetu...

 

 

 

Bet sākt ar C/C++ ir grūts ceļš, vismaz pēc personīgās pieredzes. Pirmā grāmata, ko biju nopircis bija tieši par Visual C++, kurā izlasot pirmās 100 lappuses neko neiemācījos un likās kaut kāds vājprāts. Arī joprojām šo valodu uzskatu par mākslīgi sarežģītu un marazmainu programmistu izdomājumu, it īpaši to, kas skar unicode teksta virkņu apstrādi.

Nu, sākt ar Visual C++ un uzreiz WinAPI vai MFC tiešām ir vājprāts. Tādēļ sākt vajag ar normālām CLI (komandrindas) programmām un labāk pat C nevis C++. Pēc tam pārslēgties no C vai izmantot abus tāpat nav problēmu, bet sākt ir daudz vieglāk ar C, jo tas lūk nav šāds nevajadzīgi sarežģīts! Unicode gan ne ar ko nav savādāks par parastu ASCII tekstu apstrādi, ja vien to dara pareizi, ko protams atkal jēdz tikai retais...

 

 

 

Labs programmētājs programmē tajā valodā, kurā vajag programmēt, un par to daudz nepukst.

Ja ar to domāti visādi biznesa uzspiesti nosacījumi, tad tas ir tikai labs vergs, nevis labs programmētājs!

 

 

 

2) sinhronas operācijas main thread'ā (un tad vismaz Application.DoEvents Method (System.Windows.Forms) ) ir jāizmanto kā vorkaraunds

Un nāk palīgā nevietā izsaukts ļaunais message loop, lai superstulbā kodera-līkroča kods vismaz kaut kā tiktu uz priekšu... :D

 

 

 

Paint.NET, piemēram, ir rakstīts iekš .NET. Man tas nekad nav kāries vai bremzējis arī uz lēnākām sistēmām.

Kāries man arī nav, jo kods laikam ir prātīgi veidots. Bet nekad nav bremzējis? Salīdzinot ar ko? Uz i7 mobilā telefona bildītes apstrādājot? :D Atvēru 10 MPix bildi un softs jau aizņem 180 MB RAM. Kā tas var nebremzēt mazāk jaudīgu sistēmu? Bet galvenais jautājums - ja 32-bit 10 MPix bilde RAM aizņem max 40 MB, vai tas ir adekvāti, ka softs norij 140 MB?

 

 

 

programmētāju armiju, kas optimizē ātrdarbību

Nu ko jūs gandrīz visi varat slēpties aiz tās mistiskās optimizēšanas un asamblera slīpēšanas? Nu nav kur tipiskajā softā tur zinātniski slīpēt algoritmus. Tas, par ko runāju es un vēl daži, ir vienkārši nesalaist visu dēlī, aprijot milzīgus RAM un CPU resursus par neko, plus uztaisot visu ar nenormāliem latency dēļ miljons nevajadzīgām abstrakcijām un konversijām tajās.

 

 

 

Paskaties uz Paint.NET. Tas ir labais piemērs par to, ko var .NET dabūt gatavu.

Paskatos. Nolieku blakus Adobe Photoshop, kas izstrādāts C++. Pasmīnu par Paint.NET. :) Tad vēl iedomājos par Premiere, Audition, visiem CADiem, Microsoft Office un citiem softiem, kas valda pār pasauli, un vispār sāk nākt smiekli par .NET sasniegumiem.

 

 

 

Starp citu... vari nosaukt kādu piemēru, kur būtu kāds drazains (bet populārs) .NET softs?

Labāks jautājums ir vai var vispār nosaukt kādus populārus .NET softus, īpaši kvalitatīvus. Bez jau minētā Paint.NET vēl varu pievienot CDBurnerXP, kam gan arī tikai interfeiss ir VB .NET, bet apakša C vai C++. Nu, ir vēl? 10 savāksim? :D

 

Nav jau tā, ka visi programmēšanas kantoros lauž luni un taisa sūdīgu softu

Apzināti nē. Vienkārši 95% ir tik stulbi, ka pat nesajēdz, ka taisa sūdus. Tas tādēļ, ka viņiem nekad nav bijusi vēlme attīstīties un darīt lietas labāk kā jau māk.

 

Bet kāds būs rezultāts - šie profesionāļi būs pārslogoti, softs taps gadiem vai maksās tik daudz, ka neviens klients par to nemaksās.

Arī ar moderno lēto pieeju gandrīz nekad netiek ievēroti termiņi un viss top gadiem. Nē, nē - ķeksīti "gatavs" atzīmē ātri, tikai pēc tam izstrādi pabāž zem vārda "uzturēšana". Un tad nu "uzturēšanas" gaitā reāli tiek strādāts pie tā, lai pamata funkcionalitāte vispār sāktu strādāt. Tikai īstenībā to sauc par krāpšanu!

Labots - Inspektors Caps
Link to comment
Share on other sites

@@Inspektors Caps - Nu cik Tu vari piesiet cilvēku trūkumus valodas trūkumiem? Tas nav pat attāli adekvāti!

 

Programmēšanā, tāpat kā jebkurā citā industrijā, valda 80/20 likums (procenti izzīsti no zila gaisa, protams). Tas ir cilvēka dabā. 20% būs aktīvisti, evaņģēlisti, kuri tiešām cenšas, attīstās, raksta spīdošu kodu, utt. Pārējiem 80% ir pilnīgi pofig par to, kāds ir viņu kods, kamēr vien tas iziet līdz ar nagiem iziet akcepttestus. Viņus interesē tikai atsēdēt savas 8h, lai mēneša beigās var dabūt naudu kontā un aiziet uz koncertu. Jebkāda sevis pilnveidošana programmēšanas jomā notiek vai nu tad, kad priekšnieks liek iet uz kursiem/eksāmeniem, vai arī tad, ja tiešām jādomā par jaunu darbavietu, un šobrīdējās prasmes nedavelk.

 

Vai tas ir labi? Slikti? Normāli? Es nezinu. Bet tā tas ir visur, un iemesli tam meklējami psiholoģijā nevis kompilatorā.

 

Jā, šobrīdējā situācija ir tāda, ka C++ programmē lielākoties cilvēki no 20%-gala, bet C#/Java/PHP - 80%. Tāpēc arī ir tā, kā esi novērojis - daudz stipri viduvēja koda šajās valodās. Bet tā nav valodas vaina. Ja visi šie cilvēki tagad pārmestos uz C++, Tu vienkārši dabūtu tikpat daudz tikpat draņķīga C++ koda.

Labots - Vilx-
  • Patīk 1
Link to comment
Share on other sites

Guest wersa

Jebkurā valodā rakstīta programma būs ātrāka par līkroča sainstalētu OS. BTW, kādā valodā ir rakstīts kašpirovskis? Ļoti interesē. Imho, subjektīvi, flaši un līki banneri rīn vairāk kā java progas. Par to pašu bremzēšanu - uz core i3 lapša ar 8GB RAM diezgan veikli šancē Eclipse vai NetBeans, ar visu pārlūku fonā, jauku muzonu utt. Gan jau, ja softu neraksta debiliķis, arī java taisītas progas uz tāda ies normāli. Cik tur %, manuprāt vairākums HTML, CSS utml&js + php darbojas. Vismaz darbameklētāju cv šitādi dominē. :)

Labots - wersa
Link to comment
Share on other sites

Guest wersa

Vienkārši, manīts, ka tā populārakā  valoda, daudz darbameklētāju uzrāda php prasmes ( biežāk kā citas valodas).

Link to comment
Share on other sites

Ar PHP ir komplicēta un unikāla situācija.

 

Kā programmēšanas valoda tā ir diezgan draņķīga. Par to var palasīties šajā jaukajā rakstā. Viņi gan šobrīd mēģina kaut ko vērst uz labo pusi, bet, nu, nesalaužot eksistējošo kodu ir grūti kaut ko pasākt.

 

Taču tajā var ļoti vienkārši uztaisīt ļoti vienkāršas lietas. Triviālas PHP weblapiņas ir elementāri uztaisīt. Tāpat arī to ir ļoti vienkārši uzinstalēt un tas ir pieejams uz visām platformām (windows, linux, utml). Tāpēc tas patīk gan iesācējiem, gan sistēmu administratoriem.

 

Rezultātā PHP ir kļuvis ellīgi populārs. Ir iestājies sociālo tīklu apburtais loks - jo vairāk programmu sarakstīts PHP, jo lielāks pieprasījums pēc PHP programmētājiem, jo vairāk cilvēku mācās PHP (un raksta internetā par PHP), jo vairāk programmu tiek rakstīts PHP.

Link to comment
Share on other sites

nevertell

Te jau sen tika nospriests, ka labākā iesācēju valoda priekš kvalitatīvām zināšanām ir C/C++.

Ar C# var iemācīties ātri kautko radīt.

Link to comment
Share on other sites

Inspektors Caps

Vilx-, šādā skatījumā es Tev pilnībā piekrītu, tikai precizēšu - es trūkumus vairāk piesienu nevis valodām, bet managed principam, liekām abstrakcijām un bremzētiem freimworkiem. Būtībā ir taisnība tam, ka sākt var dažādi un iet dažādus ceļus. Tas, kuram tiešām interesēs, tāpat nonāks tajā galapunktā, kas viņam interesē, patīk un padodās, un kļūs par speciālistu, bet idiots-halturščiks nekļūs par labu koderi ne sākot ar C, ne C#, ne ASM, ne JavaScript. Tas ir par indivīdu. Bet tas, kam es nepiekrītu, ir tas, ka ir vienalga ar ko sākt, ja skatās plašā tautas mērogā. Tagad piemēram (skaitļi arī izzīsti no pirksta) labu koderu ir 1%, bet, ja lielākā daļa sāktu programmēt ar C, Pascal vai nesajātu C++ pieeju, tad labu koderu būtu 10%. Jā, tā tāpat ir maza daļa, bet tomēr 10reiz lielāka kā tagad. Tāda ir tā mana doma - izpratne un zināšanas stimulē uz labāku darbu, jo cilvēks JAU zin lietu un nav jāiegulda laiks apmācībā. Iesācēju ir iespējams piespiest un iebarot pareizo lietu, bet pēc tam jau strādājošam cilvēkam ar ģimeni tas ir faktiski neiespējami, jo viņš mežonīgajā kapitālismā jau vairs savu pakaļu nekustinās ne pa kam. Diemžēl neattīstīties un veģetēt uz esošā mūsdienās tiek uzskatīts par normu.

Link to comment
Share on other sites

Hehe! Taj jau jāsākar arduino. Ir C un ierobežots resurss, kas diciplinē. Trololo! :D

 

Bet ja nopietni, skaidrs ka viss ir bizness, kur galvenais ir produkts, nevis tā kvalitāte. Pa BoomFM pirmdienās ir tāds raidījums Dr. Starp Citu. Pēdējos divos raidījumos runāja par spēlu teoriju. Tur bija apsēlēta arī situācija par cenu/kvalitāti. IMHO 100% attiecināms uz modernas programmatūras izstrādi.

 

Atgriežoties pie SDR# un manis nīstā .NET Viss ir foršu Open source projektiņs. Forši un ātri uztaisāms softs un tā. Vienīgi, man .NET vienmēr asociējas ar bloatware. Katrreiz, kad atver programmu, kura taisīta ar .NET tā jāgaida kamēr ielādēsies. Protams, var pārmest ka jālieto SSD un tā, bet šoreiz stāsts ir par to, ka katra jaunāka versija paliek lēnāka par iepriekēšejo. Tieši ielādes laiks. Gluži kā JAVA uz endusera datora.

 

Rezultātā jautājums: kur ir progress? idioti raksta aplikācijas ar šaubīgu kvalitāti (bugi utml), programmatūra ir kretīniski lēna. Runtime sver simtos megabaitu. Jāpērk jaudīgāka kaste. utt utml. Skumji ka notiek regress. Tas ir apmēram tāpat kā pateikt ka cilvēki ar katru dienu paliek aizvien stulbāki un stulbāki. To var labi redzēt arī tepat forumā, teiksim no jaunbiedriem un viņu jautājumiem.

Link to comment
Share on other sites

Guest wersa

Papētot to pieprasījuma pamatmasu varbūt subjektīvi, bet man rādās tā.

Mazas firmas,  vajag php js CSS HTML fotošopu, kādu drīmvīreri, utml - meklē kas ātri un lēti taisīs ar minimālu izmaksu. Klienti ar taujājas forumos utml pēc lētākās cenas - ātrāk, lētāk.

 

Protams, uz visiem to nevar attiecināt. :) .

 

Tam C un pascal ir pieprasījums?

Par kašpirovski - kurā valodā ir rakstīts KAV un jamā komponenti? Vink ļoti interesē?



Nu kad tiek pieprasīts maksimāls temps un minimālā izmaksa, nav ko brīnīties, tas ir visās sfērās. Rezultāts attiecīgi, protams, lēnu un lēti vrb var ko labu taisīt, bet ātri un labi lēti nebūs nevienā jomā.

Link to comment
Share on other sites

@Inspektors Caps - Zini, es īsti nepiekritīšu. Mūsu flagmaņprodukts Horizon ir taisīts iekš Delphi, kas, tāpat kā C/C++, ir nemenedžēta valoda (Pascal dialekts). Un... programmētāju "sadalījums pa spējām" ir tieši tāds pats, kā visur citur. Tāpat visi kopē kodu viens no otra, taisa līkus risinājumus, cīnās ar nepārdomātām performances problēmām, utt. Cilvēki ir cilvēki - programmēšanas valodas tur neko nemaina.

 

Par menedžēto principu - IMHO tas ir klasisks "memory vs CPU tradeoff". Menedžētajā principā atmiņas paņemšana ir ātrāka un atbrīvošana ir atlikta uz nenoteiktu laiku. Rezultātā kods vidēji ir ātrāks nekā nemenedžētajās valodās, bet aizņem vairāk RAM.

 

Un tas, ka process var tikt nepareģojami iesaldēts, kamēr notiek GC - jā, bet preemptive OS (kā Windows vai Linux) tas var notikt tāpat. :)

 

Par standarta bibliotēkām un freimworkiem - grūti pateikt, nepazīstu C++ tik labi. Ja ir interese, varam pamēģināt uztaisīt kaut kādus benčmarkus (Tu uztaisi C++ softu, es C#). Lai arī bīstos, ka atšķirības tur radīsies nesaistītu lietu dēļ (tas pats GC utml).

Labots - Vilx-
Link to comment
Share on other sites

 

 

Tam C un pascal ir pieprasījums?

 

Es gribētu atgāditāt, ka nav jāmācās konkrēta programmēšanas valoda, bet gan programmēt (domāt) kopumā. Ja mācēsi programmēt (domāt), tad pofig vai C,C++ ,C#, JAVA, python, PHP utt utml.

  • Patīk 1
Link to comment
Share on other sites

Guest wersa

Tā jau ir.

 

Vienīgi jaunie parasti piedāvā tirgum php prasmi biežāk kā citu valodu iemaņas. Kā jau vilx minēja, masveidīgāk mācās viņu.

 

python kāds šeit regulāri izmanto ( resp, programmē šajā?).

Labots - wersa
Link to comment
Share on other sites

Neesmu programmētājs, tas man tik tāds epizodisks hobijs, bet šīs 'profesionāļu' diskusijas c vs. c# vs. PHP man šķiet mazliet dīvainas:
- atšķirība pēc būtības taču nav nemaz tik liela, visos gadijumos jāprot pierakstīt algoritmu.
- visu izšķir pieejamās bibliotēkas, komponenti, freimworki, ... Ja nemaldos Jumis joprojām tiek taisīts uz MS Access - tātad VB6.
- vai tad nav tā, ka programmēšanas valodas un vides izvēle atkarājas no tā, ko tu gribi dabūt gatavu. Ja taisīsi web lapas - PHP, ja Dynamics AX/SAP sistēmas X++/ABAP. Man vairāk interesē jautājums, piemēram, vai Delphi un C# ir labāks risinājums priekš mazas datu bāzes aplikāciju izveides par MS Access. Manā skatijumā pliks .NET atpaliek no MS Access, jo, piemēram, tur nav multicolumn combobox.
- c++ arī ir vairākas alternatīvas, Embarcadero c++ Builder ir kautkas pilnīgi atšķirīgs no VS c++.
- un protams, ja esmu pēc dabas mazliet dumš, tad neiemācīšos, ne VB, ne c++.
 

Link to comment
Share on other sites

Guest wersa

nebija domāts vs vs, php pieminēju, jo šā prasmes visbiežāk min darba meklētāji :) .

Jā, ir te diskusijā tādi, kas pelna ar programmēšanu. Nezinu, kā vērtēt to profesionalitāti, bet fakts, ka cilvēki strādā, tātad viņu rakstītam ir kāda vērtība :) :) .

Link to comment
Share on other sites

 

 

python kāds šeit regulāri izmanto

 

neāku jamā neko, bet nākas izmantot iekš GNU Radio Companion kā gatavus moduļus. Retos gadījumos kaut ko pašam jāpielabo vai jāpieraksta klāt.

 

Zinu vienu paziņu, kurs ikdienas lietas risina ar Python savā linux kastē. Es teiktu ka pietiekoši efektīvi risina savus uzdevumus.

Link to comment
Share on other sites

@@camel:
  • jā, tieši tā, pārsvarā izvēlētais algoritms (un datu struktūra!) ir visbūtiskākais.
  • MS Access izmanto nevis VB6, bet VBA (Visual Basic for Application) kas ir kaut kas līdzīgs, bet ne tas pats. VB6 ir miris un tā morālais pēctecis ir VB.NET.
  • Dažreiz darbs tiešā nosaka valodu, bet bieži vien ir arī alternatīvas. Tās pašas weblapas mierīgi var taisīt ne tikai uz PHP, bet arī uz C#, VB.NET, Delphi, VBScript, JScript, Javascript (Node.JS), Ruby, Python, utt. Un, jā, arī C/C++.
  • .NET no Access neatpaliek. Tas pat nav godīgs salīdzinājums - Access ir DB (patiesībā samērā tizla DB, salīdzinot ar SQL Server/Oracle/MySQL) ar iespējām skriptēt UI. .NET ir universāla programmēšanas valoda.
  • Tu aizmirsi GNU C++, kas popularitātes ziņā sacenšas ar Visual C++. C++ Builder ir reti izmantots. :)
Link to comment
Share on other sites

Liriskai atkāpei: Kāpēc VB6 ir miris? Morāli novecojis? Vairs netiek supportēts? Nu un tad? Miris vai nē, bet manus uzdevumus pilda. protams man ir specifiskas prasības. ērts un minimāls GUI, nekādas datu bāzes, maz datu, maz matemātikas, galvenais lai nekarās un viss strādā bez čakara un lieliem install. Protams, MSComCtrl un WinSock nākas lietot specifikas dēļ.

 

Protams pro developmentam VB6 nekad nav bijis nopietns rīks. Lai arī... Bosch Presideo sistēmā PC aplikācijas ir rakstītas tieši ar VB6. Izskatās quick and dirty, bet kopumā strādā.

Link to comment
Share on other sites

Tāpēc, ka vairs nevar nekur dabūt nepieciešamās lietas developmentam? Kompilators un IDE atrodas tikai vecos CD. Ja Tev ir - super. Ja nav - kod pirkstos (vai meklē tumšos interneta nostūros, apšaubāma paskata torrentos). Tas ir tas, ko es saprotu ar "miris".

Link to comment
Share on other sites

 

 

Access ir DB (patiesībā samērā tizla DB, salīdzinot ar SQL Server/Oracle/MySQL) ar iespējām skriptēt UI

 

Kurš tad ir populārāks Jumis vai Horizon?

Par MS Access:

- UI komponenti ir pārāki par pliko .NET un bieži arī par komerciālajiem Telerik utml.;

- priekš localdb DAO ir pārāks par SQL server / MYSQL, par serverDB nezinu;

- MS Access var, piemēram, viegli ģenrēt formas no koda.

 

Varbūt .NET ir universāla programmēšanas valoda, bet asm arī ir tāda.

Link to comment
Share on other sites

ērts un minimāls GUI, nekādas datu bāzes, maz datu, maz matemātikas, galvenais lai nekarās un viss strādā bez čakara un lieliem install.

Ja ierēķina to, ka .NET framework 2.0 nāk kopā ar Windows jau, emm, 7 gadus, tad .NET un Visual Studio arī atbilst šīm prasībām. ;)
Link to comment
Share on other sites

 

 

Par to pašu bremzēšanu - uz core i3 lapša ar 8GB RAM diezgan veikli šancē Eclipse vai NetBeans, ar visu pārlūku fonā, jauku muzonu utt.

NetBeans normāli šancē arī uz 5-6 gadus veca laptopa ar 4GB RAM un 1.9GHz dual cori (AMD Turion X2, TL-58). Ar mega lielu piezīmi - ar 32bit JRE. Atlika pamēģināt 64bit JRE, lai saprastu, ka java ir vēl lielāks mēsls nekā biju iedomājies - RAM uzreiz rija 2-3 reizes vairāk (wtf?), bremzēja uz katra stūra. Kā atliku atpakaļ 32bit JRE, tā atkal viss OK.

Eclipse? Nu tā kā java kodējis neesmu, tad Eclipse vien priekš PHP pamēģināts. Pieredze divējāda - ar to free PHP pluginu viss bremzēja un nekas negāja, savukārt ar Zend Studio kaut kas pat strādāja.

Nezinu, varbūt tagad ir kas mainījies. Šitā pieredze man no "senajiem laikiem", kad biju spiests kodēt PHP. Kāpēc spiests? Da tāpēc, ka pašvērtējuma dēļ biju nolēmis pāris gadus pastrādāt web dev jomā - tāds pagaidu variants, kamēr iejutīšos Rīgā un nostāšos uz savām kājām. Tie "pāris gadi" ievilkās, jo ja CV ir ieraksts "strādājis web izstrādē", tad normālos kantoros labākajā gadījumā atnāk automātiskā atbilde "piedodiet, bet…" Kopumā pagāja ~5 gadi, kamēr kāds uzaicināja uz interviju un pat pieņēma darbā, tiesa, ar nosacījumu - "tu mums te vispirms nelielu iekšējās lietošanas web sistēmiņu uztaisi, pēc tam laidīsim pie C".

Lieki piebilst, ka PHP apguvu "nejauši" pēc tam, kad dažus gadus biju kodis Delphi… Un arī pēc tam pamatvaloda bija Delphi, savukārt PHP tik tā, lai kaut ko blogveidīgu uzturētu. Bet darba devējiem par to pofig - ja CV ir pieminēts "web developeris", tad neko vairāk nemaz i nepiedāvā.

 

 

 

Tam C un pascal ir pieprasījums?

Pascal - nezinu, nav redzēts. C - principā ir, bet ne pēc tādiem darbiniekiem, kas naudu pelna ar PHP.

 

 

 

Par menedžēto principu - IMHO tas ir klasisks "memory vs CPU tradeoff". Menedžētajā principā atmiņas paņemšana ir ātrāka un atbrīvošana ir atlikta uz nenoteiktu laiku. Rezultātā kods vidēji ir ātrāks nekā nemenedžētajās valodās, bet aizņem vairāk RAM.

What?!

 

 

 

Es gribētu atgāditāt, ka nav jāmācās konkrēta programmēšanas valoda, bet gan programmēt (domāt) kopumā. Ja mācēsi programmēt (domāt), tad pofig vai C,C++ ,C#, JAVA, python, PHP utt utml.

Bullshit. Esmu redzējis PHP kodu, kuru rakstījis cilvēks, kas principā strādā ar Delphi, C++. Tāpat arī īstu(!!!) python pat lasīt(!) nemācēs cilvēks, kurš jūtas kā zivs ūdenī, kad runa ir par C/C++.

Es, protams, piekrītu, ka "jāmācās programmēšana, nevis valoda", taču valodai, tās ideoloģijai un pielietojumam ir milzīga nozīme.

 

 

 

python kāds šeit regulāri izmanto ( resp, programmē šajā?).

Jā. Nevarētu gan teikt, ka baigi pārzinu viņu, bet visādi iekšējās lietošanas tūļi viņā tiek rakstīti (un to tūļu ir dauuuudz).

 

 

 

Man vairāk interesē jautājums, piemēram, vai Delphi un C# ir labāks risinājums priekš mazas datu bāzes aplikāciju izveides par MS Access. Manā skatijumā pliks .NET atpaliek no MS Access, jo, piemēram, tur nav multicolumn combobox.

Es studiju gados pamēģināju vienu studiju darbu uzrakstīt iekš MS Access. Kā datubāze tas softs varbūt arī ir labs, bet advancētiem GUI IMHO neder. Var jau būt, ka vienkārši pieredzes tai lietā pietrūka, bet nu čakars tāds, ka sapratu, ka tādu pieredzi nemaz nevēlos :D

 

--------

 

Runājot par managed vs native, kompilatoriem vs interpretatoriem utt - ir tāds teiciens, "use the right tool for the job". Kamēr native softs nepatērē >10% CPU, tikmēr ar to pašu tasku lieliski tiks galā arī managed softs, lietotājs nekādu bremzi nejutīs.

 

Runājot par ātrdarbību un nevēlēšanos optimizēt. Te vēl viens aspekts ir koda lasāmība. Lasāms kods un ātrs kods ir pilnīgi dažādas lietas. Uzrakstīsi ātru kodu - ļoti iespējams, ka nākotnē to būs jāpārraksta. Uzrakstīsi lasāmu - tas būs lēnāks, taču vēlāk varēs pielabot, papildināt.

Optimizēt visu pēc kārtas - pilnīgi nepareizi. Ir pat tāds jēdziens "premature optimizations". Lietotājiem, kas nīd, ka jāpērk jaunu kompi, tas varētu arī nebūt saprotams.

Ko vajadzētu optimizēt? To, uz ko profileris norāda. Tikai cik daudzi tādus vispār lieto?

 

p.s. sorre, ja rakstu nesaprotamos teikumos - smaga diena bijusi… :)

Link to comment
Share on other sites

 

 

Ko vajadzētu optimizēt? To, uz ko profileris norāda. Tikai cik daudzi tādus vispār lieto?
 

Ar mazu piezīmi- ar produkcijas datiem, uz kuriem ir problēma. Savādāk programmētājs paprofilēs, pateiks, ka tur jau nav ko optimizēt, milisekundes vien ir. Ar testa (=maziem) datiem.

 

 

 

python kāds šeit regulāri izmanto ( resp, programmē šajā?).
 

Izmanto. Bieži vien, lai ātri izstrādātu algoritmu, kuru pēc tam realizētu C (redzot darbojošos kodu man kaut kādu iemeslu dēļ ir vieglāk identificēt edge-cases). Pie tam vienībtestu rakstīšana priekš python ir tik vienkārša, ka vieglāk ir uzrakstīt testu, nevis katru reizi programmu palaist, ievadīt datus un pētīt rezultātu.

Link to comment
Share on other sites

fest, produkcijas dati ne vienmēr ir pieejami ;) Arī testa dati ne vienmēr ir mazi. No jomas atkarīgs.

 

"Lai izstrādātu algoritmu, kuru pēc tam realizētu C" - citiem vārdiem sakot, prototipa izstrādei. Nav slikts pielietojums. Reizēm noder, lai saprastu, vai vispār kāda ideja strādā un vai ir vērts turpināt izstrādi tajā virzienā.

Link to comment
Share on other sites

 

 

Arī testa dati ne vienmēr ir mazi

Normālā izstrādes procesā- jā. Mazos uzņēmumos valdošajā __radošajā haosā__ testa dati bieži vien ir tas, kas paliek pāri pēc datu ievades testēšanas beigām :>

Link to comment
Share on other sites

nevertell

Es neciešu interpretātās valodas. A vot princips. Stulbie gnūisti sajāja manu gnome desktopu ar javascript'u. Interpretējamām valodām ir ļoti labi tas, ka visu var mainīt reāllaikā. Bet vai java to dod ? Vai C# to dod ? Nu ne tak, tur kompilē līdz baitkodam un tad interpretē to. Ta jau tikpatlab var rakstīt visu js.asm, kas pārkompilē visu asembler baitkodā. 

Runājot par gui, jābeidz ir vienreiz ņemties ar platform-ierobežotiem freimvorkiem un jāraksta ir gui iekš html. Kāpēc ? Jo kods top arvien portējamāks. 

Link to comment
Share on other sites

Nu ne tak, tur kompilē līdz baitkodam un tad interpretē to.

Pilnīgas muļķības. Gan Java, gan .NET jau daudzus gadus izmanto JIT dinamisko rekompilāciju. Tas ir, palaižot programmu tā no baitkodiem tiek runtaimā pārkompilēta par mašīnkodiem. Nekas nekur netiek interpretēts. Labots - Vilx-
Link to comment
Share on other sites

nevertell

Un ko tas JIT man dod ? Lielāku overhead'u. Jā, funkciju inline'ings ir kruts, bet tas tāpat ir overhead's.

Link to comment
Share on other sites

Šobrīd man gribas pielietot kādu D_L cienīgu terminoloģiju. JIT nevis dod overheadu, bet to ievērojami samazina. .NET programmas iestartējas mazliet lēnāk (jo vajag sākumā pārkompilēt no MSIL uz natīvo baitkodu), bet pēc tam tās izpildās tikpat ātri kā jebkura natīvā programma (lasi C/C++). Tas pats attiecas uz Javu. Funkciju inline'ingam ar to nav nekāda sakara. Un vispār - kā gan funkciju inline'ings ir overheads? Mazliet lielāks kods? Tev pāris KB RAM žēl?

Link to comment
Share on other sites

Vilx-, par to managed. Es tā saprotu, ka ir divas lietas - menedžēts kods (kas gan ir MS termins, bet nu pieņemsim, ka to attiecinām uz .NET un Java) un atmiņas menedžments. Šīs divas lietas ir pilnīgi dažādas. Ja neko nejaucu, tad arī C/C++ var uzrakstīt savu atmiņas menedžmentu, kurš spēs ātrāk "iedot" atmiņu, kā arī nesteigties ar tās faktisku atbrīvošanu. Priekš tam nevajag ne C#, ne Java, ne Python, nedz arī ko citu.

"Menedžētais princips" dod ērtību (kods teorētiski ir vieglāk rakstāms), drošību (dažādi ierobežojumi), iespējams - lielāku neatkarību no platformas.

Nu tas tā, mana sapratne par tām lietām. Var jau būt, ka smagi kļūdos…

 

Par to, ka JIT samazina overheadu - tas tāpēc, ka tas overheads pēc definīcijas jau ir. Tā ka nevis JIT ir labs, bet nepieciešamība pret JIT ir nosodāma.

 

Ja par funkciju inline runājam, tad inlainošana kodu nevis palielina, bet nereti pat samazina, turklāt arī kods paliek ātrāk izpildāms. IMHO.

 

Runājot par gui, jābeidz ir vienreiz ņemties ar platform-ierobežotiem freimvorkiem un jāraksta ir gui iekš html. Kāpēc ? Jo kods top arvien portējamāks.

Kods ta' portējams, bet lietojamība pilnīgi nekāda.
Link to comment
Share on other sites

Vilx-, par to managed. Es tā saprotu, ka ir divas lietas - menedžēts kods (kas gan ir MS termins, bet nu pieņemsim, ka to attiecinām uz .NET un Java) un atmiņas menedžments. Šīs divas lietas ir pilnīgi dažādas. Ja neko nejaucu, tad arī C/C++ var uzrakstīt savu atmiņas menedžmentu, kurš spēs ātrāk "iedot" atmiņu, kā arī nesteigties ar tās faktisku atbrīvošanu. Priekš tam nevajag ne C#, ne Java, ne Python, nedz arī ko citu.

Tev taisnība, es mazliet aizrāvos ar to menedžēto atmiņu. :blush:

 

Par neatkarību no platformas - tā ir Javas stiprā puse. Vienu un to pašu Javas programmu sakompilētā formā var laist visur, kur ir Javas runtaims - gan Windows, gan Linux, gan kauču uz mobilā telefona.

 

.NET ar to ir švakāk. Teorētiski varētu, bet Microsoft nav centies ar sava runtime portēšanu. Mono mēģina, un sanāk tīri OK, bet, nu, līdz tam līmenim, kāds ir paša Microsoft produktam viņiem vēl tālu. Laikam vienīgā alternatīvā arhitektūra, kur vispār .NET oficiāli ir bijis, ir Itanium procesori, kad vēl Microsoft tos supportēja.

 

Es ticu, ka tas arī varētu būt bijis galvenais iemesls, kāpēc vispār tika izvēlēta šī MSIL pieeja. Citādi uz Itanium bija salīdzinoši maz softu - nevienam negribējās ķēpāties ar šo mazpopulāro arhitektūru.

 

Lai arī uz x86 tam arī ir savas priekšrocības - piemēram, praktiski jebkura .NET programma uz x64 datora automātiski kļūst par x64 programmu - nav pat nepieciešams pārkompilēt, un programmētājiem normālos apstākļos vispār nav jādomā par mašīnas "bitīgumu".

 

Par to, ka JIT samazina overheadu - tas tāpēc, ka tas overheads pēc definīcijas jau ir. Tā ka nevis JIT ir labs, bet nepieciešamība pret JIT ir nosodāma.

Tā ir cena par portabilitāti. IMHO arī ne pārāk liela, jo tā jāmaksā tikai vienreiz, procesam piestartējoties. Plus, vismaz .NET, eksistē NGEN - ar to var MSIL .DLL pārveidot par "natīvo .NET DLL". Izmantojot tādu, JIT vispār netiek aiztikts. Tad šo cenu var samaksāt vienreiz - instalējot programmatūru. Labots - Vilx-
Link to comment
Share on other sites

Inspektors Caps
Par kašpirovski - kurā valodā ir rakstīts KAV un jamā komponenti? Vink ļoti interesē?

Nezinu, bet visdrīzāk jau C++. Tas ir labs stulbu koderu un pretīgu biznesa principu piemērs.

 

Cilvēki ir cilvēki - programmēšanas valodas tur neko nemaina.

Es arī neteicu, ka valodas izvēle automātiski nozīmē ko labu. Neuzskatu, ka viens uzņēmums, pie tam Latvijā, ir masu tendenču rādītājs. Pat visa Latvija nav.

 

Par menedžēto principu - IMHO tas ir klasisks "memory vs CPU tradeoff". Menedžētajā principā atmiņas paņemšana ir ātrāka un atbrīvošana ir atlikta uz nenoteiktu laiku. Rezultātā kods vidēji ir ātrāks nekā nemenedžētajās valodās, bet aizņem vairāk RAM.

Kā binary jau teica - WHAT? Absolūtas muļķības! Kādēļ lai managed atmiņas paņemšana caur liekajiem slāņiem būtu ātrāka? Par atbrīvošanu vispār - pat, neņemot vērā nekontrolējamību, GC ir jādarbina darbietilpīgs algoritms lai tikai noteiktu vien, ko vispār var atbrīvot. Tādēļ jau to sauc "managed" - tā menedžēšana arī ēd CPU! Un kādēļ lai kods būtu ātrāks? Managed kodā pat katrs pamata datu tipu mainīgais ir vesels objekts heap atmiņā ar pointeriem, papildus datiem un simtpadsmit liekām pārbaudēm. Par kādu vēl ātrumu Tu tur murgo?

 

palaižot programmu tā no baitkodiem tiek runtaimā pārkompilēta par mašīnkodiem

Un vēl viens lieks CPU un RAM rīma...

 

Un tas, ka process var tikt nepareģojami iesaldēts, kamēr notiek GC - jā, bet preemptive OS (kā Windows vai Linux) tas var notikt tāpat.

Tu nesaprati galveno - ja arī OS apstādina pavedienu, tas nekādi nemaina mana koda secību. Bet GC gadījumā secība nav zināma! Un vēl - pārtraukumi kernel space ir par kārtu ātrāki par native user space, kas savukārt ir par kārtu ātrāki par managed user space.

 

Ja ir interese, varam pamēģināt uztaisīt kaut kādus benčmarkus (Tu uztaisi C++ softu, es C#).

Tas būtu interesanti, bet būs grūti vienoties par produktu, jo es nu jau esmu tendēts darīt tikai tās lietas, kas tiešā veidā palīdz man šodien vai nākotnē. Esmu savulaik salīdzinājis performanci datu ielasīšanai no DB tabulas. Mans C un ODBC kods uz vienkodola Athlon XP 1700+ no Access MDB faila lasīja divreiz mazāk ierakstu sekundē kā analoģiskā konfigurācijā C# savos dataset vai hvz kur no MS SQL Server uz... 2x2 kodolu Xeon. Toreiz dižie argumentētāji pamatīgi aptaisījās!

 

Tam C un pascal ir pieprasījums?

Khm... Gandrīz visas pasaulē vadošās OS, to draiveri un visas vadošās programmas ir rakstītas C/C++. Vai ir kas vēl pieprasītāks? Vai latvietis jebkad spēs izkāpt no sava Rīgas lēto sūdu kupi-prodaj weblapeļu un IS sistēmu tirgus? T.i. atvērt acis un sākt beidzot radīt kaut ko ar jēgu un lielu pievienoto vērtību, lai nebūtu vergs! Spēs vai paliks savā mazajā kalpa pasaulītē?

 

pārsvarā izvēlētais algoritms (un datu struktūra!) ir visbūtiskākais

Ne tikai datu, bet arī pašas programmas un sistēmas kopumā.

 

Kāpēc VB6 ir miris? ... Miris vai nē, bet manus uzdevumus pilda.

Embarcadero Delphi vai C++ arī pilda, pie tam labāk. :)

 

priekš localdb DAO ir pārāks par SQL server / MYSQL, par serverDB nezinu

DAO ir piekļuves komponente, nevis datu bāze. Un ātrākā piekļuve ir ar ODBC.

 

Varbūt .NET ir universāla programmēšanas valoda, bet asm arī ir tāda.

Stulbs vai izliecies? ASM ir katram procesora tipam sava!

 

Lasāms kods un ātrs kods ir pilnīgi dažādas lietas.

Šim gan absolūti nepiekrītu. Visbiežāk tieši kārtīgais kods arī ir vismaz viens no ātrākajiem, jo nav ne lieka teksta, ne arī liekas apstrādes. Ja tā nav, tātad programmas arhitektūra ir nepareiza un būtu jāpārveido.

Labots - Inspektors Caps
Link to comment
Share on other sites

Izveido kontu, vai pieraksties esošajā, lai komentētu

Jums ir jābūt šī foruma biedram, lai varētu komentēt tēmas

Izveidot jaunu kontu

Piereģistrējies un izveido jaunu kontu, tas būs viegli!

Reģistrēt jaunu kontu

Pierakstīties

Jums jau ir konts? Pierakstieties tajā šeit!

Pierakstīties tagad!
 Share


×
×
  • Izveidot jaunu...