Re: Python has Traps; Does Euphoria have Programming Traps?
- Posted by jaygade Aug 13, 2013
- 2288 views
Thanks for expanding my understanding...
So far I see Python (a teaching language) has more programming traps than Euphoria.
The Python Division Trap is found in Python2.7; Python3 has fixed the problem by introducing the // operator for integer division (but is not in common use.)
The Python Octal Trap is nasty since we normally teach everyone that a zero before a number does not change its value.
I wish it didn't do that:
- puts crashes when some text is nested in a string
- puts behaves as described, still a common error
- can't use = to compare strings or sequences
- probably a common wish-list idea
- needs more emphasis in the documentation
- self-modifying loops
- expect them to work instead of crashing
- better examples and explanations needed
- short-circuit evaluation
- the different actions for conditionals and expressions is documented
- but, my head hurts before I finish reading
- input and output in Euphoria is different from conventional language
- need and automagic output routine
- display is a bit of a monster
- no string data-type
- novices sometimes complain, not understanding how Euphoria works
Documentation at fault? It it crashes it is not a "trap."
In a "for structure" the start and finish limits are locked-in at the time of writing; changing a for loop into an infinite loop while running is a bad idea. ( The "Python for structure" doesn't work any better. It also looks Python designers even created immutable data-types to prevent self-modifying code. )
The descriptions and examples for looping structures need a make-over.
TOM
I actually like display -- it's a bit of a monster but it's easier to use than puts/printf when you want mixed text output.
Input is simple enough too -- use "gets". I'm not sure if there is an input equivalent to "display" though. That might be nice.
I think that input and output is a bit simpler in Euphoria compared to some languages (C).
I'm not sure about your comment with regards to for loops -- the example given by ~SDPringle is an error not because the for loop structure changed but because the length of the sequence changed. The loop counter going past the new length of the sequence is the error no matter what the end limit of the for structure is. Still, it should be pointed out as a possible unexpected error (and that modifying the end condition of a for-loop is bad practice -- use a different kind of loop).
Edit: Yes, that reverse loop is an elegant solution.
Since I've been playing around a bit with sorting (with very little success), I've had some ideas on sequence comparisons which I'll have to present. Ideas which we've hopefully not hashed over millions of times before.
Edit: I agree about the essay on floating point numbers;they can cause a lot of confusion.
I believe there are already many programming-related ones available on the internet, especially with regards to C and comparing for exact values.