The project is interesting and I have to give it props for being one of the few Linux distros that’s put the necessary level of thought into UI/UX and made consistency a priority.
That said, I question some of their technical choices, most namely the choice of Vala as the project’s official language. Not that Vala is bad, but it’s incredibly niche at best and I think it severely limits contributions. Not many are going to want to learn a new language that’s scarcely used elsewhere in order to be able to work on any kind of project.
Learning Vala is still far better than GObject-C. Rust GTK bindings are probably not yet there. So what's left? Python and JavaScript. If you care about native performance the way I believe they are these will also not cut it.
Vala seems then a logical choice, especially at the time they were deciding. The question I have is: will Vala be supported further by Gnome in foreseeable future? I heard some time ago that it's not so sure. I would be pleased to hear otherwise.
>There are currently 179 unreviewed patches in Vala’s request queue. The oldest patch there is 2,556 days old, so we know that it’s been seven years since anyone has cared for the outstanding patches. Any of those discouraged contributors might have eventually turned into Vala maintainers if only their patches were reviewed. Of course, most would not have, but if only one or two of the people who submitted patches was an active Vala maintainer today, the project would be in a significantly better state.
If you're using the link on the blog post, you should also notice the queue looks empty without any status code, which tells me the link is broken. The banner says they've migrated to GitLab, where of 29 merge requests (since May, apparently) 8 are open, 2 of which are older than a month:
I will agree it definitely doesn't look as bad, and the door is open to "much better" -- the above is just a nitpick -- but it's too early to say that for sure. They just basically wiped the slate clean with the migration.
This kind of attitude towards less popular programming languages is very damaging to the field of software engineering. Domain-specific languages are our best tool to combat the excessive complexity of software. The difficulty of learning a new programming language is overblown.
When people say they resent having to learn another language, I wonder if it's really the language they don't want to learn or another set of libraries and frameworks. I mean, that's fair enough, the wheel only wants reinventing so many times.
Windows has Windows Forms, WPF, and UWP; macOS has Cocoa; and Linux has … well, a lot of things, each with their own quirks, and not all of them with bindings into every language a developer might want to use.
Steve McConnell observed something like this in "Code Complete": an experienced programmer can get some level of proficiency in a new language in a few weeks, but mastering the tools, libraries and idioms of a language can take a couple of years. Hence, it's a pretty big investment for a whole professional team to switch platforms, and you should try to avoid it.
OP argued that the choice to go with a niche language limits contributions, which is almost certainly true, even if it does combat complexity. You can both be right.
I think once you know 2 (or 3 if the 2 are as similar as, say, Java and C#), picking up new ones is comparatively easy. New paradigms can be challenging (looking at you, Prolog and Haskell) but quite doable.
However, if you resent being forced to learn a new language, or if you are more of a copy/paste developer than someone who really understands what you're doing[0], yeah, a new language can be a very challenging barrier.
[0] I want to be clear: most people start out with very little clue what they're doing in programming. That isn't meant as a disparaging description. I wrote (and copy/pasted) a hell of a lot of code before I started understanding the underlying mechanics of it all, and I'm still baffled by a lot of the development world (again, hi Prolog and Haskell).
>The difficulty of learning a new programming language is overblown.
I'm not sure that's the primary reason for people to disagree. A larger reason is that a smaller language has a smaller ecosystem, and solutions in a common language need to be completely rewritten to the new language.
I briefly flirted with contributing to the project, but the code was a horrendous mess and the build system was worse (CMake mess; most of the dependencies were implicit; etc). Vala aims to be intuitive for C# developers, which is a nice goal but everything is built on the trashfire that is GObject and the Vala abstraction leaks like a seive. Hopefully much of that was fixed with time, but I doubt GObject is any better these days.
What exactly do you mean by implicit dependencies with CMake? Do you mean that they just linking libraries without searching for them via find_package or find_library?
Thanks I was staring at the code examples trying to figure out which language it was. Some of the examples looked like C# but then some I could have swore were C++. Took me a minute.
Vala is to me the Dutch of programming languages. A fine language. When I hear it I first "know" it's English, then I know it's Danish, then I "know" it's German.
Which is when I realise is has to be Dutch.
But should I learn Dutch? Even though it's a fine language? Maybe I'm better off learning English and German first. And French. Dutch, and Vala, are too niche.
I wish ElementaryOS, would, in probably this order, would have:
a) used ObjectiveC instead of Vala. Elementary is attractive to to Mac users or admirers. Why not leverage what they know?
b) Exposed their API through some language agnostic mechanism. Heck, spits .NET even?
c) Supported interpreted languages such as Ruby, Python, Perl even.
IIRC I brought this up on some mailing list or other a LONG time ago, but (of course) was met - "Get with the program. Vala is fine."
It is fine, but come on. Everything about Linux (desktop) is niche to begin with. Why jump into a super-niche of a niche?
I don’t think Vala is the problem. The problem is GObject, and if you are tied to GObject, Vala is probably as good as or better than the alternatives. The only language that is clearly better than Vala is Go (better tooling and type system, quite a lot simpler, etc), but its bindings weren’t mature (and still aren’t terribly mature) when elementary kicked off.
Linux really just needs a better GUI toolkit than GTK and Qt, but these things are tremendously complex to build and as shitty as the web is, it’s quite a lot less shitty than these toolkits. This is why I think the ChromeOS model is the right way to go—every app’s UI is a browser app with a local daemon running on the backend, maybe in a container (but do away with ChromeOS’s custom modified kernel and prohibition against native code execution). In the worst case we’re writing JavaScript/TypeScript/etc on a browser instead of Vala on GObject, but WASM may well mean that we can write in any language.
The gobject system that underlies Vala is a language agnostic mechanism. Vala also produces gobject introspection information, so bindings can be automatically generated for many languages, including Python and Ruby. Obviously, that doesn't solve the problem of Vala being a barrier to entry for developers wanting to work on Elementary's core apps.
(I once offended some Dutch friends of mine by calling Dutch "German with a Geordie accent," although when you get down to it, "German with a Geordie accent" pretty much describes English, too.)
GObject is language agnostic in the sense that it’s terrible in every language. You still have another type system and memory model that is different from those of the host language, and you end up writing code that feels only marginally better than writing GObject in C. It’s all terribly disappointing in my experience. GObject has served us well, but if the Linux desktop is to survive, it needs a better desktop toolkit story (I left my suggestion on another comment in this thread).
I have no problem with the technical underpinnings. Or rather, I think (almost) every programming language today is kind of lousy, and the choice of Vala doesn't scare me off any more than anything else would have. No platform in the history of computing has made a great choice for its primary language, so I can't hold that against them.
When a platform gets the user experience right, developers will figure it out. Developers complain endlessly about JavaScript, but they want to target the web, so they made it work. Or Objective-C, and the Mac. Or C++, and Windows. We like complaining, but a non-ideal programming language really isn't a blocker.
The issue I have is that I don't see a great user experience here. This new brand of "consistency" just looks confusing to me. Every possible UI control -- from window title bars to tabs to buttons to lists to labels to text fields -- is a plain gray rectangle, with the same color and border. Am I supposed to figure out everything from context? I don't have much confidence that I'll be able to learn a new app, much less write one that other people will be able to figure out.
The metaphors, where I can find them, make little sense. I don't know why I'd want to "flick through" a grid, to select from a list. How is this better than scrolling through a list? They seem to be blindly copying parts of Apple's systems, without understanding why or when Apple made those design decisions. There's so many obvious rip-offs of macOS here, it's sometimes hard to tell if it's meant to be a parody.
And for some crazy reason I just can't get over the lone word "Applications" sitting in the corner of the screen -- the only word anywhere. It looks like a mistake. At best, it's clumsy. My steering wheel doesn't need "Steering" printed on it.
I think its part of that UX consistency you were praising. Vala's got 'nice' coupling with Gnome in the same way C# has 'nice' coupling with the Windows UI.
valac also compiles to C so no weird ABI stuff. No external runtimes or VMs required. I hate to say it but Gnome did something pretty neat with Vala.
Even so, it’s going to scare off a lot of potential contributors long before they investigate the language deeply simply by having a name they don’t recognize. It effectively limits the contributor pool to those who’ve previously written GTK apps, which is relatively tiny compared to the number of devs coming from more mainstream backgrounds.
I was looking through some of their sources, and that was the first encounter I’d had with Vala. If anything, it makes me more interested in potentially contributing.
Now, whether the tooling is up to snuff is another question. If it’s not, then the language choice could still end up being a turn-off, if not an immediate one.
> Not many are going to want to learn a new language that’s scarcely used elsewhere in order to be able to work on any kind of project.
As someone trying to make some (proprietary) software compatible with elementaryOS, Vala looks really fun to work with... but the cross-platform story for Vala isn't clear. 98% of any sales are going to come from the Windows & Mac versions, so I have to prioritize what will work best on those platforms.
If I could make significant sales just from an elementaryOS version on its own, that'd be a different story. But elementaryOS already discourages sales by making their App Store "pay what you want" & excluding proprietary software. That's fine, and I understand their reasons! But as an elementaryOS user, it'd be nice to be able to install Sublime Text directly from the elementaryOS App Store, even though it's proprietary software, just like I can from Snapcraft.
That said, I question some of their technical choices, most namely the choice of Vala as the project’s official language. Not that Vala is bad, but it’s incredibly niche at best and I think it severely limits contributions. Not many are going to want to learn a new language that’s scarcely used elsewhere in order to be able to work on any kind of project.