jaked89's comments

Line drawings work because they represent the centers of symmetry for surfaces and volumes. They trigger the same center-neurons that the original shape would.

A hand could appear on you retina in different sizes and orientations. According to distance, the size will grow and shrink. But the center of symmetry will stay the same.

This goes further. There's also a center of symmetry between edges, and higher-level features as well. Our brain has no issue detecting these.

Strawman attack. I didn't mention mining; anyone can purchase crypto.

If you prefer to support the fiat thugs by holding into their tokens, be ready to pay the price.

Early crypto adopters are freedom minded people. I have no problem with a new economic system where the wealthiest are the most freedom-oriented.

If crypto ever replaces the current monetary system, late adopters will have to fight for crumbles.

And that's OK; you support deception & violence, so you stay poor. That's cosmic justice.

This has nothing to do with my point. Law exists to establish peace and consensus.

Contacts are the most basic construct enabling modern life in a crowded society. Reinterpreting contracts in a liberal, unreasonable manner destroys peace and introduces chaos.

It prevents members of society from ever trusting one another, and makes all agreements tentative, subjective to the retroactive whims of politicians and court.

It serves the court, positioning it as an ultimate dictator, not the society.

Examining this case from a "similarity to employee" perspective neglects a crucial factor: the expectations between the parties at the time of contract.

It's patently obvious no Uber driver expected to be treated as an employee, as no employment contract was signed, and the Uber model is known and clear.

The court merely implements "social justice", which is nor social nither justice, destroying basic trust in society. Progressivism is cancer.

FP didn't invent immutable data, or mathematical functions. It just makes it easier to use them for some domains, while complicating others.

Imperative programs can have isolated, pure subsections of functionality which are based on composition and immutability, without having to deal with the "ideological" strictness of FP.

You're considering only a minute aspect of large systems. Any real banking system has much more than a ledger to deal with. And most of it involves huge amounts of state, which you can't just pile on top of RAM, or waste CPU on. Anything that doesn't serve a real business/user purpose is just waste.

And text editors don't need FP to support undo either. I'm not sure what point are you trying to make.

The most successful editors in the market, supporting all the features you mentioned, do quite fine with imperative, and in fact, I'm not aware of any meaningful editor written in a FL.

> Memory is cheap now

Not really. This comment strikes me as if it comes from someone who never dealt with significant amount of data.

FP can be extremely wasteful; take head-tail lists for example, which are the default container in many FPs. They waste object-container data, pointer data, and scatter the list items, causing cpu cache misses.

Claiming that imperative is only better for low-level is extremely disconnected from reality. Try writing a game with FP, and I assure you no one will care for code "beauty" when FPS sucks.

Sometimes, arguing with FP purists feels like debating socialists.

Also: go ahead and downvote me, as apparently FP zealots can't tolerate questioning their religion.

Glad to hear there's commercial interest for Nim!

Didn't expect otherwise. You'd use a logical response if you had one.

My comment is a direct response to the OP who implied FPs are going to "take over".

I'm being downvoted probably by FP zealots who can't deal with the idea that their solutions aren't perfect or universal.

BTW, I'm not "against" FP in general at all. I have used it in the past, and it has useful idioms to contribute to imperative languages, and it's perhaps useful on its own in some domains; I'm just pointing out its limitations.

Debugging and (semantic) renaming. As said, this is the minimum requirements I pose on any language for production use. Nim in VS Code lacks both.

There's some limited debugging support at the generated C code, but this is not sufficient for me.

You'd be more convincing providing a substantial response instead of referring me to "investigate". I've used FP extensively, and they all make mutation very hard, by design.

Do you disagree with this premise? Do you disagree with my claim that the world is dynamic, and that FPs are limited in representing them?

Please address my points specifically if you have anything meaningful to contribute.

The ability to change value by ref is crucial to most real-world apps. This is not surprising, as those apps are modeled to represent a real, dynamic world.

Functional languages tend to disregard this, and demand composition over mutation. While this works for some domains, it's a burdensome complication for others.

Imperative languages are here to stay.

D & Nim (especially Nim) are very appealing from a language perspective, but the lack an IDE undermines the advantages they bring.

I personally won't consider using a language for a meaningful project unless it has a decent debugger, and reasonable refactoring; ie. at least find references & rename.

Beef is building on an IDE, which is a refreshing take, but it's still too early.

Where Mindustry falls short for me is where once the waves are over, you're forced to leave your base and start all over.

I'm not motivated to invest in optimization if the production line is going to be abandoned soon; the game becomes more of a tower defense, and less of a production one.

There's no real drop, but number manipulation. They just label you as "healed" if the tumor doesn't return after a some short period of time, which gets shorter by the year.

Actually mortality rates are at all times high, globally.

The entire medical field is based on opinion and wizardry. We're sicker and weaker than ever. I've healed myself from various conditions by going carnivore.

Take it or leave it.

Cancer is not a disease, but a state of overall body deterioration. You can't fix it; only the body can fix itself.

Stop attacking it with carbs and plant oils, and give it the fuel it needs: unprocessed animal protein and fat.

Also, forgot to mention, that in some analyzers, even if you have no actual code change, the symbols change meaning, and then you're forced to recreate the tree regardless, because you can't change the node-symbol association.

The problem with immutability in a rapidly mutating environment is that the theory clashes with reality.

Anytime a leaf node changes, all its ancestors have to be replaced, instead of just updating the leaf in place. (I'm aware of the red-black node separation, but I believe that in practice most of the tree is constantly regenerated all the time).

I realized it when trying to write a complex analyzer. I had to replace the tree all the way up to the project level. If you combine different chunks of the tree, each with a slight change, you're forced to recreate each of those chunks.

This is extremely wasteful, and no wonder the IDE behaves so poorly.

> the overall size of your code has increased a lot over time, causing performance issues due to issues that have existed for a long time, but weren't being felt yet.

Not really. A simple empty project displays the same problems. You can try going back to 2017 right now with any project you're working on, you'll feel the difference instantly.

Intellisense simply takes longer to respond, and likewqise other editor functions.

Their feedback forums have hundreds of similar reports.