branchly2

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.

Forums work better.

Using IRC/Slack in place of forums is like using a wiki in place of real documentation.

The problem is though, that some people like to be the local expert on IRC/Slack with all the answers. They don't want to document it elsewhere.

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.

Thank you. Though I really like having Clojure's:

* 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.

The Pandoc site appears to provide binary downloads for the major platforms. Myself, I just always do `apt install pandoc`.

Pandoc is written in Haskell, but when built it's just a regular binary.

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.

This looks excellent, and I'm going to curl up with it and a cup of tea tonight to read it more carefully. Thanks!

Would love to see the author do one for the GPL. I realize the result would be quite a bit longer.

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).

Having to rely on others to ensure you can get around causes a lot of anxiety.

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.

Yes, the US.

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.

Pandoc is damn good, but that's not my primary reason for using Markdown.

I choose markdown primarily because it's readable.

Where weight and energy density is not a concern, you'd just use regular old-fashioned lead-acid. Lots of charge cycles, easily recycled, simple, no overheating, existing infrastructure.

The answer here isn't batteries with more capacity. The answer is:

* 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.

I wouldn't say amusing, though it is interesting, and taking note of Go and Dart, it may reflect what role Google thinks Python plays.

The word "freedom" doesn't work because it can also imply "do whatever you want". I've heard "free as in libre", but that word may not be clear enough.

The clearest I can come up with right now is "free as in liberty" vs. "free as in a gift to you".

For professional looking docs, you can still write them in Markdown, and then have Pandoc process them into LaTeX. Pandoc even lets you put raw LaTeX commands into your Markdown.

Clojure is great if you want to use it in an enterprise, multithreaded, Java shop working on large amounts of data. It's really great at exactly those things. If that's not your use case, then it may not be a very useful environment to get into.

Great!

Though Clojure fans like various aspects of the language, Clojure's use case is being a Java replacement (or else integrating very well with Java) in non-free-software enterprise shops, specifically for when you need multithreading while working on large amounts of data.

And for exactly that use case, there is industry adoption.