1. Euphoria vs The Other Guys --- and RTFM
- Posted by _tom (admin) May 01, 2014
- 1851 views
How many people come to Euphoria after learning another language? Which becomes...how many people are confused by Euphoria because of lingering conventional ideas that are not Euphoric?
How valuable is a comparison between Euphoria vs Other Languages as part of the documentation?
Do we need cooked, baked, raw, and extra crispy explanations?
_tom
2. Re: Euphoria vs The Other Guys --- and RTFM
- Posted by jaygade May 02, 2014
- 1780 views
How many people come to Euphoria after learning another language?
In my experience, people come to Euphoria if they've known older dialects of BASIC such as QBasic and the like and people who aren't used to the edit-compile-link-execute process of other languages such as C. Additionally, many people come to Euphoria who are completely new to programming.
That's not to say that everyone, but it's probably the majority of any given sample.
I don't know how true this is any more, as fewer and fewer people have experience with older languages. Are we getting many more new users? Maybe we need some kind of user survey to truly answer the question.
Which becomes...how many people are confused by Euphoria because of lingering conventional ideas that are not Euphoric?
Can you expand on this question? To me, the central idea of Euphoria is pretty easy to grasp.
How valuable is a comparison between Euphoria vs Other Languages as part of the documentation?
I think that explaining to someone why they should try Euphoria instead of C or Python or Java is a good idea.
Do we need cooked, baked, raw, and extra crispy explanations?
_tom
Well-done explanations?
3. Re: Euphoria vs The Other Guys --- and RTFM
- Posted by _tom (admin) May 02, 2014
- 1781 views
Which becomes...how many people are confused by Euphoria because of lingering conventional ideas that are not Euphoric?
Can you expand on this question? To me, the central idea of Euphoria is pretty easy to grasp.
Euphoria does not have a string data-type--conventional background expects it. In the past, there have been requests that a string data-type be added to Euphoria--conventional wish. Data storage for a sequence and for a dedicated string are not the same--conventional thinking sees this as a problem. Truly automated output of text data does not exist...for example console:display will sometimes show you a small integer instead of a character--conventional thinking does not understand this.
Euphoria behaves as if it has a string data-type--but not with conventional thinking. Text data in a sequence has unexpected flexibility--not conventional.
sequence s = "Hello" s += 0.1 ? s --> {72.1,101.1,108.1,108.1,111.1} puts(1, s) --> Hello
So if you learn Python first, to what extent do you keep programing in Python when writing Euphoria code?
Also how much of my documentation is based on Fortran, PL/1, C, Pascal, APL, Snobol, ... ? How does this distort my explanations?
_tom
4. Re: Euphoria vs The Other Guys --- and RTFM
- Posted by jaygade May 02, 2014
- 1776 views
Euphoria does not have a string data-type--conventional background expects it. In the past, there have been requests that a string data-type be added to Euphoria--conventional wish. Data storage for a sequence and for a dedicated string are not the same--conventional thinking sees this as a problem. Truly automated output of text data does not exist...for example console:display will sometimes show you a small integer instead of a character--conventional thinking does not understand this.
Euphoria behaves as if it has a string data-type--but not with conventional thinking. Text data in a sequence has unexpected flexibility--not conventional.
I guess I understand, but I still think that it's a symptom of over-thinking. Strings can either be first-class entities or they can be lists of numbers. BASIC and C, and Euphoria, generally treat strings as lists of numbers which are only treated specially by I/O functions. One key difference is that Euphoria uses 32- or 64-bit integers instead of 8-bit integers. Given the amount of storage today's computers have, storage shouldn't be an issue.
If a user truly needs strings of 8-bit integers, there is functionality in the library which provides for using C-style and memory-allocated strings.
I've never used console:display so I can't answer to its behavior. I pretty much stick with 'puts', 'printf', and '?'.
sequence s = "Hello" s += 0.1 ? s --> {72.1,101.1,108.1,108.1,111.1} puts(1, s) --> Hello
I don't know why someone would do that, but they're not prevented from doing it. It really speaks to the flexibility of Euphoria. I might expect puts() to throw an error or a warning in such a case (receiving a float instead of an integer).
So if you learn Python first, to what extent do you keep programing in Python when writing Euphoria code?
Also how much of my documentation is based on Fortran, PL/1, C, Pascal, APL, Snobol, ... ? How does this distort my explanations?
_tom
Sorry for being dense, but I'm still not understanding the context of the question. My stating that explaining to someone why they should program in Euphoria instead of those other languages is already pretty well handled in the manual I thought -- correctness, speed, and syntax comparisons. There should only be one small section of the manual dealing with that as introductory material.
5. Re: Euphoria vs The Other Guys --- and RTFM
- Posted by mattlewis (admin) May 02, 2014
- 1744 views
I've never used console:display so I can't answer to its behavior. I pretty much stick with 'puts', 'printf', and '?'.
I tend to use it as a quick and dirty pretty print.
Matt
6. Re: Euphoria vs The Other Guys --- and RTFM
- Posted by _tom (admin) May 02, 2014
- 1676 views
Yes, lots of overthinking, and silly meta thinking.
The text example was too messy.
If I use puts and print for all my Euphoria examples then am I still programming in Euphoria 1.5 ? That explains why I have not tried updating the documentation for writef and writefln.
If I am thinking in Pascal then I should use writefln all the time because I like the "ln" part of the procedure?
If I use i,j,k for all my loops am I still programing in Fortran?
Should I complain if I think in Python
for i in range(4): print i
and can't write generators and ranges?
Ultimately how does this meta thinking mess up the documentation. How do I accomodate completely new programmers, and how do I provide documentation for most of you who know more programming than me?
_tom
7. Re: Euphoria vs The Other Guys --- and RTFM
- Posted by jaygade May 02, 2014
- 1756 views
Yes, lots of overthinking, and silly meta thinking.
The text example was too messy.
If I use puts and print for all my Euphoria examples then am I still programming in Euphoria 1.5 ? That explains why I have not tried updating the documentation for writef and writefln.
I do think that we should update our examples to use writef, writefln, and display.
If I am thinking in Pascal then I should use writefln all the time because I like the "ln" part of the procedure?
I actually like writef and writefln, I just haven't used them much because of habit and because of not having written much code lately.
If I use i,j,k for all my loops am I still programing in Fortran?
Isn't that an informal standard for loops, not just in Fortran? I learned those in BASIC and I still see them all the time in C as well. Most generic loop code that I see uses i,j,k and x,y,z. Sometimes n or m.
If your loop variable has a more specific meaning than just a counter then you would usually give it a more meaningful name.
Should I complain if I think in Python
for i in range(4): print i
and can't write generators and ranges?
No, of course not.
Ultimately how does this meta thinking mess up the documentation. How do I accomodate completely new programmers, and how do I provide documentation for most of you who know more programming than me?
_tom
Write the documentation for new or intermediate programmers. Don't assume experience in any other language. Old programmers can skim over the basics and get to the meat of what sets Euphoria apart.
IMO.
8. Re: Euphoria vs The Other Guys --- and RTFM
- Posted by DerekParnell (admin) May 02, 2014
- 1741 views
I tend to use it as a quick and dirty pretty print.
That was my intention. It's not really intended to be used as a serious output tool. I wrote writef() for that purpose.
9. Re: Euphoria vs The Other Guys --- and RTFM
- Posted by DerekParnell (admin) May 02, 2014
- 1730 views
How many people come to Euphoria after learning another language? Which becomes...how many people are confused by Euphoria because of lingering conventional ideas that are not Euphoric?
Euphoria was certainly not my first programming language. Before it I'd programmed in COBOL, PL/I, IBM-360 assembler, Motorola assembler, Intel assembler, Pascal, C, C++, BASIC (many flavors), Lisp, Forth, UFO, Progress, Autocoder, and dabbled in a few others.
How valuable is a comparison between Euphoria vs Other Languages as part of the documentation?
If at all, maybe just a sidebar note. Euphoria has a couple of very different concepts to most other languages, but everything else (conceptually) is pretty stock-standard.
Do we need cooked, baked, raw, and extra crispy explanations?
Not at all. The purpose of these various ways to encode literal text inside one's program text is to make coding easier to write and to easier to read. They are not there to improve algorithms.
10. Re: Euphoria vs The Other Guys --- and RTFM
- Posted by jaygade May 02, 2014
- 1706 views
Do we need cooked, baked, raw, and extra crispy explanations?
_tom
Well-done explanations?
To be clear, I thought that _tom's last bit here was a joke which is why I responded in kind. I hope that my half-baked attempt at humor didn't cause any confusion.
11. Re: Euphoria vs The Other Guys --- and RTFM
- Posted by DerekParnell (admin) May 02, 2014
- 1692 views
Euphoria does not have a string data-type--conventional background expects it. In the past, there have been requests that a string data-type be added to Euphoria--conventional wish. Data storage for a sequence and for a dedicated string are not the same--conventional thinking sees this as a problem. Truly automated output of text data does not exist...for example console:display will sometimes show you a small integer instead of a character--conventional thinking does not understand this.
Euphoria behaves as if it has a string data-type--but not with conventional thinking. Text data in a sequence has unexpected flexibility--not conventional.
Hmmmm... your definition of conventional might be an issue. Many programming languages do not have a purpose built-in string datatype, though most recent ones do.
Euphoria, like all programming languages, makes compromises. Euphoria attempts to prioritise execution speed over complex datatypes. We could create a built-in string type in Euphoria, but the immediate effect will be to slow down all programs ... even ones that don't use the string type. This is because of the object concept in which many data access decisions are made at runtime by Euphoria.
Obviously, a string datatype is not actually required because you can achieve everything right now in Euphoria, so what would it gain if it had one? Less bugs - maybe. Better parse-time error reporting - possibly.
Its a discussion worth having and probably documenting in the manual.
12. Re: Euphoria vs The Other Guys --- and RTFM
- Posted by _tom (admin) May 02, 2014
- 1689 views
I rather like raw/cooked as an antonym pair; I hope to keep it in the documentation. But, the whole idea is to get some discussion going. I respect anyone who can come up with a "Well-done explanantions?" retort.
So far "conventional" vs "Euphoria" is my way of looking different languages and seeing what there is to be learned.
I am partial to the idea that documentation should not refer to outside sources and languages.
I'm a bit intimidated by writef, so its going to take some time figuring out the syntax.
In my first look at text data I was locked into the old idea that one byte was one character; that makes indexing a character in a string very easy. UTF-8 results in variable length encodings; indexing individual characters in Euphoria is no longer fun. In a Python3 string: x = "▒∆ Hello", printing x[1] produces ∆, which is {226,136,134}. How is Euphoria going to evolve to get a similiar convenience?
_tom
13. Re: Euphoria vs The Other Guys --- and RTFM
- Posted by DerekParnell (admin) May 03, 2014
- 1657 views
In my first look at text data I was locked into the old idea that one byte was one character; that makes indexing a character in a string very easy. UTF-8 results in variable length encodings; indexing individual characters in Euphoria is no longer fun. In a Python3 string: x = "▒∆ Hello", printing x[1] produces ∆, which is {226,136,134}. How is Euphoria going to evolve to get a similiar convenience?
It's easy. A unicode string in Euphoria is just one element = one code point, where each element is a 32-bit integer. In other words, unicode strings in Euphoria are held in a sequence using UTF32 encoding. We would have functions that convert to and from other UTF encodings. So in your example above, the resulting sequence would be {38424, 34576, 72, 101, 108, 108, 111}
Of course, I'm speaking about future functionality as it currently doesn't support unicode source text.
14. Re: Euphoria vs The Other Guys --- and RTFM
- Posted by jimcbrown (admin) May 03, 2014
- 1635 views
Of course, I'm speaking about future functionality as it currently doesn't support unicode source text.
I think we agreed that we'd eventually use something like http://site.icu-project.org/ to handle the unicode implementation in the backend. Technically, Euphoria already has limited UTF-8 support as source text (though not for routine/variable names), but none at all for UTF-32 or UTF-16 encoded files.
Of course, if someone needs to have the capability to do unicode conversion "right now", they can use and adapt http://scm.openeuphoria.org/hg/euphoria/file/9ab1491bf4a0/include/std/unicode.e (written by Derek) to suit their needs.
15. Re: Euphoria vs The Other Guys --- and RTFM
- Posted by SDPringle May 03, 2014
- 1529 views
As to what is 'Euphoric'. You need to define this. Strings are easily implemented as a UDT. If added as a builtin type, you would only need to modify the parser part. I disagree with making something builtin when you can do something in user code, efficiently.
Naming conventions is not something we really enforced or made up. We have lowercase routines and upper case constants. The lowercase words consist of English words with underscores separating them.
We have 'create_directory' and 'clear_directory' and all sorts of routines named this way. Why on earth do have a routine named 'chdir'?
We mostly follow this convention of using complete words but we sometimes take things from C and break the convention: 'getenv' and 'sizeof'. When these ought to be 'get_environment' and 'size_of'. Another is 'sqrt' instead of 'square_root'.
The regular expression routines which scan strings for string patterns have 'find' in them, whereas find is for seeking members of a sequence and match is for searching sub-strings. They really ought to have been named with 'match'.
There is one routine that returns the year as years since 1900. Who was born in 1900?
Finally, the ifdef/endif syntax forces the user to think of two distinct symbol tables when programming. The ifdef usage doesn't help the user with spelling mistakes. One, however, can use platform() and version() somewhere in std/*.e to do the same thing. Yes, I know, it is slower though.
In spite of these warts, working with a string is the same as working with a sequence of integers, or a sequence of anythings.
S D Pringle
16. Re: Euphoria vs The Other Guys --- and RTFM
- Posted by DerekParnell (admin) May 04, 2014
- 1475 views
... Strings are easily implemented as a UDT.
Not quite. UDT have some restrictions. They are only used during assignments or explicit if UDT(x) tests. We can't tailor other operations to deal with UDTs, nor can we arbitrarily have existing library functions know what to do with a UDT when they encounter one. That, of course, also applies to built in types too.
If added as a builtin type, you would only need to modify the parser part.
Actually, it turns out to be a lot more complicated than that. A new built-in type has semantic implications that would undoubtedly affect nearly every aspect of the existing language operations.
... working with a string is the same as working with a sequence of integers, or a sequence of anythings.
Again, only if you are talking about sequence operations, but even then we would need to add some extra semantics to some operations. For example, adding an atom to a String type should do what, exactly? Issue a runtime error, maybe? Then there's the whole complication of how to output String data. If the string is going to a console device, we would probably need to convert it to UTF8. But what about out to a file? Or output to a windowed applications - UTF16 or ASCII? Now consider functions like upper() etc, these need special handling for unicode strings.
Forked into: Integrating string types into EUPHORIA handling
