Re: A controversial topic
- Posted by jimcbrown (admin) Feb 20, 2023
- 1487 views
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.
I think "larger" is the keyword here. There's nothing inherently wrong with aiming higher, but I'd rather not waste time designing something that no one is ever going to build.
You can see this with my experimental branches (for euphoria threads and for self modifying IL/eval statement) - when a useful idea is proposed, I like to flesh it out so others can play with it. But a lot of good ideas aren't so easily whiped up.
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.
Probably because that's what we were given to start with.
Though I've not made a secret about replacing OE with Phix outright (again echoing my point about RDS Eu bringing baggage and being hard to develop on).
I wasn't targetting mIRC, i was trying to bring together some concepts with Eu's less-restrictive sequences and faster speed.
Ah, gotcha. Even less reason to resist these concepts then!
I still believe in mIRC's .timers,
Not too familiar with these, but re: timers in general, I think it's a good idea. (On nix I emulate them by using system() to start a process in the background using the ampersand, which will sleep for the required interval and then send a signal to the Eu process afterwards.)
access to the var list,
Me too. I vaguely recall that you have access to this nowadays through the debug api, but perhaps a slicker, more developer friendly version wouldn't hurt.
test for and reading of functions,
Again, all for it - see the euphoria-eval branch I set up some years ago, which would support something like this.
and reloading of pseudo-include files during runtime.
My memory is vague but I think a long time ago, even before OE, I wrote a preprocessor called Dredge that would do something like this: basically it'd copy over an include file to a new temp name, then include it, and then call a procedure (to go back to the main code).
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.
For the record, I don't.
What have you got against reloading include files whenever desired?
As pointed out above, I don't. Heck, combine that with namespaces and we've got a poor man's OOP.
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.
I forget how much nicer nix is sometimes - I can instead wrap fork() and the shared memory api available on nix. If I need to worry about locking files and stuff I can also wrap flock().
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.
Not aware of any members of the developer team who did this.
Even of forum members, I only know of one case - the author of Nim. (Actually, the author of Nim would have been happy to continue talking about the development of Nim on this forum. But it also seemed clear to me that the author would have wanted to create Nim from scratch on his own regardless, it's not something we could have changed even if we invited the author to join the developer team.)
Not sure Phix counts either, as I believe petelomax started on it in the RDS Eu days - and no one can accuse him of running off from these forums.
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?
If you are referring to https://openeuphoria.org/forum/137604.wc
It's because the implementation was done in an incomplete way. (Another compromise that in hindsight...) We actually know the way forward on this (as Greg pointed out regarding the need to support JSON), but again ... volunteer effort.
This problem didn't exist until maps was added!
A bit like saying "Folks wouldn't be complaining about fire hoses being too short if we never got fire hydrants!" - technically true, but kind of missing the point. Fires will still burn things down in either case, what needs to be done is to finish the job by making fire hoses long enough to reach the fires from the hydrants.
LIkewise, in the above example, the OP likely would have been posting about how to store data in a map like structure if OE didn't have maps at all, and possibly even more effort to implement the answers (assuming something like EDS was out of the question for some reason).
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.
Whoops, my mistake - I meant to say "more flexible and allow variables, expressions, and etc"
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.
Aside from Eu itself, I have never worked with IRC in any of the languages mentioned in this thread. It's not very common nowadays.
I don't recall the "call for code" anymore, but I vaguely recall that there were multiple attempts to make one. jeremy had an Eu IRC client iirc that he was working to converting into a generic IRC library for the stdlib, and ryanj was looking to do something similar.
It was simply another situation where even the devs didn't have time to finish the projects that they started.
I wrote strtok.e, and it was re-written and functions dropped.
Perhaps, but not by the dev team. https://openeuphoria.org/forum/m/109731.wc
But you have maps.e.
As has been pointed out, maybe not entirely...
I extended tasks, and so what? <shrug> I most recently tossed out "fake classes" and "shared vars" and "named_vars".
Certainly, what you do with your own time and your own code is your own matter.
A decade ago, it wouldn't really have been of interest to the dev team until there was some actual code shared that could be integrated into the stdlib or the other parts of the language. Nowadays ... I mean, Greg's the one saying that more volunteers are required and essential.
Some people left to form new languages,
Like Nim. I think this was rare, just because it's not so easy to write your own compiler or lexer...
some quietly worked on run-arounds.
Like yourself. Less quietly, like myself (with the Dredge preprocessor) and dcuny (who did a lot of preprocessors in the RDS Eu days).
Few concepts were welcome,
Sorry for sounding like a broken record here, but again - the concepts themselves were welcome, but finding folks with time and experience to code them into the language was another matter.
and the contribution process got overy complex (<coff>spelling errors in source code</coff>),
Ironically, things like https://openeuphoria.org/forum/m/137385.wc were because of an experiment to simplify said process.
and knowing C was required.
Well, yeah, okay, you got me there. Even a guy as brilliant as Greg took years to get up to speed with OE's C internals, https://openeuphoria.org/forum/m/137253.wc
IIRC it wasn't solved, it was disallowed,
Ah right, task_yield() getting compiled out in std/net/http.e's execute_request()
which broke the point of handling the blocking of the entire program by http.e if the server hung.
That's .. not quite how it worked. The sockets library has a receive() method that respects a timeout. If the server hung, the receive() method would time out, no data would be received, and the routine would exit out and return.
Also, tasks are a form of cooperative multitasking, but the sockets library didn't play nicely with that - if receive() waited too long before timing out, there was no way for other tasks to continue in the meantime. That would have required preemptive multitasking - or threads.
Where the task_yield() was useful was to allow other tasks to run in between grabbing globs of data, if the http library was busy downloading a huge chunk of data in small bites. Other tasks get to run if we're downloading a big multigig DVD or something over the web.
I guess the reason this hasn't been a big problem is that most http stuff I've seen with Eu has been either fully interpreted, or only on nix if translated. On nix, the translated shared library can be loaded, then fork() can be called. The http call then runs inside the child process, without blocking the main code that runs in the parent process.
fork() is so useful.
BTW, another good reason to be able to unload malfunctioning include files.
Hey, you know me, I'm all for being as dynamic as possible.
(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
The only truth to the above quote is the "we have no contributers or developers" line. Concepts are open to discussion and most have been found to be welcome, and not everyone has to use new features like maps or regex or http, or even goto - but they still made it in.
While I would disagree, I can see how the dev team of, say, twelve years ago, with its vigorous debates, might give a wrong impression here.
But I don't see by any measure how you could say that petelomax or ghaberek are unwelcoming... (Phix and OE are both essentially one-person teams now)
Also don't forget, but we actually have a lot of common ground here: agreeing that requiring C is a bad thing, supporting a lot of nice features (eval, reloadable includes, timers, nonblocking http in a translated shared lib), etc.
