skysight-inc/HackerNews huggingface dataset:
> Some projects try to package this into a single framework, but this approach doesn't always work either, because it necessarily introduces new generic mechanisms and complexity

If the author doesn't want to have to learn "new generic mechanisms and complexity", then they'll certainly hate any huge breakthroughs in programming, because of course such a thing will come with lots of new generic mechanisms and complexity.

The reason single frameworks always fail is because they are single. The combination of technologies and abstractions is as important (or moreso) than the individual technologies themselves, and those are decisions you need to be able to make and change independently. Use small libraries that are focused on doing one thing well, are mildly interesting, and can be tweaked or swapped out without impacting everything else in your code. Don't use "single frameworks".

> A good hint is the recent GitHub Copilot development.

Absolutely not! This is entirely the wrong direction! You still have bloated code that you need to test and maintain, but instead of it being your code, it's the code of some (literally) brainless intern who has an unbounded potential for stupid errors?

All "scaffolded code" is doing what the compiler (or some abstraction) should be doing. Writing code the first time is the easiest part. Why do you want help with the easiest part, at the cost of making the hard part harder?

> And yet, most of programmer's time is spent reading or planning how to change the code.

Is the author really just another person who thinks that programmer productivity is based on the number of times they hit their keyboard? This is so off the wall that it threw me for a loop. You just complained about writing too much boilerplate, and you want people to think less and type more? This is insanity! The two most productive activities, by far, a software developer can do are:

- Discuss the problem space with other programmers and experts with a whiteboard nearby
- Stare out the window with the problem on your mind

The author wants us to do less of this!?
Glue code is used to piece together libraries. I think it's a sign you used the right libraries and aren't reinventing. It's boring, but glue code essentially describes why your project is not the same as every other apo using those libraries.

Boilerplate is a thing that happens when libraries don't have sane defaults. It's one of the more unpleasant things about Docker et al. I wish we had a dev climate where something like Linux Standard Base could take off.

I find frameworks to be perfectly fine, as long as you break out of the "Perfectly fit the code to the vision in my head" model and go for "How do I make this product using only these high level blocks I have, without modifying them".

Frameworks are great as long as you don't fight them. Using a distro like Mint? Don't try to swap out core system services. Using a declarative web framework? Don't try to do some synchronous imperative stuff it was never meant to handle.

I get the feeling a lot of programmers really value creative freedom and don't want to feel like they are playing a rail shooter, just coding the one obvious thing the opinionated tools tell them to do, and then they have a bad time when they use tools that were specifically designed to remove any need for interesting code.
> The thing I really would like to see is a smarter CI system. Caching of build outputs, so you don't have to rebuild the world from scratch every time. Distributed execution of tests and compilation, so you are not bottle-necked by one machine.

This is already achievable nowadays using Bazel (https://bazel.build) as a build system. It uses a gRPC based protocol for offloading/caching the actual build on a build cluster (https://github.com/bazelbuild/remote-apis). I am the author of one of the Open Source build cluster implementations (Buildbarn).
Decentralized Voting Application
Is this a joke?

I thought so, until I read Death's End.
The first time I returned the address of a local variable from a function and it _wasn’t_ a footgun was eye opening. Then digging into why that actually worked and understanding how go does escape analysis gave me more respect for the language and it’s compiler.
I still can't believe they decided that the new logo (right) was better. A purple silhouette of a K is just drab.

https://blog.jetbrains.com/wp-content/uploads/2021/07/Screen...
Rust_net
RustNet is an extensible Reactive library that makes it easier to create Distributed systems for Rustaceans.
> Just like with dieselgate this will be a closely guarded secret.

So ... no secret at all and widely published and discussed?
> The question is - if most of the work we want to do is about changing existing code, then why is the system not optimized for change by default? The code we write is optimized for reading the source text and its storage.

But it is optimized for change! That's exactly the reason line-by-line textual coding has been so hard to disrupt! Many, many non-text or augmented-text options for code have been tried, and they all fail exactly because they're not optimized for change! It's a pain in the ass to go and change some visual, graph-based program that someone else wrote, and an even bigger pain to keep it in source control. Text is the easiest thing in the world to change.

And I'll repeat the same refrain whenever the idea of non-text-based programming comes up: you're underestimating how long code spends in a non-functional state (cannot be unambiguously parsed into an AST), and how important that intermediate state is. Text handles that state beautifully, and every other option fails at it hard.

> Or even better, I want to specify a goal like "I want this function to not take this parameter" and let the system figure out how to transform the program to achieve this goal.

Or, even better, I want to specify a goal like "Make me a website that does cool shit" and let the system figure out how to achieve this goal. The author's stated goal is extremely ambiguous, and it's exactly our jobs to resolve that type of ambiguity. What exactly should the system to do? If you want someone else to figure that out for you, then you just don't really want to be a programmer.

>I can imagine a system that can combine small transforms into larger ones and use some AI magic to figure out how to compose them to achieve the specified goal.

So this whole article really is just "I'm sick of programming and I want an AI to do it for me". It's OK to be sick of your profession, but that doesn't mean other people are doing it wrong.

> If we instead focused on building the right model, we could better optimize that model for editing and the text could be just a view of that model. If the text is just a view, it doesn't matter how it's written. Let everybody customize it the way they want. I don't care if you put opening brace on a new line, I don't even want to care.

But we do just focus on building the right model. The text is not the hard part -- not by a long shot! That's why discussion and deep thought are where the real programming happens; translating it into working code is a very small fraction of the whole process. "The text is just a view" just kicks the can down the road -- a view into what? Whatever that underlying thing is (some awful clunky graph-based model?), that's now your language. Of course you have a language somewhere.

Again I get the impression the author is just sick of being a programmer.
> That's like complaining you need to break eggs when you want to make an omelette.

I have a friend who we discovered didn't like cooking eggs because picking the shells out of the bowl was tedious. Turns out he was never taught how to crack an egg so he would just throw it in the bowl and have bits of shell everywhere. Point is that breaking eggs may not be so easy for everyone. (Of course, after describing to him how eggs are properly cracked, he was excited to try it out.)
I don't understand the argument the author is trying to make. The vehicle in question is not an autonomous vehicle, but rather a data collection vehicle that is collecting data about road conditions, environment, etc. in order to make use of that data as part of BMW's autonomous vehicle project. All of this is explained at the URL that is literally written on the vehicle: http://www.bmw.com/autonomousdriving

The author acknowledges having read that information, yet for some reason concludes that BWM is deliberately trying to mislead the public. The reason for that leap of logic is not obvious to me.
To claim that you need to spend money equal to the tax-assessed value of the building over the course of 30 years to maintain equal value is slightly less ridiculous, but still not exactly reasonable. The (conservative) rule of thumb is 1% of the property value per year in repairs, which would be 30% of the property value over 30 years. And even then, it seems there's no shortage of fairly decrepit buildings that have no problem finding tenants.
Git don't even know about "folders", it's just implied from file names stored in the git trees.

https://git.wiki.kernel.org/index.php/GitFaq#Can_I_add_empty...

> Currently the design of the Git index (staging area) only permits files to be listed, and nobody competent enough to make the change to allow empty directories has cared enough about this situation to remedy it.

> Directories are added automatically when adding files inside them. That is, directories never have to be added to the repository, and are not tracked on their own.

> You can say "git add <dir>" and it will add the files in there.

> If you really need a directory to exist in checkouts you should create a file in it. .gitignore works well for this purpose (there is also a tool MarkEmptyDirs using the .NET framework which allows you to automate this task); you can leave it empty or fill in the names of files you do not expect to show up in the directory.
> Software testing doesn't work

Got it right there!

> We have some promising ideas. Some examples include strong type system, fuzzing, snapshot tests and sanitizers.

Okay, look. There's a lot of different times when a software error can be detected and fixed -- a whole spectrum. Let's be real generous about the categories of things "software error" can include here, including inefficiencies or building something the user doesn't actually want. The lower on this list we find errors, the more costly it is to fix them. Our goal is to push up where we detect errors as high as possible in the spectrum. It looks something like this (details and order may vary):

- Initial ideation ["Facebook for dogs? That idea sucks."]
- Requirements analysis ["That's not actually how we calculate that metric."]
- Conceptual system design ["Wait, these parts don't fit together like that."]
- Low-level design ["Crap, a loop won't work here, I need a different flow."]
- Brain-to-fingers typing ["Whoops I almost typed 'elesif'"]
- Immediately post-typing [Red squiggly line under 'elesif']
- Re-reading ["Wait that should be i-1, not i"]
- Compile time ["SYNTAX ERROR: Unknown identifier 'elesif'"]
- Unit test time ["Assertion failed: expected 7, got 8"]
- Code review time ["You didn't handle the case where N is negative"]
- Merge / integration test time ["Oh crap, David's commit broke my commit! How the hell do I merge this?"]
- Internal manual testing time ["You need to tighten up the graphics on level 3"]
- Production ["The users say the application keeps crashing when they run this report! Fix it!"]
- Years later/never ["Turns out the last 10 years of analysis that we used to make business decisions were wrong."]

Testing is actually quite low on the list, and there are lots of ways to move more errors higher up that list, such as strong typing, good abstractions, and really clean code. It's also tightly coupled to the implementation itself, so a conceptual error in the code can also exist in the test's assertions. I'd much rather write test that is obviously correct (errors caught at re-read or compile time) than write tests; only when you can't do you fall back to that lower-level option.
Look, of course there's lots of unexplored territory in software engineering, and we absolutely should continue to strive for better programming languages and abstractions. And we are! From reading this article, this author is looking in entirely the wrong direction for such improvements. It's not going to be some magic visual model that

One thing we should not expect is that new developments will be easy for us to learn, because we are already steeped in the current way of doing things. Supposedly, lexical scoping (what we're all familiar with) was extremely difficult to understand by early waves of programmers that were used to dynamic scoping (an insane way of doing it). They could have easily complained that this was just some new over-complicated abstraction and language construction that we don't need, but once you get over that hurdle and understand it, life actually becomes much simpler. New breakthroughs will hopefully be simple, but probably not very easy for us [1].

Many of this author's complaints about the current state of programming sound like they just haven't really achieved fluency in their programming language yet, and that they've been burned out on bad abstractions and have stopped trying to create (or just can't recognize) good ones. That's OK, this is all really hard to do! But it doesn't mean that everyone else is doing it wrong.

[1] https://www.infoq.com/presentations/Simple-Made-Easy/
This is 100% true up until demand is met, then it will stabilize. Currently though, the more you can utilize land the more it is worth.

Single families can compete against 2 families for the land, it is a lot harder when you can fit 10 units on the same property.
Hey this is pretty cool. Instead of Electron app I would prefer it as a browser tab. Wish it could be self hosted.
I am referring to the mascot names people are suggesting, not Kotlin itself. Hence the future tense, and speaking of the mascot directly. No smugness - some of the suggestions translate to completely different things in other languages, and that is what I am pointing out.

I see why my recounting of BorderWare's product made you think that. It's related, but not the same story.
High modernist city planning from the 1950s and 60s was a disaster. No, we should go back to the organic cities of the 1910s and 20s, with their mixed-use, medium density streetcar suburbs.
>Most of these customs prohibitions are not to protect people eating it -- it's to protect disease from being spread to local agriculture.

It's the other way around - these prohibitions are to prevent the unsanitary conditions at slaughterhouses from causing outbreaks. It's these conditions that cause the US to be the only country in the world that dunks slaughtered chickens in bleach before selling them.

https://www.telegraph.co.uk/food-and-drink/features/us-trade...
Rectangle (It's a window manager)

Chrome

Firefox

VSCode

My extensions for various web browsers

Homebrew

Other then that it's just what I end up needing in the course of work.
> But discrediting the technical part of a project because of the marketing part of the project can be short-sighted.

Fundamentally, I disagree. "Too good to be true" marketing is a great sign you're being scammed. I wouldn't trust a used car salesman who's throwing in free "undercarriage protection" and other junk after "talking to his manager". Why should I trust a website that's doing the same?

What's more, because Arweave like all crypto projects probably depends on users continuing to buy and mine tokens to function, unrealistic marketing contributes to boom-and-bust dynamics that might put my data at risk if enough people give up on the project/token. Whatever the underlying technology, this is enough of a reason to stay away. When Luna collapsed, a lot of people lost all their money. If the Arweave token collapses, users might also lose their "permanent" data.

Incidentally, this prompted me to look at the Arweave "yellow paper", and I found this gem:

> While the Arweave’s mechanism design is generally engineered to promote adaptivity to new circumstances, the core Arweave team does not expect that the network as it is currently formulated will continue to produce blocks in true perpetuity. This does not, however, mean that we expect that the information stored inside the weave will be lost after the final block is mined. It is our expectation that when eventually a permanent information storage system more suited to the challenges of the time emerges, the Arweave’s data will be ‘subsumed’ into this network. After the mining of the final block, the financial incentive mechanisms for data preservation will subside and give way to social incentives for data preservation. This effect will likely be compounded by the exceptionally low cost of storing the data from the network, due to its decreasing relative cost over time.

So data is stored "forever", assuming someone comes along and archives all the data at some point in the future for free.
My family has two cars - a 5 year-old Subaru and a relatively new Tesla. The Subaru has great physical controls for pretty much everything. It has a slightly janky touch-screen for changing audio sources (with nice physical buttons on the wheel for pause/skip/change channel). The touch screen is a little frustrating to use, but I rarely need it. I can imagine I'd be pretty annoyed if it was required for car functions or climate control. But the buttons and knobs are great.

The Tesla touchscreen is very good. I would be annoyed if I frequently had to use it while actually driving, but I don't. Everything in the Tesla is pretty much automatic, including climate control, windshield wipers, lights, and door locks. It's easy to use the touchscreen to raise or lower the temperature a degree - that's the main thing I find myself doing while driving that requires the screen. Everything else I do has a physical control on the wheel. The one frustrating exception is defog which the latest update put behind a menu. I have them shortcutted on the home screen but it is obnoxious.

I think having a big screen is nice. It does require thoughtful UX design and a few physical controls. Tesla probably errs a little too much on the side of automation + no buttons but it's generally well done. As driving becomes more automatic I think it really is less important to have tactile controls and more important to have screen real estate.
Land is finite, but housing is basically infinite. If I can get 2 houses to fit on the same piece of land, I would be willing to tolerate a 30% discount per house and still be up on my investment. It's a win win. Cheaper houses for the buyers and more profit for me

So clearly, the problem cannot simply be that housing is an asset.
We talked about it in this video, about how it's grown the way it has. https://www.youtube.com/watch?v=Ryj5c8zLF50
it's disingenuous to the user

That is nonsense. It is just a different model and the model Mac users have been used to since the 80ies. When I close a window/document, I often want to another document with the same application, so why close it? If I want to close an applications, I can use Cmd-q. Moreover, their visual presence is not gone, such an application is still in the Dock and in the app switcher.

And why do I care if an application continues running? If it hasn't been used for some time, macOS compresses its pages. And inactive native applications will be put in App Nap, which freezes the application, so that it doesn't use system resources until it is activated again.
I've seen this on Linux too, specifically with this VPN application https://github.com/yuezk/GlobalProtect-openconnect

Closing it via the "x" will minimize to tray and hide (which is the behavior I want, but an example nonetheless)
Small bug report

23 USD to CAD = -28.875332087 CAD

$23 USD to CAD = -30.174259569 CAD

It does not appear to like the USD/CAD stuff
Midjourney - Prompt based image generator similar to DALLE
Dennis Ritchie wrote C for himself.
I wake up at 5:30 every morning with this one weird trick: I lived to be old. Haven't set an alarm for years.
The people that he's rewarded in work are the one staying late. If you come early you don't get reward.

It is just that narrative of early people being rewarded more does not hold up to anything I see around. It is working lage everyone wants to see
Can you share your usecases for Alfred? I downloaded it but never used it.
Uh oh: Haven't you ever typed "ps aux"? :)

There is a third space on mac, different from a menubar, called "dock". In the old days it was integrated into the main persistent menu bar, but was removed maybe in the early 2000's. Personally I prefer one menubar, but at least I can hide the dock.

EDIT: "dock" not "launchpad". Duh.
Challenges in Single Sign-On [pdf]
more investment is needed in code generation . the best platforms i’ve worked on had ample code generation tools eg to generate a API out of a spec
Feel free to drop me a note craig.kerstiens at crunchydata and happy to have a conversation to see what options may exist.
So if there goal was to make a system that’s easy to use and understandable, I am failed to understand it; this after scanning research paper, website, etc.

For example, might be wrong, but appears they weight how nutritious item is for a single dietary goal, since to me sounds flawed; as in dietary goals and restrictions should first be picked/evaluated, then the items.

I have looked a few times at topic, spoken to nutritionist, etc - and as is, still find the topic unnecessarily confusing and clearly biased. Apps require massive amounts of personal information and restaurants & grocery stores to be feel like they’re designed to sell unhealthy foods.

__

Research Paper:

https://www.nature.com/articles/s43016-021-00381-y.epdf

Quick Ranking on the 8000 items:

https://sites.tufts.edu/foodcompass/research/data/

Supplementary information, which list 8000 items:

https://static-content.springer.com/esm/art%3A10.1038%2Fs430...
They are closing Russia’s offices right now and offering relocation packages to everyone still left there.

It is somewhat hard to work with Russian security services after this statement: https://blog.jetbrains.com/blog/2022/03/11/jetbrains-stateme...
Thanks for the response. I think we probably ultimately agree. I was taking aim at that second group you outline with my rant.

I had always assumed punch-tape was encoding some other representation of code than text until I did the research for my blog post. I think text is here to stay and I don't have any real problems with that. Where my tools offer designers or visual editors for code/UIs I still prefer to use text.

As an on-ramp to programming nothing quite beat opening up an HTML file in Notepad (or text editor of choice), making some changes and seeing that your header now flashed and was red.

I do think however that much like digging on a beach with a plastic bucket and spade is fun when you are young and carefree; when you're being paid to dig holes you want the biggest shiniest JCB you can get.

I am mainly reacting to the second group who curl their lips with disdain at the idea of doing anything other than coding in Nano or whatever pure text environment. They seem to see programming as a priestly sect dedicated to text like Lindisfarne's monks and people who don't know their Cherry Reds from Browns as fake/noob/impostor programmers.
Contra this, people's chronotypes change as they get older with people (on average) becoming more early birdish as they age. I think a lot of people struggle to recognise this and try to force themselves to continue to be night owls as they age, even though they would actually fare better if they started getting up early. I speak as someone who has gone from rarely going to bed before 2am when I was a yoof, to being someone who considers 6am to be a luxurious lie in. But I'm also dead on my feet by 10pm!
Norway has no inheritance tax at all; property taxes are microscopic (relative to other places that levy property taxes with intended market effects).