Structure and Interpretation of Computer Programs

[Silas Silva]

Salve senhores,

Como os senhores sabem, nas disciplinas mais básicas de programação em
nossa universidade (LP e MAC), temos a linguagem Java. Muita polêmica
surgiu, surge e surgirá se a escolha de Java para aprendizado foi
acertada.

Eu tenho minha opinião de que foi uma das piores escolhas que foram
feitas e que é uma das principais causas do horror criado à programação
em nosso universidade (basta sair perguntando aos nossos colegas quem
quer fazer ciência da computação para se ter uma noção de quantos são).

Enfim, o MIT a algumas décadas utiliza uma variação do LISP chamada
Scheme. O textbook que os caras utilizam é aberto e está aqui:

http://mitpress.mit.edu/sicp/

Também achei um site com algumas aulas filmadas e palestras:

http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/

Várias universidades ao redor do mundo adotaram esse livro como livro
padrão para o ensino de programação. No Brasil, a única que adotou até
agora foi a Universidade Federal de Santa Catarina.

Fica para avaliarmos e pensarmos que existe alternativas ao que está
colocado e imposto.

Um abraço.

--
Silas Silva

[Maurício Szabo]

Sobre Java, eu tenho minha opinião de que ensinar APENAS Java é incorreto. Mas, discordo veementemente que LISP seria uma escolha para substituir Java. Lisp não é usado comercialmente, ou é muito pouco usado comercialmente, além de usar outro paradigma de programação (LISP é funcional, ao invés de orientado a objeto, LISP tem tipagem dinâmica, etc). Ensinar as duas em simultâneo é até possível, mas entre uma e outra eu escolheria o Java (como estudar POO com uma linguagem que não é orientada a objeto, por exemplo?)

Note que eu também não gosto de Java, eu até prefiro C++ nesse ponto, então não estou defendendo uma posição pessoal. Inclusive, quando foi citado que seria ensinado SmallTalk eu até sugeri Ruby por ter aplicação comercial e ter muitos conceitos do SmallTalk.

Na minha visão, seria legal ensinar pelo menos uma linguagem dos seguintes grupos:

Procedural (C, etc)
Orientada a Objetos com tipagem estática (Java, C++)
Orientada a Objetos com tipagem dinâmica (Python, Ruby)
Funcional (Lisp, Haskel, etc)

2009/3/25 Silas Silva <sil...@gmail.com>

--
CAMPANHA CÉU PARA TODOS - Pelo desperdício zero na iluminação noturna!
http://www.revistamacrocosmo.com/ceuparatodos/   <-----  Faça sua parte

Air conditioners and Computers are the same - they both crash when you open Windows.

GCS s+:- a? C++ UL+++ P-- L++ E--- W++ N* K--- w--- !O M PS+ Y-- PGP- t- X- R++ b++ DI-- D-- G- e h!

[Fernando H. Sanches]

Curiosamente eu estava pensando nisso hoje (raios, penso nisso toda
semana).

Não só Java está frustrando os alunos como a ementa de algumas
matérias está sendo prejudicada por causa disso. Por exemplo, em MAC,
se dedica pouco mais de 1 semana para aprender "Interfaces", que é
algo específico da linguagem. Nunca vi outra linguagem com Interfaces.
Nesse ponto a escolha de Java prejudica a todos: 1 - Aos que não
querem computação, por terem que aprender algo que possivelmente nunca
vão usar, e 2 - Aos que querem computação, por perderem tempo com algo
específico que poderia ser aprendido com qualquer tutorial ou livro do
assunto, conforme a necessidade (se a pessoa não usasse Java nunca
precisaria aprender).

O SICP é simplesmente ótimo (assim como o HtDP, que temos na
biblioteca). Infelizmente ainda não pude pegar ele pra ler seriamente
(apenas li trexos), mas pelo pouco que vi é fantástico. Impressionante
como o livro começa com aritmética básica e termina fazendo um
compilador. O nível de profundidade atingido é algo que nunca vai se
ver com Java. Ver esse livro ser utilizado (e BEM utilizado) nos
cursos introdutórios daqui é praticamente um sonho.

Se você pegar, por exemplo, o conteúdo do capítulo 4, é algo que
nesses 2 anos de bacharelado eu nunca ouvi ser comentado em sala de
aula. Aliás, nem precisa ir tão longe - o capítulo 1.3 (que trata de
funções de alta ordem e suas aplicações) já é algo impossível de se
ver em Java, que não dá nenhum suporte a isso. *Se* virmos algo do
tipo no curso será em Paradigmas de Programação, que vai acontecer lá
pelo último. E nos meus estudos "por conta" eu já vi que é um tema
importantíssimo. Mas tente mostrar isso para quem usa Java! Você vai
ter sorte se a pessoa entender o que você está falando.

[Cesar Fuentes]

Que livros são esses (SICP e HtDP)?

2009/3/26 Fernando H. Sanches <fernando...@gmail.com>

[Silas Silva]

On Thu, Mar 26, 2009 at 10:03:52AM -0300, Cesar Fuentes wrote:
> Que livros são esses (SICP e HtDP)?

Passei a URL para o SICP uns e-mails atrás (nessa thread). O HtDP eu não
conhecia. Tem na UFABC mas é também um livro aberto e está aqui:

http://www.htdp.org/

--
Silas Silva

[Silas Silva]

Salve Fernando,

Pois é... talvez agora com a mudança na grade curricular ou com o tempo
o pessoal veja que não é a melhor escolha... veremos...

Não conhecia o HtDP, hein? Muitíssimo interessante cara, e o melhor de
tudo: é aberto e grátis. Tá no seguinte link.

http://www.htdp.org/

Porra, essa galera do MIT é foda. Vocês já viram o OpenCourseWare? Muito
bom.

Valeu pela dica!

--
Silas Silva

[Silas Silva]

Salve Maurício, tudo jóia?

A questão da escolha de uma linguagem de programação é um assunto
delicado e vários fatores tem que ser levados em consideração. Um deles
é o uso comercial da linguagem mas, a meu ver, este é um fator menor em
comparação com outras coisas.

Acredito que existe uma diferença fundamental entre "aprender a
programar linguagem X" e "aprender a programar". Ao que aprende o
segundo, pode-se programar em qualquer linguagem. Ao dar-se prioridade
muito alta à importância comercial da linguagem pode-se fazer péssimas
escolhas, como a escolha de Java. Creio que alguns professores (não sei
se na UFABC) defenderiam até o ensino de .NET em M$ Visual Studio
(!argh), porque tem uma importância comercial bastante grande. Quem
"aprender a programar", independentemente da linguagem, pode utilizar
qualquer uma delas, até pseudo-código.

Por quê Java? Acho que o principal argumento dos professores, além da
importância comercial, é o fato de java ser OO. Mas não há outras
linguagens OO? Não poderíamos utilizar, como você recomendou, Ruby ou
Python, ou uma variação de algum deles com tipagem estática (outra
discussão interessante: linguagens de tipagem dinâmica vs. linguagens de
tipagem estática no ensino...)? Python é incrivelmente intuitiva e não é
necessário aquela burocracia para se rodar um programinha: chame o
interpretador e pronto. Em Java, deve-se criar uma classe principal com
o método main()... bla bla bla... é uma burocracia que espanta o aluno
iniciante.

Bom, aí acho que temos uma discordância a respeito do paradigma
utilizado como curso inicial. Acho que a escolha de OO não é saudável e
defendo que o paradigma imperativo (procedural) deva ser priorizado. Por
quê? Minhas razões:

1. O paradigma imperativo é mais intuitivo, como uma receita de
bolo.
2. Resolve com elegância a maioria dos problemas que encontramos no
dia-a-dia acadêmico (algoritmos de cálculo numérico, problemas de
física, etc.): não é a toa que o povo do meio científico adora
Fortran, que até pouco tempo atrás não suportava OO (me corrijam
se eu estiver errado, pois não conheço em detalhes a linguagem).

Uma outra possibilidade seria focar no paradigma funcional, pelo seu
rigor matemático e pelas mesmas vantagens que citei acima para o
paradigma imperativo.

Quanto ao ensino de OO, seus defensores de OO justificam que é mais
próximo do mundo real, composto de classes de coisas e suas instâncias,
e por isso seria mais natural o aprendizado. Ledo engano. Quando quis
aprender OO pela primeira vez, lia tutoriais que tentavam fazer este
ingênuo paralelo:

"Um projeto de uma bicicleta é uma classe, as bicicletas são suas
instâncias. Uma bicicleta pode ter propriedades como cor, tamanho e
métodos como pedalar(), subir(), descer()."

Péssimo. Só fui entender de fato pra o que servia OO quando fui ver uma
aplicação computacional prática, sem tentar "concretizar" os aspectos
"abstratos" da OO. Infelizmente na UFABC ainda estamos caminhando nos
mau exemplos (quem teve aula de LP, MAC e POO talvez concorde comigo).

Uma última consideração: a programação tem um papel muito forte de
aproximar as pessoas para a computação e a matemática, quando bem
ensinada. Infelizmente na UFABC esta parece espantar as pessoas dessas
duas (em especial da primeira).

Um abraço a todos.

--
Silas Silva

[Maurício Szabo]

Interfaces está presente no C# também, mas concordo que é algo específico... apesar que tem conceitos muito parecidos em outras linguagens (C++, por exemplo, tem as funções virtuais, que meio que funcionam parecido com as Interfaces...)

Eu já vi um tutorial emulando funções de alta ordem, mas não consegui achar ele (e também, pelo que eu me lembro, não é uma emulação muito boa...). A propósito, existe um "dialeto" de Java chamado Nice, que eu ouvi dizer que permite alguns conceitos a mais...


Sobre a história de Orientação a Objeto, sejamos sinceros, Java é a piorzinha nesse pontos (sem overload de operadores, sem múltipla herança, etc...). Mas eu defendo OO DESDE QUE fosse ensinada direito... Essa história da bicicleta realmente é péssima, eu prefiro pensar como filosofia platônica (classe é o "conceito" de algo, como o plano platônico ou o plano das idéias), mas essa é outra discussão...

Além disso, Ruby é multi-paradigma (OO e Funcional), e pode ser usada como linguagem procedural... Python tem algumas coisas que poderiam ser aplicadas na linguagem funcional também, mas lembrando que Haskel é puramente funcional, já Lisp/Scheme não... eu acho o paradigma funcional bem mais chato que os outros, mas isso é minha opinião...

A idéia de usar uma linguagem de cada paradigma é que aprendendo a programar em uma linguagem você aprenderia a programar em todas... mas quando vc aprende a programar em OO, é difícil que vc se entenda com Haskel corretamente... eu mesmo tinha um preconceito considerável por Ruby por ser dinâmica (minha experiência sempre foi com linguagens estáticas, tipo Delphi, C++, e Java...)

[]'s

2009/3/26 Silas Silva <sil...@gmail.com>

[Renato Riccieri]

Eu sou a favor de usar Ruby como linguagem "inicial", e com o paradigma procedural.
Dentre todas as linguagens que já experimentei, essa é, na minha opinião, a mais intuitiva.
Como alguns autores deixam bem claro, programar em Ruby se assemelha muito a escrever um algoritmo em uma pseudo-linguagem(corrijam-me se esse não for o termo correto) como portugol. Isso fica bem evidente ao nos depararmos com alguns programas mais simples, em que é possível realmente ler o programa em voz alta, como se fosse um texto.

Quanto a tipagem dinâmica x tipagem estática, eu não vejo tanta diferença. Mesmo em linguagens como Ruby e Python, é necessário se preocupar com o tipo de dado que a variável está guardando na hora de usar determinadas funções. O fato do tipo ser explicitado na hora da declaração só faz com que essa checagem seja feita automaticamente, ao invés da necessidade de funções como "is_a?"

Abraços

2009/3/25 Silas Silva <sil...@gmail.com>

[Maurício Szabo]

Particularmente eu também adoro Ruby, mas discordo quanto a programação procedural / tipagem estática x dinâmica. Programar em Ruby proceduralmente é arrebentar com uma das melhores coisas que a linguagem tem, além de ser meio impossível. O código:
c = 10 + 20

por incrível que pareça, já está orientado a objetos porque o "+" é um método da classe Numeric, que é responsável pelos números... além disso, em C:
char a[] = "10";
int b = atoi(a);

é a conversão de texto para número, claramente procedural. Em ruby:
a = "10"
b = a.to_i

claramente orientada a objetos... e sobre o estático x dinâmico, eu acho que o ritmo é diferente. Em ruby eu posso ter um array [1, 2, '3', 'Quatro'], que é impossível em C++ e esquisito (pra dizer o mínimo) em Java... da mesma forma, quase todas as bibliotecas de Ruby tem funções que, se vc passar um array, um "range", um número ou string tem comportamento diferente, o que não é comum em Java. Por exemplo, uma consulta a base de dados:
Aluno.find(10) #Busca o aluno com ID 10
Aluno.find([10, 20]) #Busca os alunos com ID 10 e 20
Aluno.find(:all) #Busca todos os alunos
Aluno.find(10..20) #Busca os alunos com ID do 10 até o 20


Aliás, em alguma disciplina está sendo ensinado Ruby? Parece-me que no começo queriam ensinar SmallTalk, e eu sugeriri Ruby por ter mais aplicação fora do mundo acadêmico... é uma linguagem bem interessante eu diria, mas pode deixar o pessoal mal-acostumado hehehe. Por exemplo, calcular o fatorial em Ruby:
def fatorial(x)
  (1..x).inject(1) { |res, valor| res *= valor }
end

Coitada dessa pessoa, quando acostumar com essas facilidades e for para uma linguagem como Java hahahaha.

Abraços,
Maurício.

2009/3/26 Renato Riccieri <renato....@gmail.com>

[Fernando H. Sanches]

Maurício, Ruby não está sendo ensinada em nenhuma disciplina. Ela faz
uma "aparição relâmpago" numa das primeiras aulas de POO mas só isso.

As linguagens que foram utilizadas até agora:

- Java (LP, MAC, POO, Estrutura de Dados II, Programação Web);
- C - Estrutura de Dados I e II
- Prolog - Lógica de programação
- SQL - Banco de Dados e SGBD

Quanto eu fiz POO com o Marcelo Zanchetta, ele mostrou trexos em
código de C++, Python, Ruby e Smalltalk, passou uma apostila de C++ e
disse algo sobre a linguagem da matéria ser livre (mas acho que todos
acabaram usando Java).

O Jerônimo incentivou o uso de alguma linguagem de fora dessa lista em
Inteligência Artificial e passou alguma coisa de Common Lisp em
Estrutura de Dados I. Também fez uma apresentação sobre Programação
Funcional ao final da disciplina.

Computação Evolucionária e Conexionista também ficou com linguagem
aberta. Mas, como a ferramenta usada era em Java, todo mundoa cabou
usando ela, até para facilitar integração de código...

Além dessas houve Cálculo Numérico e Programação Gráfica, mas não as
fiz então não sei o que usam (se não me engano C.N. usa Matlab, mas
não tenho idéia quanto a P.G.).

Dessas linguagens ensinadas, Java acaba realmente sendo um
"denominador comum". Programar em C é trabalhoso demais (Sementation
Fault...), e Prolog não é adequada para todas as coisas (assim como
SQL). Aí em grupos o povo acaba recorrendo a Java, já que dificilmente
todos integrantes vão saber Python ou Ruby, por exemplo.

Quanto à escolha de primeira linguagem a ser ensinada, isso é uma
antiga discussão não-resolvida. Na minha visão os principais fatores,
em ordem de importância, para a decisão disso devem ser:

- Disponibilidade de bom material (não há curso bom sem bom
materiais , e eu não considero Deitel bom material);
- Simplicidade/Intuitividade (ou: "se preocupar com os algoritmos e
não com a máquina");
- Nível de abstrações;
- Reutilização posterior da linguagem.

Por esses critérios, Scheme vai bem nos 3 primeiros itens mas não tão
bem no último - só é usada por acadêmicos (embora dê para reaproveitar
o conteúdo em Common Lisp, mas mesmo ela tem aceitação comercial quase
nula no Brasil).

Ruby vai muito bem nos três últimos, mas sofre no primeiro - não
existe, até onde eu saiba, um bom livro introdutório de Ciência da
Computação que usa Ruby.

Python já vai bem em todos os itens. Eu só conheço um bom livro
introdutório a ela (Introduction to Computer Science with Python) e
não cheguei a ler, mas é o que o MIT usa atualmente então coisa ruim
não é.

Haskell eu não vou comentar muito - apesar de estar apaixonado pela
linguagem e ser fã do paradigma funcional, acho que ela não tem a
simplicidade necessária pra isso.

(curiosamente, Java só vai bem no último item :) )

[Maurício Szabo]

Eu, particularmente, não sou fã de Python por não gostar do tal do "Python Zen"... a idéia de que só deve existir uma maneira de fazer as coisas não combina comigo hehehe. Além disso, a idéia de Python se contradiz no "Explícito é melhor que implícito" (a explicação daquele operador "self" em todos os métodos), mas que não funciona muito bem com overload de operadores (__len__ para o tamanho de um array, __lt__ para o operador <, etc). Além disso, acho a linguagem feia, tipo:
class Algo(Pai):
    def __init__(self, var):
        self._var = var

    @property
    def var(self):
        return self._var

    @var.setter
    def var(self, valor):
        self._var = valor

Comparado com Ruby:
class Algo < Pai
  attr_accessor :var

  def initialize(var)
    @var = var
  end
end

é uma pena ver que Ruby não está sendo ensinada... eu meio que comentei isso uma vez com alguns professores que eu achava ruim as universidades praticamente "treinarem" os alunos a usarem Java... isso meio que limita a visão a uma linguagem (e sejamos sinceros, uma bem estranha por sinal...)

Aliás, uma leitura engraçada para que também não gosta de Java:
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

Abraços.

(PS: Java não tem bons materiais para ensino? Sempre achei que por ser uma linguagem que é ensinada praticamente em todo lugar, ela teria uma quantidade de livros bem maior que as outras....)

2009/3/26 Fernando H. Sanches <fernando...@gmail.com>

[Fernando H. Sanches]

Maurício, embora eu concorde que no seu exemplo Python está mais feia,
considere que você está fazendo Ruby em Python. Em poucos casos se
cria setters e getters nela.Eu mesmo nunca precisei usar os
decorators.

E eu já tinha lido esse texto, muito bom. Criativo e sempre
verdadeiro.

Quanto a materiais de ensino pra Java: Tem, muitos. Mas a maioria é
coisa muito "prática" e "mercadológica". São livros para se aprender a
programar, não para aprender Ciência.

Se você for na página[1] da Deitel sobre o livro deles (Java: How to
Program, um dos mais usados em LP), você vai ver algumas "key
feytures", por exemplo:

# New GroupLayout layout manager.
# New JDBC chapter introduces JDBC 4 and uses the MySQL and Java DB
databases.
# New JTable sorting and filtering capabilities.
# New Java2D gradient capabilities.
# Strong treatment of generics and generic collections.
# New application using Google Maps web services.

Muito bacana pra programador Java, mas *não tem importância alguma
para quem quer aprender Ciência da Computação*.

Só comparando os índices dele com os do SICP você já vê as diferenças.

Deitel:
1 Introduction to Computers, the Internet and the Web
2 Introduction to Java Applications
3 Introduction to Classes and Objects
4 Control Statements: Part 1

SICP:
1 Building Abstractions with Procedures
2 Building Abstractions with Data
3 Modularity, Objects, and State
4 Metalinguistic Abstraction

A diferença de profundidade está em ordens de magnitude!

[1] - http://www.deitel.com/Books/Java/JavaHowtoProgram7e/tabid/1191/Default.aspx

[Maurício Szabo]

Sobre Getters e Setters, uma das práticas mais recomendadas sobre o assunto é nunca expor diretamente os atributos para facilitar o tratamento de informações incorretas... concordo que o "Python Way" é meio diferente mas... bom, como eu disse, opinião pessoal eu não gosto muito da linguagem (na verdade, até gosto da linguagem, não gosto de ter que engolir o "Python Way"...)

Só uma pergunta (eu não sou aluno), Deitel é o que está sendo usado na UFABC? E realmente, a comparação do Deitel com o SICP é realmente assombrosa... essas matérias que usam o Deitel são do curso de ciencia da computação mesmo, ou são do BCT?

2009/3/27 Fernando H. Sanches <fernando...@gmail.com>

[Fernando H. Sanches]

Em Python você declararia os setters getters só caso fosse necessário,
e a sintaxe seria a mesma de uma chamada direta (assim como em Ruby).
No final não gera muita diferença... Mas como raramente se precisa,
raramente se usa. Mas no final isso acaba gerando pouca diferença...
Quer dizer, tanto Python quanto Ruby são infinitamente melhores que
Java nesse ponto. =P

Quanto ao Deitel, ele não é o livro "oficial" de nenhuma disciplina,
mas, como as introdutórias não possuem nenhum livro (ugh), o povo
acaba se apoiando no Deitel, já que há uma grande quantia de cópias na
biblioteca, lida diretamente com Java e possui alguns códigos prontos
que podem ser incorporados em projetos.

E sim, são matérias do próprio BC&T (Linguagens de Programação,
Metodologia e Algoritmos Computacionais). O problema é que elas também
acabam sendo as introdutórias para o povo da computação... Apesar de
que elas estão caindo fora da grade nesse período e sendo substituídas
por outras (e aparentemente não está havendo nenhuma disciplina de
programação no primeiro período - quero só ver o que isso vai dar).

[Fernando H.]

Ah, sim, só pra botar um pouco mais de lenha na fogueira contra Java,
dois textos criticando o uso dela como primeira linguagem:

http://www.stsc.hill.af.mil/CrossTalk/2008/01/0801DewarSchonberg.html
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html

O primeiro texto é de um povo mais industrial, e o segundo é de um
programador do "business".

Meus trexos favoritos (2 do primeiro e 1 do segundo texto,
respectivamente):

"I have had a lot of complaints about that [the use of Java as a first
programming language] from industry, specifically from AT&T, IBM,
Intel, Bloomberg, NI, Microsoft, Lockheed-Martin, and more."

"It [Texas A&M] did [teach Java as the first language]. Then I started
teaching C++ to the electrical engineers and when the EE students
started to out-program the CS students, the CS department switched to C
++."

"The recruiters-who-use-grep, by the way, are ridiculed here, and for
good reason. I have never met anyone who can do Scheme, Haskell, and C
pointers who can't pick up Java in two days, and create better Java
code than people with five years of experience in Java, but try
explaining that to the average HR drone."