[SP-pm] DBIx::Class

[Eden Cardim]

Cara, isso tá muito engraçado. Atenção pessoal, só tem besteira minha a
partir daqui! É tudo por motivo de descontração.



>
>
>>     "In God we thrust: all others must bring data".
>>
>>
>> Pornografia já? Tem menores de idade, e o próprio deus, lendo ;)
>>
>
> Deus não lê e-mails: ele tem um programa do Yahoo! para fazer isto para
> ele (vide Todo Poderoso). :-)


Mas quando alguém escreve "nós enfiamos em deus" acho que o yahoo marca
como *mensagen importante*.


> Pra ser mais exato: "Se você quiser ser realmente eficiente com o banco,
>> acho que vai ter que abandonar o DBIx::Class"
>>
>
> Para este caso de upsert Eden! Só para este caso!
> Use o contexto... não estou escrevendo uma especificação.


Olha só! E eu que pulava no mar quando o capitão gritava "abandonar
navio!", quer dizer que era só pra trocar uma lâmpada? Vivendo e
aprendendo...


>
> Fato. Mas como você apontou, não precisa ser o Memcached. Pode ser
> qualquer coisa, de IPC a modperl para criar cache.


É verdade, dá até pra usar um dildo pra desentupir a privada.


> "Nojinho" do Java e similares... aquelas linguagens de programação
> corporativas, morte ao Bill Gates e todo aquele blablabla...
>

Essa maconha que você fumou... Sobrou uma ponta? Eu quero também :)


>
>
>  mas porque na minha visão elas
>> são um convite pra violação do princípio de menor conhecimento (também
>> conhecido como Law of demeter) e toda a super-engenharia que acompanha e
>> foi demonstrada nessa thread.
>>
>
> Isso é assunto para outra thread. Mas até tomar água em excesso faz mal.


E já que agua em excesso faz mal, vamos tomar ácido e assistir O Submarino
Amarelo.


>
> Geralmente "solução híbrida" é expressão sinônima de "super-engenharia".
>>
>
> Na teoria parece bonito, mas vou te dar o lado prático da moeda.
>
> Em mainframe, os programas são em sua maioria em Cobol. Diferentemente de
> plataforma baixa, programas lentos custam mais dinheiro porque os
> fabricantes cobram, periodicamente, o valor de ciclos de processadores
> utilizados.
>
> Então se o programa em Cobol, depois de otimizado, ainda é considerando
> lento, os programadores descem para o C.
>
> Se com C a coisa ainda não ficou do jeito que queriam, vão mesmo para o
> Assembly.
>

Mas assembly é ineficiente pacas! Você nunca sabe onde o compilador
desgraçado vai enfiar as constantes, então não dá pra reaproveitar os
registradores, e putz, mó saco ficar carregando registradores. :(
Aliás, micro-código é lento pra cacete, não vejo porque alguém iria
programar em assembly quando você pode projetar seu próprio CI de cadastro
e contratar 4 estagiários pra resolver mapas de karnaugh o dia todo e pagar
eles com a economia da cobrança de ciclos.


>
>
>
>> Ah, mas que mal humor... Se você aparecer no próximo ES te pago uma
>> cerveja de qualidade pra ver se melhora. ;)
>>
>>
> Vê como eu não preciso "vencer" a discussão para ganhar alguma coisa? ;-)


Mas não se esqueça que mal humor não escala. ;)
-------------- Pr?xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20130917/dd966022/attachment-0001.html>