kpgiskpg's comments

I think a recent update (March 3rd, version 2.5.3) to SBCL added this sorta breakpoint debugging functionality. Hopefully we'll see it integrated with SLIME soon.

> enhancement: breakpoint debugger commands have been added. Included is a stepper based on breakpoints requiring no extra instrumentation. However, it still has less functionality than the existing single stepper. See the new debugger manual section titled "Breakpoint Commands" for more information on the new commands.

Oh wait, Hackernews seems to have removed one of the astericks symbols. It should be Python's exponentiation operator (2 astericks symbols), ya. (edit: fixed now).

That's cool too! How do you define the variables?

That's a question of interface design. You can also create ugly, ambiguous interfaces with functions (10 arguments, it mutates some of them, etc), or any other language feature. If a library designer uses operator overloading well, then it should be obvious what "a+b" is doing if you know the types involved.

On one hand it's a question of philosophy -- do you provide the user with tools to better express themselves, if they might possibly shoot themselves in the foot and create a crappy interface?

On the other hand, it could be an engineering issue. Maybe it's not worth the technical challenge or the increase in complexity for the language designers. I'd be more sympathetic to this reason. Then again, Python and C++ manage it.

(Author here).

Here's a not-so-mathy application that I had recently. I was implementing a units system in Python. Operator overloading allowed me to define joules like so: `J = KG * M**-1 * S**-2`. Then I could define grays (a radiation-related unit) like `Gy = J/KG`. Repeat for hundreds of units. If I had to do it in Java, I'd be frustrated by the verbosity and it would be easier to make mistakes.

My point -- Guy's point, actually -- is that if you don't give people the ability to grow a language, then their expressive power will be limited. And you can't anticipate ahead of time all the ways they'll want to express themselves.

Admittedly, my application is kinda mathy under the hood, because the units exist in a vector space. I guess that's to be expected when the operators come from maths.

My favourite illustration of this is in The Wire. The city wants to crack down on crime and increases the target number of arrests. The police chief sends out the word and police officers begin making a bunch of spurious arrests. Do you blame the politicians for picking crappy metrics and for their poor understanding of human nature? Or do you blame the individuals who choose to exploit the metric out of self-interest? Plenty of blame to go around.

This looks awesome! I wonder why I haven't heard about it before.

The previous user said that you can do "literally anything" in VSCode that you can do in Emacs, I think these examples were chosen to prove that statement wrong. It doesn't mean that Emacs is better for everyone.

I didn't realise that popes getting poisoned was a common occurrence at any time in history.

I actually started working on a CLI calculator a few days ago that sounds exactly like what you're looking for: https://github.com/Kevinpgalligan/ka

So far it just has variables and basic arithmetic. Other features on my roadmap: rational numbers, a type hierarchy, units, and lazy/smart combinatorics.

What do you imagine the timezone DB would look like? I'd love to hear your ideas!

Beauty is in the eye of the beholder, I guess. I wouldn't put matplotlib graphs in a paper without tweaking the style, and it gets frustrating when you have to do this for every single plotting script you write. And the defaults certainly aren't colourblind-friendly.

Getting the job done is the main point, of course, but I think a visualisation library should also handle common cases gracefully and have defaults that don't make me want to gouge my eyes out.

Every time I use matplotlib, I have to look up how to remove the border on my graph, make things slightly transparent, etc. The default colour palette isn't colourblind friendly, so the other day I spent half an hour trying to set up a more accessible one. I had to create / fetch 3 objects, their names being something like ScalarMap, Normalize and cmap. Why do I need to understand the relationship between these 3 objects when all I want to do is switch from one palette to another?

Meanwhile, it's so flexible as to be annoying for a non-expert. I often encounter matplotlib answers on StackOverflow about things that I would expect to "just work", but that actually require 20 lines of code to solve, written by someone who appears to be deeply familiar with the internals of the library.

Note: I'm not saying that a declarative approach solves these things.

I've always hated matplotlib, even though it gets the job done. The graphs are ugly by default, and the API would be unusable if it weren't for StackOverflow. Maybe I just need to sit down and learn it really well.

Anyway, this seems cool.

Calculus Made Easy has a heap of exercises at the end of each chapter, it's not bad in that respect.

Funnily enough, I'm working through this book right now. The writing amuses me to no end, from the anachronism of calling it "the calculus" to the chain rule being referred to as a "dodge".

It goes well with 3blue1brown's calculus series on YouTube, which gives more of a visual intuition for the concepts.

That's fun, thanks!

Cool! I love projects involving colour, because they always have nice visualisations. Would you mind explaining your project in more detail? I'm intrigued by your site! Not sure if it's supposed to be interactive because I'm on mobile.

I haven't looked too much into the general case. You could consider a tuple (R1, R2, ..., Rn) and compute the probability distributions one at a time for R1, R2, etc. I don't want to get sucked into the exact details of how to do that, but I think it would involve some head-wrecking combinatorics in a loop. Then you could do the same for G and B.

Like you implied, this would be slow if you did it 1000s of times. That's why I pre-computed the R probability distribution in my code, which unfortunately would not be applicable to the general case because there would be too many possible distributions (exponential) to pre-compute. To generate 1 set of RGBs, however, I think it would be fine.

Alternatively, you could try a non-combinatorics interpretation. The folks on Reddit (thread linked in the article) suggested a geometric interpretation of the problem, which might work better.

There's also the approach I suggested at the end of my article: compute the number of possible tuples that average to A (one-off combinatorics), generate an index k between 1 and this number, then pass k to a magic function f that spits out the kth tuple. I'm just not sure what f would look like, hehe. It could be a recursive function. Not sure how to write f without having to do the same probability / combinatorics as before. Or looping through all possible tuples (yikes).