This is cool. I bought an Inkplate for this and got as far as writing a custom image format suitable for e-ink sort of things (4-bit RLE; trivial to decode, but good compression for diagram/text type images).
Where I got stuck is calendars... Unfortunately Google Calendar doesn't seem to provide a nice API where you can just say "give me the events for these days", instead you can only download all of your events in iCal format. It's then extremely non-trivial to convert that information into "what is happening today".
There are several ways to get all events for the day! The easiest one in my experience has been to write a simple Apps Script project and expose that as a published Web App[1]. That moves all of the oAuth logic and Calendar API plumbing to Google's server-side code, and gives you a simple long URL that contains exactly what data you want.
Something like:
```
function doGet(req) {
let start = new Date();
start.setHours(12,0,0,0);
let end = new Date(start);
end.setDate(end.getDate() + 3);
let events = CalendarApp.getEvents(start, end);
return ContentService.createTextOutput(events.map(x => x.getTitle()));
Most of my colleagues are content to spend 50 hours chopping up the tree with a pipe. We don't have time to spend making things work properly! This tree has to be finished by tomorrow! Maybe after we've cut up this forest, then we'll have a bit of spare time to sharpen things.
As Charlie Munger used to say “show me the incentives and I’ll show you the outcome”.
What are the incentives for these developers? Most businesses want trees on trucks. That’s the only box they care to check. There is no box for doing it with a sharp axe. You might care, and take the time to sharpen all the axes. Everyone will love it, you might get a pat on the back and a round of applause, but you didn’t check any boxes for the business. Everyone will proceed to go through all the axes until they are dull, and keeping chopping anyway.
I see 2 year old projects that are considered legacy systems. They have an insurmountable amount of technical debt. No one can touch anything without breaking half a dozen others. Everyone who worked on it gets reasonable rewarded for shipping a product, and they just move on. The business got its initial boxes checked and everyone who was looking for a promotion got it. What other incentives are there?
It's not about incentives; it's just bad management. As you said, the business just wants trees on trucks, so good management would realise that you need to spend some time sharpening axes to get trees on trucks quickly. It just seems to be something that a lot of software managers don't get.
I don't think every company is like this though. E.g. Google and Amazon obviously have spent a mountain of time sharpening their own axes. Amazon even made an axe so sharp they could sell it to half the world.
Early on in Amazon’s history (long before same day shipping), they added a feature that would tell you, on a product page, whether you had recently bought that same product. The metrics spoke loud and clear: it caused purchase count to go down. Human common sense about the customer’s experience overruled the data and they have some variation of that feature to this day. That’s the “customer obsession,” but unfortunately most businesses only copy the “data driven”.
There is some amount of time to spend on sharpening that, if you spend either more or less time sharpening, net amount of trees on trucks goes down. Smart businesses look for that amount. Really smart businesses know what the amount is, and make sure that they spend very close to that amount of time sharpening.
> Because we did this exact same transition from running in software to largely running in hardware for all 2D and 3D Computer Graphics.
We transitioned from software on CPUs to fixed GPU hardware... But then we transitioned back to software running on GPUs! So there's no way you can say "of course this is the future".
It was never the only hard part, but it definitely was a hard part (at least in most cases; obviously there are some monopolies with relatively simple software - mostly where there are network effects like WhatsApp).
But give me the source code for something competitive with Solidworks, Jasper Gold, FL Studio, After Effects, etc. and I'm sure as hell making a business out of it!
Furthermore while good software may not guarantee business success, it is pretty much a requirement. I have seen many projects fail because the software turned out to be the hard part.
Point taken. I forgot that brackets are not shifted on my keyboard.
They do require worse acrobatics than a shift key on a German keyboard, though - one of the Alt keys is special and needed to trigger them, if memory serves.
Well, that's another argument for everyone to use an English layout for coding, I suppose.
It's such a lot of effort to make a language like this. I don't get why they don't just put in like 2% more effort and add syntax that makes it less awful for humans. Nobody really wants to write `[* 5 5]` do they?
[fn square [x] [* x x]]
Could very easily be
fn square(x) = x * x;
Or something like that, which is much more readable.
Also
> Hindley-Milner inference eliminates type annotations.
I think it's pretty widely agreed at this point that global type inference is a bad idea. The downsides outweigh the upsides. Specifically: much worse errors & much less readable code.
I do. The advantage being that if you suddenly realize that you want to do super-duper-multiplication instead of regular multiplication, you can just change the name instead of having to rewrite the entire expression. And honestly, having a few random functions be called differently from others feels gross.
There’s no use arguing. As the ancient Lisp proverb says, when the programmer is ready, the parens will disappear. Until then, you’re just wasting your breath.
No because the syntax is so awful. Programming languages are consumed by machines but written by humans. You need to find a middle ground that works for both. That's (one of the reasons) why we don't all program in assembly any more.
Lisp and similar are just "hey it's really easy to write a parser if we just make all programmers write the AST directly!". Cool if the goal of your language is a really simple parser. Not so cool if you want to make it pleasant to read for humans.
I've never used a Lisp either, but I get the impression that "forcing you to write the AST" is sort of the secret sauce. That is, if your source code is basically an AST to begin with, then transforming that AST programmatically (i.e. macros) is much more ergonomic. So you do, which means that Lisp ends up operating at a higher level of abstraction than most languages because you can basically create DSL on the fly for whatever you're doing.
That's my impression, at least. Like I said, I've never actually used a Lisp. Maybe I'm put off by the smug superiority of so many Lisp people who presume that using Lisp makes them better at programming, smarter, and probably morally superior to me.
> Lisp and similar are just "hey it's really easy to write a parser if we just make all programmers write the AST directly!".
Its not just that, it makes syntax more uniform and it allows adding all sorts of features using the same parens syntax where other languages have to invent all sorts of special symbols to distinguish between things.
It makes it easier to parse for both machines and humans. This is why I asked if you ever wrote in lisps, because it takes some time to adjust but once you do it all makes sense.
Many languages tried to make programming look like a human-readable text, they all failed in one way or another. Because writing program instructions requires specific structure and s-expressions do that extremely well.
As someone who writes a lot of Scheme, I agree that the math syntax is not good. There have been proposals to add infix expressions (https://srfi.schemers.org/srfi-105/) but nobody seems to want them, or can agree on specifics.
However, code that is mostly function calls is fine for me, since those would have parentheses anyways in C++/Rust/whatever. In that case it makes the language more regular, which is nice for writing macros.
Earlier last year, I "quietly" introduced an infix support macro into TXR Lisp.
I devised a well-crafted macro expansion hooking mechanism (public, documented) in support of it.
It works by creating a lexical contour in which infix expressions are recognized without being delimited in any way (no curly brace read syntax translating to a special representation or anything), and transformed to ordinary Lisp.
A translation of the FFT routine from Numerical Recipes in C appears among the infix test cases:
The entire body is wrapped in the (ifx ...) macro and then inside it you can do things like (while (x < 2) ...).
In completing this work, I have introduced an innovation to operator precedence parsing, the "Precedence Demotion Rule" which allows certain kinds of expressions to be written intuitively without parentheses.
This view is false because what is hard to parse for machines also presents difficulty for humans.
We deal with most languages (Lisp family and not) via indentation, to indicate the major organization, so that there isn't a lot left to parse in a line of code, (unless someone wants to be "that" programmer).
> This view is false because what is hard to parse for machines also presents difficulty for humans.
Yes definitely to some extent, but they aren't perfectly aligned. Most languages make things a bit harder to parse for machines but easier for humans. Some get it wrong (e.g. I would say OCaml is hard to parse for humans, and some of C's syntax too like the mental type declaration syntax). I don't think you could say that e.g. Dart is harder to parse for humans than Lisp, even though it's clearly harder for machines.
If they were perfectly aligned, you could easily parse 128 levels of parentheses without any line breaks or indentation.
Every rule for inferring a hiddnen, implicit structure within a sequence of tokens makes things harder, even on the scale of just a few tokens in one line within an indented structure.
Where I got stuck is calendars... Unfortunately Google Calendar doesn't seem to provide a nice API where you can just say "give me the events for these days", instead you can only download all of your events in iCal format. It's then extremely non-trivial to convert that information into "what is happening today".
reply