Re: Constructive criticism
- Posted by kinz Mar 07, 2009
- 1165 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.
OK, so 2.3 section is not totally outdated or wrong already. Good.
Try please this to be sure:
http://www.algorithmic-solutions.info/leda_guide/graph_algorithms/maxcard_matching.html
"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...
OK, so 2.3 section is not totally outdated or wrong twice. Very good.
Ask the EU community for the code of a stack you need.
"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.
But "trivial" and "easy" are different things. Then, "1993" and "nowadays" are different things too. Then, many languages still do not have this feature nowadays. Then, this feature itself can not be outdated at all, it is very useful feature, and EU is one of the very first languages with trivial using of this feature.
So, 2.3 section is not outdated or wrong here and never will.
"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.
OK, but "large data objects" is not "all" objects, so just read please the docs carefully to avoid just yours mistake.
So, 2.3 section is not Misleading here and never will.
"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.
So, 2.3 section is not outdated or wrong here. Then, external libraries (of .dll form) are just from that "dangerous world of bits, bytes, pointers and machine crashes". Just avoid them, read please the docs carefully to avoid just yours mistake.
So, 2.3 section is not Misleading here and never will.
"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.
Sorry, LISP and Smalltalk families, both, consist of dozens of different versions, implementations, variants and packages. Give us, please, one LISP and one Smalltalk for DOS32, WIN32, Linux, FreeBSD, OSX to see if their GCs were and are so good as in EU from 1993 to nowadays.
Not sure?
So, 2.3 section is not outdated and never will.
"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 do not see any suggestion here. It seems to be just yours mistake again.
So, 2.3 section is not Misleading here and never will.
"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.
To C only? The main language for the system coding is now *only*? There are dozens of different C and similar languages-derivatives.
In EU, anyone can use "equal" instead of "=" to compare atoms, is it
a problem to you?
So, 2.3 section is not outdated or wrong here and never will.
Same about Misleading.
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.
Not sure?
Try Basics please for yet another examples.
Just yours mistake.
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.
Ok, ok, maybe you are right here, I'm not sure, let's delete the letters
"an int *", just 8 letters, just as typo, just for you.
But you have to explain us why 4 can not to be a pointer.
But the paragraph still is good, not outdated, not wrong, I think.
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.
Again Smalltalk and Lisp, again nowadays, again 1993 ...
OK, I'll reuse my objections too.
Sorry, LISP and Smalltalk families, both, consist of dozens of different versions, implementations, variants and packages. Give us, please, one LISP and one Smalltalk for DOS32, WIN32, Linux, FreeBSD, OSX to see if their GCs were and are so good as in EU from 1993 to nowadays.
Not sure?
So, 2.3 section is not wrong, outdated and and misleading here.
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: 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.
Ok, 2.3 section is not wrong, outdated and and misleading here.
This section is not about EU's source code at all.
"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.
EU is not a language for the system programming, remember please.
Do you see that you seem to be almost totally wrond on 2.3 section, sorry?
EU docs need to be updated, sure, but the existing docs are not wrong,
are not totally outdated as you say, and are not misleading.
Tom hardly and nicely works on docs.
Regards,
Igor Kachan
kinz@peterlink.ru