branchly2
* 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.
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.
Using IRC/Slack in place of forums is like using a wiki in place of real documentation.
Now I can't find any mention of free software on their site's About pages.
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 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.
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 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.
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.
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.
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.
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.
Pandoc is written in Haskell, but when built it's just a regular binary.
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.
Would love to see the author do one for the GPL. I realize the result would be quite a bit longer.
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).
I suppose. But as it stands I'm already relying on gas stations.
> Also, it's probably a lot easier to get consumers to add chargers to their homes {snip}
Sorry if I was unclear. I was assuming that as a given. If I've got an EV, it's going to be plugged into the charger at home every night.
My point is, you can either increase range by having better batteries, or you can do so by charging up while at your destination (ex., in your parking lot at work).
It gets even better if you're running errands and you've got a charging station at the grocery store, library, city hall, etc.
I choose markdown primarily because it's readable.
* more areas to lock your bike/scooter/moped (electric or otherwise)
* coin-/card-operated charging stations (as in, "plug in while you shop")
* charging stations where you work (to charge your EV during the day)
I don't think swappable battery stations would be useful, since batteries are damaged by deep-discharging them, and swap-stations would end up with too many damaged batteries that way.
As more people start using EVs, it will be a no-brainer for companies (or even local electric utility companies) to start placing EV charging stations all over town.
The clearest I can come up with right now is "free as in liberty" vs. "free as in a gift to you".
And for exactly that use case, there is industry adoption.