RV: Thoughts from an outsider

Esto vino hoy a la lista y representa un punto importante a conocer sobre
las diferentes formas de programación y de críticas a como están las cosas
en este momento.
Tambien sirve para ver si están recibiendo los mails...



------ Mensaje reenviado
De: J J <[hidden email]>
Responder a: The general-purpose Squeak developers list
<[hidden email]>
Fecha: Wed, 30 Aug 2006 08:04:07 +0000
Para: <[hidden email]>
Asunto: Thoughts from an outsider

Hello group,

I have been reading through the mail list archives and I thought I would
share my thoughts as an outsider (at the moment) to the smalltalk community.
  I appoligize in advance for the size of this email. :)

Computers were not my initial profession, so I came in from a learn-as-you
go situation.  But I have been in IT over 10 years now and think I have a
pretty good idea of a possible silver bullet when I see one. :)  Smalltalk
seems to be the perfect development environment and what's more; it deserves
to be used more then the languages that are used right now.

Before I was an effienciency/static typing junky, but smalltalk has made me
rethink the typing at least. :)  After all, how many errors *has* that
really caught for me compared to all the times code didn't compile because
the compiler was confused about something that should work.

Smalltalk even showed me that self generating code could be a good thing.
When I first heard of, and thought about the possibilities of this years ago
in Perl I cringed.  But the reason I cringed was simple:  Assembly, C/C++,
Perl, Java, everyone else really have two distinct modes:  Design mode
(where your code is layed out and how) and runtime mode (what it actually
looks like as a running system).  Self modifying code in this situation is a
scary thing because it pushes those two modes even further apart then they
were to begin with (which is often pretty far).  But smalltalk opened this
door for me because it doesn't have that problem.  The design and runtime
modes are almost the same thing.  If I impliment a "doesnotunderstand:" that
builds any messages it recieves, let it run for a few days and then come
back, the system will have made my methods for me.  Then I can take that
method out if I want.  Amazing.  But it's ok, since the source code and the
running system are almost one and the same this practice doesn't cloud my
view of what the running system looks like.

As I have been looking through the programming languages out there (have
been between jobs, so I decided to brush up on my programming a bit) you
can't help but see lisp.  I know lisp people hate to hear it, but lisp seems
like the best of research languages.  It seems like every advance in
languages came from lisp at one point or another.  But it feels like
smalltalk has taken the advances and made them usable by the normal man.
And smalltalk did the right thing taking the real ideas, not a castrated
version of the idea.  The exception mechanism for example (see C++, Java, et
al), smalltalk has method resumes, restarts, everything.

Perl is the classic case of a sense of loyalty taken too far.  A man saves
your life (and perl did save us.  We were programming CGI in C before it
came along and woke everyone up) but as time goes by he has asked to move in
with you (perl decided cgi and sys admin wasn't enough, it wants to develop
all your apps!) and one day you dont see him anywhere but cloths are all
over the floor, perl and your wife are no where to be seen and there is some
uncomfortable noise comming from upstairs.  But he saved your life right?

Perl is a disgusting hack from top to bottom.  It is a filesystem based
language like the rest, but even having a source of more then one file is a
hack.  "Why do I need a 1; at the end of my file again?  Oh right, someone
somewhere might want their file to execute code when it gets included and in
perl TIMTOWTDI!  Since they might, we all must?  What was that you said
about 'simple things simple, hard things...'?".

Ruby is of course appealing because it has something like the smalltalk
syntax.  But in the end it is a script language and to get where it needs to
be to be the best it needs to, well, be what smalltalk is right now.

What about Java?  Well you can build anything you want with turds and glue.
You can build a big boat, you can build a huge castle, but what do you have
at the end?  A big smelly pile of crap.  That is what Java is in my mind.
If the universe is "turtles all the way down", smalltalk is "objects all the
way down" and Perl is "hacks all the way down" then Java is surely
"inconsistancy all the way down".  And just as perl has shown, a million
monkeys typing on a million keyboard wont reproduce the works of
Shakespeare, and it also wont turn a big pile of crap into a Ferrari.  But
it might be able to build something to get you to work if you can bear the
smell.

So what went wrong?  You have the right idea, why isn't everyone here
already?

Reading through the list, a few things struck me:

First, Luckas and Andreas fighting over extending functionality vs. backward
compatibiltiy.  Well, I wouldn't presume to take sides in such an argument,
but there are a couple of important points we must always keep in mind:
backward compatibility is a noble cause.  No one wants to work where they
syntax of the language can change before you can even get your program that
used the "old" syntax finished.  But on the other hand, backward
compatibility is an open paracute on your back.

In Estonia in the early 90's it was not uncommon to not have running water.
Only about 50% of the population had a phone line.  But in 2004 Estonia
became the most technologically advanced nation in all of EU, maybe the
world.  It has the largest % of cell phone users, the government was
completley paperless!  How did they come so far so fast?  Simple: no
backward compatibility what-so-ever.  No one screamming "Wait!  I'm still
using windows 3.1, we can't make that change!"  No open paracute's on
anyones back.

So what is the right answer between Luckas and Andreas?  I don't know, but
when we talk about backward compatibility, while we dont want to break
things just to say we did, we also can't get in a situation that takes 15
years to dig out of.  In some cases backward compatibility is the 100% right
answer, but in my mind the backward compatibility side has 1 default mark
against it.  If it is indeed the right answer, then it should be able to
overcome this easily, and perhaps this particular argument is just such a
case.

Scripting.  Do we need it?  Well Java doesn't have it.  C++ doesn't have it.
  And those are the two most popular languages afaik.  But both of those
have huge business backing them.  The languages that do *not* have this kind
of backing, but are sucessfull are all script languages, or can run in
script mode.

How hard would it bee to just make an image that looks a little different
then the default image, it expects arguments set up the way they are with
typical #! setups?  And any syntax chosen needs to look as close as possible
to what smalltalk is now.  No new strange constructs that are totally
different inside the image, no meta-programming as a rule.  It needs to look
like it does in the browser.

Tim is right, this would be a step back.  Smalltalk has a much better
environment if you just use the image.  But what is more important at this
point: being right, or getting a bigger base for the language?  I know which
one I would pick.  I know it's frustrating having the solution and having to
stuff it down peoples throats, but if hair dryer companies can put those
stupid labels on hair dryers, can't we give a scripting option?

And hey, when a squeakscript user says "By the way, have you guys got any
kind of debugger?"  Out pops the smalltalk salesman complete with a huge
grin and a cheasy suit saying "Why sure!  Just run this" and presto, when
they see they can change code in the debugger and it just resumes from
there, most of them are going to become converts.  But first you have to
drag them kicking and screaming somehow.

I'm sure the Howard Aiken quote is familiar to all smalltalkers: "Don't
worry about people stealing your ideas. If your ideas are any good, you'll
have to ram them down people's throats."

What smalltalk also needs is a killer app.  Maybe seaside will be that
killer app if the inferier language crowd doesn't steal it first.

But no matter how you get them here, it wouldnt matter one bit today because
they wont stay.  Why?  Because smalltalk documentation is like a ghost town.
  When I found whysmalltalk.com (shows up #4 if you google "smalltalk
tutorial") I was excited about all the examples and tutorials.  After 90% of
the links pointed nowhere I started doing searches on the net to find out if
I was simply too late, maybe smalltalk was dead already.  And your own
squeak site isn't much better.  Nothing screams "no one lives here anymore"
like dead links.  And the more dead links the loader the scream.

One thing I think I disagree with stéphane about (not sure I understand his
point exactly) is the releases.  If a squeak version is released in the
forest and no one is there to see it, will anyone care?  Fixing bugs are
important if that's what you mean by release.  New features to help support
those killer aps are important.  But if you don't have any documentation
anywhere no one will stay.  I stayed because I was determined to fix this
gap in my knowledge and learn this language, dead or not.

And dont go down the road that "smalltalk is simple so the code documents
itself".  The code NEVER documents itself, that is a cop-out and a bold face
lie.  If you don't want to document then for God's sake, hand it off to
someone who will.  Not every single method ever of course, but anything the
API user uses directly should be documented.

And it needs to be consistant too.  I'm a "digger", if it is there I will
find it.  But most people aren't.  If your solution is "well go to the class
side, there is maybe some method there that documents the class" then you
don't have a solution.  "Documentation is always on the class side in the
'documentation' protocol (and here is how you find that)" would be much
better.

You have a very friendly mail list, the best I've ever seen to be honest.
But that doesn't overcome documentation.  People are not trained to look on
mailing lists for documentation.  When thinking about users you have to
think Homer Simpson.  You can scream "look in the news groups" on every page
and he will say "Thanks, what is the link to/program that shows the
documentation?".

I hope someone somewhere finds something I said useful. :)




------ Fin del mensaje reenviado



       
 p5.vert.ukl.yahoo.com uncompressed Wed Aug 30 09:27:04 GMT 2006
       
               
__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas 




correo electrónico a: [hidden email]


correo electrónico a: [hidden email]

 
Enlaces de Yahoo! Grupos

<*> Para visitar el sitio web del grupo, andá a:
    http://ar.groups.yahoo.com/group/squeakRos/

<*> Para cancelar tu suscripción a este grupo, enviá un mensaje a:
    [hidden email]

<*> El uso de Yahoo! Grupos está sujeto a las:
    http://ar.docs.yahoo.com/info/utos.html
 

Interesante post Edgar. No estoy totalmente de acuerdo, pero esta un poco
relacionado con mis primeros post en este grupo.

*...What smalltalk also needs is a killer app.  Maybe seaside will be that
killer app if the inferier language crowd doesn't steal it first.*

Smalltalk no necesita eso. El Seaside no es una killer app.
Ya expuse esta opinion en anteriores post. Smalltalk no lo necesita porque
ya es un "killer enviroment"!!! y eso es mucho mas fuerte.


*...But no matter how you get them here, it wouldnt matter one bit today
because
they wont stay.  Why?  Because smalltalk documentation is like a ghost town.
  When I found * *whysmalltalk.com* <http://whysmalltalk.com/>* (shows up #4
if you google "smalltalk
tutorial") I was excited about all the examples and tutorials.  After 90% of
the links pointed nowhere I started doing searches on the net to find out if
I was simply too late, maybe smalltalk was dead already.  And your own
squeak site isn't much better.  Nothing screams "no one lives here anymore"
like dead links.  And the more dead links the loader the scream. *

Esto en parte es cierto... el
SqueakSwiki<http://minnow.cc.gatech.edu/Squeak>esta un poco flaco pero
es suficiente como para empezar a explorar.
Por otro lado me parece que la intencion de publicar este sitio (
whysmalltalk.com) es darle difusion al lenguaje. No hay una actitud un poco
patologica de boicot interno? Se quiere o no se quiere darle difusion?
**

*...People are not trained to look on
mailing lists for documentation.  When thinking about users you have to
think Homer Simpson....*
**
 Me parece que el tema es un poco mas complejo. Como se quiere que la gente
aprenda Smalltalk? Por exploracion, por imitiacion, por  receta? Cual es la
mejor manera? Sera posible un parendizaje por exploracion con mejor soporte
de documentacion?
Habria que tratar a los novatos como si fueran Homero?
La curva de aprendizaje en Smalltalk es bastante pronunciada, todos lo
sabemos. La industria del Soft actualmente lo que menos quiere es gente en
medio de una curva de aprendizaje. Pero eso no solamente es un problema de
Smalltalk. Hay demasiada gente desarrollando que ni siquiera tiene los
conocimientos minimos procedurales, o de conceptos de estructuras de datos.
Como por ej: en vez de copiar y pegar codigo, encapsular esos fragmentos en
un procedimiento o funcion, o, por que se debe evitar el uso de variables
globales y cuales son las consecuencias de usarlas, o, saber que es un
arbol, para que se usa, como se usa, etc, etc,etc.
Como deberia aprender esta gente? aprenderia?
Me voy un poquito del tema: a mi me parece que en general la gente debria
estudiar (al margen de Smalltalk) mas teoria de Orientacion a Objetos. Asi
dejan de hacer la burradas que hacen con Java.

Volviendo: ya se hizo una constante, estas discuciones dejan mas
interrogantes que respuestas. Quizas sea un buen indicio. Lo mas importante
me parece es que estas respuestas las tenemos que construir nosotros, los
desarrolladores, los entuciastas, los docentes, los amaterus.

Para sondear voy a comenzar una pequeña encuesta con una pregunta simple:
Que es lo que queremos para Squeak? Desarrollo? investigacion? las dos? etc?

Saludos

Elvio



* *

>Me parece que el tema es un poco mas complejo. Como se quiere que la gente
aprenda Smalltalk? Por >exploracion, por imitiacion, por  receta? Cual es la
mejor manera? Sera posible un parendizaje por exploracion >con mejor soporte de
documentacion?

El tema es ccomplejo porque todos somos diferentes.
Muchos lo primero que pregunta es que pueden leer, que libros hay.


>Habria que tratar a los novatos como si fueran Homero?
Yo intento que los que aparecen aquí elijan que quieren hacer. En todo caso
les muestro mis pavadas para que se orienten

>La curva de aprendizaje en Smalltalk es bastante pronunciada, todos lo sabemos.
La industria del Soft >actualmente lo que menos quiere es gente en medio de una
curva de aprendizaje. Pero eso no solamente es un >problema de Smalltalk.

Concuerdo

>Hay demasiada gente desarrollando que ni siquiera tiene los conocimientos
minimos procedurales, o de conceptos de estructuras de datos. Como por ej: en
vez de copiar y pegar codigo, encapsular esos fragmentos en un procedimiento o
funcion, o, por que se debe evitar el uso de variables globales y cuales son las
consecuencias de usarlas, o, saber que es un arbol, para que se usa, como se
usa, etc, etc,etc.

Hay gente que está en las facultades donde se enseña esto por el mismo
motivo que el perro en la iglesia.
Imitando al inolvidable Maxwel Smart, me creerias si te digo que al menos
aquí gente que se titula Ingeniero en Sistemas nunca oyó hablar de parsing ?

>Como deberia aprender esta gente? aprenderia?
Lo peor de los objetos es que tal vez no sean para todos.

> Lo mas importante me parece es que estas respuestas las tenemos que construir
nosotros, los desarrolladores, los entuciastas, los docentes, los amaterus.
>Para sondear voy a comenzar una pequeña encuesta con una pregunta simple:
>Que es lo que queremos para Squeak? Desarrollo? investigacion? las dos? etc?

Vas a tener tantas respuestas diferentes como cosas se pueden hacer con
Squeak.
A mi me empieza a asustar el ³efecto Big Bang² que se ve.
Me refiero a las ideas divergentes que tienen a Squeak como iniciador.
Ahora apareció TimLizzie