Technologijos programavime: į ką svarbu atkreipti dėmesį programuotuojams

Dar reiktu patobulinti šia formulę. laikas = programuotojo sugebėjimai + noras dirbti. Mūsų įmonė buvo užsakiusi AutoCAD funkcionalumo praplėtimą (autoLisp). Tai programuotojai dirbo prie jų gal trys mėnesius. Bet vis tiek nesugebėjo kai kurių funkcijų tinkamai padaryti, o kitos dėl ne aiškių priežasčių kartais užlūždavo. Tai po kurio laiko man atsibodo ir pats visas funkcijas persikodinau, taip, kad jos veiktu kaip reikia. Ir tai buvo pirmas kartas kai mačiau autolisp programavimo kalbą. Nors ir dabar jos gerai nemoku. Bet sugebėjau viską išmoktį ir sukodinti greičiau nei jie. Taip, programos kodą iš pradžių padarai taip kad tik veiktu, bet prieš jį perduodant klientui jį pratestuoji ir jei reikia patobulini. Arba duodi ji savo klientui pratestuoti realiomis darbo sąlygomis. Ir tada patobulinį ir oficialiai išleidi. Nes kitaip didelės ir ilgalaikės sėkmės nelabai sulauksi. Kaip jau sakiau skaitau knyga "API design for C++" ir ten puikiai parašyta kiek kainuoja programavimas (parašiau bele kaip ir išleidau). Nebent nesiruoši nieko vėliau tobulinti.

didesnėj firmoj visa ta formulė galioja. geresni programeriai gauna daugiau, dirba geriau. Tuo pačiu kyla projekto kokybė ir kaina. Laiką labiausiai lemia žmonių kiekis projekte (turiu omeny didelį), bet 9moterys per mėnesį vaiko nepagimdo.

Tiek diskusijų dėl ekonominės formulės Programavimo srityje šia formulę interpretuoju šitaip (jos nereikai perrašyti, tiesiog tinkamai interpretuoti): laikas - projektavimo, programavimo, testavimo, taisymo, palaikymo trukmė. kaina - programavimo įrankių ir priemonių kaina, atlyginimas programuotojui, jei tokį samdome, konsultacijų kaina, jei reikia pagalbos. kokybė - realizacijos atitikimas užsakymui, programos stabilumas, palaikymo ir atnaujinimų politika. Reikia nepamiršti, kad daug faktorių yra reliatyvūs. Nebūtinai ilgiau projektuodami programą, ją sukursime kokybiškiau. Nebūtinai labiau apmokamas darbuotojas dirbs efektyviau. Tačiau abu šiuos dlaykus darydami tikrai statistiškai tikrai galėsime tikėtis kokybiškesnio produkto. Kiek akivaizdžiau dėl įrankių: nori aukščiausios klasės kompiliavimo - naudoji Intel kompiliatorius, kurių kaina yra didžiulė, tačiau jie pranoksta tiek MSVS kompiliatriaus, tiek įvairiausius GCC ir pan. Nori greito ir palengvinto (intellisense, debuger) programavimo - naudoji funkcionalias brangias programavimo aplinkas. Noriu priminti - nežiūrėkite į šia formulę labai tiesiogiai, nes ją, kaip ir daug kitų santykinių formulių, reikia interpretuoti.

Kaip matau pats ir gerai moki kabinti(apie viską tuo pačiu ir apie nieką..) Man dar iš tavęs mokytis ir mokytis.. Man tai keisti tokie karksėtojai-ironizuotojai, kad va programeriai kalti, kad jie netaiso klaidų. Užuot karksėjęs, pasiimk ir susikodink pats ir prikišk tos kokybės, kad per kraštus lietųsi, kad šviestų virš tavo galvos kokybės aureolė, tada galėsi nebelaikyti savęs kaip jūzeris=lūzeris P.S. Beje, padaryk geriau už kitus ir už tuos alternatyvius ir pasiūlyk konkurencinga kaina bei tapk milijardierium.. Kas trukdo? Ironija(verkimas, kad visi blogi) ar kreivarankiškumas?

Jeigu kalbame apie matematiką tai ir kalbėkime matematiškai. Tarkime, kad yra du dalikliai n yra mūsų tikrinamas skaičius ir n = d1 * d2. Tarkime, kad d1 > sqrt(n) ir d2 > sqrt(n), bet tuomet d1*d2 > n. Tada turime, kad arba d1 <= sqrt(n) arba d2 <= sqrt(n) nuosekliai ieškodami daliklių nuo 2 negalime rasti d1 > sqrt(n), nes d2 = n/d1 < sqrt(n) ir mes jį būtume radę anksčiau. Jeigu kalbant apie optimizacijas, tai pateiktą algoritmą galima dar šiek tiek optimizuoti Turėtų būti main funkcijoje, o ne isPrime? Na, bet čia turbūt neesmė. Jeigu kas domisi algoritmais ir nenori skaityti angliškų knygų gali perskaityti įdomią knygą lietuvių kalba: Informatikos olimpiados: algoritmai ir taikymo pavyzdžiai Autoriai: L.Petrauskas, J.Skūpienė

Che, smalsu pasidarė - ar dar kas pabandys patobulint tavo variantą ir kitas dalykas, kažin kaip ieškojo didžiausio pirminio skaičiaus, berods prieš kelis metus sumušė didžiausio pirminio skaičiaus rekordą. Ten irgi patys rašėsi programą

Tikrai geras pastebėjimas. Bet straipsnio mintis nebuvo parašyti patį efektyviausia algoritmą, bet parodyti, kad visados galima jį patobulinti. Kaip procesorių kūrėjai pastoviai tobulina procesorius taip programuotojas turi tobulinti algoritmus. Kitaip sakant programuotojas visada turi bandyti pasirinkti efektyviausia variantą sprendžiamoje problemoje. Taigi, kadangi šiame cikle pasi skaičiaus šaknis nėra įdomi, bet tik norima sumažinti ciklų skaičių, tai šaknies traukymas nėra būtinas. Bet kažkodėl pats šito nesugalvojau

Off-topic. Vien paskaitęs komentarą apie autocad, kad tu sugebėjai parašyti funkcionuojantį kodą, kurio kiti nusugebėjo padaryti per ilgą laiką iškarto supratau, kad tu tipinis programuotojas, kuriam visi kiti yra nepakankmai logiškai ir greitai mąstančios butybės. Bet šitas komentaras kaip sakant "damušė". Pasirodo kažkur yra žmogus, kuris sugebėjo pastebėti tai ką tu "kažkaip" praleidai pro akis. Negali būti, kad kažkas gali būti gudresnis už tave. Tikriausia dar ieškai, kaip čia duot atkirtį...? Todėl manau, kad su tavimi yra pakankamai sunku dirbti komandoje, kai į visus žvelgi iš aukšto ir jautiesi pats protingiausias. Žodžiu styvas jobsas tik neįvertintas:)

Iš tavo avataro taip pat matosi kuo tu save laikai. Visi kas už tave geresnį į sibira. O atsakant į tavo komentarą tai visada yra geresnių. Jei aš nemokėdamas lisp parašiau geriau veikiantį LISP algoritmą - tai kad aš geresnis už tuos kurie jį rašė yra faktas. Bet tai nereiškia, kad aš geriausias. Vieni te sugeba malkas su kirvių kapoti, o kiti dirba prie dalelių greitintuvo. Tai ar jų intelektiniai sugebėjimai lygus ar kažkurio geresnį? Jei lenktyniautum su pasaulio 100 m bėgimo čempionų - tai tavo sugebėjimai bėgti butu jam lygus ar būtum tarsi sraigė jam?

Atsižvelgiant į buvusius komentarus gauname dar efektyvesnį algoritmą.

Vietoj įmonės vadovo aš tave tikrai ištremčiau į kitą kabinetą nuo visų kitų komandos narių. Parodyk bent vieną atvejį, kad po straipsniu apie gretintuvą komentarą būtų parašęs lietuvos mokslininkas, kuriame teigtų, kad jis protingesnis už kaimo žmones, kurie malkas kapoja? Tai atrodytų kvaila ir lygiai taip pat atrodai tu. Ir išvis iš tavo sakinio galima suprasti, kad vieni su kirviu malkas kapoja, o kiti su kirviu prie dalelių greitintuvo dirba

Straipsnio autorius šaunuolis. Žilvos paminėta knyga yra labai gera „Informatikos olimpiados: algoritmai ir taikymo pavyzdžiai“ Autoriai: L.Petrauskas, J.Skūpienė Dar viena gera knyga yra „Kelionės į ŠIUOLAIKINĘ MATEMATIKĄ“, Peteris Tannenbaumas/Robertas Arnoldas. Iš angliškų man patiko „Introduction to Algorithms“, 3rd Ed. - MIT Press Nesupratai palyginimo - blogai, siūlau labiau įsigilinti ką žmogus norėjo pasakyti arba jeigu neišeina siūlau pasimokyti lietuvių kalbą. O programuotojų galimybės labai skiriasi. Yra tokių kurie uždavinį gali išspręsti per 1 h, o kiti neišsprendžia to pačio ir per mėnesį laiko. Čia Tau ne dulkes nuvalyti nuo rašomo stalo kur procesas nereikalauja intensyvaus protinio darbo ir daug žinių, kurį +/- panašiu greičiu žmonės atlieka

Programavime visada bus ką tobulinti, (kaip ir pedantai, visada ras ką pavalyti) tad svarbiausia, kad kodas būtų kuo trumpesnis, parašytum kuo greičiau, būtų saugus ir žinoma, kad nesikartotų... Kodą reikia taisyti ne tada, kai tau atrodo, kad jis negražus ar gali būti parašytas gražiau, o tada, kai puslapis blogai veikia. Tarkim vieną tinklapį atidarinėja kokias 3-5sekundes.

Čia kažkas klausė apie Big O notation, tai čia yra polinominis algoritmo sudėtingumas laiko ir vietos atžvilgiu. Matematika, nes kiekvienas algoritmas yra funkcija, kiekvienas if else statementas yra determinuotas automatas.

- Gerbiamieji kolegos, visi optimizavimai, kuriuos Jūs čia atlikote, pilnai gali būti atlikti automatinio kodo optimizatoriaus..

Negali ir negalės, nes į kompiliatorių nesukiši visų jau žinomų žmonijos žinių ir dar neatrastų žinių. Kitas dalykas visa tai apskaičiuoti kompiliatoriui yra dar sudėtingiau, nes jis turi pamatyti pattern'us (kartais juos labai sunku pamatyti, arba jie turi išimčių jeigu daug ką įtrauki). Kaip ir vienu metu vykstančių užduočių negali paskirstyti tarp procesorių automatiškai normaliai. O vienam konkrečiam parašytam atvejui visada galima „string replace“ padaryti, bet tai nėra realus optimizavimo automatizavimas, verčiau šaudymas bet kur norint pataikyti į taikinį kuris yra už 1 šviesmečio, vaizdžiai tariant. Čia kaip bandyti atmintinai mokytis vietoje to, kad suprasti kas iš tikro vyksta. Ką jau kalbėti, kad dirbtinį intelektą sunku padaryti... Iki šiol laipsnio kėlimo greituoju būdu kompiliatoriai nemoka optimizuoti, o algoritmas žinomas visiems jau seniai.

Na, nesunku patikrinti - į kompiliatorų pirmą straipsnio variantą, paskui paskutinį, paskui pasiūlytą komentatorių - o vėliau rezultatus į sceną. Tikrai būtų itin smalsu. Nereikės spėlioti Tai būtų mokslinis metodas ginčui spręsti

Daugybos operacija taipogi yra brangi. Ypač kai ji atliekama kiekvienos iteracijos metu. Be to čia nebūtinas „šaknies“ tikslumas, galima taikyti ir spartesnius, apytikslius šaknies traukimo algoritmus: http://en.wikipedia.org/wiki/Methods_of ... #Example_4

Sutinku, kad nėra sunku prie konkrečių tų pačių duomenų visus variantus ir parinkus skirtingus duomenis ir jų išsidėstymą išmėčius tada kažkiek pasimatytų algoritmų teorija. Šiaip ar taip manau paskutinis variantas veiks greičiausiai, bet būna ir anomalijų. Jeigu kalbi apie tai ką vvv2 rašė (kompiliatorius), tai jis pats sakė, kad „kol kas optimizuojantys kompiliatoriai moka šiek tiek mažiau“. O jeigu apie algoritmų teoriją tai nežinau ar kas dėl to ginčijasi labai Juolab kaip g3n1us sakė, programavime visada bus ką tobulinti (fiziniame pasaulyje tai dar pagadina, kad greičiau pirktų naują, aišku priklausomai nuo firmos ir tai kas gaminama...), tad manau reikia sutarti, kad koncentruotis reikia ties svarbiausiais dalykais, nes laiko resursai riboti. O kaip užtikrinti, kad kodas veiks greitai su tuo kuo susidurs naudotojas? O tai jau sunkiau. Tarkim jeigu užklausiami pastoviai maži skaičiai arba užklausiami pastoviai tie patys ir tų skaičių kiekis nedidelis, gal tada verta naudoti atsiminimą ir tai būtų saugoma CPU „cache“ arba registre. Tada kompiliatorius turi atkreipti dėmesį į CPU kuriam bus generuojamas kodas, kiek jame L1, L2, registruose ir pan. esančios atminties, kokie jų greičiai, šiuo atveju turi pats parašyti kodą, kad išsisaugotų arba kažkoks kitas sluoksnis (OS, DBVS ir pan.) tai darys arba daro. O realiame gyvenime dažnai būna tie patys duomenys užklausiami pastoviai. Čia jau dinaminio programavimo sritis. Iš naudotojo pusės Vytax'o pasiūlytas variantas priklauso nuo CPU, jeigu daugybą atliks per vieną CPU taktą/periodą (cycle) ir skaičiai bus maži tai tada dar klausimas. Bet algoritmiškai tai vytax būdas dar geresnis, apie šaknies skaičiavimo iškėlimą ir aš buvau pagalvojęs

Štai palietei vieną iš mokslo pavyzdžių bėdų. Būtent šis atvejis - gražiai parodo, kaip kodas optimizuojamas, bet realiai pritaikyti - užtektų paprastos lentelės su surašytais skaičiais ir paieška, o jie kas norėtų rasti patį didžiausią pirminį - šis kodas, manau, netiks. Tiesiog bukai skaičiuoti kas skaičių - kompui, aišku, nenuobodu, bet... Ten reikėtų kitokio požiūrio - reikšmių apytikslis prognozavimas (spėju) ar dėsningumo paieška, ar net teorija, kaip skaičiuojamas pats paskutinis pirminis skaičius. Taigi - šis pavyzdys yra puikus kaip pavyzdys, su kuriuo gyvenime duonos nevalgysi. Ar vadovėlių sudarytojams, mokytojams ir tokių straipsnių autoriams trūksta noro ieškoti pritaikomų pavyzdžių? Mano durna galva, tai teorija turi būti „teoriška“, abstrakti, kad išmoktum mąstyti plačiai, įžvelgtum dėsningumus ir panašiai, o pavyzdžiai turi būti pritaikomi ūkyje tiesiog dabar Jei straipsnio autorius būtų įdėjęs kokios mini programėlės kodą, tai jau turėtume optimizuotą variantą „made in technologijos“savo telefonuose (tarkim) O su vaikais ypač - pavyzdžiai, kuriuos jis gali pritaikyti pats savo kambary įtvirtina žinias galvoje kaip betonas