spookylukey

e.g.:

pyastgrep --css 'Call > func > Name#main'

For other people: I'm pretty sure the author is talking about https://cuelang.org/

Over 200 posts, spanning nearly 20 years. Mostly on programming, Python, Web development, some personal and Christian stuff.

This is not to make the general claim "Typing is a hindrance in parsing applications", or anything close. It's saying "the current static type system(s) available in Python would have made this Python library much worse".

This might be because of really old data and old code that saved it. But changing this decision is very hard, so I imagine many systems that adopted escape-on-input once are stuck with it.

I'm currently enjoying using the "Recursive Mono Semicasual" variant of Recursive - https://www.recursive.design/ . It adds just a little bit more fun that a typical mono font, especially at higher font sizes (e.g. for headings in Markdown in an editor).

When you need a bit of extra UI goodness, htmx https://htmx.org/ is a fantastic solution, and you can still use SPA-type approaches for things that need them.

You can also benefit from massively faster (and more reliable) functional testing when you are mostly standard HTML - see django-functest https://github.com/django-functest/django-functest/ for an example of this.

Can you, for any button in your interface, at any point in time, reliably calculate at runtime what your page's data model would look like, and if there were going to be any side effects, if you were to click on that button - but without clicking on it or invoking its callbacks (which could potentially change all kinds of things)? You can do that with Elm (more info here - https://lukeplant.me.uk/blog/posts/two-experiences-with-elm/ ), due to The Elm Architecture and everything being immutable.

(In theory you could do this in TypeScript, but it would be a lot of work and its reliability would depend on everyone coding everything a certain, very unnatural way, with no help from the compiler).

I'm using Elm in production, version 0.18, it is an extremely robust way to make front end code. You just don't have runtime issues.

However, like IBM folks (mentioned in another reply) who said in the their post they didn't know how they would upgrade to 0.19, I also don't know how I will be able to upgrade. Specifically, 0.19 adds some cripple-ware restrictions (you can't use native modules unless you are contributing to certain projects). So, if you want to use something like Intl - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... - not only is there no wrapper provided, the restrictions in 0.19 attempt to stop you from writing your own wrapper. Only the core team can do it, which requires them having both the expertise and motivation to do so. Plus Elm has essentially a closed-source development process. In fact, there is no 'process' for contributing, and the fact that there is no process is deliberate, as far as I can tell.

So for me, if I can't find a way around the restrictions, they may kill my ability to being able to keep my code nicely architectured (i.e. using The Elm Architecture). I may be forced to switch to something like ReasonML with bucklescript-tea - https://github.com/OvermindDL1/bucklescript-tea

Banks do indeed make money "from nothing". If you get a loan of $1000 from a bank, they just add $1000 to your current account, and write down in another account that you owe them $1000. They don't have to "get" this money from somewhere.

This is all as it should be. Say I can make tables, and you want one, but don't have anything to give me in exchange. We can agree that you now owe me $100, say. You can write me an IOU and sign it. Suppose you are trustworthy enough that an IOU from you is considered acceptable as payment. I can now use your IOU as money - we have just "created" $100 money from nowhere (or, $100 debt, same thing).