One fairly compelling argument in support of Musk's viewpoint is that if it is possible to create a simulation capable of supporting our existence, then it is also likely that we're already living in such a simulation.
That's not supporting Elon's argument, that's Elon's argument.
Otherwise, you'd need a specific reason to believe that we're living in the one true reality that underlies countless (possibly nested) simulations. Denying that we live in a simulation amounts to a special pleading fallacy.
You still need to show how simulations can be nested one within the other.
That assumption is not trivial at all. How could such nested process appear spontaneously, and why anyone would want to allow nested simulations to happen within their beautiful walled garden to begin with, instead of optimizing them away?
So Chile doesn't represent a planned economy; it represents a market economy which has formed a stable, closed, politically dominant class of relatively wealthy people.
Actually that's not bad at all for a beta version of a new cheap technology.
It may not look the best for random photos (like those in a magazine), but it would be great for showing diagrams (useful in companies); and advertising companies might fine-tune their designs to be displayed on that and still look good.
And surely, it it catches on, further versions will have higher resolution and thus more accurate colors.
But in terms of a language that entices you in and makes it easy enough for you to WANT to learn it, it's probably the last one I saw.
Certainly the last popular one, side by side with Hypercard. Which is utterly sad, as we could build much better environments like those nowadays for easy prototyping and easy distribution, with everything we have learned since then.
But it just seem that developers are not interested in creating those tools anymore, programming environments for people who will never learn how to program complex systems; any novice tool is oriented to teaching the first steps towards becoming a full-blown professional, and there's a glaring hole for a tool helping people write simple and easy applications that go beyond the "if-this-then-that" trivial rules.
TFA: We are surrounded by powerful, capable computers, and we use so little of their maximum capability.
No, we are surrounded by powerful, capable computers, and we run them into the ground interpreting (or JIT-compiling) Javashit frameworks to interpret/JIT-compile Javashit code, and then use that to manipulate the DOM on the fly, all to produce a little fade-in/out effect to make up for the delay while other Javashit contacts an ad auction amongst another few dozen offsite machines bidding for the right to serve yet more Javashit, when all we wanted to do was read static text on a http://motherfuckingwebsite.co...
Yes, we do. And the fact is that we like it that way. We could all be using command-line tools on CP/M to launch our single-execution sovereign application; but most of us don't, because we enjoy the benefits of a flexible system - where you can distribute software through the Internet, run many applications at the same time in a windowing environment, or port software between different architectures.
Processors today are orders of magnitude faster and more capable than just a few years ago. There shouldn't be a question that our apps run faster on them.
The problem is we are loading them down with extraneous cruft. Remove the bloat and you remove the problem. Throwing hardware at it may solve some of the problem - but that is just a bandaid, and definitely won't allow you to lead the market if your competitor is producing leaner, faster code.
What you gain by the layers of complex software is mostly flexibility. Older computers had vastly slower processors that could run application at speeds similar (or even slower) to those that we use today, but:
- The software came distributed through magnetic media, or had to be run on a centralized mainframe accessed through a dedicated network. - You could only run one program at a time on a workstation. - Interpreted languages were awfully slow - you wouldn't run full-fledged applications on top of them. - Forget about multi-platform; most software was tied to a single environment, and porting applications to different platforms required wizardry-like knowledge of several operating systems and architectures. - Of course, such a thing as a "hypervisor" allowing several OSs to run on the same machine at the same time was unthinkable.
Sure, there could be a lot of streamlining and cutting corners to gain speed - on problems that you understand thoroughly; for those problems, such streamlining it is still possible and frequently done, as long as you don't need the flexibility because the problem won't change.
What that "bloatware" gains you is the possibility to work efficiently and explore new workflows on problems that you barely understand, or not at all, without having first to assemble dedicated of engineers to build the software to solve the problem.
What the GP fails to understand is that "voluntary exchange for mutual benefit" inevitably leads to corporatism, as controlling the market is benefiting to the owners and managers of the largest corporations; a "free market" does not survive for long when people act in pure self-interest.
Pure capitalism is a pipe dream as theoretical communism, depending too much on the good will of its participants to comply with the rules required to keep the system working (such as ensuring that voluntary exchanges are trully benefital to both parties, and not extortions from the strongest party that "can't be rejected").
>there's always some imbecile who can't grasp the meaning of words
Which proves my point. No matter how carefully you think you have selected your words, or how well you think you have used them, non-mathematical expressions are inherently ambiguous and therefore require the other party to interpret them. Communication requires participation of both ends of the channel, and you can't control what happens at the other end.
I tend to think if a specs to code tool were implemented tomorrow, my job would shift from writing code to interpreting what my customer said they wanted into an actual spec that this tool could use to create a correct program. I don't believe the standard person is actually capable of creating a spec specific enough to implement.
How many spreadsheets have you been commissioned to write in lieu of your customers, who are unable to decide by themselves what columns to put in them or how to filter them?
Given the right tools, of course people are able to use them to solve their own problems, using knowledge from their own problem domain. I see them doing it day in, day out with the kind of data processing that can be implemented in Excel.
In fact, if you think about it, it makes much more sense than hiring some outsider with no knowledge about your businesses, and teach them about your work barely enough for them to build a program that does the same thing. Of course there will always be a place for external consultants that analyse your practices and teach you how to make them better, but that's not the common case and doesn't apply to the majority of developments.
Many of us who get paid well, get paid well because we can take vague, poorly written specs, figure out the real world business requirements and fill in all the missing parts
The thing you're missing is that, if someone automates the specs-to-code part, the end users can do the "figure out the real world business requirements" all by themselves, and only pay for the software platform, cutting out the middleman.
It worked for processes that can be represented as Excel spreadsheets, you only need to build some domain specific languages for the other most common businesses use cases to replace a large part of the work currently done by grunt developers.
Those guys wouldn't be the first ones to be surprised when people uses their open-sourced product in ways they never intended for releasing it under a license they didn't understand.
Yet even those of us who think we understand FLOSS don't know how it will work out in the long term or even if it is viable at all, at least in its current shape. It's a whole new economic model made possible by a radically new technology, and it combines some ideas from extreme communism (radical lack of proprietary control) with some ideas from extreme capitalism (radical competition and meritocracy). I say, let's those guys fund it so we can figure it out with real-world examples, instead of killing it because of a fear for the unknown.
If it were possible, you could use gravity for FTL communication, possibly even allowing you to violate causality.
What makes you think that this make it inconceivable? I wouldn't find it any more strange than the many-worlds interpretation of quantum theory, and that one has many supporters.
A lack of causality would mean that our perception of causes and effects is just the biased way we see the world, as a projection of a small subset of events (those with a direct causality relation) within a much more complex reality, where events can exist in a sequence without a direct causation.
In fact I would argue that many SF works about time-travel have conceived exactly that. The fact that it has a small chance to be true doesn't mean that we can't conceive it.
Slashdot Mirror
That's not supporting Elon's argument, that's Elon's argument.
You still need to show how simulations can be nested one within the other.
That assumption is not trivial at all. How could such nested process appear spontaneously, and why anyone would want to allow nested simulations to happen within their beautiful walled garden to begin with, instead of optimizing them away?
I'm not sure I follow you. If you consider the hydrological cycle to be renewable, why not the sun energy which powers it?
The sun has been providing stable energy for billions of years, and it's the thing that ensures the hydrological cycle remains steady.
So, it is the end-game of a market economy?
By that criterion of yours, the expression "renewable energy" is an oxymoron.
Actually that's not bad at all for a beta version of a new cheap technology.
It may not look the best for random photos (like those in a magazine), but it would be great for showing diagrams (useful in companies); and advertising companies might fine-tune their designs to be displayed on that and still look good.
And surely, it it catches on, further versions will have higher resolution and thus more accurate colors.
Certainly the last popular one, side by side with Hypercard. Which is utterly sad, as we could build much better environments like those nowadays for easy prototyping and easy distribution, with everything we have learned since then.
But it just seem that developers are not interested in creating those tools anymore, programming environments for people who will never learn how to program complex systems; any novice tool is oriented to teaching the first steps towards becoming a full-blown professional, and there's a glaring hole for a tool helping people write simple and easy applications that go beyond the "if-this-then-that" trivial rules.
And how long did it take to build a new application?
How fast did your dynamic programming language with generics run?
And could your users buy commercial software downloaded through an online store to a portable device?
And how well did your grandma use it?
Are you sure you had the same?
Yes, we do. And the fact is that we like it that way. We could all be using command-line tools on CP/M to launch our single-execution sovereign application; but most of us don't, because we enjoy the benefits of a flexible system - where you can distribute software through the Internet, run many applications at the same time in a windowing environment, or port software between different architectures.
Processors today are orders of magnitude faster and more capable than just a few years ago. There shouldn't be a question that our apps run faster on them.
The problem is we are loading them down with extraneous cruft. Remove the bloat and you remove the problem. Throwing hardware at it may solve some of the problem - but that is just a bandaid, and definitely won't allow you to lead the market if your competitor is producing leaner, faster code.
What you gain by the layers of complex software is mostly flexibility. Older computers had vastly slower processors that could run application at speeds similar (or even slower) to those that we use today, but:
- The software came distributed through magnetic media, or had to be run on a centralized mainframe accessed through a dedicated network.
- You could only run one program at a time on a workstation.
- Interpreted languages were awfully slow - you wouldn't run full-fledged applications on top of them.
- Forget about multi-platform; most software was tied to a single environment, and porting applications to different platforms required wizardry-like knowledge of several operating systems and architectures.
- Of course, such a thing as a "hypervisor" allowing several OSs to run on the same machine at the same time was unthinkable.
Sure, there could be a lot of streamlining and cutting corners to gain speed - on problems that you understand thoroughly; for those problems, such streamlining it is still possible and frequently done, as long as you don't need the flexibility because the problem won't change.
What that "bloatware" gains you is the possibility to work efficiently and explore new workflows on problems that you barely understand, or not at all, without having first to assemble dedicated of engineers to build the software to solve the problem.
What the GP fails to understand is that "voluntary exchange for mutual benefit" inevitably leads to corporatism, as controlling the market is benefiting to the owners and managers of the largest corporations; a "free market" does not survive for long when people act in pure self-interest.
Pure capitalism is a pipe dream as theoretical communism, depending too much on the good will of its participants to comply with the rules required to keep the system working (such as ensuring that voluntary exchanges are trully benefital to both parties, and not extortions from the strongest party that "can't be rejected").
Early automobiles certainly benefited from existing wheel engineering and shock absorbers. And there's a reason why horsepower is called that way.
>there's always some imbecile who can't grasp the meaning of words
Which proves my point. No matter how carefully you think you have selected your words, or how well you think you have used them, non-mathematical expressions are inherently ambiguous and therefore require the other party to interpret them. Communication requires participation of both ends of the channel, and you can't control what happens at the other end.
>>"I do not care, I only listen to the good stuff which is usually at least ten years old but more often older."
>There's lots of good new music, you just need to find a good way to filter out the crap.
I think the GP has found his method.
If you believe words convey accurate information over IM, you know shit about words and IM.
s/virtual reality/augmented reality.
This freely available visual novel is a must-read, now that corporation-driven virtual reality is becoming real (pun not intended).
Fascinating. Does that particular paradox have a name? It reminds me of Monty Hall's game paradox.
You, sir, broke my parser.
At the very least, this means that all users who do think logically will get rid of the need of developers working for them.
How many spreadsheets have you been commissioned to write in lieu of your customers, who are unable to decide by themselves what columns to put in them or how to filter them?
Given the right tools, of course people are able to use them to solve their own problems, using knowledge from their own problem domain. I see them doing it day in, day out with the kind of data processing that can be implemented in Excel.
In fact, if you think about it, it makes much more sense than hiring some outsider with no knowledge about your businesses, and teach them about your work barely enough for them to build a program that does the same thing. Of course there will always be a place for external consultants that analyse your practices and teach you how to make them better, but that's not the common case and doesn't apply to the majority of developments.
The thing you're missing is that, if someone automates the specs-to-code part, the end users can do the "figure out the real world business requirements" all by themselves, and only pay for the software platform, cutting out the middleman.
It worked for processes that can be represented as Excel spreadsheets, you only need to build some domain specific languages for the other most common businesses use cases to replace a large part of the work currently done by grunt developers.
Those guys wouldn't be the first ones to be surprised when people uses their open-sourced product in ways they never intended for releasing it under a license they didn't understand.
Yet even those of us who think we understand FLOSS don't know how it will work out in the long term or even if it is viable at all, at least in its current shape. It's a whole new economic model made possible by a radically new technology, and it combines some ideas from extreme communism (radical lack of proprietary control) with some ideas from extreme capitalism (radical competition and meritocracy). I say, let's those guys fund it so we can figure it out with real-world examples, instead of killing it because of a fear for the unknown.
What makes you think that this make it inconceivable? I wouldn't find it any more strange than the many-worlds interpretation of quantum theory, and that one has many supporters.
A lack of causality would mean that our perception of causes and effects is just the biased way we see the world, as a projection of a small subset of events (those with a direct causality relation) within a much more complex reality, where events can exist in a sequence without a direct causation.
In fact I would argue that many SF works about time-travel have conceived exactly that. The fact that it has a small chance to be true doesn't mean that we can't conceive it.
Here, hear the pronounciation.
I've found also a phonetical transcription linked from here.
By that principle, we are going extinct even if we learn interstellar travel.