-
Programiranje
(
http://www.devprotalk.com/forumdisplay.php?f=23)
| Dragi Tata |
07. 04. 2009. 15:37 |
Citat:
Originalno napisao nixa
(Napišite 68112)
[url]
Ovo je kao poručena tema za jablana :)
|
Posebno ovaj deo:
": I’d definitely want to hammer home what Steve said about typing. As our system has grown, a lot of the logic in our Ruby system sort of replicates a type system, either in our unit tests or as validations on models. I think it may just be a property of large systems in dynamic languages, that eventually you end up rewriting your own type system, and you sort of do it badly. You’re checking for null values all over the place. There’s lots of calls to Ruby’s kind_of? method, which asks, “Is this a kind of User object? Because that’s what we’re expecting. If we don’t get that, this is going to explode.” It is a shame to have to write all that when there is a solution that has existed in the world of programming languages for decades now." |
| jablan |
07. 04. 2009. 15:49 |
Scala je definitivno jedan od jezika koji bih želeo da isprobam u budućnosti i ovo će sigurno pomoći njegovoj popularizaciji. Bilo je malo iluzorno očekivati da će Rubi moći da skalira bek-end sistema poput Tvitera. Štono kažu, right tool for the right job... ;)
|
| nn.nn |
07. 04. 2009. 16:02 |
"Most of our recent issues have been related to database management. We have people on it." Alex Payne, on twitter ;) |
| bNasty |
07. 04. 2009. 18:50 |
|
| kaizen |
10. 04. 2009. 01:38 |
Citat:
Originalno napisao Dragi Tata
(Napišite 68133)
Posebno ovaj deo:
": I’d definitely want to hammer home what Steve said about typing. As our system has grown, a lot of the logic in our Ruby system sort of replicates a type system, either in our unit tests or as validations on models. I think it may just be a property of large systems in dynamic languages, that eventually you end up rewriting your own type system, and you sort of do it badly. You’re checking for null values all over the place. There’s lots of calls to Ruby’s kind_of? method, which asks, “Is this a kind of User object? Because that’s what we’re expecting. If we don’t get that, this is going to explode.” It is a shame to have to write all that when there is a solution that has existed in the world of programming languages for decades now."
|
:1002: Ovo nema nikakvog smisla. Pa i kad bi takav kôd portovao na neki statički jezik, opet bi imao proveru tipa.
EDIT: sad pročitah ponovo (pošto sam bio u neverici :)) i videh da je na početku rekao "either in our unit tests or as validations on models", što već donekle ima smisla, mada čini se bespotrebno jer bi drugi testovi (klijent kôda) to trebali da pokriju. |
| degojs |
10. 04. 2009. 04:49 |
Citat:
Originalno napisao kaizen
(Napišite 68232)
:1002: Ovo nema nikakvog smisla. Pa i kad bi takav kôd portovao na neki statički jezik, opet bi imao proveru tipa.
|
Zasto? Ako imas funkciju:
func( A b )
Ne moras unutar te funkcije da proveravas da li je b tipa A (tj. kind-of A). Ostaje provera za null. A kod nekih tipova ni to (int, double, itd).. |
| ivanhoe |
10. 04. 2009. 08:04 |
iskreno, mislim da su ovi iz twittera neopevani lozaci :) Prvo im nije valjao php, pa su pisali sve u rubiju, pa su ga napisali tako da je sve prslo cim je servis postao popularan (ne zbog rubija, nego sto nisu seli i razmislili o skaliranju). Pa su onda sve rewrite-ovali, menjali celu arhitekturu, pa je to neko vreme radilo. Sad opet menjaju sve zivo, i opet uzimaju neki egzoticni jezik, posto kao sad je to prava stvar, to ce im resiti sve probleme... spreman sam da se kladim da ce biti rewrite za pola godine opet... :D
ps. da ne ispadne da pljujem po Scali, nemam pojma o tom jeziku, i nemam nista protiv novih jezika naravno, nego me nervira taj "we are on the bleeding edge of technology" pristup, i svo lozenje koje ide uz to, a onda posle par meseci bude "ups, a vi ste mislili da ovo skalirate, pa trebalo je ranije da mi kazete". :D
|
| kaizen |
10. 04. 2009. 10:36 |
Citat:
Originalno napisao degojs
(Napišite 68234)
Zasto? Ako imas funkciju:
func( A b )
Ne moras unutar te funkcije da proveravas da li je b tipa A (tj. kind-of A). Ostaje provera za null. A kod nekih tipova ni to (int, double, itd)..
|
Kapiram ali opet (po meni) to nije dobar stil programiranja jer zagađuje kôd silnim proverama koje nisu ni potrebne jer zašto bi pozvao metodu sa pogrešnim tipom argumenta? To se retko dešava, a čak i ako se desi, pa šta ako "eksplodira" uhvatićeš prilikom testiranja, to nije baš neki "edge case" koji će se potkrasti. |
| srdjan |
10. 04. 2009. 11:27 |
Citat:
Originalno napisao kaizen
(Napišite 68237)
To se retko dešava, a čak i ako se desi, pa šta ako "eksplodira" uhvatićeš prilikom testiranja
|
I tako toplina oko srca obuzme svakog CLIPPER programera :seljak: |
| bNasty |
10. 04. 2009. 12:07 |
Citat:
pa šta ako "eksplodira" uhvatićeš prilikom testiranja
|
Kompajler je najbolji unit test |
| kaizen |
10. 04. 2009. 12:25 |
Citat:
Originalno napisao bNasty
(Napišite 68240)
Kompajler je najbolji unit test
|
Ih, pa dobro sad. Ja ne osporavam korisnost statičke provere tipa, ja samo mislim da je mnogo veća i za programera značajnija dobit nepostojanja istog - mnogo manje koda, čitljivost, fleksibilnost, ... |
| ivanhoe |
10. 04. 2009. 14:42 |
po meni je idealno da jezik sam ume da odradi type casting, ali da je moguce hardcodovati proveru tipa tamo gde zelis... isto tako i za deklaracije promenjivih, jezik koji bi to imao kao obavezno bi mi ustedeo bar jedno 70% bagova
|
| bluesman |
10. 04. 2009. 14:54 |
Ja mislim da je njima bilo pametnije da su napravili dobru arhitekturu, sa tim kvalitetom možeš da odradiš kako treba u skoro svakom programskom jeziku. Da li će da bude php, ruby ili neki drugi, to je onda samo stvar ličnih afiniteta. Mislim da je frka što su onui prsli zbog krš arhitekture, pa se sada izvlače kao ne valja programski jezik.
|
| caboom |
10. 04. 2009. 15:37 |
mislim da nije fer nazivati staru twitter arhitekturu "krsh" - prosto nisu mogli da predvide takvo skaliranje - sa druge strane arhitektura jeste bila problem kod twitter-a, takodje - izbor ne bih rekao da je izbor programskog jezika irelevantan, cak ni u slucaju da je jedini razlog za izbor izmedju nekoliko kandidata potpuno subjektivan - ziveces sa tim kodom mesecima, ili godinama.
drugo, micro-blogging na ovoj skali je jedan od najtezih problema koji mi pada na pamet u kontekstu danasnjeg web-a - cak dosta tezi od onoga sa cime se susrece facebook, real-time delivery i ordering nad tolikom mrezom ljudi, malo li je.
trece, skakati za svim sto se pojavi u ekstremnijim uslovima, ili ekstremniji oblik NIH-a, je normalan impuls (osim ako nije hobi) u situacijama kada sve krene da raste, stari servisi krenu da se raspadaju i "ekipa" koja ih je pisala nije prethodno bila u slicnim situacijama - gomila tog "edgy" softvera od pre 5-10 godina je sada postala mainstream, bas zahvaljujuci early adopterima, koji su - gle cuda - bili i commiter-i, ili full-time developeri, na dobrom delu tih projekata. sve je to deo zdrave evolucije i svako od nas moze da bira da li ce da se nalazi medju alfa-geek-ovima, ili udobno baca hejt iz 9-17h common paradigme (been there, done that).
cetvrto - da, twitter ekipa je napaljena, kao i ceo taj neki valley engineering, ali u njihovom slucaju - nije bas da nemaju razlog i zasto. voleo bih da vidim koliko ljudi bi izdrzalo takav pritisak - nije u pitanju "uuu brate, odvalio sam se 48h nisam spavao" (well done, braindead test passed) - nego je "mesecima me gazi product, management i mislim da nisam dovoljno dobar, a radim 80h radne nedelje i nemam pojma gde se nalazim".
peto - scala je dobar izbor sada (izuzetno ekspresivna, bar onima koji nemaju otpor prema sintaksama, ima obicno dovoljno dobre performanse i jako lepo se "lepi" na ogroman set biblioteka i okruzenja koje vec postoje), ruby je bio dobar izbor tada - pre svega u kontekstu tadasnje "baze znanja", oni su bili pokusni kunici po pitanju testiranja i skaliranja ruby-a i RoR-a u ekstremnim uslovima i, pre svega, nisu ocekivali da ce biti u toj poziciji. hats off - preziveli su.
|
| Dragi Tata |
10. 04. 2009. 15:41 |
Citat:
Originalno napisao bluesman
(Napišite 68251)
Ja mislim da je njima bilo pametnije da su napravili dobru arhitekturu, sa tim kvalitetom možeš da odradiš kako treba u skoro svakom programskom jeziku.
|
Recimo da se ne slažem baš sasvim. Da li su oni imali problem u dizajnu (ne smem da koristim reč "arhitektura" da moj ćale koji je pravi arhitekta to negde ne pročita) ili ne to ne znam, ali činjenica je da je većina programskih jezika prilagođena rešavanju određene vrste problema. Sistemski softver ćeš verovatno da pišeš u nečem kao što je C ili C++, biznis desktop aplikacije u C#u ili VBu, web front-end u PHPu, Rubiju, itd. Naravno, možeš da pišeš web aplikaciju u C-u a šel ekstenziju u PHPu (valjda, nisam siguran) ali je to malo mazohistički a i nisam siguran kakav bi rezultat ispao.
Što se Twittera tiče, oni su rešili da koriste statički jezik (Scala) za pisanje messaging sistema, a dinamički (Ruby) za front-end, što je po meni sasvim logična odluka. Bilo bi logično i da su npr koristili Javu za messaging a PHP za front-end, ali to je već stvar ukusa. Ne bi bilo logično da su uradili obrnuto: (Ruby za messaging a Scala za front-end). |
| bNasty |
10. 04. 2009. 15:56 |
Citat:
micro-blogging na ovoj skali je jedan od najtezih problema koji mi pada na pamet u kontekstu danasnjeg web-a
|
Apropo, zna li neko koje dimenzije su u pitanju kod twitter-a? Koja je frekvencija poruka?
Interesuje me radi poredjenja, trenutno radim na slichnim problemima, dodushe u drugom domenu.
Citat:
oni su rešili da koriste statički jezik (Scala) za pisanje messaging sistema
|
Hard-core je uraditi to u hardveru :) |
| caboom |
10. 04. 2009. 18:15 |
@bNasty
ako se secam dobro, ~10k u sekundi na 3 MQ (kestrel) servera u regularnim peak-ovima i oko 4-5 puta toliko tokom npr. obamine inauguracije, ako mislis na sam message queue?
|
| bluesman |
10. 04. 2009. 20:13 |
@Dragi Tata: nisam mislio bukvalno :D
A ovo sve mi liči na "blame it on...", zato sam i napisao to što sam napisao. Još od pre skoro 20 godina počeo sam da se srećem sa tim, izdavačima je kriv štampar, štamparima je uvek kriv dizajner, dizajnerima je kriv izdavač...uvek je neko drugi kriv.
|
| bNasty |
10. 04. 2009. 23:03 |
Citat:
Originalno napisao caboom
(Napišite 68259)
@bNasty
ako se secam dobro, ~10k u sekundi na 3 MQ (kestrel) servera u regularnim peak-ovima i oko 4-5 puta toliko tokom npr. obamine inauguracije, ako mislis na sam message queue?
|
Da, upravo to. Nije nekakva strashna brojka sa stanovishta samog mq-a. Ne znam zashto tvrde da im vec postojece mq implementacije nisu zadovoljavajuce, bilo bi lepo chuti konkretne detalje. |
| caboom |
10. 04. 2009. 23:34 |
mislim da su pominjali razloge u diskusiji - konkretno amq jeste prilicno trom, sa rabbitmq-om su imali probleme u disproporcionalnom broju producera vs. consumer-a (u trenucima kada krenu da se gomilaju porukice i imaju disproporciju u consumer-ima, desavalo im se da rabbitmq "pukne"), itd. - zapravo, bar sam se prilicno opekao pre 2-3 godine sa amq-om u malo ekstremnijim situacijama, ali cak na daleko manjem broju poruka u sekundi (konkretno - ~50-100 poruka u sekundi u peak-ovima, veliki broj producer-a i porukice od oko 20-40KB) - plus je bilo maltene nemoguce napraviti neki elegantniji monitoring posto bi odr. queue deadlock-ovao - ali bi ostatak queue-ova radio korektno i tako sam redom nailazio na razlicite probleme sa drugim JMS implementacijama (switfmq, mantaray, etc. etc.), tako da je pitanje sta je srecniji izbor - da li potrositi konacno vreme na tune-ovanje nekog od postojecih resenja, ili napisati nesto sto se ponasa dobro unutar okvira koji su potrebni. nemam pojma, nisam pametan - ali twitter ima veoma dobar inzenjerski tim, tako da kontam da razlozi nisu iracionalni. druga stvar je sto su mesecima bili pod izuzetnim pritiskom i sasvim sam siguran da je bar deo inzenjerskih poteza posledica toga.
|
| ivanhoe |
11. 04. 2009. 03:20 |
zar nije Twitter koristio starling za queue-ing ?
|
| degojs |
11. 04. 2009. 03:38 |
Citat:
Originalno napisao kaizen
(Napišite 68242)
Ih, pa dobro sad. Ja ne osporavam korisnost statičke provere tipa, ja samo mislim da je mnogo veća i za programera značajnija dobit nepostojanja istog - mnogo manje koda, čitljivost, fleksibilnost, ...
|
..i mnogo veća briga prebačena na programera. Vidi primer:
Kôd:
deklaracija x;
...
Dosta šugavog ili komplikovanog koda koji je pisao neko drugi :)
Možda čak i kod koji ima bag pa x prebaci u krivi tip..
...
Kog tipa je x? Ili, npr., šta ću da dobijem kao rezultat x + 2?
Kod statičkih jezika nema mnogo dileme kog tipa je x dole, a kod dinamičkih bi morao da pregledaš kod.. zar ne? |
| caboom |
11. 04. 2009. 04:19 |
Citat:
Originalno napisao ivanhoe
(Napišite 68273)
zar nije Twitter koristio starling za queue-ing ?
|
yep - kestrel je starling-in-scala, ali su takodje ispitivali i jedan deo opensource resenja. imho - zaista razumem NIH u ovom slucaju i mogu da se identifikujem sa pricama tipa "rabbitmq se ne skalira dobro ako je broj producera dovoljno velik u odnosu na broj consumera", iako deluje kao da je ponuda message queue-ova izuzetno velika i da su fantasticno robusni, ova teza se fino urushava u odredjenim slucajevima. |
| Vreme je GMT +2. Trenutno vreme je 09:55. |
|
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.
