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

It's like 4 lines of code that saves you so much grief later on:

    from django.contrib.auth.models import AbstractUser
    class User(AbstractUser):
        pass

    AUTH_USER_MODEL = "myapp.User"

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

Only if you have complete end-to-end control over all the devices that everyone uses, including their brain, can you stop people from copying data.

If I have a file that I want to limit access to, I would never dream of sending it via e-mail. Some hosted document service which only shows parts of the file would be far preferable.

This being a falsehood is a matter of considerable debate, and it's impossible to prove (There are certainly some people with very low ability for computer programming, to the point of effectively useless. How would you prove this was entirely nurture and not nature?). This is a not a good candidate for a "list of falsehoods" article.

If the answer is "to get some async goodness, just use this easy code, plus rewrite your entire project to use a different framework and set of libraries", then we are only fooling ourselves.

Or, it's a memory saving feature. To implement "View source from cache" requires keeping around the raw page HTML, which you might not otherwise need after parsing - except you probably will for all the developer tools to work, so this probably should just be considered bug.

curl|bash is much less secure, in general, than using your package manager (since not everyone will serve downloads over HTTPS, and won't take the steps described in the article etc.). By encouraging it, they are making this method normal, when it shouldn't become normal.

* do you need to keep supplying electricity?

* do you need to keep paying the bills so that someone else will supply electricity?

* will it continue working if there is a hardware failure? What kind of hardware failures can be tolerated? Do you need to intervene if the data gets migrated to a new system?

* will it continue working if there is a flaw (not just a bug) found in something? e.g. it uses TLS version X which turns out to have some flaw in Y years time

* what about it society changes in some way so that the load on it is quite different in the future?

* how long are you expecting to do zero maintenance? At some point the operating system you run on will be obsolete, and there will be no upstream fixes to critical security bugs - what will happen then?

I suspect the divide in reactions to YAGNI comes between people who have embraced those practices and those who haven't (and probably don't even know what they would look like, and can't imagine an environment that uses them).

In the context of a project where making changes is hard and dangerous, and where you have few automated tests, you will be tempted to change a lot at once, so that you can then manually check everything works once, rather than having to do that multiple times. And that might well be the better strategy.

Consider the question "What if we need extra fields in our 'product' table?". The Extreme Programming answer is both 'embrace change' and YAGNI. That means 1) we absolutely definitely require some general mechanism to be able to add columns to tables in the future, so we must have that in place, and not assume the product table schema is fixed forever 2) we have no idea what columns or how many columns will be needed in the future, so we don't add any now speculatively.

But many people work in environments where adding a column to a table would be a massively expensive task (thousands of stored procedures that need rewriting etc.). In this context, the 'YAGNI' response which just refuses to think about future does sound stupid, because it is.

[1] http://c2.com/cgi/wiki?ExtremeProgramming [2] http://c2.com/cgi/wiki?UnitTest [3] http://c2.com/cgi/wiki?RefactorMercilessly

Read "Thinking, Fast and Slow" by Daniel Kahneman and you will become much more suspicious of sentiments like "I think it’s pretty easy to tell whether someone’s smart in casual conversation". We are actually extremely bad at guessing people's competences on first encounter, and very prone to cognitive biases such as the halo effect.

With no objective measures, it seems this method is likely to be subject to massive bias towards people that you just get on with or like for some reason.

You will either end up with an ad hoc, informally-specified, bug-ridden, slow implementation of half of SQLite ... or, you will fail to even attempt the features that SQLite gives you - such as locking and dealing with concurrency - and you will have bugs.

For example, you use file_put_contents. See this comment: http://www.php.net/manual/en/function.file-put-contents.php#...

Please don't go and add locking now! (It's hard to get right). SQLite was invented to be a better fopen() - use it! There is no reason not to, if you are requiring PHP 5.3. If you want a simple plain text dump of your SQLite DB, that's not hard to add.

I think the definition of wealth that is quoted at the top, and the one I normally use, is different from the one you are using (at least at some points).

As far as I understand the definition, (material) wealth refers to the physical things that you can own or enjoy that are good and useful. So that includes cars, houses, clothes etc. But not things are purely money generating things (like stocks and shares). A house is a good and useful thing in its own right because you can live in it. Stocks and shares, and money itself, are not (apart from the sheer pleasure of seeing a large number on your bank account).

You might also include 'things' that are not quite in the same category as physical possessions, but are things that can be enjoyed - like holidays and gym membership.

In that sense, money and wealth are almost opposites - you have to give up money to get wealth. At the extremes:

You can have millions in the bank and have no wealth - if you refuse to spend it, you'll die of starvation in cold, broken down house; and you can also have no money but plenty of wealth if, for example, you are the owner of a large, entirely self-sufficient farm, with servants etc. who are all paid via the produce of the land and live in buildings you own. Neither are very likely in our economy.

It seems you are mixing into that definition of wealth the ability to get money/wealth. I'd agree that is a form of wealth (in that you would say that person is in an enviable position), but, like money, it is more "potential material wealth" and not really physical/material wealth itself. And the ability to be happy with little material wealth is the best form of wealth, but, by definition, not a part of material wealth itself.

steghide has a far superior approach:

http://steghide.sourceforge.net/

But that can be broken too:

http://dl.acm.org/citation.cfm?id=1578445