En Wed, 16 Sep 2009 16:41:20 -0300, Daniel Moisset  
<dmoisset@except.com.ar> escribió:
> 2009/9/16 Alejandro Santos  
> <alejolp@alejolp.com>:
>>
>> Ahora, el asunto del break que no se puede usar es muy subjetivo. Eso
>> data de lo que se conocia como "programación estructurada" cuando la
>> gente programaba en cosas raras como COBOL o Pascal donde tenias
>> codigo horroroso. La idea es que, dada una función, puede haber un
>> solo flujo de código (de ahi que tambien el goto no está bien visto).
>
> [OT] pero lo que decís de pascal es justamente al revés... pascal fue
> de los primeros lenguajes sin break (ni instrucciones de flujo de
> control que no sean "single entry-single exit"), justamente por
> purismo en ese sentido.

Y todo esto ya se discutió 35 años atrás...

Este paper de Knuth [1] de 1974 es de la época del artículo de Dijkstra  
"GO TO considered harmful"; es largo pero vale la pena leerlo. Analiza  
exhaustivamente las implicaciones de eliminar el GO TO: eficiencia, manejo  
de errores, chequeo de subíndices, hashing, comparación de strings,  
búsqueda en árboles, eventos [excepciones], iteración. Y cuándo es  
conveniente usarlo (ej: eliminar recursión, ramificación múltiple).

De paso, contiene varias frases célebres:

	«We should forget about small efficiencies, say about 97% of the time:  
premature optimization is the root of all evil. Yet we should not pass up  
our opportunities in that critical 3%. A good programmer [...] will be  
wise to look carefully at the critical code; but only after that code has  
been identified. It is often a mistake to make a priori judgments about  
what parts of a program are really critical, [programmers'] intuitive  
guesses fail.»

Y una que muestra que los súper gurúes tambien son humanos :) :

	«I remember feeling frustrated on several occasions, not seeing how to  
write programs in the new style; I would run to Bob Floyd's office asking  
for help, and he usually showed me what to do.»  (el "new style" sería  
"prohibido usar goto")

En otro artículo está más claro ("A review of 'Structured Programming'",  
comentarios al libro de Dijkstra de ese titulo, de 1973; no tengo URL a  
mano):

	«Whenever I'm trying to write a program without GO TO statements,
I waste an inordinate amount of time in deciding what type of iterative
clause to use (while or repeat, etc.). The reason is that our notations
aren't really complete. I know in my head what I want to do, but I have
to translate it painstakingly into a notation that often isn't well-suited
to the mental concept. I know I want to repeat something over and over,
and it's easy for me to give a step-by-step description; "first do α,
then β, then if γ we are done, otherwise do δ and we're in the same
situation we started." Now this is not suited to present
languages since I have to test γ either first or last, writing:

	α; β; while not γ do { δ; α; β }

or

	δ´; repeat { δ; α; β } until γ;

where I invent some trick δ´ inverse of δ.

Surely you must face the same dilemma. I really want to say is
something like:
	
	loop { α; β; if γ then exit; δ } end loop;

Since this is a frequent mental construct, in my experience, I believe
it deserves a suitable syntax. Otherwise we also find ourselves testing
the same condition twice.»

(Esto lo llama "bucle de N 1/2 repeticiones" y es justamente el  
while+break que tiene Python).

[1] "Structured Programming with go to Statements"
http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf

-- 
Gabriel Genellina


---------------------------------------------------------------------
Para dar de baja la suscripcion, mande un mensaje a:
   pyar-unsubscribe@decode.com.ar

Para obtener el resto de direcciones-comando, mande un mensaje a:
   pyar-help@decode.com.ar

PyAr - Python Argentina - Sitio web: http://www.python.com.ar/