Maybe, but their actions should definitely not be oriented to decide how to maximize their profit.
4,474 karma · joined September 28, 2012
I hope the spam filter will respect it!
1 - Wash
2 - Rinse
3 - Repeat
I wonder if that's something that can be trained, just like 'fixing' aphantasia can be trained [1]:
- Sit in front of a table, with a large vase of flowers on it.
- Remove the vase and put it behind you.
- Looking at the now empty table, try to remember the look of the vase on it.
This is how it 'feels' being able to put imagined objects into your FOV. You don't get to actually see it, but you can imagine what it's like to do it.
[1] https://photographyinsider.info/image-streaming-for-photogra...
Maybe the scammers thought "I have tried 50 different mails, and this is the one that got me incredible results"; so this was the one that was popularized, even if the people doing it didn't understand why it worked better than the others.
What's better:
- relying on the common sense of the people in the judicial system to interpret the intent of the law as it applies to a particular situation,
- or relying on the common sense of legislators to write a precise, unambiguous law that will cover all possible situations without negative unintended consequences, and without the law-writing process being influenced by spureous interests and pressures?
The answer highlight why the law is interpreted as is now, with a body of trained public servants analyzing the particulars of each situation, rather than by fanatics trying to follow the letter of the law.
Languages like this may help clarify the intent of legislators so that it is not twisted by clever lawyers; but a human reviewer should always check the relevance of one law to any particular case, and wether the text corresponds to the original intent as applied to a given situation.
That would defeat the point of having the notetaking window open instantly.
Back in the day, that was one of the major selling points of the new language Java over the more common C and C++. Developers don't learn about it nowadays because changing pointers is practically never done outside the most esoteric parts of system programming.
(*) Semantically, at least. The compiler is free to relocate the value to a different memory position in a way transparent to the programmer.
Prudent companies also require the source code to be kept in a holding that transfers ownership to them if the supplier goes bankrupt.
Also we don't known how it will be licensed, but if it's proprietary that could also be a selling point with companies that won't touch Grain's LGPL license.
I'm all for growing children with creative teaching and avoiding rote memorization, but I'd be horrified if that was at the cost of missing the best years for setting the pillars of rational thought.
However, that doesn't seem to be any better in any other web CMS, and Moodle is extendable with lots of open source plugins for any imaginable purpose, so overall it's a powerful Swiss army knife, and it has all the advantages of a self-hosted, open source project.
There used to be a Firefox extension to force text reflow on any website, but recent versions with the new extension API don't allow installing it.
If I zoom in to increase the font size and make it more readable, the text doesn't reflow so it forces me to drag left and right to read the whole line.
There used to be a time where you could have actual adaptive reflowing zoomable text content, but web designers and browser developers conspired to break it and make it worse.
If not, it's just a diploma from some random organisation off the street.
So, wake me up when you know how OpenAI and Google are cooking their models.
I, for one, salute my 160-years-old grandma.
If you had to build the whole runtime yourself from first principles, functional behaviour would be way simpler to define.
Then you missed the point, which is that using mutation a.k.a. cells a.k.a. imperative code when it's not needed is a dinosaur to be culled. But you need to understand when it's not needed to realize this.
Functional reactive programming adoption is not something caused by the state of one particular stack; as it is also being adopted by game engines, big data analysis tools, development environments like web notebooks, etc. People throughout the industry are seeing the value and are simplifying their tools thanks to the paradigm.
> Functional programming claims to have abstractions that make the latter more simple than imperative programming, which may or may not be true.
Look, I get it, I really do. You don't see the possibilities of the functional paradigm and don't know how and where to use it effectively, so you keep criticizing the small part of it you do understand. I've been there, done that (though it was a long time ago).
With that attitude you can stay comfortably in a corner and be impervious to the changes the industry is undergoing, and miss out on a really cool programming style out of prejudice. Or you can accept the intellectual challenge (which it certainly is, especially for someone who has spent his entire career with a single style), and know concepts that those who learn them agree that they improve their programming even if they do not adopt them 100% for their work.
It's up to you. I don't gain anything with this, so I will not try to convince you of it.
Not something I said. I explicitly mentioned the functional core, iterative shell architecture, and explained how you need to understand functional enough to know when it's a good time to not use it.
At this point your posts look like someone making fun of a complex technology they do not understand, without really approaching any valid criticism of its real shortcomings, because such criticism require a thorough understanding of the thing being criticised.
> Functional programming that introduces or models state requires more abstraction, and then complexity.
I'm pretty sure I've said exactly that. Good thing we agree on it. But you don't seem to realize that this fact is only true for handling state, and not for other aspects of programming.
> Imperative programming with state is as simple as functional programming without state.
You've never tried to compose multiple asynchronous event streams of complex data types from different subsystems into one single user-facing unified presentation, have you? Your assertion is simply not true. Such feat is way simpler in functional reactive style, and a true nightmare in an imperative multithreaded program. That's why web frameworks are evolving to handle more and more reactive functional patterns for compositional asynchronous tasks.
All abstractions introduce complexity in terms of indirection and the need to particularise to different instances. Imperative and functional simply happen to have a different approach to where they place complexity and what parts they simplify.
Imperative makes it easy to update state, but then it forces you to keep in your mind every remote part of the program where your symbols may be modified (which is way harder than most developers recognize). Functional requires more work to keep track of state, but on the other hand it allows much better control of program composition and deep complex hierarchical data transformations.
As they say, use the best tool for each job. It makes no sense to deride a key wrench for being more complex than a hammer and being worse at hitting nails.
Sure you can create good programs without them, and the first developers often did; but nowadays a good programmer is expected to understand why those techniques are relevant and what kind of problems appear if you decide to ignore them on purpose.
For complex modern programs, specially on the web, the 'pure functional core with iterative shell' (possibly imperative, but it can also be funcional reactive) is an increasingly common architecture that the most popular frameworks are converging to.