1. RE: What we really need...
- Posted by thomas at columbus.rr.com Nov 12, 2002
- 425 views
Maybe some of it has to do with the web site? I personally think that it could use a bit of tuning up, and that it doesn't look too hot right now. You can compare it to the resources like www.perl.com and java.sun.com. You can go there and immediately they look more established because of their web presence. Their languages could be pieces of crap, but perl.com especially immediately has more reference material and white paper than I can shake a stick at. I think improving the web site may just help draw more people into those "Download" links than one might expect. Just my two cents. ~Tom -----Original Message----- From: irv at take.maxleft.com [mailto:irv at take.maxleft.com] Sent: Tuesday, November 12, 2002 4:04 AM To: EUforum Subject: What we really need... Do we need a 'killer app' to make Euphoria more popular? I say no. No, because most people do not know or care what language their applications are written in. Would you stop using your favorite and most productive app just because you discovered that it had been written in VisualWhooPas-2.0? Didn't think so. No, because any competent programmer knows that any app can be written in any language. What matters is _how easily_ it can be written in a given language. What DO we need? To make Euphoria more popular among programmers ~ who else is going to use it? ~ we need to honestly evaluate where Euphoria excels, and where it fails. RDS has done a good job of emphasizing Euphoria's strong points: speed and simplicity, but speed and simplicity apparently aren't enough. Consider Perl, Python, Java, Ruby, Rebol..... Euphoria is smaller and faster than any of the above. Euphoria is more readable than perl or java, and (arguably) python and ruby as well. Yet perl, python, java and ruby each have 10, 100, 1000 times as many users as Euphoria. Why? If you really expect Euphoria to be more popular, you'll have to be able to answer that question. Let's see what you think. Regards, Irv ==^^=============================================================== This email was sent to: thomas at columbus.rr.com --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.410 / Virus Database: 231 - Release Date: 10/31/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.410 / Virus Database: 231 - Release Date: 10/31/2002
2. RE: What we really need...
- Posted by Ray Smith <smithr at ix.net.au> Nov 12, 2002
- 411 views
David Cuny wrote: [snip] > My conclusion: both occupy a niche that there doesn't have a lot of > demand. > People seem to prefer more features and bloat over faster execution. The > same > features that make Euphoria attractive to the current user base make it > unattractive to the larger programming community. > > Is this necessarily a problem to be solved? As long as the user base is > sufficient to support Robert, I'm not sure that there's an issue here. > > -- David Cuny I agree ... developers aren't worried about bloat, who cares if it's a 10MB (or even 50MB) download to install a development system. Who cares if the software you write needs a 5MB or 10MB install and will only run on a PII PC with 64MB ram (except Igor :)). I'm becoming a Python advocate ... and everyone says Python is very very slow ... full blown applications are written all the time in 100% Python without speed issues. Google is (I beleive) mostly written in Python. The speed and memory of PC's and the speed of the internet are all expanding faster than bloat and slow speed of development tools. THE REAL ISSUE IS ... How easy (or difficult) is it to develop my apps. This is the highest priority for developers when deciding on a development tool. All other issues are secondary ... speed, size, etc Ray Smith http://rays-web.com
3. RE: What we really need...
- Posted by Ray Smith <smithr at ix.net.au> Nov 12, 2002
- 425 views
irv at take.maxleft.com wrote: [snip] > Consider Perl, Python, Java, Ruby, Rebol..... > Euphoria is smaller and faster than any of the above. > Euphoria is more readable than perl or java, and (arguably) python and > ruby > as well. The reason??? Perl, Python and Ruby are 100% free and open source. Many people add features, apply patches and make improvements. Because they are open source they exist on almost every OS ever invented! Java is being developed, supported and promoted by almost all the big computer companies in the world. Probably hundreds ... no ... thousands of people are involved in its development and promotion. Lesser issues but still important ... there are basically no tutorials or documentation to help people learn to use Euphoria. One killer app won't make a difference ... maybe 10 solid apps would. I like Python ;) ... When Python people say Google runs on Python, or these 50 commercial web sites, or these 100 commercial applications are written in Python it matters. I dare anyone who hasn't looked at the Python code repository ... the "Vaults of Parnassus" (http://www.vex.net/parnassus/) to go there and tell me they aren't impressed. Or browse the online builtin module list of Python at ... http://python.org/doc/current/modindex.html Want to connect to any of the databases at http://python.org/topics/database/modules.html using a standard API? Anyone interested in web programming http://python.org/topics/web/? This is the work of many dozens (probably hundreds) of people over a very long period of time. As a note ... much of this work is done in a commercial environment and given back to the community because Python was given to them! The current Euphoria business model will never compete with these languages. Anyone who wants Euphoria to be anything that it currently isn't will be very disappointed. Saying all that I still like Euphoria, if Euphoria can do the job you want that's great, if it can't do what you want and "you personally" can't make it do what you want, then it most likely won't do what you want in the near future. Everyone makes their own choice. My comments might sound negative (and they are) ... nothing I have seen in the last 3 or 4 years makes me believe Euphoria in the future will be anything different to what it is now. (Yes the number and quality of Euphoria libraries are improving but at a slower rate than the competition ... it will never catch up) Ray Smith http://rays-web.com
4. RE: What we really need...
- Posted by stabmaster_ at hotmail.com Nov 12, 2002
- 437 views
>And considering that the majority of Eu's new users, are novice >programmers, there is no learning materials available. Refman.doc and Library.doc provide quite sufficient information about Euphoria. As for the novices you're talking about; what they need is probably info on programming in general (the concept of variables, flow-control, subroutines etc), and I don't see that as "our" responsibility to provide. However, maybe RDS ought to simplify for those wanting to do Win32 programming by shipping win32lib and an IDE (Judith's or an own-made) with the Ex/Exw package.
5. RE: What we really need...
- Posted by Don Phillips <EuNexus at yahoo.com> Nov 12, 2002
- 428 views
> > Maybe some of it has to do with the web site? I personally think that it > > could use a bit of tuning up, > > Isnt that funny, I said the very same thing years ago. > Get rid of the "PINK" on the site and the "Gay" swash > that resides around the Euphoria name. and things may pickup > BTW, No offence to the openly Gay community. Naa, some of my most popular sites which contain really top notch software that I frequent have *horrible* websites. I dont *go* there for the web site. I go there for the software. I could care less how a particular page looks. > 10) And Don Phillips EuNexus Project or MEdit > a) ofcource Don would need to get rid of that MSC .dll he uses a) <<-- Hah! Fat chance =) Main reason why... convenience. Win32Lib does a superb job of hiding the details of what is going on behind the scenes. API programming is not for the faint of heart. There are more constants, data types, and structures than you can shake a stick at. I have one file at home *one*, which is about 55k full of nothing but constants. Nothing else. Point? It is easier for me to code API in just about any other language than Euphoria because of structure support. Heck, the top three assembly languages I use all have structures. I find it unfortunate that Windows is so reliant on these things. I find it even more so that Euphoria does not directly support them. Trying to program API structures with Euphoria is like pulling teeth. If done directly via peeks and pokes, its nice and fast. Its also hard to read and maintain. You can use a library to hide the details (many to choose from; I even have my own), but you trade readability for speed. I needed both for the editor portion thus the code resides in a DLL.
6. RE: What we really need...
- Posted by Bernie Ryan <xotron at bluefrognet.net> Nov 12, 2002
- 435 views
irv at take.maxleft.com wrote: > Consider Perl, Python, Java, Ruby, Rebol..... > Euphoria is smaller and faster than any of the above. > Euphoria is more readable than perl or java, and (arguably) python and > ruby > as well. > > Yet perl, python, java and ruby each have 10, 100, 1000 times as many > users > as Euphoria. Why? If you really expect Euphoria to be more popular, > you'll > have to be able to answer that question. > > Let's see what you think. > Regards, Irv: You will also notice that most of the above langauges are included with the common distributions of LINUX. Bernie
7. RE: What we really need...
- Posted by Don Phillips <EuNexus at yahoo.com> Nov 12, 2002
- 423 views
> Ive been writting in C and using Masm32 myself and this Euphoria snippet > is what I use to make code smaller and faster. Just a very small snipp.. > > constant > sizeof_trm = 32 -- Size of trm structure > > atom trm > trm = allocate(sizeof_trm) > mem_set(trm,0,32) > > constant > trm_Op = trm + 0, -- Tsunami operation number > trm_File = trm + 4, -- Tsunami file handle > trm_DataPtr = trm + 8, -- Address of data buffer > trm_DataLen = trm + 12, -- Length of data buffer > trm_KeyPtr = trm + 16, -- Address of key buffer > trm_KeyLen = trm + 24, -- Length of key buffer > trm_KeyNo = trm + 28 -- Key number > > ->>>> is definatly better than > > trm_Op = allocate(4) > trm_File = allocate(4) > trm_DataPtr = allocate(4) > trm_DataLen = allocate(4) > trm_KeyPtr = allocate(4) > trm_KeyLen = allocate(4) > trm_KeyNo = allocate(4) > > and then peek4( ) each time you need access to a particular part of the > struct sucks. > Also, when you peek or poke a value you eliminate the extra "addition" > (+) > required > e.g, poke4(trm + trm_Op,val) -- why not do this only once at the start > of > your proggy. > > Maybe this is hard for some to understand but for me this seems easier > and > besides > is obviously faster with less messy code. Yes, that method (besides maybe immediate values) would be the fastest you can get. However, while this might be the fastest, it makes it harder to use as name reuse is not possible defining constants in that manner. This is a fine practice (imo) for your own structures or simply several wrappers, but for something like the API I dont want to have to constantly have to go back and forth to find which constant I used for which definition. I would like the names to be exactly the same as in the API reference so I only have to look them up once. Doesnt really matter though. I can program either way with almost no slowdown at all. Besides, I created a new library for myself which deals with exactly this problem. I plan on using it in all my future proggies that I submit so its really a non issue. Masm32 is nice and simple. I (now) prefer FASM over Masm32 now that I completely understand how the stack frame works and how I can manipulate it. I post to the board all the time. You probably seen alot of my posts over there and didnt even know it :P Don
8. RE: What we really need...
- Posted by thomas at columbus.rr.com Nov 12, 2002
- 445 views
> Naa, some of my most popular sites which contain really top notch=20 > software that I frequent have *horrible* websites. I dont *go* there=20 > for the web site. I go there for the software. I could care less how a=20 > particular page looks. You may not go to the web site for the web site itself, but I tend to see a web site like the front of a building. If you see a fa=E7ade that looks like it hasn't been touched for 5 years, it's not going to matter that there are freshly baked cookies behind the broken glass and spider webs. I think that if we can get a better layout for the site that promotes the archive, support (chat and forums) and learning materials a bit more, then there's a better chance of people staying at the site and learning more about the language before pounding into the download link thinking it's a miracle language. It's not, but it *is* extremely powerful. ~Tom Reinhart --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.410 / Virus Database: 231 - Release Date: 10/31/2002 =20