Have been using Xfce since the the Gnome 3 initial introduction. I only want:
* the main apps menu
* the widget to lock screen, log out, shutdown.
* tabs along the top (or bottom) showing open windows
* the widget with the workspace switcher, clock, and network/printing/whatever status indicator
Last time I looked at Gnome 3, it tried to be like MS's "Cortana" thing where it wanted me to search for everything I wanted, or else have me find things by "most recently used". I want none of that. Xfce has it right. The desktop doesn't need to be reinvented.
There's actually a third dip: Comcast can tell the customer that for an extra fee they can get faster Netflix.
That is, even though the customer is already paying for internet access, Comcast can throttle Netflix traffic (even making it unusably slow), then offer to the customer to remove the throttling ("get turbo Netflix speeds!") for an additional fee.
Seems like they used to at least tip their hat (no pun intended) to free software, GNU, etc. --- the whole free software ecosystem on which much of their distribution is based. Though maybe I'm remembering it wrong.
Now I can't find any mention of free software on their site's About pages.
> The super advantage of Lisp (including Scheme): Its format for defining data is the same as for writing code, making macros a natural part of the syntax: You can change your source code just like you’d change any other list (or rather tree) data type.
I've heard this repeatedly over the years, but the explanation unfortunately always stops right there. Could you please give an example of why you'd want to change your source code programatically? It's always assumed that the reader implicitly knows why this is a good and important thing. Perhaps a practical example showing
(A) how this would work,
(B) what the benefit is, and
(C) how the added work in reasoning is worth that benefit.
Note: I personally like the parentheses, as they group everything together so simply.
* literal syntax for maps, vectors, sets, and regexes
* keywords
* clear separation of functional constructs (`for`, `map`, etc.) vs side-effecting ones (`do`, `doall`, `when`).
* large standard library of built-in functions, with overall fairly nice naming of things.
I've looked at Scheme, but it appears to be missing those things. I think some of them may be provided by srfi's, but upon a quick reading I couldn't make much sense of how to include and use them.
Don't need all those Java libraries if you've got good FFI with C libraries.
Don't need AOT compilation; if you want performance, just stick with regular Clojure on the JVM.
I'd love to just see a small general-purpose interpreted Clojure (quick start up, small memory footprint, easy access to C libs), even if it lacked concurrency features.
> However, most people have dismissed it because they think Perl 5 is dead and anything using Perl should be replaced with Python or Ruby or Go or Rust or some other language.
I didn't dismiss it for that reason. I wanted to like Perl 6, but dismissed it because last time I tried learning it:
* it seemed to include too much syntax
* too much lingo required to understand core concepts
* no coherently-written definitive tutorial. No Camel book for that matte.
* most examples seem to be written with maximum quirky-ness to show off the acrobatics you can do. I just want to get work done.
> I want to get on with my tasks. An operating system linked to s fixed set of hardware provides me exactly this.
I get the same thing from [ThinkPenguin](https://www.thinkpenguin.com/), though the OS isn't linked to the hardware in any way --- they just choose free-software compatible hw.
Alas, this ambitious project appears to be not currently under active development.
My largely uninformed armchair opinion as to why, is that the author is very performance-driven, and in the end it's very difficult to beat the JVM performance-wise. Lesson: if you want high-perf Clojure, you already have it on the JVM.
Personally, I think there's room for a simple small native Clojure implementation where performance is not top-priority. Small footprint, quick startup, access to native C libs. Still holding out hope for that one.
Sure. Alas, I don't know a flex from a bison, so I won't be implementing it any time soon.
Seems like language implementors are like carpenters: once you're a skilled pro, you're not interested in making a plain simple bookshelf. It's got to have dovetail joints, beveled edges, countersunk fasteners with plugs over them, light sanding between multiple coats of finish... then it's great, but not affordable and I'm back to looking for a simple bookshelf.
I'm an old curmudgeonly programmer (more hobby than pro), have kids in middle and high school, and have some meager amount of teaching experience. Here's my take: your students (especially in middle and high school) are generally a captive audience. Maybe later, if they have more interest in comp sci, they may be interested in using a more alternative language, but right now they want you to give them something that looks mostly like the current lingua franca and then get out of their way.
For the language I described above:
* it's like JS but with warts removed
* it's like C or C++, but higher level
* it's like Java but doesn't require types or the JVM
* it's like Perl but without the context rules and other zaniness
* it's like Python but with better names, more familiar syntax, and better scoping
(It's even a little like Scheme but with more conventional syntax, and regular lists, maps, and sets.)
Students can use it in your class, then if they want to pursue programming in earnest, can very easily segue to any of those common languages above. Not only that:
* They can easily re-type their classwork programs in any of the above langs, and not feel like their teacher had them using something that was only applicable to their particular class.
* They can show their classwork programs to any JS/C/C++/Java/Perl/Python programmer and it will be easy for that person to make sense of what they're looking at (with no previous experience with the lang described above).
I have no experience with Pyret, and don't want to cast any judgement on it or the people working on it. Maybe it's great and will benefit students even when they move on from their class which uses it.
Every time I see a project pop up touted as being simple and a good "teaching language", it has some weirdness or pet features thrown in that turns enough people off to keep adoption low.
If you want a good teaching language which will receive substantial adoption, do this:
* syntax-wise, use curlies and semicolons like C, Java, Perl, JS, etc.
* use many of the good function names that Perl uses.
* have all variables be refs to objects, like Python does.
* use nice normal lexical scoping like Scheme et al
* this shouldn't have to be mentioned, but provide data literals for lists, maps, and sets
* keep it small, and written in C, like Lua.
* resist the temptation to complicate things by adding this really amazing advanced feature that it's just got to have to distinguish itself.
* plan for it to become used for general purpose programming, as it very likely will.
And some "don'ts":
* don't worry about performance, that can come later
* don't worry about lack of libs --- your implementation is in C, and you should get good ffi down the road. And with the substantial adoption you'll see, libs will come later anyway.
* don't have it be on the JVM, LLVM, or any other existing VM. Keep it simple. Even an interpreter is fine for now.
That's it. That's all you need to do for amazing success in a teaching language that will also see serious adoption.
That said, no one does this. Presumably because if you're skilled enough to implement it, you have some neat but obscure features you'd like to add, or a unique syntax you'd prefer, which ... turns users off and keeps adoption low.
I think it's because the language appears to be very complex. So much syntax, context, and novel terminology.
It appears that Perl 6 lets you be very clever and can save you some keystrokes. But I don't want to be clever, and am willing to type a few extra keystrokes if it makes things easier for me to understand the next time I look at my code.
I get all my systems from [ThinkPenguin](https://www.thinkpenguin.com/), and have been very happy with them. Those folks are dedicated to free software.
Could work, though I think it would add operational complexity ("hey, I paid to swap in good batteries, but these barely held a charge!").
I wonder if it's possible to have a battery go into a low-current mode when it gets down to $n percent charge ("Warning: time to recharge or swap! You have $x Amp-hours left! Going into econ mode."), then disconnect itself completely when down to $m (where $m < $n, and going lower than $m would significantly affect the life of the battery).
* the main apps menu
* the widget to lock screen, log out, shutdown.
* tabs along the top (or bottom) showing open windows
* the widget with the workspace switcher, clock, and network/printing/whatever status indicator
Last time I looked at Gnome 3, it tried to be like MS's "Cortana" thing where it wanted me to search for everything I wanted, or else have me find things by "most recently used". I want none of that. Xfce has it right. The desktop doesn't need to be reinvented.