bilžu pievienošana lietotājam

[codez]

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.

Edited September 7, 2016 by codez

[Wuu]

 

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ā

 

Sākumā testi, pēc tam kods. Un jāraksta ir funkcionālā stilā - ES6 baybe. Bez mutācijām. immutable.js neskaitās, ka tu uzreiz raksti bez mutācijām.

Tās bija manas lielākās kļūdas ar JavaScriptu. Kodam kurā nav for, while, let, var un citi OOP sūdi, ir cita atdeve. Tanī brīdī kā sāc lietot var i = 0, vai let = temp, vai ja uz brīdi aizdomājies, kā nosaukt mainīgo, tā jau ir mīnusi. Jo ja mainīgajam ir nozīme aizpildīt caurumu dizaina, tad problēma ir citur. LEAN :>

[codez]

Sākumā testi, pēc tam kods.

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.

 

 

Un jāraksta ir funkcionālā stilā - ES6 baybe. Bez mutācijām.

Pfff, pamēģini tā uzrakstīt kādu webgl programmu, kurā jāstrādā ar typed arrays. Neatbilstoša ātrdarbība garantēta.

 

Kodam kurā nav for, while, let, var un citi OOP sūdi, ir cita atdeve.

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.

 

Tanī brīdī kā sāc lietot var i = 0, vai let = temp, vai ja uz brīdi aizdomājies, kā nosaukt mainīgo, tā jau ir mīnusi. Jo ja mainīgajam ir nozīme aizpildīt caurumu dizaina, tad problēma ir citur. LEAN :>

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.

[Wuu]

Gribi teikt tavā kodā joprojām ir for, let, var un kā kās tā jauna klase? Tav piemēr par forEach neprecīzs. Objektiem nav forEach

 

Maģija sākas kad

return array.map(val => ..)
filter(val => ..)
reduce(...

[jurchiks]

Bļē, veci, tu tak neko nesaproti no OOP. Tavs kods IR OOP! array šajā gadījumā īstenībā nav pliks masīvs, bet gan objekta wrapperis ap to ar papildus metodēm [map, filter, reduce], no kurām [map, filter] vai nu maina esošo vai atgriež jaunu wrapotu masīvu.
 
PHP ekvivalents būtu:

class Arr
{
	private $data;
	
	public function __construct(array $data)
	{
		$this->data = $data;
	}
	
	public function map(callable $callback)
	{
		$this->data = array_map($callback, $this->data);
		
		return $this;
	}
	
	public function filter(callable $callback)
	{
		$this->data = array_filter($this->data, $callback, ARRAY_FILTER_USE_BOTH);
		
		return $this;
	}
	
	public function get()
	{
		return $this->data;
	}
}

Un pielietojums:
 
$result = (new Arr(['foo' => 'bar', 'bar' => 'baz']))
    ->map(function ($v) { return 'prefix_' . $v; })
    ->filter(function ($v) { return $v === 'prefix_baz'; })
    ->get();

 

Vienkārši JS masīvi jau ir wrapperi, ērtības labad.

 

Viņa piemērā someObjects ir masīvs, nevis objekts, tik daudz jau nu tev vajadzēja spēt atpazīt.

[Wuu]

Protams, jo JavaScripts ir OOP. Bet tik un tā, tu vari mierīgi beigt mutēt rezultātu un padod datus no funkcijas uz funkciju, funkcionāli. Piemēram map ir funkcija, kāda starpība kur viņa atrodas? Kaut piesaistīta pie HTML diva.

 

Ideja ir ļoti vienkārša, dati kustās no funkcijas uz funkciju un ārējie parametri funkcijas rezultātu neietekmē. Nevaru sagaidīt ka JavaScripta parādīsies daudz kodolu mapi utt..

[Леший]

Neatceros pēdējo reizi, kad šis būtu bijis keiss.

Mhm, tikai reiz nedēļā kāds WAI čatā prasa, kāpēc nulle ir vienāda ar "asdf".

[Леший]

OOP un funkcionāls programmēšanas stils nav pretstati - tās ir divas lietas, kuras var izmantot vienlaicīgi.

Ja runa ir par pseido-funkcionālo programmēšanas valodu, piemēram Scala, tad jā. Bet tīri funkcionālās valodās objekti nevar pastāvēt. Tuvākais objektiem var būt ieraksti.

 

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.

Bez problēmām var īstenot tail recursion jebkurā imperatīvā valodā, it īpaši JS. Funkcionālās valodās tail biežāk ir iebūvēts pateicoties laziness.

[Mr.Key]

Nu bļin... Varbūt vēl sāciet kaislīgi apspriest tādas "aktuālas" tēmas, kā paša taisīts FW vs. gatavs FW?

[codez]

Ja runa ir par pseido-funkcionālo programmēšanas valodu, piemēram Scala, tad jā. Bet tīri funkcionālās valodās objekti nevar pastāvēt. Tuvākais objektiem var būt ieraksti.

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.

 

Bez problēmām var īstenot tail recursion jebkurā imperatīvā valodā, it īpaši JS. Funkcionālās valodās tail biežāk ir iebūvēts pateicoties laziness.

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.

[Леший]

Neizrādi savu nekompetenci.

Objekts nepadara valodu par tīri ne funkcionālu, bet tas, vai ir iespējams mutēt stāvokli.

Nemutēšana nepadara valodu par funkcionālu, lūdzu neraksti muļķības un neizrādi savu nekompetenci šajā jautājumā.

 

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.

Nu prasīju tikko, neraksti muļķības. Es lieliski zinu, kā strādā tail recursion un kā strādā funkcijas izsaukumi CPU līmenī (call = push IP + jump) un kā var mainīt to adresi, uz kuru ret'ojas funkcija. Es tev teicu, ka nefunkcionālās valodās var izveidot tail ar ciklēšanu, un ES6 tail ir realizēts natīvi. Edited September 8, 2016 by Леший

[codez]

Nemutēšana nepadara valodu par funkcionālu, lūdzu neraksti muļķības un neizrādi savu nekompetenci šajā jautājumā.

https://en.wikipedia.org/wiki/Functional_programming

 

In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data.

 

Nu prasīju tikko, neraksti muļķības. Es lieliski zinu, kā strādā tail recursion un kā strādā funkcijas izsaukumi CPU līmenī (call = push IP + jump) un kā var mainīt to adresi, uz kuru ret'ojas funkcija. Es tev teicu, ka nefunkcionālās valodās var izveidot tail ar ciklēšanu, un ES6 tail ir realizēts natīvi.

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.

[Леший]

https://en.wikipedia.org/wiki/Functional_programming

Jā, šajā linkā ir uzrakstīts, kāpēc tikai nemutabilitāte nepadara valodu par funkcionālu.

[codez]

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.

[Леший]

Tu uzskati, ka, ja grozā ieliek ābolus un bumbierus, tad grozā nav ne ābolu, ne bumbieru.

Nē, es uzskatu, ka ja grozā ir gan āboli gan bumbieri, tad tas nav ābolu grozs, bet grozs, kurā ir arī āboli. Augstāk es rakstīju par tīri funkcionālām valodām. Tādās valodās ir konkrēts pilnvērtīgs koncepts bez liekām lietām. Scala nav no tādām valodām.