FizzBuzz CSS

Szembe jött ez : http://c2.com/cgi/wiki?FizzBuzzTest

És gondoltam miért ne csináljam meg HTML/CSS-ben. 


<html>
<head>
	<style>
		b {counter-increment:page; display:block;}
		b:after {content:counter(page);}
		b:nth-child(3n+0):after {content:'Fizz'}
		b:nth-child(5n+0):after {content:'Buzz'}
		b:nth-child(15n+0):after {content:'FizzBuzz'}
	</style>
</head>
<body>
<b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b>
<b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b>
<b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b>
<b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b>
<b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b>
<b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b>
<b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b>
<b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b>
<b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b>
<b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b><b></b>
</body>
</html>

Akinek van jobb ötlete a<b></b> kupac helyett, ne tartsa vissza :)

( rpsoft v | 2015. 06. 21., v – 10:31 )

Ugyan a linkelt oldal szépen elmagyarázza, hogy a teszt miért nehéz, de nem győzött meg teljesen. Inkább azt hinném, annak nehéz, aki valamilyen módszer szerint kódol, amibe ez nem fér bele. Vagy akkor is elhasal rajta a jelölt, ha hibátlanul írja meg, de a kód nem elég szép/nem optimális? (Mondjuk azt egyáltalán nem vitatom, hogy CSS-ben nehéz, de C-ben egész triviálisnak érzem.)

CSS-ben sem nehéz.
A teszt elég furcsa... de a tapasztalat az, hogy sokan elhasalnak rajta. Amit furcsállok. De sok ismerős mesélte, hogy a programozónak jelentkezők hmm... nem tudnak programozni. Ennek a kiszűrésére jó. Igazad lehet a szépség-optizáltság vonalon. Bár azt hiszem az utóbbi időben ezek a dolgok kicsit háttérbe szorultak a szakmában.
Példának okáért 10 sor JS-miatt JQuery-t használni szerintem erősen sub-optimális. Mégis gyakorlatilag iparági szabvány.
Ami engem érdekel, hogy vajon miért hasalnak el rajta olyan sokan.
http://blog.codinghorror.com/why-cant-programmers-program/

### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch

Viszont ez a kód-szépség nagyon szubjektív. Miután nagy pofával leírtam, hogy könnyű, írtam C-ben két változatot, hogy kipróbáljam, hogy tényleg könnyű-e. A * és a % operátor precedenciáját mondjuk elsőre elszúrtam. A két kódból az egyik a struktúrált programozás szabályainak megfelelő (if, else if, else if, else), a másik nem (3 if, benne goto),
és nekem mégis a második a szebb. Közben van egy olyan érzésem, hogy lehetne sokkal jobb kódot írni, ha kicsit gondolkodnék a maradékokok, valhogy végigmenni a számokon n1 * n2-es blokkokban (n1=3, n2=5 eredetileg), azon belül kicsit trükközve. De nem gondolkodtam rajta igazán, hogy ez gyorsabb vagy lassabb lesz.

"10 sor JS-miatt JQuery-t használni szerintem erősen sub-optimális."

Az, senki nem vitatja. Viszont amig a bongeszok nem egyeztetik az API-jukat, es csak a fejlesztoket birjak szopatni a sajat egyedi (mukodesu) API-jaikkal, addig kell valami wrapper, ami egy egyseges platformot ad IE-tol Operaig. A jQuery eleg szeleskoruen tamogatott, aktivan fejlesztett, jo keretrendszer, amire konnyu megbizhato, karbantarthato alkalmazast epiteni. A Vanilla.JS-re eleg nehez ezeket igy osszehozni.

Sajnos hiaba a sok ajanlas a JS-ben, ha barmi picit is speckot akarsz osszehozni, mar kezelned kell a fragmentalodast.
--
Blog | @hron84
Üzemeltető macik

Ez teljesen igaz. És ha az ember webes alkalmazást fejleszt akkor bizony ezt figyelembe is kell venni. Az a trend viszont, hogy pl. stackoverflow-n feltesz az ember egy JS kérdést, és JQuery-ben válaszolnak az azért már kicsit erős. Mint ha built-in lenne.
Az én problémám a wrapperekkel, hogy a csomagolás alatt elrejtenek egy csomó mindent. És így az optimalizálás rémálom.

### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch

Ha nagy a kód, akkor a JQuery-re építve fognak az emberek saját frameworkot írni. Plussz egy réteg így is úgy is. A programozó hozzáállásán múlik az egész valahol.

Részemről én igyekszem nem használni sem JS, sem PHP frameworkoket.

### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch

Az optimalizalas vs kompatibilitas kuzdelem mindig is problema volt es mindig is az lesz. Meg kell talalni a leghatekonyabb optimalizalasi lehetosegeket.

Egyebkent en kimondottan orulnek, ha egy jQuery API-val kompatibilis reteg lenne beepitve minden bongeszobe, mert akkor vegre lenne valami standard-fele, amire lehet epiteni, es vegre lennenek kicsit okosabb rendszerek, mint ami a Vanilla.JS-ben van.
--
Blog | @hron84
Üzemeltető macik

Igen, bár evvel automatán eldöntenéd az opt. vs komp. vitát, a kompatibilitás oldalán. És mivel én az optimalizálásnak vagyok nagy híve ezért mehh :D

Az okosabb rendszerek sok-sok CPU-t esznek. Mert okosak. És ezt nem igen lehet kikerülni. Én inkább okosabb programozókat szeretnék.

### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch

De valamilyen szinten mindenkeppen okos rendszereket kell irnod, ha nem akarsz abba a bad patternbe belemenni, hogy "Kedves paraszt, telepits X bongeszot, mert mi csak azt tamogatjuk. Udvozlettel, webfejlesztok". Ez nem egy atlagos PHP kod, amit megirsz egy verziohoz, oszt megmondod az uzemeltetonek, hogy ha verziot valt, letorod a kezet es a hataba szurod, a felhasznalok toled tokeletesen fuggetlenul fognak mindenfele szemettel felmenni az altalad krealt oldalra, ami csak beszeli a HTTP protokollt (meg olyasmivel is, ami nem annyira). Es legalabb a fobb rendering engine-ket illik lefedni.

Nekem az a problemam ezzel az egesszel, hogy a custom megoldasok vagy stabilak, de lassan kovetik a valtozasokat, vagy ossze vannak csapva es lassan kovetik a valtozasokat, mert nem ez a fokusz. Ellenben ott vannak a kulonbozo frameworkok, amiket projektek ezrei, userek millioi hasznalnak rendszeresen, ha abban valami kompatibilitasi nyug van, az hamarabb kiderul, mint egy random fejlesztoceg tiz user altal latogatott oldalan.

Lehet, hogy eloitelet, de nagyon sokszor lattam mar olyan kodot, ami buszken hirdette magarol, hogy o mennyire framework-mentes, aztan amikor mondtam, hogy nem megy ez vagy az a bongeszo alatt, akkor a fejlesztok nagyon gyakran valaszoltak azt, hogy hat hasznald az X bongeszot, mert ahhoz irtuk meg. Szoval, szep-szep, hogy baromi gyors az oldalad, de inkabb lenne lassabb es tamogatna a fontosabb bongeszoket.
--
Blog | @hron84
Üzemeltető macik

azert jquery-vel sem feltetlen fenekig tejfel a dolog. Lehetnek olyan jquery-re epulo js 'gyujtemenyek' (amiket hasznalsz), amelyek a jquery x verziojaval kompatibilisek, igy egy jquery upgrade-nel esznel kell lenni...

--
"what is mostly works", "mods that I describe is choosed" (hrgy84 "nem vagyok anyanyelvi angolos")

Ezek mind teljesen jogos érvek a frameworkök mellett.
Sajnos a sebesség, és erőforrás igény pedig nagyon jó érv gyakran ellenük.
Az én megoldásom ált. valamiféle lkkt böngészőfunkciók terén. De szerencsém van és nem igazán kell figyelnem régi IE-kre és hasonlókra.
Igazából nem vitatkozom senkivel aki használ frameworkot. Főleg ha valóban azért, hogy kompatibilis szép kódot írjon. Tegye. Én olyan vonalon mozgok az utóbbi időben, ahol a teljesítmény fontosabb. Ilyet kerestem, mert ezt szeretem csinálni.

Felhasználóként időröl-időre érint, hogy a webfejlesztőnek 8 magos i7 volt a gépében 32 Giga RAM társaságában Gigabites nettel. És erre optimalizált. Vagy az, hogy két fade effekt kedvéért húz le a gépem 2 mega JS-t. Vagy amikor egy 5000 byte adatot tartalmazó form elküldése elhasal egy webhosting cég oldalán Out of memory-val Mert a PHP memória limit 100 Megára volt állítva, és erre szerintük 150 kell (500 byte adattal elmegy a form (hosszú volt a levelem nekik )).

Szakértelemmel párosítva valószínűleg tök jó dolgok a frameworkök. De túl könnyű velük "működő" de szörnyű dolgokat létrehozni. Még itt a mi cégünknél is látok durva dolgokat. :(

### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch

Figyelj, ahhoz nem kellenek frameworkok, hogy eroforraszabalo szornyeket irj barmilyen nyelven, csak alulrol kell szagolni a programozashoz es elhinni, hogy profi vagy, pusztan ennyi kell hozza. Nem attol lesz valami eroforraszabalo, hogy frameworkoket hasznal vagy nem hasznal, az legfeljebb mar csak a tunete annak, hogy a programozo egy kicsit sem jo munkat vegzett. Az olyan kodokkal altalaban tobb problema is van.

Nekem volt szerencsem (errm...) olyan PHP kodhoz, ami egy darab frameworkot nem hasznalt, sot, gyakorlatilag semmilyen kulso libet, viszont a futasahoz (nem viccelek) 1GB memory limit kellett, az alatt ropkeptelen volt, a webes cronok meg 4GB-os memory limittel indultak. Tegyuk hozza, hogy egy eleg nepszeru site-rol van szo, tobbtizezer felhasznaloval.

Szoval szakertelemmel szerintem frameworkokkel es anelkul is tok jo dolgokat lehet csinalni, anelkul meg nagyon konnyen mindenbol szornyu dolgok jonnek ki.
--
Blog | @hron84
Üzemeltető macik

A frameworkök túlnyomó többsége nem oldja meg azt az alapvető problémát, ahogyan és amire a javascriptet használják. Csak adnak egy kompatibilitási réteget a böngészők egyedi implementációi fölé, meg talán egy kicsit szebb dsl-t, használnak pár elterjedt patternt (pl. promise-okat), de végső soron ugyanazt csinálják: manipulálják a DOM-ot, AJAX kéréseket indítanak, eseményeket kezelnek. Szerintem erre teljesen felesleges frameworköket használni, kompatibilitás biztosítására ott a polyfill, a többire írsz pár általános függvényt, esetleg beemelsz egy-egy kicsike libraryt (nem frameworköt). Ha ennél több kell, akkor én mindenképp olyan irányba mozdulnék el, hogy a kliens oldalt mint önálló MVC alkalmazást kezeljem, pl. angular js-sel vagy GWT-vel. Ez ugyan a kliens oldalt jobban megterheli, de egy bizonyos szint felett a fejlesztés komplexitását csökkenti, ami egy nagy alkalmazásnál fontos szempont.

Csak reszben ertek egyet. A "kicsike library-k" is lehetnek rosszul megirva, eroforraszabalo cucchoz nem kell frameworknek lenni.

A klienst MVC-kent kezelo frameworkokben viszont nem hiszek annyira. Egeszen jo cuccok ezek, de pont elegge komolyan megterhelik a bongeszoket, es szerintem a bongeszo nem jo alkalmazasplatform. Ott, ahol felmerul, hogy alkalmazast kell irni, ott irni kell egy alkalmazast, es nem bongeszovel szopni majd remenykedni, hogy a user nem fogja harom toltokepernyo utan odacsapni az egeszet.
--
Blog | @hron84
Üzemeltető macik

Viszont kis librarykkel már moduláris az alkalmazásod, könnyebb lecserélni egy rosszul megírt libraryt mint egy frameworköt.

Azal maximálisan egyetértek, hogy a böngésző nem jó alkalmazásplatform. De hagyományos oldalak is elérhetik azt a komplexitást, ahol szerintem van helye ezeknek a technológiáknak, pl. gondolj egy webshopra. Egy rakás adatot kell szépen prezentálni, formokat kitöltetni, állapotot tárolni (kosár), stb. Ha ezt mind kliens oldalon szeretnéd (márpedig miért is ne szeretnéd) megoldani, akkor egy jquery már kevés lesz.

Na a webshop tipikusan az az alkalmazas, amit nem tudok es nem is szeretnek kliensoldalon elkepzelni. Ennek csak egy resze a teljesitmeny feletti csendes aggodalmam, masik resze viszont az, hogy a keszletezes es a visszakovethetoseg miatt majd' minden allapotot a szerveren is reprezentalni kell, felesleges azt meg a kliensre is letukrozni. Nem kell mindenbol mindenaron clustert csinalni, ahol szinkronizacios retegek probaljak egybentartani a rendszert, tobbe-kevesbe sikertelenul.

A kis libraryktol meg nem lesz modularisabb az alkalmazasom, ha eleve nem modularis szemleletben fejlesztem. Attol, mert behuzok egy smallib1.js -t meg egy smallib2.js -t, attol meg lehet, hogy az en kodom egy darab 100 kb-os scriptben ul.
--
Blog | @hron84
Üzemeltető macik

Nyilván az adatok a szerveren tárolódnak, a kliens csak megjeleníti azt és tárolja a köztes állapotot. A szervernek elég arról tudnia, hogy milyen termékek vannak, mik a felhasználók adatai, melyik termékek szerepelnek egy megrendelésben. Nem kell arról tudnia, hogy milyen sorrendben és mi alapján szűrve kell a termékeket megjeleníteni, milyen invalid adatot adott meg a felhasználó, mely termékek vannak a kosárban (oké, ez utóbbi más okból érdekes lehet szerver oldalon, de ettől most nagyvonalúan tekintsünk el).

"milyen invalid adatot adott meg a felhasználó"

De, ezt nagyon is tudnia kell a szervernek. Ugyanis ha szerver oldalon nem tortenik adatvalidacio, akkor egy rosszindulatu felhasznalo siman bekuldhet olyan rendelest, ami valojaban nincs, vagy valamiert amugy nem lehetne megrendelni az oldalrol.

Es mivel nincs ertelme a validaciot ketszer megirni (DRY-elv ugyebar), azt a legegyszerubb eleve a szerveren kezelni, ahol amugy is kell ilyesmit csinalni.

--
Blog | @hron84
Üzemeltető macik

De, van értelme. Be se engeded küldeni a formot, ha az adat nem valid, a validációs hibát real time jelezheted. Ez egy kényelmi funkció a felhasználónak, ettől még a szerveren ugyanúgy kell validálni természetesen, de jóval kevesebb invalid requestre kell számítanod, ezt értettem az alatt, hogy a szervert az nem érdekli, hogy hogy a felhasználónak csak ötödjére sikerült érvényes e-mail címet megadnia.

A szervert igazabol semmise erdekli, ha otezer invalid requestet kap, az se, o boldogan visszacsapja a usert. A validacios logikat meg lehet AJAX-bol is hasznalni, es akkor a szerveroldali kod validal kliensoldalon is, mindenki happy.

Amugy meg mar egyre nagyobb divat a formbekuldeseket AJAX-bol intezni, onnantol kezdve pedig mar nagyon egyszeru implementalni azt, hogy ha a szerver boldog volt, redirect, ha nem, akkor szepen rendereljuk a hibakat a megfelelo textboxok melle.
--
Blog | @hron84
Üzemeltető macik

Mert error-prone. Ha valaki elfelejt implementalni egy uj validaciot a kliensoldalra is, es nincs rendesen lekezelve a szerveroldali validacio hibaja ("de hat ugyanazt tudja!"), abbol siman lehet eleg nagy szopas is. Persze, egy idealis vilagban ezeket az eseteket az integracios tesztek lefedik, de... sajnos nem elunk idealis vilagban.
--
Blog | @hron84
Üzemeltető macik

Tudom, én pont azt mondom, hogy kétoldali validáció szükséges - tehát (kényelmi szempontból, főleg) kliensoldalon sem érdemes elhagyni, de szerveroldalon nyilván kötelező.

Erre visszakapom érvként azt, hogy ez azért rossz, mert ha kliensoldalon elfelejtem implementálni az ellenőrzést, szerveroldalon pedig hibás, akkor nem működik. :)

a böngésző nem jó alkalmazásplatform.

-1

azert sok elonye van, ha a bongeszod az 'alkalmazasplatform'. Vegyunk egy tipikus desktop alkalmazast, pl. office. Hogyan upgrade-elteted meg a userekkel? Vegyuk az alternativajat, a google docs-ot. Ott hogyan megy egy upgrade? Hogyan megy egy A/B teszt egyik, ill. masik esetben, etc? Nem azt mondom, hogy mindent brozerbe kell vinni, de a saas termekek zome bongeszot feltetelez a kliens oldalan (meg akkor is, ha van naiv kliens is az adott platformra, pl. box). Ok valahogy kepesek kezelni a brozerek nyugjeit.

--
"what is mostly works", "mods that I describe is choosed" (hrgy84 "nem vagyok anyanyelvi angolos")

Persze, fejlesztőként ezek nyilvánvaló előnyök, a munkám során én is ilyen alkalmazást fejlesztek, ismerem az előnyöket. De felhasználóként pl. szeretném, ha én mondhatnám meg, hogy mikor frissítem az alkalmazást, vagy ha az jobban integrálódna a környezetembe. A böngészőkben futó alkalmazásokkal az a baj, hogy mindenki újra fel akarja találni a kereket, de valahogy a négyzetnél tovább senki nem jut, és a böngészők is legfeljebb egy hexagont támogatnának.

"azert sok elonye van, ha a bongeszod az 'alkalmazasplatform'."

Nem tagadom, ugyanakkor ettol nem lesz alkalmasabb a bongeszo alkalmazasplatformnak. Nekem pl. atm 8 giga RAM van a laptopomban, es ha sokat hasznalom az ilyen bongeszos "alkalmazasokat" (Google Office, GitHub, etc), egy ido utan elkezd ocsmany mennyisegu memoriat enni a bongeszo, heti egyszer-ketszer kenyszeru vagyok kiloni, mert konkretan belassul a gep tole.

Nem annyira veletlen az, hogy lecsillapodott a HTML alapu alkalmazasok iranti laz a mobilokon, egyszeruen tul sok teljesitmeny nyug volt veluk kapcsolatban, amire nem szulettek jo megoldasok, mara minden nagyobb HTML appot keszito ceg visszaallt a nativ Javas cuccok gyartasara.
--
Blog | @hron84
Üzemeltető macik

Most bantoan oszinte leszek: Chrome user vagyok. Ez nem FF-specifikus problema, meg csak nem is Chrome specifikus, egyszeruen olyan elvarasokat tamasztunk a JS enginekkel szemben, amik tulmutatnak azon a szerepkoron, amire eredetileg ki lettek talalva, aztan most megy a kapkodas, hogy hat megis legyen akkor egy teljes erteku engine a bongeszokben.
--
Blog | @hron84
Üzemeltető macik

( sj | 2015. 06. 21., v – 13:08 )

a perl se maradjon ki: 


#!/usr/bin/perl

## "Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz"."

for($i=1; $i<=100; $i++) {
   if($i % 3 == 0 && $i % 5 == 0) { print "FizzBuzz\n"; }
   elsif($i % 3 == 0) { print "Fizz\n"; }
   elsif($i % 5 == 0) { print "Buzz\n"; }
   else {
      print "$i\n";
   }
}

--
"what is mostly works", "mods that I describe is choosed" (hrgy84 "nem vagyok anyanyelvi angolos")

Egy másik verzió ugyanerre a témára: 


for($i=1; $i<=100; $i++) {
  printf "\n";
  printf "Fizz" if $i%3==0;
  printf "Buzz" if $i%5==0;
  printf "%d", $i unless ($i%3==0 || $i%5==0);
}

Ugyanez Bash-ben megfogalmazva: 


for (( i=1; i<=100 ; i++ ))
do
  echo
  [ $((i%3)) -eq 0 ] && echo -n "Fizz";
  [ $((i%5)) -eq 0 ] && echo -n "Buzz";
  [ $((i%3)) -eq 0 -o $((i%5)) -eq 0 ] || echo -n $i; 
done

Volt egy telefonom, es veletlen egy korabbi verzio volt a vagolapon, most megneztem, a gepemen a helyes kod van es helyes eredmenyt is ad vissza. A valtozo inicializalasa jon lejjeb kettovel, a for cikluson belulre.

A javitott kod: 


#!/usr/bin/env perl


for($i=1; $i<=100; $i++) {
  $noprint = 0;
  if($i % 3 == 0) {
    print "Fizz";
    $noprint = 1;
  }
  if($i % 5 == 0) {
    print "Buzz";
    $noprint = 1;
  }
  if($noprint == 0) {
    print $i;
  }
  print "\n";
}

--
Blog | @hron84
Üzemeltető macik

tan te is olvastad azt a topikot, ahol megbeszeltuk hrgy84-gyel a dolgot. Namost vagy amneziad van, es elfelejtetted (persze ez ne tartson vissza a hulyesegektol), vagy szandekosan hazudsz. Megfelelot keretik alahuzni...

--
"what is mostly works", "mods that I describe is choosed" (hrgy84 "nem vagyok anyanyelvi angolos")

Így fejből fogalmam sincs, melyik topikról van szó, mivel nem én vagyok az archive.org, de még csak a gabucino.hu sem

Ettől még akár olvashattam is, sőt az is lehet, hogy kommenteltem rá, de linkeld már be megint, kérlek. Érdekelne ugyanis, hogy mit sikerült ezen megbeszélni, lévén zavartalanul tolod a rosszindulatú lejáratókampányodat már hetek óta.

fogd fel pozitivan a dolgot: a kovetkezo eletedben biztos angoltanar leszel. Legalabbis a blogod 2 bekezdeseben sikerult annyi rossz karmat bespajzolnod, hogy ha letezik igazsag a vilagon, akkor igy kell lennie :-P

--
"what is mostly works", "mods that I describe is choosed" (hrgy84 "nem vagyok anyanyelvi angolos")

( kikuchiyo | 2015. 06. 21., v – 14:27 )

Ehh, már megint a fizzbuzz.

Ez nem azt hivatott mérni, hogy a jelentkező mennyire vagy milyen szépen tud programozni, hanem hogy tud-e programozni egyáltalán (és ez sajnos nem annyira vicces, mint amilyennek hangzik, mert a fejlesztői állásokra jelentkezők nem elhanyagolható része nem tud programozni). Úgy tűnik, hogy ez egy alapvető, képesség- vagy gondolkodásmódfüggő dolog, hogy valaki el tudja-e sajátítani a programozáshoz szükséges algoritmikus gondolkodást, vagy nem. És aki nem, annak egy ilyen fizzbuzz leküzdhetetlen nehézséget fog okozni. (A meglepő az, hogy az ilyen emberek mégis valahogy képesek diplomát szerezni egy releváns egyetemi szakon).

A másik kanonikus észrevétel a fizzbuzzal kapcsolatban az, hogy akárhányszor előkerül egy progamozói fórumon, a hozzászólók nem bírják megállni, hogy ne írják be a saját megoldásukat. Pedig hát épp az lenne a lényeg, hogy annak kéne lenni az alapértelmezésnek, hogy ezt egy programozónak meg kell tudni oldania, szóra sem lenne érdemes a téma.

Mindegy, akkor már én is:


perl -E 'say +("Fizz")[$_%3].("Buzz")[$_%5] || $_ for 1..100'

Nem hiszem, hogy sokat árt, ha megadsz egy jó megoldást. Sokkal könnyebb megérteni, mint megjegyezni.

Az, hogy diplomát tud szerezni valaki úgy, hogy nem tud kódolni, szerintem amiatt van, hogy a programozással kapcsolatos szakokon többnyire kockák oktatnak, akik úgy mentek oda, hogy kódolni már tudtak, azt akarták megtanulni, ami ezen felül van a programozásban, és arra számítanak, hogy a tanítványaik is pont ilyen kockák.

Annyival egészíteném ki, hogy a programozók inkább azon szoktak versengeni, hogy ki tud rövidebb implementációt adni. A FizzBuzz azért érdekes probléma, mert a triviális implementációban van egy rakás kódismétlés, ami mindenkinek bántja a szemét. Pl. az it linkelt tömör C implementációban is lehetne meg mit javítani.