Re: Constructive criticism
- Posted by jimcbrown (admin) Mar 06, 2009
- 1149 views
Here we go again...
"By basing Euphoria on this one, simple, general, recursive data structure, a tremendous amount of the complexity normally found in programming languages has been avoided. The arrays, structures, unions, arrays of records, multidimensional arrays, etc. of other languages can all be easily represented in Euphoria with sequences. So can higher-level structures such as lists, stacks, queues, trees etc."
Well, general graphs cannot be easily represented in EU with sequences, IMHO. But since it does not mention graphs explicitely, I can live with the paragraph.
I have to agree with you here. It is possible, but it isn't intuitive, and argubly is rather ugly.
OTOH, you could always use allocate() and free() and peek4s() and poke4() and use pointers - then your graphs are also readable from C.
"Furthermore, in Euphoria you can have sequences of mixed type; you can assign any object to an element of a sequence; and sequences easily grow or shrink in length without your having to worry about storage allocation issues. The exact layout of a data structure does not have to be declared in advance, and can change dynamically as required. It is easy to write generic code, where, for instance, you push or pop a mix of various kinds of data objects using a single stack."
Lack of pass by reference makes a stack harder to write...
Hmm. I've never used PBR to write a stack, so I'll have to take your word for this.
"Making a flexible list that contains a variety of different kinds of data objects is trivial in Euphoria, but requires dozens of lines of ugly code in other languages."
Well, it is easy in JavaScript, Python, Lua, Lisp, Smalltalk, etc. The thing is called dynamic typing. Many languages have it nowadays. - Outdated.
Concurred.
"Data structure manipulations are very efficient since the Euphoria interpreter will point to large data objects rather than copy them."
Copy-on-write does not avoid all copies. - Misleading.
As a native english speaker, I don't see much difference between the above and this:
"Data structure manipulations are very efficient since the Euphoria interpreter will point to large data objects rather than copy them whenever possible."
"Programming in Euphoria is based entirely on creating and manipulating flexible, dynamic sequences of data. Sequences are it - there are no other data structures to learn. You operate in a simple, safe, elastic world of values, that is far removed from the rigid, tedious, dangerous world of bits, bytes, pointers and machine crashes."
True - if you do not interface with external libraries. - Misleading.
The standard library provides plently of routines that safely handle this. (See safe.e)
Even when we do crash due to external libraries, Eu is usually able to tell you that the crash occurred outside of your euphoria code, and what line of that code made the call to the external library.
"Unlike other languages such as LISP and Smalltalk, Euphoria's "garbage collection" of unused storage is a continuous process that never causes random delays in execution of a program, and does not pre-allocate huge regions of memory."
Outdated - LIPS and Smalltalk have better GCs nowadays. Use Java as an example. One needs to tell JVM how much memory the program is going to use.
Concurred. I've personally had experience (and many headaches) with GC issues in Java.
"The language definitions of conventional languages such as C, C, Ada, etc. are very complex. Most programmers become fluent in only a subset of the language. The ANSI standards for these languages read like complex legal documents."
That suggests that one learns a language by reading an ANSI standard. - Misleading.
I disagree. It states that most programmers become fluent in only a subset...
With the expanded language of 4.0, this section becomes misleading. But I think it is accurate as of 3.1.1
"You are forced to write different code for different data types simply to copy the data, ask for its current length, concatenate it, compare it etc. The manuals for those languages are packed with routines such as "strcpy", "strncpy", "memcpy", "strcat", "strlen", "strcmp", "memcmp", etc. that each only work on one of the many types of data."
That refers to C only. EU has a similar problem with "equal" vs. "=". - Misleading.
I agree with the first part (C only) but disagree with the second (as equal() works with everything).
Much of the complexity surrounds issues of data type. How do you define new types? Which types of data can be mixed? How do you convert one type into another in a way that will keep the compiler happy? When you need to do something requiring flexibility at run-time, you frequently find yourself trying to fake out the compiler.
Maybe for C or some other statically typed languages. - Misleading.
I agree that this paragraph seems to target C.
In these languages the numeric value 4 (for example) can have a different meaning depending on whether it is an int, a char, a short, a double, an int * etc. In Euphoria, 4 is the atom 4, period. Euphoria has something called types as we shall see later, but it is a much simpler concept.
Well, 4 never is an "int*" and never was - even in 1993. - Wrong.
Back in 1993, the i386 was only a few years old. Many programs were still 16bit. Back then, an int* with a value of 4 could point to a valid memory location. (Today, if you are writing OS code on the x86, it is still possible to use (int*)4 as a valid pointer.)
It is bad practice, but this is a valid operation. DOS apps written in C still use this method to access video memory.
Issues of dynamic storage allocation and deallocation consume a great deal of programmer coding time and debugging time in these other languages, and make the resulting programs much harder to understand. Programs that must run continuously often exhibit storage "leaks", since it takes a great deal of discipline to safely and properly free all blocks of storage once they are no longer needed.
The thing is called garbage collection and most languages have it nowadays. And Smalltalk and Lisp definitely had it in 1993. - Wrong, outdated and misleading.
I can't say for sure, but I'd reckon that Lisp's good GC came after 1993. (As Matt Lewis pointed out, earlier versions of Lisp did not have a perfect GC.) As I've personally experienced a situation where Java's GC lead to a memory leak (and eventually a server crash due to OOM), and that this occured in 2008, I don't see this as outdated, wrong, or misleading.
Pointer variables are extensively used. The pointer has been called the "go to" of data structures. It forces programmers to think of data as being bound to a fixed memory location where it can be manipulated in all sorts of low-level, non-portable, tricky ways.
Well, that is exactly what EU's implementation does:
Irrelevant. Who cares? The average EU programmer doesn't deal with EU's implementation of native EU datatypes.
If yout cast pointers to integers and store your type information in the lowest bits in the pointer, you violate ANSI C. But it does not follow that this is generally needed when programming in C.
This is correct. However, it doesn't account for the number of times that programmers (even experienced ones) end up shooting themselves in the foot because of accidental pointer misuse.
"A picture of the actual hardware that your program will run on is never far from your mind. Euphoria does not have pointers and does not need them."
Well, for cyclic object structures, you have to work around the lack of references and pointers by using an index. So arguably, EU needs them just like any other programming language.
Why does EU need cyclic object structures?
(EU already has a way to create and use pointers that are compatible with C, can simulate pointers in an ugly manner using indices, and 4.1 will probably have pass-by-reference - which, like Java, will not require the use of explicit pointers.)
