K^2

Problems you can solve after learning semester of C++ don't need C++ to be solved. You need C++ on complex projects with many moving parts and strict performance requirements. If you don't have one of these, no need to bother with C++; just throw some Java Script at it. Of course, there's nothing wrong with using C++ for simple problems. If that's all you know because you just started, you want more practice, or even just for fun, C++ will do. But if you're only planning to learn a language for semester, I wouldn't recommend C++. Python or Java Script are going to be better options for that. If you think you might be interested in taking it further and go into a life of crime software engineering, then that is a good reason to start learning C++. That said, I completely support C++ as requirement for Physics majors. It's nowhere near enough for most things practical (read, things you can't do in Matlab/Mathematica on your laptop), but it's good exposure, and modern theoretical physics is 50% CS. One should know what one is signing up for.

Woah, there. C always had safe methods of handing strings. It just didn't make it hard to write bad code. // Lazy. Unsafe. char string[20]; strcpy(string, input); // If input > 20 chars, buffer overflow. Vunerability. // Correct. Secure. char string[20]; static const size_t kSize = sizeof(string); strncpy(string, input, kSize - 1); // Copies at most 19 characters. string[kSize - 1] = '\0'; // Makes sure copied string is terminated, even if truncated. I've been learning C++ for over 20 years. Can't say I've learned it all.

Also, we have a good place for questions that don't merit their own thread.

Any sensible implementation will JIT it, much like JS code, so performance of a switch on WASM shouldn't be dramatically different from native. There are two things to keep in mind. First, WASM doesn't really outperform JS by a whole lot, because JS itself already runs very close to native. On a good engine, JS has about 20% performance penalty on average compared to native, and WASM falls in the same ballpark. The reason is that no modern engine will run raw JS, but rather transform it to intermediate, optimized representation. C++ to WASM compiler will take exactly the same steps. And then both WASM or JS intermediate will be JITed to native on run time. The advantage of WASM is primarily that you don't need to waste time parsing, transforming, and optimizing JS. All of this has been done in advance, and WASM is ready to be executed directly. Also, you can potentially compile to WASM from just about anything. C/C++ being the most exciting, IMO. This allows for greater flexibility and greatly improves time to interactive and memory overhead, but raw execution performance is not considered a benefit. The second part is that WASM is going to go through a lot of changes in the near future. Consider the current iteration as something of a beta test. Everyone seems to be pretty happy with core instruction set, so I wouldn't expect any great changes, but memory layout and bindings are going to change dramatically. Currently, WASM expects a block of flat memory fed to it, and binding it to JS is awkward. So if you are planning a big project that relies on WASM, it might be wise to wait a bit to see how these things resolve. Edit: Compiler support might also improve in the future. Currently, the two options I've found is to either compile via LLVM, which is a bit of a chore, or use EMScripten, which still uses LLVM under the hood and introduces some bloat. Hopefully, WASM support in Clang will get improved, and maybe other compilers will catch up.

Terraform Mars. Land pressurized rover on parachutes. Realize you don't actually need a pressurized rover anymore.

Get a Pi Zero, install Linux, and that can be your flight computer.

You can write an interpreter and compile it for a microcontroller. That's not a contradiction. Of course, writing a simple interpreter is not that different from writing a simple compiler.

I don't disagree. I could probably write a mostly-compliant C compiler in a couple of weeks. Not an optimized one, mind. Just something that takes C sources and spits out an executable that will do what the specs say it should. I wouldn't touch a C++ compiler with a very long stick. I'd be ok with working on some components as part of a compiler team, but you have to be either extremely naive or extremely stubborn to take on a project of writing a C++ compiler from scratch solo. It'd be months, if not years of work for very questionable gain. In contrast, I have written simple interpreters, and even compilers, in an afternoon. Brainf**k compiler, as an extreme example, took me just a few hours to write, debug, and do some fun projects with.

I've never looked at specs as an actual book, or more than a few sections at a time. But I'd be surprised if 1600 pages is more than just core language specs. Standard libraries are going to bloat that by factor of 10 at least. I'll see if I can find a digital version somewhere. Edit: I was completely wrong. The full standard is not freely available, but there's a 1440 page draft that should be pretty close. Core language is about 400 pages of that, rest being compatibility and libraries. STL (containers) is only about 100 pages, though. There's a lot more standard C++ incoming, though. File systems, networking, co-routines, modules, concepts. C++20 standard is going to be a lot larger than C++17. Also, there's difference between understanding the standard, which you need to know if you're writing a compiler, and in some cases, when you're doing optimization/debugging, and understanding nonsensical edge cases like this, which you need to survive in C++ dev environment. std::string text{"Hello_World"}; for (auto i = 0; i[&text[0]]&='_'; i=-~i); std::cout << text << std::endl;

Famous last words.

Indeed, but it feels a bit too much like BASIC for my tastes. I like the option of introducing some priority via parentheses, hence Lisp-like rather than Forth-like outcome.

Whenever I write my own scripting language, what comes out is usually some flavor of lisp. I'm just usually too lazy to write an expression parser more involved than that. RPN makes ones life way easier. I've written assemblers as well, including for my own VM, but that's way easier. Of course, real compiler authors would say that none of it even counts until you have optimization and linking. But yeah, learn to program in C and x86-64 Assembly. Then you can start reading books on compilers to understand how to make your own. Trying to come up with your own language before learning how existing ones work is definitely a cart before carriage situation.

A magnification device consisting of a single lens acting as both the objective and the ocular and located a fixed distance from subject is called a loupe. This is what you are describing. Fact that modern loupes are typically designed for comfort, rather than extreme magnification, is a separate discussion. If you have access to good lenses, it's much easier to build a compact microscope that will produce greater magnification at greater image quality than any loupe. Hence, nobody builds loupes for such extreme magnification anymore.

I would argue that you are describing a loupe, not a microscope. But distinction isn't relevant to the discussion beyond the name.

Thin Airfoil Theory A bullroarer behaves essentially as a thin airfoil. The important things to note are that if a thin airfoil travels at an angle to the incoming airflow, it will generate lift, and therefore, a pressure difference. That pressure difference depends on the angle to the flow. Secondly, the center of pressure is not at the center of the airfoil. It's one quarter from the leading edge. Since bullroarer is attached near the central axis, the pressure causes an instability. With no other forces present, that instability would cause the airfoil to bob back and forward, but once it is already spinning, Magnus Effect tips the balance, and the instability keeps increasing the rotation speed until the twist in the chord is sufficient to overcome it. At that point, the bullroarer stops very briefly, and twist in the chord starts the spin in the opposite direction. Since pressure differential changes with the angle to the airflow, and angle constantly changes as bullroarer rotates around its axis, you end up with a source of periodic pressure change, also known as sound. As @Zeiss Ikon pointed out, this is identical to how a thin rectangular sheet of wood behaves when dropped. But the above is the reason why it works this way.

I don't think there is a strict definition. Duna locals were trying to improve it, and hoping to turn it into a green world over the generations. So clearly, they thought it needed terraforming. But if we're starting with a dead world like Mars, I have a fairly low plank for where I'd call it terraformed. Can grow plants that produce food and oxygen without pressurized domes, airlocks, or other environment processing beyond basic air filtering. Greenhouse is ok. GMO ok. Can breathe the air without significant ill effects, again, minimal filtering is fine. Passive protection for warmth or moisture conservation is also fine. In other words, if we can get the entire world to something similar to Sahara or Antarctic, where humans can survive with the right equipment pretty much indefinitely, relying only on minimal imports of building materials and water, I'd call it a success. By that standard, getting Mars to state of Duna would certainly be considered terraformed.

Mars is a cold rock covered in toxic dust with just enough atmosphere to be a nuisance. Amount of energy required to give that planet a proper atmosphere is absolutely off the scale. We don't have any sources that would allow us to deposit that much energy in anything like a reasonable amount of time. We could make the Sun do the work, by playing with albedo of the surface, or adding mirrors in orbit. But that will take millenia on top of requiring centuries of work to build the structures. But even supposing that we found a way to get that much energy fast, that will put all the aforementioned toxic dust in the air. That will also take an absolutely crazy amount of time to settle, oxidize, and become harmless. Using today's technology, and stretching plausibility of human cooperation on that scale to the limit, terraforming Mars would still take far longer than we could possibly hope to predict future for. We are talking timescales at very least comparable to span of written history, if not much greater. In that time we might find much better ways to go about it or go extinct.

If that was true, radiation shielding wouldn't be an issue. Sufficiently high energy beam will penetrate air pretty well. Granted, you will see attenuation with distance, and overall range won't be great, but if you're looking for urban combat weapon, low density, high energy plasma beam might actually be quite serviceable. Admittedly, I cannot think of any scenario where railgun isn't a better option, even if you have power to spare either way.

Plasma isn't going to have sufficient density to act as a ballistic weapon. If you want to build anything like a practical plasma gun, setting aside energy requirements, what you're looking for is a particle accelerator to produce a particle beam. At energies where it can qualify as a weapon, the effect would be almost identical to that of a laser beam of similar intensity. Since lasers are quite inefficient and bulky, it is conceivable that a plasma pistol might end up being more practical than equivalent laser pistol. But from perspective of user or observer, effect would be much the same.

Don't ever be sorry to correct. But what you're saying isn't contradictory. General terminology distinguishes between Ancient Egypt and Prehistoric Egypt. Former starts a little before 3,000BC and roughly coincides with the beginning of the Bronze Age in Near East. The Prehistoric Egypt goes at least 3,000 years further back and is primarily neolithic as you've indicated. While majority of pre-Classical history of Egypt is, indeed, neolithic, that time period is not classified as Ancient Egypt. If we are talking specifically about Ancient Egypt, and not just "Egypt in the olden times," we are talking about a civilization characterized by its use of bronze tools, among other things. P.S. Yes, I'm not talking about bronze being necessarily common in all aspects of life. Nonetheless, Ancient Egypt has grown dependent on use of bronze tools in agriculture, not just warfare, which was a contributing factor in the collapse.

The problem with Dayton is that unless you live in Ohio, it's hard to come up with excuse to go there. But it's a great museum. I still think I got a better kick out of Udvar-Hazy, but maybe because I like really big aircraft, and it delivers on that. If you want to see a great variety of "smaller" aircraft with no distractions, Dayton is definitely the place to go.

Ancient Egypt was a Bronze Age civ, relying on writing and counting systems to maintain trade routes with their neighbors, on whom they relied for imports of tin that they needed to make bronze. And without bronze, they could not sustain agriculture on the scale that was necessary to maintain that level of civilization, hence the utter devastation of the Bronze Age collapse. I think I can tell where you were going with this, but Ancient Egypt is an example of civilization that thrived due to its use of metal, and collapsed, partially, due to its shortage. There were plenty of nomadic groups, both before and after the Bronze Age, that managed to get by without metals. So it's not a requirement for a civilization, of course. Just not Ancient Egypt type civ.

That's bad advice. First of all, even building a campfire could be illegal. Local laws can be weird. Second, it depends on materials you use. Even packing rocket engine with gun powder without a licence could be a law violation, let alone other materials. Finally, if that thing goes boom, and that's very likely, you'll have very hard time proving that you did not make a destructive device, and that's violation of federal laws with significant jail time attached. You don't want that. You ought to stick with TRA/NAR rules and get any licensing they require for the engines you're going to test, not only because that's least likely to result in you breaking laws, but also because they tend to provide support if you do run into legal problems. Especially, if you're a member. A good rule of thumb is, if you wouldn't be ok with detonating a petard of the same fuel/weight as your rocket engine in your backyard, then you shouldn't be testing that rocket engine in your backyard. In many jurisdiction, small sugar rockets pass this test. In some, even these don't.

Well, the patent is nonsense, as what it suggests plainly violates conservation of momentum. Ionocraft referenced by @Nuke is a little different. It relies only on the static charges. No EM wave involved. I can see there being a connection if the author of the patent has built a prototype and it "worked" because of the ion movement. But the claim of the patent is that the lift/thrust is due to EM field self-interaction, which is absurd.

Low orbits around black holes are unstable. If you start orbiting from within 3 rs you'll fall in eventually if you don't make corrections. If you end up bellow 1.5 rs escape is practically impossible. Above the 3 rs there are stable orbits, though. So if we're picturing a Solar System with sol-mass black hole instead of the Sun, everything would work exactly as it does now. Nuclear reactors exploit the chain reaction. When nucleus of suitable nuclear fuel decays, it produces neutrons. Or, at least, some products that eventually release neutrons. These neutrons have a chance of being absorbed by other nuclei, triggering them to decay as well. A neutron can, however, be absorbed by something that will remain mostly neutral, or escape the reactor core. So if the net probability of triggering another reaction is less than one, reaction dies out. If it's greater than one, it snowballs out of control. The point where the ratio is exactly 1 is the critical point. Nuclear reactor operates at that point of criticality. There are several ways to control this. You can move rods of nuclear fuel closer together. That increases number of neutrons absorbed by fuel. You can put certain moderation materials in the way. They slow down neutrons, increasing the chance that they get absorbed by nuclei in fuel rather than just bounce off, or trigger a completely different decay mode. You can also put in materials that absorb neutrons and reduce number of them available for the fuel. In its cold state, reactor is kept subcritical. To start the reactor, all you have to do is bring it to criticality. You do this either by moving fuel rods and/or control rods to change conditions in one or more of the ways described above. If you aren't designing a nuclear weapon, where things have to happen in an instant, it doesn't even matter where the initial neutrons come in. There's always going to be some radioactive decay producing neutrons that will trigger the chain reaction. So as long as you keep the reactor critical, it will basically start itself. Then you just want to make sure not to take it supercritical, and also to take away the heat produced by the reactor so that it doesn't melt. You might find this video interesting.