codez

Ko tu, tas ir AI, kurš cenšas iekļauties cilvēku sabiedrībā un meklē programmētāju, kurš viņu varētu uzlabot.

Lūk tepat Somijā no SO sludinājumu dēļa - arī remote. PHP + Go, atalgojums līdz 90k usd gadā + stoki. https://stackoverflow.com/jobs/125913/full-stack-web-developer-tophatch-inc PHP, 100% remote, 80 - 100k+ gadā. https://careers-protechitjobs.icims.com/jobs/4127/php-developer-%28100%25-remote%29/job Lūk standarta remote darbs parastam PHP senioram, kurš raksta API un strādā Scrum režīmā. Klasiska un ļoti izplatīta kombinācija ar atalgojumu virs 10'000 euro. Attiecīgajā lapā ir vēl vairāk kā 500 remote sludinājumu ar norādītām algām un liela daļa no sludinājumiem atbilst tam, lai strādātu no Latvijas. http://www.jobsite.co.uk/job/senior-php-developer---remote-957148916 60k$/gadā, PHP, Laravel, Codeigniter, 100% remote: https://app.crossover.com/x/redirect/job/2275 Es nezinu, kāpēc LV tik daudzos sludinājumus izvēlas nenorādīt atalgojumu. Laikam jau kaunas rakstīt summas, kuras 5x mazākas par tirgū pieejamajām.

Ir tik daudz labu sludinājumu ar norādītām labām algām, lai šādu spamu pat neņemtu vērā.

Ideja "teksta blāķi" pārveidot masīvā ar simboliem, lai to apstrādātu, neizskatās īpaši pievilcīga + tas FP kods ir absolūti nelasāms. Ja tu šitādu murgu uzrakstītu manis pārraudzītā projektā, tu izlidotu, acis nepamirkšķinot, ja vien tev nebūtu pietiekami ticama atruna, ka to izdarīji, lai izjokotu kādu kolēģi.

Tagad nedaudz sarežģītāks uzdevums: Izveidot funkciju ar parametru n, kura izvada masīvu ar pirmskaitļiem līdz n un strādā jēdzīgā laikā (teiksim 3 sekundēs), ja n = 1'000'000 Imperatīvais risinājums ( ar n=1'000'000, man iet 142 ms ): https://jsfiddle.net/1rh9vqee/ function f(n) { let r = [] for(let i=2; i<n; i++) { let ok = 1 for(let j=0; r[j]*r[j]<=i; j++) { if (i%r[j]==0) { ok = 0 break; } } if (ok) r.push(i) } return r }

Nestrādā ar visiem utf8 simboliem: https://jsfiddle.net/dfuLay3h/4/

Ok, tas bija viegls, bet tik un tā, nākas izveidot starp masīvu, kas funkcionālo algoritmu padara 4x lēnāku: https://jsfiddle.net/dfuLay3h/3/

Wuu, piedāvāju tev parādīt FP klasi un uzrakstīt javascriptā šo vienkāršo algoritmu funkcionālā stilā: Dota simbolu virkne, atgriezt virkni, kurā izdzēsti visi dublikāti: Piemērs. aaabccddaaa -> abcda https://jsfiddle.net/dfuLay3h/1/ function f(s) { let r = "", prev = "" for(let c of s) { if (prev != c) r += c prev = c } return r } Šis protams vēl ir salīdzinoši vienkāršs piemērs, jo vienlaicīgi ir vajadzīgs piekļūt tikai diviem elementiem.

Tu teici, ka Skala nav funkcionāla valoda (vai arī tu nepareizi lieto vārdu "pseido"). Piekrītu, ka Skala nav tīri funkcionāla, jo tajā ir arī iespējas, kas neatbilst funkcionālas programmēšanas paradigmai, bet skala nav pseido-funkcionāla, skala ir funkcionāla programmēšanas valoda, jo Skalā ir viss nepieciešamais funkcionālajai programmēšanai. Vienkārši paralēli tam Skala ir arī imperatīva un objektu orientēta programmēšanas valoda.

Vienkārši tava loģika ir kļūdaina. Tu uzskati, ka, ja grozā ieliek ābolus un bumbierus, tad grozā nav ne ābolu, ne bumbieru. Es savukārt uzskatu, ka grozā ir abi. Ja skalai ir gan funkcionālās, gan imperatīvās, gan OOP iespējas, tad tā valoda ir gan funkcionāla, gan imperatīva, gan OOP.

https://en.wikipedia.org/wiki/Functional_programming ES6 nekas nav realizēts, jo ES6 ir abstrakts standarts, nevis konkrēta implementācija. Nodē ir implementēts tail recursion, bet nevienā no top browseru js dzinējiem tas nav implementēts.

Neizrādi savu nekompetenci. Objekts nepadara valodu par tīri ne funkcionālu, bet tas, vai ir iespējams mutēt stāvokli. Scalā ir iespējams rakstīts nemutējamas klases, kuras iekļaujas tīrā funkcionālās programmēšanas paradigmā. Bet tik pat labi var rakstīt arī mutējamas klases, jo dažreiz tas ļauj uzrakstīt algoritmus daudz ātrāk un efektīvāk. Bet tā kā mūsdienu procesori pēc dabas ir imperatīvi, tad jebkura funkcionāla valoda tiek pārkompilēta imperatīvā kodā. Un jebkura griešanās pie lietotāja inputa nav funkcionāla un galu galā ar tīri funkcionālu valodu nav iespējams uzrakstīt praktisku aplikāciju. Izklausās, ka tu nezini, kas ir tail recursion. Tail recursion ir tad, kad funkcija tiek atkārtoti regulāri izsaukta un atsevišķos gadījumos iespējams uz katru funkcijas izsaukumu nebūvēt steka ierakstu, bet to visu pārveidot parastā ciklā. Tas ir, tur raksti funkcionālo, bet kompilātors pārvērš par ciklu. Un tail recursion pastāv tāpēc, ka algoritms ciklā izpildās daudz, daudz ātrāk, nekā ar N-tajiem funkciju izsaukumiem. Javascriptā nodē pavisam nesen tika ieviests tail recursion, taču ne populārākajos ES6->ES5 translatoros, ne browseros tas vēl nav.

Tu neizproti lietas būtību. Testi tevi nekādi neglābj no testēšanas. Kļūda pati neparādīsies. Palaidīsi testu, redzēsi, ka tests nav pareizs, tik un tā meklēsi kļūdu. Kamēr statiski tipētā valodā pati IDE jau norādīs, kur tieši ir tipu nesaderība. Vēl jo vairāk būs problēmas, ja paļausies, ka esi testus sarakstījis, bet esi to rakstījis tīri algoritma testēšanai, bet kļūda būs saistīta ar tipiem un izpaudīsies tikai atsevišķos gadījumos tā, ka testējot vari pat palaist garām. Pfff, pamēģini tā uzrakstīt kādu webgl programmu, kurā jāstrādā ar typed arrays. Neatbilstoša ātrdarbība garantēta. for, while, let un var nav OOP. OOP ir klases un objekti. Savukārt tieši klases un moduļu sistēma ir tas, ap ko griežas ES6. OOP un funkcionāls programmēšanas stils nav pretstati - tās ir divas lietas, kuras var izmantot vienlaicīgi. Arī ar funkcionālu rakstīšanas stilu, tev vajag domāt kā sauksi pagaidu mainīgos, piemēram: someObjects.forEach(myObject => console.log(myObject)) vs for(let myObject of someObjects) { console.log(myObject) } Bez tam ir kaudze algoritmu, kurus ir ļoti viegli uzrakstīt imperatīvā programmēšanas stilā, bet tie sanāk lieki sarežģīti un neefektīvi, ja tos raksta funkcionālā. Scalā un vismas ir tail recursion, kas ļauj daļu šādu algoritmu rakstīt funkcionāli ar rekursiju un pietiekami efektīvi, bet javascriptā nekā tāda nav.

Nu ja koda kvalitāte vai maksimāla koda ātrdarbība ir pirmajā vietā, tad ir jāizvēlas strikti tipēta valoda - piemēram, Scala. Ja svarīgs ir izstrādēs ātrums un izvēlies dinamiski tipētu valodu, tad lieto tās konstrukcijas, kuras tev ātrāk ļauj nonākt pie +- strādājoša koda. Nedomāju, ka dinamiski tipētas valodas izvēles gadījumā rakstīt: if (intval($_POST['page']) === 1) ir labāk kā: if ($_POST['page'] == 1) P.S. Tā kā pārsvarā strādāju ar aba veida valodām, konkrēti, Javascript un Scala. Tad esmu novērojis, ka javascriptā jaunu kodu rakstu ātrāk, taču tajā praktiski vienmēr ir kļūdas, kuras izķeru tikai testēšanas laikā, kamēr Scalā jauns kods rakstās nedaudz lēnāk, toties praktiski visas kļūdas tiek jau ieraudzītas IDĒ (kompilācijas laikā - IDE automātiski kompilē kodu un pārbauda tipu saderību). Tāpat pirms jauna koda rakstīšana Scalā ir nedaudz jāpatērē vairāk laika, lai strukturētu kodu, jo galu galā visiem galiem ir precīzi jāsakrīt. Savukārt vēlāk, labojot kodu un veicot uzlabojumus, Scalā to darīt ir daudz ātrāk un ar izteikti mazāku kļūdu skaitu.

Nu jā, bet sausais atlikums ir tāds, ka tavs rēķins nebūs viņa PVN attaisnotajos izdevumos un tas būtībā ir tāpat kā lielāks rēķins, kurā ir PVN. Tas, kur galu galā to PVN samaksā, ir otršķirīgi. Savukārt, ja nauda nāk no ārpus ES teritorijas, tad ir tā saucamā PVN 0 likme, respektīvi par visu summu PVN nav jāmaksā plus, ja kaut ko pērc no tās naudas, kas ir jau aplikts ar PVN, vēl no VIDa vari paprasīt atpakaļ to PVN.

Tas jā, bet tie ir bišķi virs 100 eur/mēn. un atkarībā no kopējā apgrozījuma var būt nenozīmīgi, bet tik pat labi, ja tev kaut kur ir oficiāla alga, tad šis atkrīt. Atkarīgs no situācijas: Ja tev ieņēmumi ir no ES teritorijas un visus ienākumus gribi samaksāt autoratlīdzībā, tad par visu summu būs arī PVN. Savukārt, ja ieņēmumi nāk no ārpus ES teritorijas, tad ir ļoti izdevīgi uz firmu pirkt dažādas lietas par kurām vēl papildus var dabūt PVN atmaksu un arī PVN nav jāmaksā.

Kā būtu ar SIA, kurš visus potenciālos ienākumus izmaksā fiziskai personai kā autoratlīdzību (IIN 23% ar 40% attaisnotajiem izdevumiem, kuri nav jāpamato), kopā sanāk nodokļos 13.8% no apgrozījuma vai mazāk, ja ir lietas, kuras var pirkt uz savu SIA? Vienīgais limits ir, lai tekošos 12 mēnešos nepārsniedz 50'000 eur apgrozījumu, jo tad jāreģistrējas par PVN maksātāju.

Noteikumi par nozarēm, kurās nepiemēro mikrouzņēmumu nodokļa režīmu

Lieta tāda, ka google jau kādu laiku savu meklēšanas dzinēju būvē no neironu tīkla un tas nozīmē, ka faktori, kas ietekmēs meklēšanas rezultātus, nebūs zināmi ne vien parastajiem mirstīgajiem, bet arī pašiem dzinēja izstrādātājiem, jo šie faktori glabāsies dziļi neironu tīkla struktūrā un tos neviens nebūs radījis. Kaut kādas ārējas izpausmes varēs protams empīriski novērot un notestēt no ārpuses. Bet domājams, ka galvenais neironu tīkla uzdevums būs maksimizēt peļņu, tāpēc faktori var atšķirties gan pa meklējuma tēmām, gan apmeklētāja parametriem, gan apmeklētāja uzvedības, konkrētā noskaņojuma, apmeklētāja meklējumu vēstures, citu apmeklētāju uzvedības konkrētā un līdzīgās lapās. Piemēram, neironu tīkls ļoti ātri atšķirs apmeklētājus, kuriem nepatīk ar reklāmām piebāztas lapas un kuri tādas ver ciet, no tādiem, kuriem tādas netraucē un kuri tās turpina lietot un pat spiest uz šīm reklāmām, tādā veidā meklētājs varētu piedāvāt dažādus rezultātus, balstoties uz apmeklētāja uzvedības, utmldz.

Ja man visu, kas salikts uz virtuālajiem desktopiem, vajadzētu sabāzt pa monitoriem, vajadzētu vismaz kādus 6 monitorus.

Manā gadījumā 3. parametru droši var lietot no ārpasaules.

Bet Wuu "neaizsargā" c parametru ("whatever it means") - kāds var ierakstīt f("foo","bar")

javascript: function f(s,n,b) { return s + (--n ? f(s, n, 1) + (b ? []: f(s, n)): "\n"); } usage: console.log(f("foo",3))

Mana mikroviļņu krāsns "programmēšanas valoda" spēj - sākumā es ieprogrammēju 5 minūtes un ik pēc minūtes skaitlis samazinās par 1. Tātad atņemšanu noteikti spēj. Vai tāpēc tā programmēšanas valoda?

Scalā ir tāds skaists tips kā Option[T], kurš implementē divus apakštipus Some[T] un None. Un, ja tev ir iespējamība, ka var atgriezt kādu objektu, bet var arī neatgriezt, tad raksta funkciju: def getSomeObject: Option[MyObject] = { ... } Un pēc funkcijas definīcijas ir viennozīmīgi skaidrs, ka funkcija varbūt atgriezīs objektu, bet varbūt None. Attiecīgi tālāk var veikt dekompozīciju un attiecīgi rīkoties abos gadījumos: getSomeObject match { case Some(object) => println(object) case None => println("Object not found") } Vai, ja objekta neatgriezšanas gadījumā ir kāds defaultais objekts, tad: println( getSomeObject.getOrElse(defaultObject) )