71–80 of 83 posts
Earlier quoted context omitted.
And if you really want to go high-level wouldn't Vala be the language?
Vala is actually a really pleasant way to interact with the various bits of the Gnome environment. It's a shame, in my opinion, that it never really received widespread love. I think all serious work on it stopped about a decade ago.
I suppose it's very gnome specific.
var i0 = $(Int, 5);
int i0[5];
Earlier quoted context omitted.
Speaking for myself, I’ve never found C++’s complexity appealing, and it only seems to be getting worse over the last 20 years. As the creator says, it’s not for production use. If I’m doing a side project, I’d give this a serious look.
I agree wholeheartedly with this. You can write high level code in C++, but the cost is a terribly complex language and standard library. In contrast, the C language is fairly simple, except for a few twisty passages (pointer declaration syntax, anyone?). The standard library does leave something to be desired, but that's not that big of a deal given all the third party libraries out there. It would be interesting to…
There was a snippet I saw a while ago where someone made C look like Java for a joke, using macros. I wish I could find it to share here, it's great.
Here's the original source tree, if you're interested: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd...
Earlier quoted context omitted.
Vala is actually a really pleasant way to interact with the various bits of the Gnome environment. It's a shame, in my opinion, that it never really received widespread love. I think all serious work on it stopped about a decade ago.
Isn't it still used by gnome, elementary, etc? I suppose it's very gnome specific.
What I can find with a quick search this morning: [1] [2]
Then again, there are also several people who still say it's worth using: [3] [4]
So maybe it's just Emmanuele Bassi advocating against it. If you look at the development pace, though, it hasn't really seen any significant development for quite a long time.
[1] https://twitter.com/ebassi/status/827482509982195712
[2] https://www.bassi.io/articles/2017/02/13/on-vala/
[3] https://blogs.gnome.org/mcatanzaro/2017/02/19/on-problems-wi...
[4] https://blogs.gnome.org/despinosa/2017/02/14/vala-is-not-a-p...
The strategy in the GC for determining the stack top for hunting GC roots will not work on all architectures. On aaarch-64, the address of a local dummy variable may be above a register save area in the stack frame, and thus the scan will miss some GC roots. In TXR Lisp, I used to use a hacked constant on aarch64: STACK_TOP_EXTRA_WORDS. It wasn't large enough to straddle the area, and so operation on aarch64 was unre…
Then use two stack frames! Every problem can be solved by adding an additional level of indirection. ;-)
Earlier quoted context omitted.
> I feel like the fine grained low level control is exactly the reason they chose C in the first place That's not the only reason, there is also simplicity, static typing and performance. If you favor the later two for whatever reason it can be used in places where you'd normal write a python/shell script or small program without too much extra effort (see https://github.com/RhysU/c99sh or suckless tools). Complexity…
> That's not the only reason, there is also simplicity, static typing and performance. I think the only meaningful benefit here is performance. Simplicity is at best determined by the nature of the problem and at worst a completely subjective opinion for C. Similarly, static typing is not usually something the programmer should care about that much. You need to know which paradigm your language uses, of course, but b…
Earlier quoted context omitted.
> Speaking for myself, I’ve never found C++’s complexity appealing, and it only seems to be getting worse over the last 20 years. True, but that's why we've got Rust these days. (Rust is actually more optimized than C, e.g. it will automatically reshuffle your structs to get rid of excess padding, and reference accesses will automatically take advantage of compiler-checked 'restrict' constraints, thus equalizing perf…
> e.g. it will automatically reshuffle your structs to get rid of excess padding This is just more complexity as well. It introduces surprising behavior that can burn you when creating interfaces or serializing and forces the developer to know that the compiler will be doing such magic.
Do you regularly order your stack variables? :D
99.99% of cases there are no expectations about details of a `struct` and having to think about it all the time is a PITA. That's a good example how silly defaults in C/C++ are. Just because I might need manual ordering once in a while, does not mean I want to be bothered by it all the time.
The strategy in the GC for determining the stack top for hunting GC roots will not work on all architectures. On aaarch-64, the address of a local dummy variable may be above a register save area in the stack frame, and thus the scan will miss some GC roots. In TXR Lisp, I used to use a hacked constant on aarch64: STACK_TOP_EXTRA_WORDS. It wasn't large enough to straddle the area, and so operation on aarch64 was unre…
> On aaarch-64, the address of a local dummy variable may be above a register save area in the stack frame Then use two stack frames! Every problem can be solved by adding an additional level of indirection. ;-)
0. We are already in a frame that doesn't take any arguments of the "val" object type; how come that's not good enough?
1. The current stack frame is entered with a bunch of callee-saved registers, some of which contain GC roots.
2. The current stack frame's code saves some of them: those ones that it clobbers locally. It leaves others in their original registers.
3. Thus, if a another stack frame is called, there are still some callee-saved registers, probably containing GC roots, and some of these will go into the area below the locals.
4. You might think that if the save all the necessary registers ourselves into the stack and then make another stack frame, we would be okay. But in fact, no. Because by the time we save registers, the compiler generated function entry has already executed and saved some of those registers into the below-locals save area and clobbered them for its own use! So our snapshot possibly misses GC roots. The compiler generated code always has "first dibs" at the incoming registers, to push them into the below-locals save area, thus kicking the GC roots farther up the stack.