GNOME Might Need To Crack Down On Their JavaScript Extensions

[Sniperfox47]

Who cares about the parser? I'm talking about someone who's reading the code. I never denied the C++ parsing rules are complex (C is actually fairly easy though). But that's not even (always) a bad thing: a language shouldn't be "simple" because then we'd all be using Brainfuck. Simplicity is not the best thing, there's a balance.

For reading the code, which is what matters, it definitely reads much better than Rust code with all those "let" and "let mut" around.

DISCLAIMER: Yes, this is an opinion, my opinion and those who share it. Like, you know, all the other anti-C flaming posts in here which are also just opinions. Why no mention of that eh?

I'm primarily a C++ programmer, who has defended C++ on multiple occasions, not on this forum but I've yet to really see an "attack" on C here.

My issue is not with your statements that it's ugly or that it messes with your head. My issue is with your totally unjustified claims as to the quality of these languages and the quality of programmers they contribute towards. That kind of elitism and egocentrism doesn't earn you any favor and if people talked about C/C++ in the same terms I would be equally up in their face. To this point nobody's made comments along the lines of "C++ is a terribly designed language. It trains programmers to ignore memory bugs and ship them to their users. It's part of the reason we have so many terrible low level programmers!".

While I also find C++ to be cleaner, beauty is in the eye of the beholder and verbosity is not inherrently a bad thing. There's nothing poorly designed about Rust, Javascript, Python, C#, Go, or any of the other widely used language, any more than C, C++, or even brainfuck are "poorly designed".

The fact of the matter is that switching to C wouldn't magically solve any of Gnome Shell's problems. JavaScript is not the problem here. Accessibility is not the problem because any language has terrible developers who will mess things up. The problem is the monkey patching a mission critical application is asinine. Monkey patching a mission critical application with no sandboxing or protection in place is even stupider.

The only point anyone in here has been making is if they're going to do a rewrite in another language -and not radically change the design to better separate out the different pieces-, it's ultimately far safer to use a language that forces you to be safer about memory and error handling. C++ is a great tool but it's a tool that's best used for specific jobs. You wouldn't cut your steak with a scalpel, despite it being a "better" knife.

[schmalzler]

Weasel, you again mix your personal preferences and abilities with general statements about the quality of programming languages.
I have difficulties to understand anything but C++ and D. C sometimes is a mystery. Rust, Go, Haskell, etc. are even worse. But I never really tried to learn those languages.
It's like with spoken languages. Polish is so weird. Or Hungarian. Or even worse - all those languages writing in Cyrillic like Russian, Serbian, Bulgarian... But I would never judge those languages or people using them by my understanding of those languages.

Calm down and accept that you never had a use for those programming languages.

[Weasel]

Wow, never thought about that. I'm not sure if the committee knows about that. I am sure you could speedup the parser tremendously!

Who cares about the parser? I'm talking about someone who's reading the code. I never denied the C++ parsing rules are complex (C is actually fairly easy though). But that's not even (always) a bad thing: a language shouldn't be "simple" because then we'd all be using Brainfuck. Simplicity is not the best thing, there's a balance.

For reading the code, which is what matters, it definitely reads much better than Rust code with all those "let" and "let mut" around.

DISCLAIMER: Yes, this is an opinion, my opinion and those who share it. Like, you know, all the other anti-C flaming posts in here which are also just opinions. Why no mention of that eh?

[creative]

Hey I have a great idea that will solve everyones Gnome woes. Just use i3 its written in C there is no bloat, and integrates well with XFCE gtk apps like thunar and pasystray. It's functionality is 100x faster than anything Gnome has. While Gnome is pretty, thats all it is, it's pretty and its clunky, and slow. Using i3 right now, it's either XFCE or i3 for me and both are excellent. I use both but not at the same time.

But here is the thing you can integrate XFCE and i3 at the same time adding hyper functionality, while I have not done this it does seem like an interesting expirement to try, I know people are already doing it. I do feel as though it defeats the purpose of each seperate wm.

The cool thing about i3 is you can pull up thunar with the dmenu and goto your desktop folder and use all you desktop icons and shortcuts for XFCE which is very nice if your XFCE desktop is cluttered with tons of stuff to use as sort of a quick launch thing. I have a very cluttered desktop but I am also highly productive when working with graphics and DAW stuff. Often times though dmenu is so predictive that once you start typing what you want it is already there in the first few letters, if not keep typing and then you can scroll through or even isolate it before typing further if you can't remember something. i3 is simply genius put into practice.

[schmalzler]

It obviously means multiplication, given the space (or lack of) between the arguments.

Wow, never thought about that. I'm not sure if the committee knows about that. I am sure you could speedup the parser tremendously!

[cochise]

B) switching the default back to X11 really doesn't solve anything. You still have random extensions crashing your shell. You still have them crippling shell performance. The X11 session is still there for the distros who want it. For and for the bleeding edge distros that are using shell without any extensions, wayland is still a better default.

But GS is able to recover with a "blink" in X, without losing all client apps and to disable extensions in the restart. This workaround reduce the damage to users.

[Weasel]

Actually it would be "let x = 5;" vs "const auto x = 5;" - we're using modern C++ after all. Or "let x = 5i32;" vs "const int32_t x = 5;"

auto is not int32, in this case it would be just int. It is also a good keyword because it tells you the type is automatically deduced, unlike crap like "let". I don't know Rust that well but it seems it defaults to i32? In C++ you'd know since a numeric 5 is int, if you wrote 5UL it would be unsigned long, etc.

Also, stop using const examples? You're intentionally using a default over a non-default to prove an invalid point, how about:

let mut x: i32 = 5;

vs

i32 x = 5;

or even just:

i32 x;

(yes, you can typedef if you want it short like that, no need to use int32_t). mut is stupid but let is just superfluous. At least with auto you don't have to specify the type, while with let you can so it's completely useless. auto also just reads better.

That's easier said than done. Luckily, there is lots of preprocessor magic in most libc-implementations, which do that for you.

Huh?

typedef int32_t i32;

at the top of your core header that everything else includes.

Yeah very "difficult".

I should have a hotkey for "const", since most of my variables in C++ are const.

Then you code the wrong way. They're called variables for a reason, not constants. Do you code in SSA fashion or what?

Personal opinion. You don't like it? Choose something else and stop complaining. I like haskell, hence I like let.

Yes, personal opinion. I do choose something else. No, I won't stop complaining, just as morons don't stop complaining about C being "ugly" when in fact it's 1 million times more "beautiful" than Rust's crappy syntax. (for the record, I'm not referring to you)

Compare that to C++l I.e. what does "a * b;" mean in C++? Does it declare the variable "b" of type "a*" or does it multiply the variables "a" and "b"? Who knows, you need to know the full context.

It obviously means multiplication, given the space (or lack of) between the arguments.

Oh, I'm not going to argue about badly written code or intentionally obfuscated. Why should a language prohibit that in the first place? It's not like they are hand-holding a guy who wants to obfuscate his code, he'll just find another way.

[schmalzler]

Recent blog post on the topic by Eike Hein (current situation and ongoing work in plasma):

https://blogs.kde.org/2018/08/02/engineering-plasma-extensions-and-stability-%E2%80%94-present-and-future

[Sniperfox47]

Why no one think in the obvious solution?
1 Set back to X11 as the default session.
2 Decouple the compositor to be able to recover on Wayland.
3 Set again Wayland as the default session.

The problem is not JS or Wayland, but putting all things on the same process. They only need to make a simple compositor daemon able to recover, not the whole window management.

A) minus switching the default back to X, that's literally option 2 that they suggested... So they *did* think of it, not to mention it's already been mentioned several times in this thread.

B) switching the default back to X11 really doesn't solve anything. You still have random extensions crashing your shell. You still have them crippling shell performance. The X11 session is still there for the distros who want it. For and for the bleeding edge distros that are using shell without any extensions, wayland is still a better default.

[cochise]

Why no one think in the obvious solution?
1 Set back to X11 as the default session.
2 Decouple the compositor to be able to recover on Wayland.
3 Set again Wayland as the default session.

The problem is not JS or Wayland, but putting all things on the same process. They only need to make a simple compositor daemon able to recover, not the whole window management.