E de Machine Learning também, promovidas pela Stanford University:
http://www.ai-class.com/
http://www.ml-class.org/
Aulas gratuitas de Inteligência Artificial
Deixe uma resposta
Arquivo da tag: Programming
HTML hates Regexp
English version below.
This probably should get HTML tags out of a string...
You can’t parse [X]HTML with regex. Because HTML can’t be parsed by regex. Regex is not a tool that can be used to correctly parse HTML. As I have answered in HTML-and-regex questions here so many times before, the use of regex will not allow you to consume HTML.
Regular expressions are a tool that is insufficiently sophisticated to understand the constructs employed by HTML. HTML is not a regular language and hence cannot be parsed by regular expressions. Regex queries are not equipped to break down HTML into its meaningful parts. so many times but it is not getting to me. Even enhanced irregular regular expressions as used by Perl are not up to the task of parsing HTML. You will never make me crack. HTML is a language of sufficient complexity that it cannot be parsed by regular expressions.
Even Jon Skeet cannot parse HTML using regular expressions. Every time you attempt to parse HTML with regular expressions, the unholy child weeps the blood of virgins, and Russian hackers pwn your webapp. Parsing HTML with regex summons tainted souls into the realm of the living. HTML and regex go together like love, marriage, and ritual infanticide. The <center> cannot hold it is too late. The force of regex and HTML together in the same conceptual space will destroy your mind like so much watery putty. If you parse HTML with regex you are giving in to Them and their blasphemous ways which doom us all to inhuman toil for the One whose Name cannot be expressed in the Basic Multilingual Plane, he comes.
Artigo completo: http://www.codinghorror.com/blog/archives/001311.html
Nunca cheguei a fazer nenhum parsing sério de HTML com expressões regulares, mas pelo visto não é uma boa idéia. A menos que você queira apenas checar algumas tags simples.
Este comentário no artigo esclarece um pouco mais:
For the brave of heart: Write a regular language to recognize all strings of balanced parens.
Actually, don’t, because this is provably impossible.
Why? Because regular expressions recognize *regular languages*, a specific, well-defined class of languages. HTML, like the balanced parens problem above, doesn’t conform to this pattern.
Every once in a while, I’m reminded of why studying bona fide computer science in college was the right idea. It won’t necessarily make you a better programmer, but it has saved me from doing really stupid things from time to time, like trying to parse html with a regex.
David R. Albrecht on November 16, 2009 10:23 AM
Realmente, regexps não podem ser usadas para nada além de checar tags simples, e nunca para um texto HTML inteiro: (http://www.perlmonks.org/?node_id=8624)
you cannot write a regexp that will match any level of nested balanced parentheses. You can always write one to match a specific number of balanced ones, but not one that can match a non- fixed number of these. I think there is an explaination in the Friedl book.
Um comentário retirado do Regular Expression HOWTO que resume bem a situação:
(Note that parsing HTML or XML with regular expressions is painful. Quick-and-dirty patterns will handle common cases, but HTML and XML have special cases that will break the obvious regular expression; by the time you’ve written a regular expression that handles all of the possible cases, the patterns will be very complicated. Use an HTML or XML parser module for such tasks.)
Portanto… não faça isto.
This probably should get HTML tags out of a string...
You can’t parse [X]HTML with regex. Because HTML can’t be parsed by regex. Regex is not a tool that can be used to correctly parse HTML. As I have answered in HTML-and-regex questions here so many times before, the use of regex will not allow you to consume HTML.
Regular expressions are a tool that is insufficiently sophisticated to understand the constructs employed by HTML. HTML is not a regular language and hence cannot be parsed by regular expressions. Regex queries are not equipped to break down HTML into its meaningful parts. so many times but it is not getting to me. Even enhanced irregular regular expressions as used by Perl are not up to the task of parsing HTML. You will never make me crack. HTML is a language of sufficient complexity that it cannot be parsed by regular expressions.
Even Jon Skeet cannot parse HTML using regular expressions. Every time you attempt to parse HTML with regular expressions, the unholy child weeps the blood of virgins, and Russian hackers pwn your webapp. Parsing HTML with regex summons tainted souls into the realm of the living. HTML and regex go together like love, marriage, and ritual infanticide. The <center> cannot hold it is too late. The force of regex and HTML together in the same conceptual space will destroy your mind like so much watery putty. If you parse HTML with regex you are giving in to Them and their blasphemous ways which doom us all to inhuman toil for the One whose Name cannot be expressed in the Basic Multilingual Plane, he comes.
Full article: http://www.codinghorror.com/blog/archives/001311.html
I never used regular expressions to do any serious HTML parsing, but thinking about it it doesn’t looks a good idea. Unless you just want to check some simple tags.
This comment in the article is interesting:
For the brave of heart: Write a regular language to recognize all strings of balanced parens.
Actually, don’t, because this is provably impossible.
Why? Because regular expressions recognize *regular languages*, a specific, well-defined class of languages. HTML, like the balanced parens problem above, doesn’t conform to this pattern.
Every once in a while, I’m reminded of why studying bona fide computer science in college was the right idea. It won’t necessarily make you a better programmer, but it has saved me from doing really stupid things from time to time, like trying to parse html with a regex.
David R. Albrecht on November 16, 2009 10:23 AM
Indeed, regexps cannot be used to anything else beyond checking simple tags, and never for a full HTML text: (http://www.perlmonks.org/?node_id=8624)
you cannot write a regexp that will match any level of nested balanced parentheses. You can always write one to match a specific number of balanced ones, but not one that can match a non- fixed number of these. I think there is an explaination in the Friedl book.
A comment taken from the Regular Expression HOWTO that sums it up well:
(Note that parsing HTML or XML with regular expressions is painful. Quick-and-dirty patterns will handle common cases, but HTML and XML have special cases that will break the obvious regular expression; by the time you’ve written a regular expression that handles all of the possible cases, the patterns will be very complicated. Use an HTML or XML parser module for such tasks.)
So… don’t do this.
Software Engineering is Dead
http://www.codinghorror.com/blog/archives/001288.html
Software development is and always will be somewhat experimental. The actual software construction isn’t necessarily experimental, but its conception is.
I can publicly acknowledge what I’ve slowly, gradually realized over the last 5 to 10 years of my career as a software developer: what we do is craftsmanship, not engineering.
control is ultimately illusory on software development projects.
MetaRogue
English version below.
Idéia para uma mistura entre os gêneros de jogo “roguelike” e ficção interativa, usando metadefinições
Conceitos
Considerações
Jogos “roguelike”, apesar de terem uma interface à primeira vista mal-feita (há versões gráficas mas elas não têm o mesmo nível de qualidade esperado dos jogos modernos), oferecem uma forma de jogo com muitas possibilidades, fator de “rejogabilidade” impressionante, e às vezes centenas de interações possíveis entre o jogador, o ambiente, as criaturas inimigas e os itens encontrados no jogo. Isso pra não mencionar a aleatoriedade: cada nova partida jogada é completamente diferente da anterior, porque partes do “mundo” serão dinamicamente geradas para aquele jogador. É por isso que este gênero de jogo continua ganhando fãs e mantendo esses fãs leais ao gênero, mesmo depois de décadas de diversão. Mesmo depois de jogar o mesmo jogo durante anos a fio, ainda é possível se descobrir novas formas de combinar itens, lidar com criaturas, interagir com o ambiente, ou apenas jogar o jogo com alguma limitação autoimposta que mude completamente seu estilo de jogo, só pela diversão de descobrir novas formas de fazer as coisas. Porém, mesmo o roguelike mais complexo terá um limite a essas possibilidades – a imaginação de seus desenvolvedores. Pode ser possível, claro, que as regras estabelecidas pelos programadores no código do jogo abram o caminho para fazer alguma coisa que não havia sido prevista por eles, mas ainda assim o jogo não irá, sozinho, criar ou inferir novas regras para o mundo do jogo.
Tela de Nethack, um jogo roguelike. Eu sou o @, o d marrom é um coiote, e o d branco é meu cachorro.
Outra característica notável dos roguelikes é a sua relação estrita com o posicionamento de seus elementos; o jogador, as criaturas e outros elementos “vivem” dentro de uma grade quadrada, e todas as relações possíveis destes elementos são diretamente conectadas à sua posição na grade. Claro, isto nada mais é que apenas mais uma regra do mundo do jogo, e que é facilmente compreendida e aplicada. E apesar de que existem algumas exceções e alternativas (geralmente em roguelikes conceito) para se mover dentro da grade, o básico se mantém. Logo um roguelike poderia ser adaptado a outras formas de interface (tela de caracteres, quadriculado de imagens, 3D, etc.), mas a grade sempre estaria lá porque é um conceito intrínseco do gênero, e o jogo precisa da grade para funcionar. Volto a este assunto mais adiante.
Jogos de Ficção Interativa são muito diferentes dos roguelikes, exceto pelo fato de que estes também se baseiam em texto, deixando de lado as capacidades gráficas dos computadores. E o fato de serem baseados em texto somente não diminui nem um pouco o valor deste gênero de jogo – alguns jogos de FI têm um enredo tão profundo ou mesmo mais profundo que um bom romance. Pra não mencionar que existem estórias de FI em uma variada gama de temas, indo desde aventuras até histórias de horror e fantasia. Resumindo, jogar uma FI é similar a ler um livro – só que você está livre para interagir à vontade com o mundo apresentado pelo livro, você não pode pular os capítulos para ver o final de antemão, e a estória não vai progredir a menos que você tome as atitudes corretas. Eu acho que estas características definem muito bem porque este gênero de jogo é tão interessante.
Anchorhead, um jogo de ficção interativa excelente de horror lovecraftiano. Recomendo.
Ainda, diferente do que acontece com os roguelikes (neste ponto eu acho que deveria me desculpar com o leitor por estar insistindo em comparar dois gêneros de jogos tão diferentes, e eu sei que eles na verdade não têm nada em comum então não tem nem jeito de pensar em compará-los, mas continue seguindo meu raciocínio), jogos de Ficção Interativa não põem o jogador dentro de uma grade; é comum que o mapa de um jogo de FI se pareça com uma grade (ou seja uma) mas isto não é necessário para que o jogo funcione; você pode andar de um lugar para outro sem se preocupar em como estes lugares estão dispostos um em relação ao outro. Vou colocar isto de forma mais clara: em alguns jogos os locais estão logicamente posicionados em relação aos outros – pense nas salas dentro de uma casa – de forma que eles funcionam com esta lógica posicional, mas novamente essa restrição não é intrínseca a este tipo de jogo; você poderia ter, digamos, três salas adjacentes em linha, e como a sala do meio não é de interesse àquele jogo em particular sendo jogado, o jogador poderia se mover diretamente da primeira sala para a terceira; a sala do meio seria ignorada ou o jogo poderia apenas dizer “você segue até a terceira sala passando pela segunda” mas essa ação seria realizada em apenas um movimento. Então a estrutura “física” (se eu posso usar esta palavra) de um jogo de FI é livre das restrições normalmente encontradas em nosso mundo. Ela não tem que seguir a forma de uma grade, uma estrutura plana, uma estrutura em 3D, ou mesmo seguir a geometria euclidiana – ela pode ser qualquer coisa que a imaginação do autor quer que ela seja.
Ainda, um jogo de FI pode ser completamente diferente de qualquer outro jogo de FI, da mesma forma que um livro pode ser completamente novo no seu próprio estilo. As regras do mundo do jogo – com relação a movimento, interação com objetos, ou qualquer outra coisa – podem ser definidas pelo autor como este assim o quiser. E o jogo ainda será reconhecível como um jogo de FI. Este grau de liberdade é esperado neste estilo de jogo, e os limites das ações e interações são definidas pelo próprio jogo, da mesma forma que este explicita as relações possíveis. Geralmente em apenas alguns minutos da estória o jogador terá noção das regras do mundo do jogo e seguirá explorando-o por si mesmo. E aqui, assim como no gênero roguelike, explorar é parte da diversão.
E, assim como eu comentei no caso dos roguelikes, jogos de FI têm a limitação inerente de deixar o jogador ir apenas aonde o autor pensou que ele poderia ir (com talvez algum grau de liberdade, indo um pouco além do que o autor tinha imaginado, mas não muito além disso). Claro, ninguém espera que o programa do jogo sozinho crie ou invente novas regras e situações.
Então, depois de considerar estes pensamentos, pode-se perguntar: ok, então jogos roguelikes e de ficção interativa são divertidos e complexos em seu próprio estilo, mas que raios um gênero tem a ver com o outro? E a resposta é – absolutamente nada, além das fracas comparações que eu fiz aqui, e por serem dois gêneros de jogo pouco conhecidos do grande público. Mas o exercício imaginativo de comparar os dois me levou à ideia que eu apresento a seguir.
Ideia
Então após toda esta introdução, a ideia, de forma resumida, é misturar características destes dois gêneros de jogo, e ao mesmo tempo adicionar à mistura a capacidade de gerar regras de interação automaticamente, baseando-se em metaregras definidas pelo autor do jogo. Como misturar os gêneros de jogo e manter o resultado “jogável” e como definir regras de interação de forma realista baseando-se em metadefinições de uma forma que funcione será o assunto de comentários (futuros) sobre este assunto. Mas vou acrescentar que eu pensei nisso enquanto estava tentando aprender a programar em Lisp, e pensei em construir algum tipo de jogo baseado em texto para aprender melhor as capacidades do Lisp.
Idea for a mix between the game genres roguelike and interactive fiction, using metadefinitions
Concepts
Considerations
Roguelike games, despite the seemingly crude interface (there are graphical versions but they do not stand up to common visual effects in modern games), offer depth of gameplay, incredible replayability, and sometimes hundreds of different possible interactions between the player, the environment, the enemy creatures and the items found in the game. Not to mention the randomness: every new game played is completely different from the previous one, because parts of the “world” will be dinamically generated for that player. That’s why they continue to gather fans and keep those fans loyal to this game genre, even after decades of enjoyment. Even after playing the same game for years it can still be possible for one to discover a new way to combine items, deal with creatures, interact with the environment, or even just play the game with some self-imposing limitation that changes entirely one’s gameplay style, just for the fun of discovering new ways of doing things. However, even the most intricate of roguelikes will have a limit to these possibilities – the imagination of its developers. It may be possible, sure, that the rules devised by the developers in the game code open way to doing something else that wasn’t in the developers minds, but still the game won’t itself create or infere new rules for the game world.
Screen of Nethack, a roguelike game. I'm the @, the brown d is a coyote, the white d is my dog.
Another notable trait of roguelikes are their strict relation with the positioning of its elements; the player, the creatures and other elements “live” inside a square grid, and all their possible relations are directly connected with their position in this grid. Of course, this serves well just as another rule for the game world, one that is easily grasped and dealt with. And although there are some exceptions and alternative ways (mostly in some concept roguelikes) to move inside a grid world, the basics are the same. So a roguelike could be adapted to other kinds of interfaces (character based, tile based, 3D, etc.), but the grid would always be there because it’s an intrinsic concept of the genre, and the game needs the grid to work. More on these thoughts later.
Interactive fiction games are very different of roguelikes, unless for the fact that they also rely heavily in text, ignoring computers’ graphics capabilities. And the fact of relying only in text doesn’t detract from this game genre not even a bit – some IF games have a plot as deep or even deeper than a good novel. Not to mention that there are IF stories in a whole variety of themes, ranging from adventures to horror to fantasy. In short, playing an IF game is very much like reading a book – only that you’re free to really interact with the world presented by that book, you can’t just skip chapters to see the end beforehand, and the story wouldn’t advance unless you take the right steps. I believe these traits define well why this game genre is so interesting.
Anchorhead, an excellent interactive fiction game of lovecraftian horror. I recommend.
Also, differently from roguelike games (at this point I think I should beg the reader’s pardon for insistently comparing two such different game genres, and I know they actually have nothing in common so there’s no way to even think about comparing them, but please keep with me), Interactive Fiction games doesn’t put the player inside a grid; it is common that the map of an IF game places resemble a grid (or is actually one) but this isn’t needed for the game to work; you can walk from place to place without actually worrying about how these locations are disposed one in relation with another. Let me clarify this: in some games the locations are logically positioned in relation to the others – think the rooms inside a house – so they work with that positional logic, but again that restriction isn’t intrinsic for this kind of game; you could have, say, three adjacent rooms in line, and just because the middle room is of no interest to the particular game being played, the player could move directly from the first room to the third one; the middle room would be ignored or the game could just say “you go to the third room passing through the second one” but that action would be done in just one movement. So the “physical” (if I can use this word) structure of an IF game is free of usual constraints found in our world. It hasn’t to resemble a grid, a plain structure, a 3D structure, or even conform with euclidian geometry – it may just be anything the author’s imagination wants it to be.
Also, an IF game can be completery different of any other IF game, just like a book can be completely new in its own style. The rules of the game world – concerning movement, object interaction, or anything else – may be defined by the author as he pleases. And still it will be recognizable as an IF game. This degree of freedom is expected in this game style, and the limits of actions and interactions are defined by the game itself, as well as it explicites the possible interactions. Usually with just some minutes of story the player will be aware of the game world rules and go on exploring it by himself. And here, like the roguelike genre, exploring is part of the fun.
And, just like I pointed in the roguelikes case, IF games have the inherent limitation of just letting the player go where the author thought it could go (with maybe some little degree of freedom, going a little further than the author had imagined, but not much beyond that). Of course, we won’t expect the game program to create or invent itself new rules and situations.
So, after considering these thoughts, one may ask: ok, so roguelikes and interactive fiction games are interesting and fun and complex in their own ways, but what the heck have one genre to do with the other? And the answer is – absolutely nothing, apart from the loose comparisons I did here, and for being two non mainstream game genres. But the imagination exercise of comparing the two lead me to the idea I present next.
Idea
So after all this introduction, the idea, in short, is to mix together characteristics of these two game genres, and at the same time throw in the mix the capability of generating interaction rules automatically, based on metarules defined by the game author. How to mix the game genres and keeping the result playable and how to realistically define interaction rules based on metadefinitions in a way that works is the subject of the (future) comments on the subject. But I will add that I was thinking of this while trying to learn how to code in Lisp, and thought of building some kind of text game to learn better Lisp’s capabilities.
Rogue'm Up
English version below.
Uns dois anos atrás, comprei numa promoção o livro Linux Application Development, e até hoje não consegui acabar de lê-lo. Acontece sempre isso com todo livro técnico que compro. Nunca consigo ler pelo menos um parágrafo de uma só sentada, sempre perco o interesse e vou fazer outra coisa.
Resolvi então mudar de estratégia: vou lendo os capítulos fora de ordem, procurando por temas que me interessem no momento. Vi então que o livro tem um capítulo sobre uso da lib S-lang, que serve para abstrair o acesso ao terminal (console). Tradicionalmente se usa a biblioteca ncurses, mas a S-Lang parece ser mais moderna.
Enfim, não só finalmente li um pouco mais do livro, como comecei a brincar com as funções da S-Lang e fiz um pequeno jogo, um shooter lateral, com o mesmo. Como a nave é representada pelo caracter @ e os inimigos são, digamos, familiares para quem já jogou um certo jogo em modo caractere, resolvi chamar este de Rogue’m Up – mistura de Roguelike com Shoot’em Up.
Ou seja, é um shooter para se jogar em modo caractere. Não espere nada muito bem feito, afinal foi só o resultado de uma tarde brincando com as funções da lib S-Lang. Movimente-se com as teclas wasd ou hjklyubn (todas minúsculas), atire com o espaço, saia com Q (maiúsculo). Cada colisão com um inimigo tira 2 pontos de HP.
Atualizado: agora com mais de uma versão e usado como exemplo de programação em C, aqui.
Two years or so ago I bought the book Linux Application Development at bargain price, but I still didn’t finished reading it. This always happens with all technical books I bought: I sit down to read the book, and before I finish even a chapter, I shift my attention to something else and drop the book.
I decided to change my strategy: now I’ll try reading the chapters out of order, selecting chapters by its themes, looking for something I’m interested in reading at that moment. Then I found that this book had a chapter about the S-lang lib. S-Lang provides an abstraction of the terminal (console), easing the programming of console applications. Traditionally the ncurses lib is more used and talked about, but S-Lang seems to be updated more often.
So I’ve finally advanced a little more in reading this book, and also spent some time playing with the S-Lang functions, enough to make a small game – a lateral shooter. The ship is an @ character and the enemies are, let’s say, somewhat familiar to anyone who ever played a certain character-mode game. And so I named this little experiment Rogue’m Up – from the wordsRoguelike and Shoot’em Up.
In other words, it’s a character-mode shooter. Don’t expect anything nice, this was just a result of an afternoon’s play with the S-Lang lib functions. Move the ship with the keys wasd or hjklyubn (all lowercase), shoot with the spacebar, quit with Q (uppercase). Every time an enemy collides with you, you lose 2 HP.
Updated: now with more than one version and used as example of C programming, here.
Plonq
English version below.
Faz um tempo que encontrei por acaso um joguinho chamado Qonk. Simples, pequeno, mas criativo. Exige estratégia e rapidez. Basicamente, o objetivo é conquistar um sistema solar, eliminando os concorrentes, conquistando outros planetas, e usando as naves espaciais produzidas por esses planetas para conquistar outros.
Também faz um tempo que conheci a linguagem Lua. Simples, pequena, mas criativa e bem flexível. E para conhecer melhor a linguagem e brincar um pouquinho com ela, instalei uma variante da mesma no meu Palm Tungsten: Plua. Como a melhor forma de aprender uma linguagem de programação é escrever um programa nela, resolvi tentar fazer um joguinho: um pequeno clone do Qonk. O jogo ainda não está completo mas já está funcional. Coloquei o jogo e o código fonte aqui:
Plonq
Some time ago I found a little game called Qonk. Simple but creative, it requires strategy and quick thinking. Basically, the goal is to conquest a solar system, eliminating the adversaries, conquering more planets, and using the spaceships produced by those planets to conquer others.
Some time ago, I also knew the Lua language. Simple, small, but creative and flexible. And in order to know it better, I installed a variant of it in my Plam Tungsten: Plua. Since the better way to learn a new programming language is to write a program in it, I decided to try making a little game: a Qonk clone. The game isn’t complete yet but already works. I’ve uploaded the game and its source code here:
Plonq
Setting Up Emacs for Lisp Hacking in Cygwin
Nice article about how to set up emacs under cygwin for use with Lisp (clisp).
Your files, TRON and text adventures
English version below.
Já jogou adventures de texto? Foram alguns dos primeiros jogos a surgirem nos computadores, e mesmo com a evolução das capacidades gráficas dos computadores, os adventures continuaram a ser jogados, ora mistos de texto e gráficos ora apenas gráficos.
Para quem não sabe o que é: adventures de texto eram jogos aonde você, o jogador, interagia com o jogo digitando comandos. Algo mais ou menos assim: imagine que seu personagem no jogo estava em uma sala, o jogo te daria uma mensagem do tipo:
Você está em uma sala verde. Tem uma mesa no centro da sala com um vaso em cima. Há uma porta para o norte e um corredor para o leste.
Deste ponto em diante, você poderia digitar o comando leste, que faria seu personagem andar pelo corredor, entrar em um novo ambiente e novamente o jogo iria imprimir a descrição desse ambiente na tela. Também seria possível interagir com os objetos dos ambientes, com comandos como pegue faca, abra porta, ou coloque vaso no pedestal. E assim podia-se viver aventuras que iam desde mundos de fantasia ou ficção científica até estórias de terror e ação.
Com o avançar da tecnologia, estes jogos ganharam imagens, e aos poucos foram se tornando cada vez mais gráficos, até o ponto em que não era mais preciso nem digitar os comandos: bastava ir apontando os objetos na tela e escolhendo as ações, clicando em menus com verbos ou em ícones. Os jogos desta categoria mais conhecidos na década de 90 eram os da LucasArts, que fez história com seu primeiro adventure totalmente gráfico, o Maniac Mansion, depois seguido de pérolas como a série Ilha dos Macacos (quem tiver interesse em jogar essas pérolas hoje em dia, conheça o projeto ScummVM).
E o que tem TRON a ver com isso? TRON foi um filme de ficção dos estúdios Disney lançado em 1982, o primeiro filme a usar extensivamente imagens criadas por computador. Claro que elas não se comparam nem de longe e com a luz apagada com os efeitos de hoje em dia, mas o mais interessante em TRON era a história: o protagonista era digitalizado e inserido dentro do sistema de um grande computador, entrando em um mundo ficcional onde os programas apareciam como pessoas, com pensamentos e emoções, e que era regido por mão de ferro pelo sistema operacional tirano, o MCP (qualquer semelhança com o mais moderno Matrix não deve ser mera coincidência…) Ainda hoje é um dos meus filmes preferidos, por mostrar parte do “mundo” com o qual convivo, como programador, como um mundo visível, fantástico e intrigante. Me chamem de nostálgico, mas eu prefiro a caracterização dos programas como entidades vivas em TRON às de Matrix…
Enfim, e daí com jogos adventures e TRON? Bem, eu estava lembrando de um e de outro, e daí lembrei de uma cena em TRON onde o personagem principal chega em uma cidade dentro do sistema, e vê um monte de “pessoas” vestidas de forma diferente que os outros programas, com roupas esquisitas, cheios de adereços… daí ele pergunta quem são aqueles caras esquisitos, e o outro programa responde “são bases de dados”. Quer dizer, no mundo de TRON até os arquivos seriam como entidades, só que com propriedades diferentes dos programas, e pelo visto menos ativos. E de repente pensei numa idéia… e que tal um jogo adventure (não precisa nem ser de texto, pode ser gráfico e em 3D mesmo), ambientado num mundo parecido com o de TRON, o interior de um sistema de computador, mas onde este jogo seria dinâmico, criado de acordo com o sistema que você está usando no seu computador, e até mesmo com os seus arquivos? Imagina só… você começa num grande salão que é na verdade o seu diretório de arquivos, o sistema te mostra uma grande sala chamada “salão principal” ou algo assim. O jogo escaneia os arquivos no seu diretório, alguns arquivos seriam selecionados para aparecerem como entidades vivas dentro do jogo… arquivos de texto e documentos seriam escaneados, e suas palavras seriam usados como diálogo pelas entidades respectivas. Arquivos de imagem seriam usados como elementos de decoração do ambiente, e de música como músicas e sons de fundo. Os subdiretórios seriam outras salas, seguindo as portas do salão principal se entraria nessas salas, que teriam portas para outros subdiretórios e por aí vai; para ganhar acesso a essas salas não bastaria simplesmente andar por elas, digamos que o acesso estaria barrado e você teria que interagir com as tais entidades para conseguir informações, ferramentas ou permissões para avançar no jogo. Agora, quanto ao que estas entidades desejam que você faça ou quais dificuldades elas impõem… isso seria baseado no tipo de arquivo, no conteúdo desse arquivo (seria mais fácil fazer isso com documentos de texto), de forma dinâmica e inteligente. A cada partida o jogo seria diferente, e completamente diferente de um usuário e de um computador para outro. Quanto ao objetivo do jogo eu não sei, mas certamente seria mais explorativo do que um jogo normal, quem sabe filosófico…
(em tempo: há alguns anos atrás um bom jogo em 3D foi feito baseado no filme TRON, chama-se TRON 2.0)
Have you ever played an adventure game (also called interactive fiction)? They were among the first computer games, and even today there are some people who find these games fun. No need to say that they evolved together with the computer hardware, so there came to be adventure games with text and images, and even with only images.
To those that don’t know what I’m talking about: adventure games were played through typed commands. Think this: you’re playing a game where your character was in a room, so the game would print a message like this:
You are in a green room. There are a table in the center of this room and a jar on the table. There are a door to north and a corridor that goes east.
From here onwards, you could type the command east, moving your character through the corridor, so he would enter a new room and the game would print that new room’s description. You could also interact with the objects in the current room, with commands like get knife, open door, or put jar on altar. And this way one could play adventures that ranged from fantasy worlds to sci-fi to horror stories and action.
As the technology advanced, these games were upgraded with graphical capabilities, and become more and more graphical, until the point that one didn’t need even to type commands: just pointing and clicking the objects in the screen, and selecting actions in menus with verbs or icons. The most famous adventure games in the 90s were from LucasArts, which first totally graphical adventure game, Maniac Mansion, made it instantly world-famous. Maniac Mansion was followed by other fine games such the Monkey Island series. (if you want to play those old games in your computer today, please see the project ScummVM).
…translate the rest later…
E o que tem TRON a ver com isso? TRON foi um filme de ficção dos estúdios Disney lançado em 1982, o primeiro filme a usar extensivamente imagens criadas por computador. Claro que elas não se comparam nem de longe e com a luz apagada com os efeitos de hoje em dia, mas o mais interessante em TRON era a história: o protagonista era digitalizado e inserido dentro do sistema de um grande computador, entrando em um mundo ficcional onde os programas apareciam como pessoas, com pensamentos e emoções, e que era regido por mão de ferro pelo sistema operacional tirano, o MCP (qualquer semelhança com o mais moderno Matrix não deve ser mera coincidência…) Ainda hoje é um dos meus filmes preferidos, por mostrar parte do “mundo” com o qual convivo, como programador, como um mundo visível, fantástico e intrigante. Me chamem de nostálgico, mas eu prefiro a caracterização dos programas como entidades vivas em TRON às de Matrix…
Enfim, e daí com jogos adventures e TRON? Bem, eu estava lembrando de um e de outro, e daí lembrei de uma cena em TRON onde o personagem principal chega em uma cidade dentro do sistema, e vê um monte de “pessoas” vestidas de forma diferente que os outros programas, com roupas esquisitas, cheios de adereços… daí ele pergunta quem são aqueles caras esquisitos, e o outro programa responde “são bases de dados”. Quer dizer, no mundo de TRON até os arquivos seriam como entidades, só que com propriedades diferentes dos programas, e pelo visto menos ativos. E de repente pensei numa idéia… e que tal um jogo adventure (não precisa nem ser de texto, pode ser gráfico e em 3D mesmo), ambientado num mundo parecido com o de TRON, o interior de um sistema de computador, mas onde este jogo seria dinâmico, criado de acordo com o sistema que você está usando no seu computador, e até mesmo com os seus arquivos? Imagina só… você começa num grande salão que é na verdade o seu diretório de arquivos, o sistema te mostra uma grande sala chamada “salão principal” ou algo assim. O jogo escaneia os arquivos no seu diretório, alguns arquivos seriam selecionados para aparecerem como entidades vivas dentro do jogo… arquivos de texto e documentos seriam escaneados, e suas palavras seriam usados como diálogo pelas entidades respectivas. Arquivos de imagem seriam usados como elementos de decoração do ambiente, e de música como músicas e sons de fundo. Os subdiretórios seriam outras salas, seguindo as portas do salão principal se entraria nessas salas, que teriam portas para outros subdiretórios e por aí vai; para ganhar acesso a essas salas não bastaria simplesmente andar por elas, digamos que o acesso estaria barrado e você teria que interagir com as tais entidades para conseguir informações, ferramentas ou permissões para avançar no jogo. Agora, quanto ao que estas entidades desejam que você faça ou quais dificuldades elas impõem… isso seria baseado no tipo de arquivo, no conteúdo desse arquivo (seria mais fácil fazer isso com documentos de texto), de forma dinâmica e inteligente. A cada partida o jogo seria diferente, e completamente diferente de um usuário e de um computador para outro. Quanto ao objetivo do jogo eu não sei, mas certamente seria mais explorativo do que um jogo normal, quem sabe filosófico…
(em tempo: há alguns anos atrás um bom jogo em 3D foi feito baseado no filme TRON, chama-se TRON 2.0)
Emacs
Retirado da Wikipédia, com adaptações:
O Emacs é um conceituado editor de texto, usado notadamente por programadores e usuários que necessitam desenvolver documentos técnicos, em diversos sistemas operacionais.
A primeira versão do Emacs foi escrita em 1976 por Richard Stallman. Sua versão atual é 22.1 de 2 de junho de 2007.
O Emacs é considerado por muitos o editor de texto mais poderoso que existe. Sua base em Lisp, especificamente num dialeto de Lisp chamado Emacs Lisp, permite que ele se torne configurável ao ponto de se transformar em uma ferramenta de trabalho completa, uma espécie de “canivete suíço” para escritores, analistas e programadores.
Alguns recursos disponíveis no Emacs:
- Edição colorida e destacada para programação (seja em Lisp, Assembly, HTML, PHP, Python, ShellScript, C, C++ etc. e etc. e etc.)
- Aceita configurações para comandos de shell (a EShell)
- Programável em Emacs Lisp
- Sua flexibilidade faz com que possa rodar dentro dele até mesmo jogos, navegadores web, clientes de e-mail e news e outros programas
- Tem embutido um programa de inteligência artificial, que simula uma consulta entre o usuário e um psicanalista (sim, é sério).
Para alguém que tente buscar bons editores de texto que sirvam para um programador, o Emacs sempre aparece como um dos indicados, principalmente se você programar para Linux ou em Lisp. Falam que é um editor extremamente poderoso, configurável, customizável, e que pode servidr como uma boa IDE (Integrated Development Environment – Ambiente de Desenvolvimento Integrado) para qualquer linguagem. Contanto, claro, que o usuário se disponha a aprender a operar o editor, cujos comandos chegam a ser quase crípticos. Por exemplo, da primeira vez que você executar o programa e quiser abrir um arquivo, o que você vai fazer? Em um editor “normal” você esperaria encontrar uma barra de menu com um menu “Arquivo”, e dentro dele um item “Abrir”. Bem, não que o Emacs não tenha um menu – ele tem um que pode ser usado no ambiente gráfico, e até no modo caractere, mas o que se espera do usuário é que ele aprenda a combinação de teclas Ctrl+x Ctrl+f para abrir um arquivo.
Complicação desnecessária? Pode ser, mas o principal argumento a favor disto é que, aprendendo estas combinações de teclas, com o hábito você será mais produtivo, pois o tempo que é gasto pressionando estas teclas é mais rápido que tirar a mão do teclado, pegar o mouse, mover o mouse até o menu, clicar, mover o mouse novamente até o item “Abrir”, e assim por diante. Ainda assim, se você preferir, você pode usar o menu gráfico e até uma pequena barra de botões. Mas tudo no editor é pensado e direcionado ao uso intensivo do teclado.
Falando assim o Emacs soa mais como um vestibular para nerds, só passa quem decorar um milhão de atalhos enigmáticos de teclado. Ou como uma sala de tortura especializada em punir os usuários de mouse, esses hereges que insistem em prestar culto à setinha do mouse ao invés de se render ao mundo dos atalhos de teclado, o único caminho verdadeiro. Mas tudo tem o seu motivo: a seqüência Ctrl+x Ctrl+f fica facilmente ao alcance da mão esquerda, assim como outras seqüências começando com Ctrl+x (são muitas). E depois, mesmo que pareça difícil demais a princípio, há coisas que facilitam muito a vida – tenha em mente que o Emacs não é um editor de texto customizável, ele é um verdadeiro ambiente operacional programável. E as suas capacidades de ser programado para executar tarefas especializadas vão muito além da mera gravação de macros, coisa que outros bons editores têm. Por exemplo, em que outro editor de texto você conseguiria editar seus arquivos, seus códigos-fonte na sua linguagem preferida, compilá-los e debugá-los, e, dentro do mesmo editor, acessar seus e-mails, participar de discussões em um grupo de news, e até mesmo jogar Tetris? (e com essa última descoberta eu cheguei à conclusão de que não sobrou nenhuma fronteira no espaço para o Tetris: se bobear é capaz dele ter sido gravado até no disco dourado do satélite Voyager e estar chegando agora aos confins do universo.)
Tudo isso, claro, se você se dispuser a entender e domesticar o bicho.
Squeak e Smalltalk no OLPC
Tirado da notícia Fisl – relato inicial e apanhado geral da primeira manhã do evento, do site br-linux.org:
…Mas pra começo, que dei uma passada voando pelo pavilhão, me diverti horrores com a criançada no estande da OLPC.
Nota: OLPC é o projeto “One Laptop Per Child”, Um Computador por Criança, que visa criar uma espécie de mini-notebooks a custo ao redor de 100 dólares para distribuir a estudantes da rede pública de ensino – tente pensar nestas máquinas como “pequenos cadernos eletrônicos”, ao invés de “vão dar notebooks de graça a crianças”; a idéia do projeto está muito além disso.
Sim, pode ser que não de certo, pode ser que dê muito cero, mas que é muito bom ver crianças brincando com interfaces inteligentes (Squeak, pra quem não conhece um smalltalk simples e perfeito para alimentar a fome de conhecimento dos nossos guris e gurias novinhos :-), e vendo que o “brinquedo” funciona.
Squeak e Smalltalk…
Conheci o Squeak uns anos atrás, quando fiquei curioso em conhecer a linguagem Smalltalk e saber como seria uma linguagem orientada a objetos ‘pura’. Achei a linguagem muito interessante, mas mais ainda o projeto Squeak e o fato de ele ser usado, principalmente, para ensinar princípios de computação e programação para crianças – vejam em http://squeakland.org/ , isto já existia muito tempo antes do OLPC ser sequer cogitado. O ambiente Squeak é inteiramente interativo, todo e qualquer objeto pode ser editado, remodelado, programado, ter eventos criados e assim por diante (*todo* e qualquer objeto, até a barra de título de uma janela, os botõezinhos de maximizar/minimizar, e até um label de texto qualquer dentro da janela).
Continue lendo