Enlightened
-
@boomzilla said in Enlightened:
This seems like one of those "pick a better algorithm" times where if exception handling is a performance problem then you have bigger problems.
Not actually true. It's one of these things which is very much true at the level of writing ordinary code, but isn't quite so clear-cut once you get into writing an optimising compiler. Instead, it's probably better there to transform the code into something with a system of tracked failures as that would let you drop generating the exception at all in some circumstances (especially after few rounds of aggressive inlining); the exception can be fully instantiated if passes across a boundary of the system being analysed, which might or might not be a function…
-
@dkf said in Enlightened:
In general, the result of a subprogram can be any type, but there's a type with only one value (sometimes called
unitorvoid) that is produced when the subprogram only has side effects.Ugh. Can we please drop the term "side effects" from our vocabulary already? It's a FUD term pushed by dogmatic-FP types to try to make effects look scary by implicitly comparing them to medical side effects. The thing is, medical "side effects" are literally side effects: other things that happen "on the side" in addition to the effect you wanted. In programming, so-called "side effects" are the effect you wanted. We already have a term for things that happen "on the side": bugs.
-
@masonwheeler said in Enlightened:
Ugh. Can we please drop the term "side effects" from our vocabulary already? It's a FUD term pushed by dogmatic-FP types to try to make effects look scary by implicitly comparing them to medical side effects.
Seems like a useful and obvious term to me.@masonwheeler said in Enlightened:
The thing is, medical "side effects" are literally side effects: other things that happen "on the side" in addition to the effect you wanted. In programming, so-called "side effects" are the effect you wanted. We already have a term for things that happen "on the side": bugs.
Side effects in code are often things you didn't realize were going on and do lead to bugs.
This sounds like a personal problem to me.
-
@masonwheeler said in Enlightened:
Ugh. Can we please drop the term "side effects" from our vocabulary already? It's a FUD term pushed by dogmatic-FP types to try to make effects look scary by implicitly comparing them to medical side effects.
I doubt anyone would consider the people in the C++ standardization committee dogmatic-FP types, and they define it in the standard as
Reading an object designated by a volatile glvalue (3.10), modifying an object, calling a library I/O function, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment.
While changes in the state of the execution environment are the goal of any program, as otherwise there's no evidence that the program ever ran, there is still value in defining the term and differentiating it from a regular operation. In particular, the optimizer is free to perform any change to the code as long as the side effects remain the same. The connotation of a side effect being negative is only in your head, and side effect is more concise than "change in the state of the execution environment".
-
@kian said in Enlightened:
I doubt anyone would consider the people in the C++ standardization committee dogmatic-FP types
No, they're just morons, as evidenced by them being on the standardization committee for a language as horrible as C++.
While changes in the state of the execution environment are the goal of any program, as otherwise there's no evidence that the program ever ran, there is still value in defining the term and differentiating it from a regular operation.
Which is what I did. "A regular operation" is an effect. As you said, otherwise there's no evidence the program ever ran.
In particular, the optimizer is free to perform any change to the code as long as the
sideobservable effects remain the same.FTFY
The connotation of a side effect being negative is only in your head
No, it's really not. Ask anyone who's not really deep into programming what "side effect" means, and you'll see it's in their heads as well.
-
@kian said in Enlightened:
In particular, the optimizer is free to perform any change to the code as long as the side effects remain the same.
Which is why it's sometimes useful to be able to tell the compiler that a function doesn't have observable side effects (other than returning a value).
Example.
bis called exactly once because the compiler knows (via the non-standard__attribute__((const))) that the function only returns a value and that this value only depends on the arguments.aon the other hand needs to be evaluated each iteration. (Unfortunately only clang seems to do that particular optimization.)
-
@masonwheeler said in Enlightened:
Can we please drop the term "side effects" from our vocabulary already?
No. It's a well-defined technical term in language semantics and isn't doing anyone any harm. In particular, it doesn't carry any negative connotations beyond limiting the number of optimisations that may be performed (as operations that have side effects can't be safely removed or reordered).
-
@cvi said in Enlightened:
Which is why it's sometimes useful to be able to tell the compiler that a function doesn't have observable side effects (other than returning a value).
That's only really useful where the compiler can't see the true definition of the function. When the compiler can see the whole truth, it can work out for itself (most of the time) whether there are side effects.
-
@dkf said in Enlightened:
When the compiler can see the whole truth, it can work out for itself (most of the time) whether there are side effects.
Presumably it errs on the side of assuming there might be side effects if it can't prove there are none?
-
@jaloopa said in Enlightened:
@dkf said in Enlightened:
When the compiler can see the whole truth, it can work out for itself (most of the time) whether there are side effects.
Presumably it errs on the side of assuming there might be side effects if it can't prove there are none?
Functioning compilers will do that, yes.
-
@boomzilla said in Enlightened:
Functioning compilers will do that, yes.
Compilers that don't tend to either not get used at all or reported rather widely as being buggy piles of
-
@dkf said in Enlightened:
That's only really useful where the compiler can't see the true definition of the function. When the compiler can see the whole truth, it can work out for itself (most of the time) whether there are side effects.
Correct. Unfortunately, mainly to minimize build-time, it can be very useful to not have the relevant function definitions visible to the compiler. Same thing with
[[noreturn]]. If the compiler can see the function, you probably don't need to specify it. If it doesn't,[[noreturn]]can improve the code quite a bit.
-
He is full of crap.
Who cares whether it takes you one or three lines to add a button ?
And since there are plenty crappy Qt applications around, I'd say fundamental part is far from menu and widget cintrol code.
Also, he conveniently omitted all that dependency hell of Qt apps.
I get routinely into situation where two packages conflict about needed version of Qt stuff.
With enlightenment, it's easy. About all I need is EFL.
-
Oh look, I found a shill.
Do I get a cookie or something?
-
-
/me looks at the date of the previous most recent post in the thread
Uhm... a little late to the game, aren't we? Also, how did you come across this thread? Seriously, were you just doing a search on references to Enlightenment Foundation Library, and decided to engage in some thread necromancy in one of the biggest hornets' nests on the Intarwebz?
'Cos it is clear you don't have the sense not to stick your johnson in a meat grinder, if you are posting here of all places.
It might helped if you had, oh, I don't know... said who you were responding to, perhaps. Not that it makes any more sense to resurrect a thread which was, at best, irrelevant given that the last gasp of it was months ago, and had been long since driven off the rails and into topics unrelated to EFL years before that.
Seriously, the thread is three years old, and in most of that time, Enlightenment wasn't even being discussed. I can only assume that you read the first post, got pissed off, and fired away without looking at anything else, right?
Eh, never mind, it isn't as if this drive-by poster will ever come back to this forum. Shill, indeed.
-
@scholrlea At least he's talking about THE FUCKING TOPIC instead of some boring-ass debate about side-effects that went on for like 50000 posts.
-
@blakeyrat Side effects are not 'boring'. They are essential to programming.
-
@branko-badrljica said in Enlightened:
He is full of crap.
Indeed "he" is. Oh wait, do you mean @NeighborhoodButcher?
@branko-badrljica said in Enlightened:
Who cares whether it takes you one or three lines to add a button ?
People who actually write programs
@branko-badrljica said in Enlightened:
And since there are plenty crappy Qt applications around, I'd say fundamental part is far from menu and widget cintrol code.
Sure, you can be an idiot in any framework
@branko-badrljica said in Enlightened:
Also, he conveniently omitted all that dependency hell of Qt apps.
Also, you conveniently omitted all that entire rant and instead focused on how many lines you need to add a button.
@branko-badrljica said in Enlightened:
I get routinely into situation where two packages conflict about needed version of Qt stuff.
Sucks for you. I'm sure @blakeyrat would tell you not to use a shitty framework. On the bright side, though, once you've worked out that dependency stuff, you don't have to worry about the framework stomping over your memory because of the devs' illogical love of C. Or getting
BITCHCOMPLAINed at in front of your boss. So... you be the judge.@branko-badrljica said in Enlightened:
With enlightenment, it's easy. About all I need is EFL.
Easy. SPANK SPANK SPANK
BITCHCOMPLAIN
-
Oh man, this is the quality of a reply I expected from a EFL developer.
@branko-badrljica said in Enlightened:
Who cares whether it takes you one or three lines to add a button ?
Anyone who writes programs. And their managers. And their bosses. And their customers. And the users. So nobody, really.
@branko-badrljica said in Enlightened:
And since there are plenty crappy Qt applications around, I'd say fundamental part is far from menu and widget cintrol code.
There are plenty of crappy apps in any framework. It so happens, all made with EFL are such.
@branko-badrljica said in Enlightened:
Also, he conveniently omitted all that dependency hell of Qt apps.
Oh, yeah - you want to deploy a qt app, you run [your os]deployqt tool and that's it - you get all the deps in one folder/package. The horror!
Also, not sure what that has to do with EFL still being a pile of dog crap.@branko-badrljica said in Enlightened:
I get routinely into situation where two packages conflict about needed version of Qt stuff.
Look at that, you get conflicts on lib versions. That's so unusual when people don't know how to deploy their apps with deps. But EFL is better at this right? Especially when you have an earlier version without the needed API. I'm sure the magic of the Enlightened Ones will make that API suddenly appear for the application.
@branko-badrljica said in Enlightened:
With enlightenment, it's easy. About all I need is EFL.
Apparently, a brain too. Seriously - you're working for them or are you simply a masochist?
-
Biggest complaint against framework X: "Dependencies can be shit!"
Biggest complaint against EFL: "All the things!"Checkmate, atheists!
-
I think we scared him away :(
-
@neighborhoodbutcher Maybe he read a few more posts in this thread and realized that the consensus was not quite going in his direction...
-
@neighborhoodbutcher As I said, I honestly expect that he never intended to come back. It was a drive-by, with TR
being that he took the time to register here in order to do it.
-
@scholrlea that's very possible. In fact, Samsung has Tizen evangelists with the sole purpose of doing such drive-bys. It's fun watching how a guy pops into a random topic, says how easy it is to do [insert random text] in Tizen, and disappears.
-
I like the pity upvotes he got.
-
@topspin Pity? That was some quality shitposting.
-
-
@neighborhoodbutcher EaaS? I think we have a new monitization plan for @sockbot.
-
@greybeard
But think of all the jobs you'd be taking away from Chinese inmates! They might have to go back to farming gold in WoW! :shudders:
-
@greybeard said in Enlightened:
@neighborhoodbutcher EaaS? I think we have a new monitization plan for @sockbot.
I'm going to go Word of Blakey on you and ask if the 'E' stands for 'Enlightenment' or 'Evil'.
Not that there is much of a difference, IMO.
-
@scholrlea
One of us has
'd here...Filed under: The E stands for evangelism
-
@izzion Again, that comes to about the same thing.
-
@greybeard said in Enlightened:
EaaS?
DBaaS. There is plenty of potential to expand that business model too.
-
These clowns wrote a C primer. For some reason, then HackerNews linked to it. So now I know about it.
-
@blakeyrat why in hell would anyone want to learn C nowadays? Why in hell would anyone want to learn C from those idiots? Why in hell weren't they euthanized already?
-
To do signed values we just interpret values differently. We can have from -128 to 127 as values. When you hit the maximum value, things wrap around to the minimum.
No.
-
Is anyone registered there to post a link to this topic in a comment?
-
@neighborhoodbutcher said in Enlightened:
@blakeyrat why in hell would anyone want to learn C nowadays? Why in hell would anyone want to learn C from those idiots? Why in hell weren't they euthanized already?
I'm sure they're having problems getting people to use their stuff for exactly those reasons. So they're presumably trying to give people a leg up on getting Enlightened.
-
@neighborhoodbutcher said in Enlightened:
why in hell would anyone want to learn C nowadays?
CppCon 2015: Kate Gregory “Stop Teaching C" – 1:00:11
— CppCon
-
@lb_ "But wiping your ass with a never-cleaned communal sponge came first and flush toilets build on it!"
Is what that slide makes me think of.
-
@neighborhoodbutcher said in Enlightened:
why in hell would anyone want to learn C nowadays?
I don't see C going anywhere anytime soon, because there is no real replacement. C#, java, javascript, perl. What do you think they themselves are implemented in?
At the same time, there are many areas where you probably shouldn't be using it. We use it for high-performance data processing, and I don't see us switching to anything else basically ever because of inertia, but there's only one 200LOC module that's defendably in C. Everything else, though it might theoretically be faster in C, has enough NIH going on that it's unlikely to make a difference. Plus we've got that whole turing-complete business rules engine thing going on.
-
@neighborhoodbutcher said in Enlightened:
why in hell would anyone want to learn C nowadays?
There's a lot of existing C code out there, and there's enough subtle differences between C and C++, especially when dealing with embedded systems, that saying that one is automatically better than the other doesn't really apply. It's not that the code couldn't have been written in C++ as it stands today, with enough application of effort, but rather that it wasn't and perhaps it would have been very difficult to have done so with C++ of the time when the bulk of the code was actually written, and to have done so within the machine resource constraints imposed on the software.
If we started today with what we know now, we wouldn't have necessarily made the same choices that led to where we are now, but in that position we also wouldn't necessarily go to where C++ advocates claim to actually want us to go. ;)
-
@dkf given I've worked with embedded for a quite few years now, I can say, except arcane microcontrollers, there's absolutely no reason to program in C, unless forced to. Teaching people C in 21st century is exceptionally stupid; making a UI framework in C is even more stupid; thinking it will gain any traction is borderline insane. Enlightenment authors should be flailed for making this abomination and then drawn, hanged and quartered for trying to spread it.
-
@pleegwat said in Enlightened:
I don't see C going anywhere anytime soon, because there is no real replacement. C#, java, javascript, perl. What do you think they themselves are implemented in?
There's nothing preventing any of those languages from being self-hosting. If you can write a JavaScript compiler in C, you can also write one in JavaScript. (It'd probably be easier in a lot of ways, and really annoyingly tough in a lot of ways.)
While the CLR is written in C++, most parts of .NET that users actually interact with are written in C# itself.
@neighborhoodbutcher said in Enlightened:
given I've worked with embedded for a quite few years now, I can say, except arcane microcontrollers, there's absolutely no reason to program in C,
People who make that "but what about arcane microcontrollers!!!" argument always forget that there are also a lot of developers working on things like COBOL on 1970s-era mainframes, yet there's zero desire or effort to teach COBOL in schools and yet somehow those "but what about arcane microcontrollers!!!" people are ok with that.
Yes there's some subset of people who need to work with some strange technology most don't. It's ok if they get on-the-job training for it.
It kind of reminds me of those people who used to say the Xbox would be a failure because it "wasn't suited for Japanese customers!" Well. Ok. But there's another 5.9 billion potential customers out there, so maybe that's not that big a deal, huh?
-
@blakeyrat you seem to misunderstand me. I meant using C for new stuff, and by "forced to" I meant exactly what you describe.
-
@neighborhoodbutcher said in Enlightened:
in 21st century is exceptionally stupid; making a UI framework in C is even more stupid
Well, Enlightenment was not written in 21st century. Its first release predates the C++ standard by a year and it has probably been under development for some time before that.
Also keeping your public interface in plain C provides certain advantages regarding maintaining compatibility and binding to other languages, which is useful to UI frameworks (you can still be using C++ in the private parts though).
-
@neighborhoodbutcher said in Enlightened:
given I've worked with embedded for a quite few years now, I can say, except arcane microcontrollers, there's absolutely no reason to program in C, unless forced to.
We're doing moderately odd things with math and are running very very close to the limit on executable code on these things. And everything is soft realtime and we're dancing damn close to the limit there in some configurations.
We could use C++ (we've run some test cases that show it is feasible) but we've not had the effort available (or the… umm… spiritual willingness) to wade in and do an ass load of work for little external benefit. As I said, we probably wouldn't do the same thing if we were starting again, but that's not where we're at. It's just so hard to justify a rewrite for what are effectively fashion reasons. ;)
The only users we have who really care about this in the first place tend to be people who would rather write raw assembly, not people hankering after higher level languages.
-
@bulb said in Enlightened:
Also keeping your public interface in plain C provides certain advantages regarding maintaining compatibility and binding to other languages, which is useful to UI frameworks (you can still be using C++ in the private parts though).
Of course, I wouldn't suggest that Enlightenment is a particularly great example of how to do such bindings. ;)
-
@bulb said in Enlightened:
Well, Enlightenment was not written in 21st century. Its first release predates the C++ standard by a year and it has probably been under development for some time before that.
That doesn't imply it's a good choice today, even if we discard how horribly written it is. The first program loader was written in Fortran, but that doesn't mean we should use it now. It could be used in legacy code (my definition of "bing forced"), but in no way it's a candidate for anything new.
@bulb said in Enlightened:
Also keeping your public interface in plain C provides certain advantages regarding maintaining compatibility and binding to other languages, which is useful to UI frameworks (you can still be using C++ in the private parts though).
That's technically true (even despite the fact C, like C++, doesn't have a standardized ABI), yet the example of Qt shows it's not really a problem, at least not in a general sense. If we use that logic, we will end up with the lowest common denominator.
C Primer
