ckdot2

That abstraction is another layer though. And additional layers are additional complexity. So, if you add another layer, the software is less simple than before. You might need to have caching in your software. I don't doubt that. But there's simply no way it makes the software more simple except if you assume some unfortunate starting point where you could get rid of any high-complex performance optimizations in your existing code by replacing them with a more simple cache solution. But then the statement should be "refactoring makes your code simpler".

"I think now caching is probably best understood as a tool for making software simpler" - that's cute. Caching might be beneficial for many cases, but if it doesn't do one thing then this is simplifying software. There's that famous quote "There are only two hard things in Computer Science: cache invalidation and naming things.", and, sure, it's a bit ironical, but there's some truth in there.

Not far. Just show all changes. Like the blog article already states, for many projects you already have code formatters, so changes in format usually don’t happen a lot - and if they do there might be a reason you don’t want to hide (like… you change your rules of code formatting). For all the other example I neither see the point why you would want to hide it. If you don’t want to see commas added in a list, make it a rule that the comma always has to be appended after the last element. Most languages allow that. Semantic equivalence? The JS example isn’t even equivalent because „this“ may have a different context. I’d prefer to have a „dumb“ diff that simply shows all the changes instead of adding these kind of complexities. Just keep your MRs small and there’s no real issue.

This is default on Mac if you use the Trackpad. Just to be sure I just tested with "man ls", which is also used in the example video. If I use my keyboard, I prefer to not have smooth scrolling.

You're right. But this only means that it won't be possible that you use the same template for different slots. Personally, I don't remember I ever needed that. Actually, most template engines I know work this way (https://twig.symfony.com/doc/2.x/templates.html#template-inh..., "{% block content %}"). But still, it's easy to archieve that by just creating another sub template. So your first template file is the layout, the second one contains the main block definition, and that definition you just include another sub template which can be reused elsewhere.

Here's a blog post which goes more into detail: https://kilb.tech/golang-templates

The same is still possible in PHP to include HTML code into you PHP files. But it's rarely still being done like this. It's considered good practise to separate your PHP (business) and HTML (view) logic.

Both is possible. See here an example how to implement use case 2: https://github.com/ckilb/golang-layout-tpl-example

I don't like Go's template engine too much, I find it a bit cumbersome in many cases. But it's quite capable.

Please, please don't mix up ORMs with ActiveRecords. ActiveRecords are one way to implement an ORM, but it's not the only way. I think many say they hate ORMs when they actually mean ActiveRecords. For bigger projects ActiveRecords suck, yes. But also you need to have some database layer logic which most likely does some Object & Relation Mapping (ORM).

No, that would be crazy. Ofc I want syntax highlighting. There's a bug in the newest version which removes syntax highlighting. I thought it's more common, so I understand that probably most are not understanding my comment. https://github.com/lapce/lapce/issues/2747

Use human readable dates:

Every blog post should include a human readable date. In fact, this extends to almost anything online and even offline. Timestamps are hard to read.

Use date and time:

Every blog post should include the time it has been created. In fact, this extends to almost anything online and even offline. I was reading Jan Kremers post about blog timestamps and it was not immediately clear to me what time the post was created. Only when I did a look into the HTML source I discovered the time there.

Syntax highlighting? Aaaaaand... it's gone!

Sooo deeeep. Woooow!

There are so many unknowns and unknown unknowns in medical sciense, especially regarding the human body. Did evolution really keep two kidneys if you actually just need one? I doubt it. When considering a donation you should also not only think about if you might die. There are more factors like quality of life. In the end, a whole organ will be removed from your body. This will have some effect.

Is there still demand? Is it better paid? There's a German website where you can compare average hourly rates for different programming languages and according to this COBOL developers get lower than average. This might not be significant, but does someone know how the situation is globally/in the US?

Of course we can expect errors, I don't doubt that. That's what I mean with "wrong". But still, how should the author consider that if he doesn't know about the precision nor quantity of errors? I just don't think that's the topic of the article. The article is about correlations in the dataset, no matter, if the dataset may contain errors.

How would you consider that? The article states that all the calculations were based on the ANSUR-II dataset. If the values in that dataset were wrong, of course the results of the calculations may not be correct.

Don't re-use using inheritance, but dependency injection. A (well-tested) software component that get's dependency-injected should get considered "final". If it makes sense to adjust it, you may still can do it - there's nothing preventing you from this. But you should always be aware that logic relying on the dependency may behave different in a way you haven't forseen. If you just want to make a change for a single place in your software, you can easily replace the dependency with another one implementing the same interface. You could even decorate the original dependency if you want to re-use most of it's code. What I want to say, nearly all of the abstraction issues come from inheritance and in many, many cases there's no need to use inheritance at all.

Even if you don't need or want to deploy daily, your software should be continous deliverable.

Well, the SQL is always somewhere. If you use an ORM library, even if you use ActiveRecord, you will find some SQL in it. In the end, it always translates to SQL. In the blogpost, the writer created a User Python object ("O"). A corresponding (R) database row will be mapped (M) to the object. That's basically ORM. Not as heavy as the usual libraries that support relationships etc, but still, ORM.

It's a pattern where a single object (the "active record") not only represents a single database row, but also usually is responsible for saving/inserting data into the database (via save method) and retrieving them (via find methods). Because of this it breaks SRP. If this is neglectable or not, I don't want to argue here. Personally, I would not use it anymore because of bad experience in the past.

there is a search, yes. but it's not working as good (and simple) as the search in VsCode... Just an example... search for "Scrolling speed" and you won't get any result. But if you click on "Mouse" in the left navigation you will find indeed a setting "Scrolling speed". Same for "Lock Screen" > "Show message when locked". Many settings will just not be found. Other settings will be found but the search result label is weird. For example if you search for "position" to change the "Dock position", you will indeed find "Dock settings" as a search result. But it's not "Dock position" so you could assume that there is no position setting existing. This is inconsistent to other search results, i.e. "Highlight colour" will produce a much better search result "Highlight colour - Appearance".

All the default* options belong to the system settings, not to the specific app. The system delegates specific functionality to a corresponding app.

Still, I admit that the whole settings structure is confusing and Apple should implement something similar to VsCode where you can globally search for all existing settings.

it's not always as simple as that. what if you once implemented some facade method to get data from database like "findProductById" and you comment it with "finds a product from database by it's ID". later on, someone (maybe you) replaced some deeper logic here, so the product might be fetched from some other source, depending on some configuration. in case you didn't even touch the facade file, will you remember to update the comment? most developers will not. this risk is ALWAYS present if the comment explains more than the nearby code. so a comment is only safe if it contains the same degree of information like the nearby code. in that case though the comment is redundant. comments only make sense if they explain the -why-, not the -what- or -how-.

If code is wrong or out of date, the program will fail or stop doing that it's supposed to do. If comments are wrong or out of date, it will mislead the developer or at least confuse them if the comment says something else than the code. A wrong comment is worse than no comment - and usually developers don't care about comments as much as for the code. Why comment some code anyway if the code is easy to read? The only reason is to explain -why- something has been developed, not -how-.

"bad practise everywhere" - you could say that for C++, Python and many more programming languages, too. If we're honest - most of the code out there is poorly written. PHP - nowadays - doesn't prevent developers in following good practises.

"Laravel was the first framework, that 'just worked' and had everything" - well, there was Symfony before. And CakePHP, and Yii (which was also considered as quite easy to learn), and much more. Laravel may did a few things "better", especially for junior devs, but it's not the first.

Please, no. While you can write really clean code in modern PHP, Laravel is a collection of anti-pattern. PHP has a bad reputation because in the past it was hard to implement clean code because of inconsistencies and lacking language features. PHPs reputation should improve, but Laravel is working against it. Please don't bring Laravel to Go.

There are ORMs (like Doctrine) that don't break SRP. I think ORMs have a bad reputation because of the ActiveRecord pattern. Not every ORM has to implement that pattern.

Is this an ad? Not cool, HN.