L'afer de l'Absenta

Quasi una setmana més tard (i un 1-0 en el Barça Madrid per el mig) postejo l'entrada commemorativa del que a partir d'ara serà conegut com a l'"afer de l'absenta".

El contexte és simple. Cal fer una pràctica de l'assignatura de compiladors. La pràctica, com us deveu imaginar, tracta de fer (en aquest cas, ampliar) un compilador. Així que un com tenim dit compilador fet, cal que compili un cert codi.

Aqui entren els tests. Hi ha un seguit de tests (codi que el compilador ha de compilar... o codi erroni que el compilador ha de detectar com a error!) que cal superar per tal d'aprovar la pràctica. He ha 5 tests públics i 50 de "secrets" (els té el profesor i els passa un cop hem entregat la pràctica. La qual cosa considero que és una "mala pràctica". O sigui, un "informàtic" quan programa ha d'estar acostumat a programar i tenir previstos uns tests i passar-los ABANS d'entregar el programa que ha fet, no després, però en fi) per aprovar calia superar 3 dels testos públics (o eren els 5? Radio Macuto fa molt mal).

En fi, que dijous passat ens van fer fora de la E^2 quan només passavem 2 tests ja que tancaven (9 de la nit) així que després de deliveracions fortes i disputades vàrem acavar decidint que acavaríem la pràctica aquella mateixa nit encara que...

Així que vam enfilar a l'alcampo a comprar pizzes, begudes... i al final absenta. Per què? Estupideses. Simplement volíem fer la gràcia de beure un xupito per cada test superat.

I així va ser, després de superar el Test2 (teniem el 1 i el 3 fet) vàrem omplir els mini-gots fins la meitat i... vam estar 10 minuts morint de dolor de gola. Els altres 2 testos van ser molt suferts. Cada vegada que els provàvem aguantavem la respiració desitjant un bon temps més per a poder païr l'absenta anterior i... dur dur.


P.S.: Sóc conscient que aquest post és un perill per a la meva imatge pública. No pretenc ni fomentar el consum d'alcohol (remarco que l'anecdota és això, una anecdota aïllada i que després de 5 anys de carrera és la primera vegada que faig una cosa així. Moderació, sisplau) ni dir que sóc un alcoholic (un altre cop, "una vez a l'año, no hace daño". Incideixo en que jo penso que de tant en tant tothom necessita fer alguna cosa estúpida. La clau està en que no sigui massa freqüent ni massa fort.)

Tutorial de Java I [Què és Java?]

Bé, aquest és un petit tutorial de Java. Malauradament, primer us haurieu de llegir el seguent post: Programació Orientada a Objectes.

Fet? Perfecte.


Tot és una classe.

Aquesta frase primer de tot és falsa. Però la idea inicial que s'ha de fical el programador de Java al cap és que: Tot és una classe.

Per tant, el programador de Java el que fa és definir un seguit de classes i com aquestes es comporten. És important tenir això a la ment a l'hora de programar Java, ja que si intentes fer-ho d'alguna altra manera, encara que puguis, no seràs tot l'eficient que podríes ser.

Una mica de història.

Bé, estic escrivint les coses de forma certament desordenada. Així que a partir d'ara començarem per al començament. D'on va sortir Java?

Java va aparèixer com una plataforma per fer arribar als usuaris de Internet coses que els navegadors "normals" no podíen fer. Volíen poder llençar programes a partir de pàgines Web, i per tal d'aconseguir-ho, calia dissenyar Java d'una forma molt específica.

Aquí hi ha les 5 directrius del llenguatge:

1. It should be "simple, object oriented, and familiar".
2. It should be "robust and secure".
3. It should be "architecture neutral and portable".
4. It should execute with "high performance".
5. It should be "interpreted, threaded, and dynamic".

El que traduit al català vol dir:

1. Cal que el llenguatge sigui simple, orientat a objectes i familiar. O sigui, que se sembli prou a C/C++ (El llenguatge més extés aleshores) per a què a la gent no li costi molt canviar, i sense masses complicacions per que no sigui difícil d'apendre.
2. Robust i segur. Essencialment el llenguatge ha d'aportar la màxima seguretat possible. És impossible que un compilador impedeixi al programador de fer certs errors, però el dur la gestió de memòria internament i descarregar al programador de tasques com aquesta es simplifiquen molts errors.
3. "Portable" i d'arquitectura neutre. Cal que el mateix programa pugui ser executat en diverses màquines sense cap canvi. Java ho fa mitjançant la màquina virtual de java. Els programes fets en Java es compilen per a aquesta JVM i s'executen sobre una màquina virtual, i no sobre el processador real. Això fa que puguis distribuir el teu programa per Internet sense preocupar-te de si el usuari ha de usar Windows i x86.
4. D'altes prestacions. Malgrat el llenguatge s'executi moltes vegades interpretat, cal que sigui ràpid. Per això s'usa avui dia JIT (Just-in-time compilation, el programa es compila per a la màquina on s'executa quan s'executa) o hi ha la possibilitat de programar una part en codi nadiu, perdent la portabilitat però guanyant velocitat de processament.
5. Interpretat (Alleugera temps de compilació i perment desenvolupament mès ràpid, al escurçar els temps de test), amb suport a programació de diferents fils d'execució a nivell de llenguatge i dinàmic en el sentit que es poden carregar noves classes i objectes a temps d'execució, descarregant-los des d'internet, per exemple.

Bé, ara que ja he descarregat els primers pensaments de Java, toca començar a explicar com funciona. Malauradament, ho hauré de deixar per un altre dia, que la feina (de veritat) se'm tira sobre, així que... sort!

Programació Orientada a Objectes

Què és la programació orientada a objectes?
Per què s'usa tant?
Quines són els seus avantatges i els seus inconvenients?

Bé, aquests són alguns dels interrogants, no els únics, que espero contestar avui en aquest post.

Primer de tot, i per explicar què és la programació orientada a objectes, cal explicar els 3 principis fonamentals sobre el quals està construït.

I si expliques abans què punyetes és un objecte i què és una classe, com la gen normal?

Bé, jo volia...

Tu volies, tu volies, comencem per el començament:
Un objecte és una entitat construïda per un estat intern (atributs) i unes accions que pot fer (mètodes) per a canviar-los.

Bé, jo no ho hagués definit millor.

Gràcies :-D

Ehmmmmmmm doncs... per on anava?

Els 3 super-principis de la OOP.

Gràcies, és que perdo el fil.

En fi, aquí teniu els principis fonamentals de la OOP:

• Encapsulament.
• Herència.
• Polimorfisme.
  

Estàs segur que existeix "encapsulament"?

No massa. Puc continuar?

Va, continua...

Doncs bé, la clau per a programar bé OOP és entendre aquests conceptes. Aneu amb compte, són gradualment més complexes, i cal que entengueu cada un bé abans de continuar.

Encapsulament [Abstracció]

A opinió meva, el atribut que menys importància se li dóna i, en canvi, el més important. Al ser el més senzill, hom acostuma a menysprear-lo lleugerament, també força moltes vegades que el programa sigui menys eficient, més lent, o que ocupi més. Si això és un problema, probablement hauries de pensar-te a moure't a un altre llenguatge, no a saltar-te el pilar principal del OOP. En tot cas aquí tenim:

L'abstracció es tracta simplement d'això: abstraure la implementació d'un objecte de la seva interfície.

Què vol dir això? Que no ha de fer falta MAI, PER A RES, saber com un objecte funciona internament per a poder-lo fer funcionar.

Saber com funciona un objecte ens dona, evidentment, avantatges: podem fer-lo servir millor, etc... però no ens hem de deixar temptar, abstraure correctament els objectes ens dóna moltes avantatges també, la primera de totes que deixem de dependre de com estigui fet.

I aquest és el salt que fa que la OOP funcioni tan bé. No us enganyeu, no és cap de les coses "guais" que fa (polimorfisme, sobrecarrega [que no mencionaré per què encara que pot facilitar la vida, el seu sobre ús la complica més que no ajuda, a més, no és una característica original i comuna del OOP], herència), sinó la capacitat de poder fer "d'acord, això funciona, continuem", i no estar-se sempre amb detalls.

Per a què ens entenem, a algú li fa falta saber com, exactament, funciona internament una radio per fer-la anar? El que el 99% (i pico) de la gen sap és, simplement, que quan l'engeguen i posen la freqüència que desitges sona la música que volen. I si necessitéssim saber fer anàlisi de Fourier i transformacions de Laplace per fer-les servir haurien tingut cap èxit les ràdios? Jo crec que no.

Resumint, un programador de OOP necessita, per fer servir un objecte, a quina classe pertany i què fa aquesta classe (no com ho fa).


Herència.

Una altra de les famoses característiques. Què és l'herència? Doncs el que el seu nom indica, que els fills hereten coses dels pares!

Què vol dir això?

Cada objecte pertany a una classe. Això és senzill d'entendre. Per tal de simplificar les coses, un pot definir una classe "Radio de Cotxe" i "Radio portàtil". Està clar que tant "Radio de Cotxe" com "Radio portàtil" tenen moltes coses comuns, entre elles, que són "Ràdios". Així, un hauria de repetir moltes coses de "Radio de Cotxe" a "Radio portàtil", per tal de simplificar això el que es fa és definir una classe "Radio" que és pare tant de "Radio de Cotxe" com de "Radio portàtil". Aquestes dues es comporten doncs, com "Radio" amb els seus matisos.

Això simplifica moltes vegades el codi, sobretot si se segueix la màxima de no repetir mai codi innecessàriament i tenir les coses sempre agrupades lògicament.

Polimorfisme.

El polimorfisme no és més que una petita volta al concepte d'herència.

Continuant amb l'exemple anterior, tant "Radio de Cotxe" com "Radio portàtil" són, a la vegada, "Radio"s. El polimorfisme s'aprofita d'aquest concepte i et permet usar un objecte de la classe "Radio de Cotxe" com si fos de la classe "Radio", i és que, en el fons, també ho és!

Com funciona això? Imaginem-nos que tens un programa que treballa tant amb "Radio de Cotxe" com amb "Radio portàtil". En un moment donat, necessites engegar un seguit d'aquestes ràdios. Pots crear un procediment que engegui primer totes les "Radio de Cotxe" i després les "Radio portàtil", o un que simplement agafi un seguit de "Radio" i les engegui totes, sense preguntar-se de quina mena de ràdio és exactament.

Potser les "Radio de Cotxe" són molt antigues, analògiques, mentre que les "Radio portàtil" són modernes i digitals i ambdues funcionen de formes força diferents. Malgrat tot, "engegar" és una cosa que poden fer totes les ràdios, i en totes es fa igual: prement el botó amb un triangle.


Bones pràctiques.

Hem vist, de forma genèrica, com funciona la OOP. Pròximament mirarem un cas concret, Java, però abans he de fer unes petites advertències.

Polimorfisme i herència donen eines molt potents i capaces de fer coses molt complicades. No caiguem en la temptació, cal sempre mantenir les coses el més simples possible per tal de seguir l'esperit de OOP: fer les coses senzilles. Un pot veure's temptat, per exemple, que quan un prem el botó d'engegar d'una ràdio faci una cosa diferent, que potser sembla adequada en una situació però (com el meu exemple vol demostrar) pot portar problemes de confusió, per molt bé que ho documentis.

I aquest és el problema que moltes vegades vé amb la sobrecàrrega de mètodes i operacions. Per tu pot semblar clar que quan multipliques 2 vectors et dóna la multiplicació element a element. Però algú pot interpretar que és la multiplicació vectorial, cosa que no és exactament el mateix, tot i donar un resultat similar (un altre vector).

Així que recordeu: amb un gran poder, bé una gran responsabilitat!

História vertical de la programació.

Bé, això pretén ser una introducció a la programació. Els conceptes bàsics i que ningú es molesta a explicar: d'on surten les coses que hi ha avui dia i per què són així.

Turing i Von Neumann

Al principi de tot hi ha la màquina de Turing... però això és molt molt molt enrere en el temps. Això, de fet, és de la segona guerra mundial. La màquina de Turing és una màquina "teòrica" que compleix certes característiques matemàtiques i és capaç de resoldre problemes NP-Complets donats temps i memòria ilimitats.

Parres a part, el que ens interessa és que existeix un model de màquina que resol problemes matemàtics: aquest fou l'invent i contrivució de Turing. La veritat és que el que és la màquina de Turing és una cosa complicada, per això ens la saltem i passem al que és la salsa en sí: un ordinador amb una arquitectura Von Neumann.

Vaig massa a saco? M'ho sembla a mi? Estic parlant d'história, no és realment important saber tot això per saber programar, però va bé tenir una mica de cultura general, i ara ja teniu paraules per buscar a la Wikipedia, així que us deixo el trevall per a vosaltres. El que si que explicaré és l'arquitectura de Von Neumann. Simplement perquè, malgrat avui dia s'hagi evolucionat, els ordinadors continuen funcionant igual. O al menys, comportant-se igual.

Von Neumann en sério

Un ordinador amb arquitectura Von Neumann té la següent estructura:

• Una memòria.
• Uns dispositius d'entrada/sortida (teclat, pantalla, modem, etc.......)
• Un processador.

L'element més important és el processador, que s'explica també ràpid. Té els següents elements:

• Registres (llocs on guardar dades)
• "Una" unitat de control
• "Una" ALU (unitat aritmetico-logica)

Bé. Comencem a explicar els conceptes:

• ALU. Una màquina de fer càlculs. Tu li fas entrar numeros per una banda i un codi dient-li què n'ha de fer amb aquests nombres i la ALU treu la operació feta per l'altra banda. Evidentment, només pot fer operacions senzilles: sumar, restar, multiplicar, -dividir-, comparar dos nombres (i dir quin és el més gran o si són iguals) i m'atreviria a dir que amb aixó n'hi ha prou.
• Unitat de control: el cerbell de la màquina. Aquesta és la que dirigeix la màquina i controla les coses. Com ho fa? Més senzill del que ens pot semblar. Llegeix una instrucció d'un dels registres (un especial) i la executa. Què vol dir executar una instrucció? En general, hi ha poques variants:
  • Llegir una dada de la MEMÒRIA i desar-lo en un registre
  • Llegir una dada d'un registre i guardar-lo a la MEMÒRIA
  • Agafar dades de registres i fer una operació a la ALU, guardant el resultat en un registre
  • Moure dades dels dispositius d'entrada als registres
  • Moure dades dels registres als dispositius de sortida.
  Vistes les operacions bàsiques, ja no sembla gran cosa, veritat? Simplement el que es fa és "codificar" cada instrucció amb un número i quan la Unitat de Control llegeix aquest número l'executa.
  

Fàcil, no?

Com funciona, un trasto així?

Tu li poses a la memòria un programa. Què és un programa? Doncs un programa té 2 parts principals: Dades i Instruccions. En general, posaràs a la memòria aquestes parts en 2 zones separades, per tal de no liar-la massa. Un cop has posat el programa a la memòria, li poses "play" i la màquina comença:
1 - Li dones on de la memòria comença el programa. Aquest numeret es guarda en un registre que s'anomena PC, de Program Counter, o contador del programa.
2 - La unitat de control agafarà la instrucció que hi hagi al lloc de la memòria que li digui el PC i se la posarà al seu registre.
3 - Incrementarem el PC, per tal de que "apunti" a la seguent instrucció.
4 - La unitat de control executarà la instrucció que li digui el seu registre i tornarem al pas 2.

Molt bé. Ara tenim una màquina que executa un seguit de instruccions i acaba, probablement, deixant un resultat a la pantalla (dispositiu de sortida). Falta, però un element important. Qué passa si la feina que hem de fer és una mica més complexa que seguir passos un rere l'altre? Si hem de prendre "decisions"? Necessitem un tipus d'instrucció que no hem mencionat fins ara: la instrucció de "salt".

Aquesta instrucció és també senzilla: Simplement, hem de canviar el nombre que hi ha al PC per el que nosaltres volguem per tal que la següent instrucció que la nostra màquina executi no sigui exactament la següent en la memòria, sinó la que nosaltres volguem. A més aquest salt es pot fer condicional. Vol dir, podem comprovar 2 nombres, i si un és més gran que l'altre, saltar i si no ho és, continuem com anàvem.

I per què sapigueu tot només falta explicar la pila d'execució però... no cal. És complicat i tampoc afegeix res essencial, simplement fa certes coses una mica més senzilles i no deixa de ser una mena de salt complicat.

O sigui, ens saltem aquest troç i avancem al llenguatge ensamblador.

O passem abans per el "codi binari"?

Codi Binari 101

Tothom sap que existeix aquest "codi binari", però qué és? Doncs no és res més que una altra manera de contar. M'explicaré. Nosaltres tenim 10 nombres diferents. És per això que fem servir nombres decimals. Conceptualment ho tenim molt senzill: començem amb el 0, després el 1, 2, 3 i fins al 9. Quan no en tenim més, afegim un 1 al principi i tornem a començar, quan ens tornem a quedar sense, sumem un nombre al principi i au!

El codi binari és exactament el mateix, però amb només 2 nombres: el 0 i el 1. Així els primers nombres són: 0, 1, 10, 11, 100, 101, 110, 111, 1000, 1001, 1010, 1011, 1100, 1101, 1110, 1111 que és el 15.

Matemàticament, podem veure que cada dígit incrementa exponencialment el seu valor quan més a l'esquerra és.

En decimal, 1.234 val 1 * 10^3 + 2 * 10^2 + 3 * 10^1 + 4 * 10^0 = 1000 + 200 + 30 + 4
En binari, 1101 és 1 * 2^3 + 1 * 2^2 + 0 * 2^1 + 1*2^0 = 8+4+1 = 13

Bé, ara es veu clar que el binari no és altra cosa que contar d'una altra manera. Desmitificar és important. Lletres? Assignem lletres arbitrariament a nombres i hem acabat. L'ASCII és la base de quasi tot el que es fa servir. Wikipediejeu.

I per què binari? Simple: fer operacions en binari és relativament fàcil. En el sentit de fer circuits elèctrics que sumin i restin nombres binaris. Què vol dir, sumar i restar nombres binaris? En un ordinador actual, agafar una ristra de cables, que representen 1ns i 0s estàn encesos o apagats, i fer que una altra ristra de cables s'ensenguin o apaguin en conseqüència.

Llenguatge màquina, llenguatge ensamblador.

Què tenim? Una màquina que va agafant nombres, els interpreta (hem construit la màquina de tal manera que sapiguem quin número vol dir quina operació) i fa operacions. A més aquesta màquina és capaç de llegir nombres que li donguem (cada vegada que apretem una tecla, li estem enviant un nombre, ell ja sap quina tecla és per el nombre que llegeix) i tornar-nos nombres en conseqüència del que digui el programa.

Bé, podem escriure programes directament en els nombres. És una matada que es coneix com a llenguatge màquina. Saber quin número correspon a quina instrucció és complicat i el que és pitjor, canvia amb una facilitat esferaidora de màquina a màquina. No és practic. Per què no fem una cosa? Creem un programa que llegeixi unes certes paraules i les converteixi a llenguatge màquina. No hauria de ser molt complicat; només cal que vagi llegint caràcter a caràcter (nombre a nombre, li assignem una lletra arbitràriament a cada nombre) i quan en tingui uns quants sabrà quina paraula li estem demanant, ergo, quina instrucció volem que faci, i "escrigui" aquesta instrucció a la sortida. I que aquest programa vagi repetint el procés i... ja tenim un ensamblador!

No ens enganyem, el llenguatge més bàsic de programació és el llenguatge màquina. Però com que no li tenim respecte i el llenguatge ensamblador no és més que una traducció directa d'aquest a un idioma "comprensible", l'obviarem i direm que el llenguatge ensamblador és el més bàsic.

Aquest llenguatge ensamblador té l'avantage de ser més fàcil de trevallar-hi i més fàcil de recordar les instruccions, però continua arrossegant problemes del llenguatge màquina. Entre elles, la dependència amb la màquina. Què passa? Màquines similars tenen llenguatge ensamblador similar, i no és gaire difícil passar d'un a altre, al menys, no tant com amb llenguatge màquina.

Compiladors

Per saltar-nos el problema de haver de programar cada vegada les coses per cada màquina on les volguem fer servir vàrem inventar el què s'anomena llenguatges de 3a generació [màquina = primera, ensamblador segona]. Aquests llenguatges són una mica més complexos que l'ensamblador i tenen una sintaxi força més complicada, però en el fons són tot instruccions del mateix tipus i amb poques coses bàsiques. Aquests llenguatges (el més important, el C, però no és pas el primer que va aparéixer, ni molt menys) es passen a ensamblador normalment abans de ser passats a llenguatge màquina per uns programes anomenats compiladors. Aquests compiladors són programes certament més complexos que els ensambladors, doncs no és una traducció directa i moltes vegades canvien el codi per, tot i acavar fent el mateix, ho facin millor que com originalment es feia.

I fins aquí aquesta primera part de la história de la programació. Espero haver estat entenedor i rebre algún comentari amb opinions, preguntes, etc...

Próximament les evolucions a partir de C; paradigmes de programació (funcional, orientat a objectes, scripts, etc...)

continua en História vertical de la programació II

Tantes eines, tant complicades

Bé, suposo que tothom s'ho imaginava, però jo estic fent un joc.

Cutre, basat en web, i aquestes coses, però un joc.

Per cert, és un MMOG, o sigui, un joc on-line multi jugador massiu, traduït al català, hi juguen moltes persones alhora.

El tema de la discussió és la dificultat de fer-lo com déu mana (en aquest cas, el w3c).

Explica't una mica que aquí vindran profans.

D'acord...

El w3c és el consorci que regula com han de ser els continguts web, i dóna als desenvolupadors d'un monzón d'eines per fer coses vàries i diverses:

• html: llenguatge per definir un document web.
• xml: llenguatge per definir qualsevol tipus de document d'una manera estructurada, i relativament senzilla de llegir tant per un humà com per una màquina.
  
• xhtml: adaptació de l'html al xml, fa que els documents tinguin un format més clar i senzill per a una màquina de fer certes operacions amb ells.
• xsl: llenguatge de programació declaratiu i funcional (rollo sml) definit segons la sintaxi xml, que serveix per transformar un document xml en un altre document (xml o pla)
• javascript: llenguatge d'script que serveix per donar contingut interactiu a les pàgines web
• css: full d'estil per a una pàgina web. Definir les posicions, atributs, colors, etc... de tots els elements d'una pàgina.

Com veieu el seguit de coses que hi ha no són poques. A més, poques tenen una manera decent de ser debugades (aka comprovar què fan exactament, per veure on t'has equivocat), cosa que fa extremadament difícil de programar amb elles coses elaborades (com les que jo, oh senyor de complicar-se la vida, intento fer).

I a tot això se li ha d'afegir el rei de la festa: PHP!!! Aquest famós llenguatge és, al meu entendre, el més malèfic de tots els que hè provat, ja que aconsegueix fer que el codi sigui menys escalable que programant en C (noti's que no considero llenguatge ensamblador com a llenguatge en si...), i molt menys clar quan comences a tenir alguna cosa amb cert tamany. Vaja, que aconsegueix fer ilegible qualsevol codi amb cara i ulls.


Wenu, després d'aquest tostón sobre programació...

VTES!

tu no pots fer només un tema per post? seria molt més clar!

Anda ja, si fa molta mandra escriure un post només per un tema.

No m'extranya que ningú llegeixi ni digui re del teu bloc ¬¬

Augh!

Wenu, doncs convençut per aquesta vívora

¬¬U

Ejem, consciència meva, us explicaré el que avui he fet en una mitja hora (màxim):

Una nova baralla setita voter!

Quan la juguis ja voràs si és o no una baralla ¬¬

Eh, que tampoc està tan malament

Tu sas què li has posat?

Pos moltes cartes :-P

Si, 90 ¬¬

No, 102 ^.^

Cazurro ¬¬

Res, lo típic, monzon de bixos petits (waters i tal) amb monzon de disciplines (ofu i pre ^.^), monzón de vots (hierofans), stealth, oracions, kines, reckless i amor vari i divers

I una quantitat de live in the city que sembles el Pobin ¬¬