The concept of Rule Beating from Systems Thinking seems apt. You have some goal so you introduce a rule, but if you choose a bad rule, it ends up making things worse. The solution is to recognize that it was a bad rule, repeal it, and find a better one.
Yeah, at first I was comparing it with Netflix where you’re paying for content and it seemed like an awful deal because you already get the content without paying. The thing that made me decide it was worth it is when I compared it to Spotify instead. A service I use multiple times daily where I can get the content for free anyway, but paying to get rid of the ads just removes all of the friction from the experience.
I’ve used React, Vue, Knockout, and just plain vanilla JS, and Vue is what I reach for now for personal projects. React is great if it’s already set up but I don’t want to waste any time with a build system for personal projects. With Vue I just add a link to a CDN, copy paste the hello world code in and I’m off to the races.
Disclaimer: I’m interested in relativity and have been reading about it lately but I’m no authority.
> We all move through time at one second per second, don’t we?
You need to define “move through time”. The only way to measure time is with a clock, and the clock’s motion relative to you affects the measurement.
If you let everyone define “time” as the thing measured by the watch on their wrist, then everyone moves through time at one second per second, but since people are in motion relative to each other and therefore have different frames of reference, their clocks will measure different times.
Since no frame of reference is privileged, there is no “absolute time”. Of course you could pick one and measure every event against that one, but that would be an arbitrary choice.
This is my understanding. If I’m wrong, I’d be happy to be corrected.
I think we're interpreting that in different ways. I'm assuming you read it as something like "words can't be used to communicate (knowledge)", which you're seeking to disprove by showing me that I only gained that knowledge through Wittgenstein's words. Please correct me if I'm wrong.
That's not what I meant though. I meant that words are like signs; they point at the real thing. We must be careful not to confuse the sign for the thing itself. We can't simply rearrange words and assume that what this new sign, this new combination of words points to, is "real". Not all words or sentences point to anything, or anything meaningful. And the trap we sometimes fall into (as philosophers especially?) is assuming that they always mean something.
Edit: First the thing exists, then we use a word to refer to it. The mistake is reversing that, by thinking that by creating new words or combinations of words, we can bring something into existence.
I read the first 100 pages or so of Philisophical Investigations before giving up since I had lost track of the lines of reasoning. Here's what I got out of what I did read though:
Language is far more important in philosophy and life than we think. The biggest takeaway I got from the part of this book I read is a way of looking at problems with the limitations of language in mind. Ask yourself: to what extent is thinking speaking? What is thinking without language? Is it even possible, or is that something else?
There's this interesting idea that has stuck with me, which is that when we say words, "pictures" are "brought before" our mind. Is language (speaking, reading/writing) simply a way for us to conjure up these mental images in other people's minds? If so, how can we be sure that what they see is what we intended for them to see? I think it's clear from experience that the images are mostly right, most of the time. But when they're not, we have misunderstandings. Another interesting statement made in the book (iirc) is that we only need more language when we feel there is a misunderstanding. The word "more" is important in the previous sentence. The idea here is that when we speak, we have some desired outcome from the outset. Once we feel that our speaking has led to the outcome we wanted, we are satisfied to stop speaking. It is only when the person we're speaking to isn't doing what we want, or seems to be getting the wrong mental picture that we need to continue speaking (this is what I meant by "more language": to continue speaking).
There's another interesting area Wittgenstein explores (which I can't admit to following very well), but I'll try to conjure a mental image in your head of it ;). Basically, so far his argument (if I understood correctly) is that "the truth" is the mental images we see and the actions we take, and language is just a means to those ends. He then argues (again, if I understood him correctly) that we usually run into trouble when we take language as the starting point of knowledge. That's not very clear, so what do I mean by that? It's sort of like, words work well when we're using them to achieve some outcome. But they start to confuse us when we use them without a desired outcome from the outset: when we use them to gain knowledge. Words are not facts that we can logically make deductions from to discover new knowledge.
I’ve come across a similar line of thought while reading about capitalism. When technology improves such that it takes less time to perform work, there are three possible outcomes:
1. The labourers finish the work in less time and get more leisure time (production and labourers stay constant, time spent decreases)
2. Some of the labourers are fired since fewer are needed to perform the same work in the same amount of time now (time and production stay constant, labourers decrease)
3. The same amount of labourers work the same amount of time, but produce more due to the increased efficiency. (time and labourers stay constant, production increases)
In my experience, unless you work for yourself, outcome 1 will never happen. Outcome 3 is desirable from a broader perspective because that extra production must be benefitting someone. But I don’t see any upside to option 2. Some people lose their jobs and there’s no extra production. I guess you could argue it would have been a waste for them to continue working on something that could be done more efficiently without them, so in the long term it works out, but in the short term they lose.
I had the opposite experience a few years ago when applying for jobs for after I graduated. I stopped trying to learn about each company and stopped writing cover letters. Instead, I just wrote a 2 or 3 sentence, completely generic blurb about myself, then sent it with my resume to as many companies as I could find in the area I wanted and with the tech I wanted. Only when I heard back did I actually look in to the companies.
I think a key takeaway is that less is more. People don’t have time to read long cover letters and resumes. Keep it as short as possible but no shorter. Cut out everything that’s not your best selling points.
I'm reading a book called Capital in the Twenty-First Century right now, which is all about this stuff. I'm only about halfway through right now, but here are some points from the book I find interesting (all of them iirc since I don't have access to the book right now):
* the author chooses not to use the terms lower, middle, and upper class because doing so just leads to arguments about where to draw the lines. Interesting that so many comments on this thread are just people arguing about what "upper class" means because it's a personal term. He instead splits the distributions of income into three parts, the bottom 50%, the 40% above that, and the top 10% and simply refers to them by centile and decile. The "top decile" has an unambiguous meaning, whereas "upper class" could mean anything.
* there are three distributions: income from labour, income from capital, and combined total income. The people at the top of one distribution aren't necessarily the ones at the top of the other. The book analyzes inequality across different countries across the past two hundred years or so, super interesting stuff
* only when you get into the top 0.1% are you earning more income from capital than income from labour
* inequality of income from labour is far lower than inequality of income from capital and always has been in every society in every period
* inequality from income from labour is _easier_ to morally justify than inequality from capital, but still not necessarily just in any absolute sense
* the bottom 50% owns only about 5% of the total capital
Which regular, simple UI toolkits do you recommend to a web developer who wants to learn desktop development? Do you also have a recommendation on which resources/approaches to use to learn those toolkits?
The course "Computer Systems Architecture" at Queen's University uses "Computer Organization and Design: The Hardware/Software Interface" by Patterson and Hennessy. It's a 400-level course in the computer and electrical engineering department. I can recommend it. Most chapters in it have a "Real Stuff" section where they look at a real world CPU and compare it with the contents of the book to see how the theory actually ends up in practice.
In my head, CPU's have few cores (1-16) but those cores are very highly optimized and have lots of specialized hardware in them. In comparison, GPU's have many cores (thousands) that are comparatively dumber, but that's fine because we use GPU's when we want to run lots of simple operations in parallel, like image processing, etc.
With that in mind, where does this chip fit into the current space? Is it meant to replace both? It contains their two different kinds of cores, which I'm assuming are similar to the complex cores we have in CPU's and the simple cores we have in GPU's. Does this mean that if chips like this are used in the future, we wouldn't have separate processing units?
Also, how does one use an SoC like this? What are its inputs and outputs? How do I access those? Do I need specialized hardware? Can I plug it into my existing desktop? Do they expect a new system to be built around this, or is it a drop in replacement for a part in an existing system?
This is what I do too. I have a pad of sticky notes on my desk and each morning I write what I want to work on today in order of priority. Then I schedule some time in my calendar to work on each thing. I cross off the things I finish, so on the following morning I can see what I didn't finish the day before and add it to the current day if need be before throwing the note out and starting the next one.
> Nonsense; the GPL does not require that one's competitors receive code, but rather one's users.
What's stopping an Intel competitor from also being a user? Am I wrong that all it would take is for an Intel competitor to buy an x86 computer with an Intel processor and then demand the source code? If that's the case, then it hardly seems like nonsense to me.
I was hoping someone would say something along these lines. My only experience with assembly has been on very simple educational platforms: nios ii on an Altera DE0 FPGA and a MIPS subset on a custom architecture made in class. I've seen photos of the huge x86 reference manual and can see how "real-life" systems would be way more complex than the simple world of assembly I've tried myself.
Very cool. Something I really love about assembly programming is that there's no black magic between me and the hardware. I can know exactly what every bit of every instruction means by looking at the instruction set documentation, and I can look at the computer architecture documentation to know exactly how to access each device.
Also, the "API"'s you have to learn are incredibly simple compared to learning API's for every framework and protocol in high-level programming. If devices are memory-mapped, than all I'll ever need to know is load and store. I just need to look at the registers that are available for each I/O device, what their addresses are, and what the bits represent in them. From there I access them all the same way: load and store. Couldn't possibly get any easier than just moving things around between registers and memory.
Compare that to high level development like web development, where you need an understanding of HTTP on top of one of infinite different web backends, written in different languages, all using different libraries with different naming conventions and different programming paradigms, plus knowledge of HTML, CSS, possibly another smorgasbord of frameworks, plus knowledge of decent security practices, databases, operations, and the list goes on.
It's obviously apples to oranges though, and I can produce a lot more real-world value doing web development than I can doing assembly programming, at least just as one person. My point is that I really like the simplicity and straightforwardness of writing assembly, at least in the few very short times I've done it. Maybe large assembly projects have all the same challenges as high-level development or worse.