Re: A controversial topic

new topic     » goto parent     » topic index » view thread      » older message » newer message
jimcbrown said...
axtens_bruce said...

Before we answer that about Euphoria, answer it for

katsmeow said...

This is the wrong way to think of a language, unless you are making an extreme leap away from the norm.

I think this is reasonable - we're asking why those other languages made it when OE didn't - i.e., what's different from OE that moved it away from the norm?

I think it's like arguing over the physical design of a Phillips-type screw instead of why it's not a nail.

jimcbrown said...
katsmeow said...

arguing for uniqueness is a dead end.

Agree in part - effort is probably better spend moving the language to the norm first. Again, I think the lessons of Nim will be instructive here.

And here i am, still arguing for NOT-norm, to make a larger step.

jimcbrown said...
katsmeow said...

I recall introducing "string tokens", the fight against pretty much every word ("string") and meaning ("word" is like an atom) and origin (mIRC) and concept (Ai processing, small databases),

I don't really recall these - except for a vague recollection of why we'd want to target mIRC, a closed source and Windoze only system (and an IRC client rather than a language meant by its authors to be general purpose) - but again this was also in the RDS Eu days.

I wasn't targetting mIRC, i was trying to bring together some concepts with Eu's less-restrictive sequences and faster speed. I still believe in mIRC's .timers, access to the var list, test for and reading of functions, and reloading of pseudo-include files during runtime.

jimcbrown said...
katsmeow said...

and then it being picked up as a library in other languages,

Well, it's hard to stop the spread of good ideas. Also, why would we want to?

I don't know why you want to. What have you got against reloading include files whenever desired? Only way around the roadblocks i know of is truely globally shared variables between programs which can be shut down and restarted with new include files. And that is a can of worms due to locking and time constraints.

jimcbrown said...
katsmeow said...

I would not use OE without these two, but sadly everything outstanding that could be built on them is disallowed because it wasn't already allowed or no one needs it right this minute.

I'd disagree on both points - in general, the team was happy to accept patches, and of course pretty much everyone needed everything five minutes ago. The issue back then, and which is still the case today, is getting volunteer effort to build these things.

Yet developers ran off and formed their own languages.

jimcbrown said...
katsmeow said...

Sadly, when OE was formed, a lot of work was put into "eye candy", such as maps,

Actually, hashmaps has become a basic data type of most languages now (Java has HashMaps, Python has dicts, Ruby has hashes, and so on).

It wasn't so much about eye candy but about updating OE to the norm.

Then why, to this day, are people mentioning that maps doesn't solve their problems? This problem didn't exist until maps was added!

jimcbrown said...
katsmeow said...

or making case() better than any one else's case().

Ah, this one I remember well. There wasn't really a serious argument over this, it was more based on my misunderstanding on how other languages like C implement the switch-case statement, which lead me to question if we should do it like C and require hard constants/literals only for optimized speed or if it should be more flexible and allow variables.

Small thinking again. Why not allow variables, expressions, and etc? Let the compiler optimize for speed on a case-by-case situation.

jimcbrown said...
katsmeow said...

I looked down the list of "improvements" and was repeatedly saying "we don't need that",

Well, it was about modernizing and moving to the norm, so we could build the better things on top more easily....

I don't think so. A "call for code" was made for irc.e, and you still do not have one. I wrote strtok.e, and it was re-written and functions dropped. But you have maps.e. I extended tasks, and so what? <shrug> I most recently tossed out "fake classes" and "shared vars" and "named_vars".

jimcbrown said...
katsmeow said...

"too narrow of focus", etc etc..

... while trying to deal with the lack of volunteer effort.

Some people left to form new languages, some quietly worked on run-arounds. Few concepts were welcome, and the contribution process got overy complex (<coff>spelling errors in source code</coff>), and knowing C was required.

jimcbrown said...
katsmeow said...

I am not saying stuff didn't work (<coff>case, compiled tasks</coff>),

Ack on case. Don't recall an issue with compiled tasks (aside from in a translated shared lib, but the one known case where it came up (using std/http from a translated shared lib) the issue was resolved).

IIRC it wasn't solved, it was disallowed, which broke the point of handling the blocking of the entire program by http.e if the server hung. BTW, another good reason to be able to unload malfunctioning include files.

jimcbrown said...

(Unlike RDS Eu, the cases of OE and Phix are less about the "owners" disallowing changes but more about folks requesting features that no one has time and interest and ability to implement. Even so, with Phix the barriers are still easier to overcome for the reasons stated above. It's the nice thing about FOSS - if you disagree, you can fork the project's source code and do it yourself.)

Yes, not welcome here because i disagree, i am not going to use that, go start your own language. We have no contributors or developers!<sigh>

Kat

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu