I've never wrestled with OSX terminals but lately I had to switch to pterm (a version of putty stripped down to be just a terminal without all the dialer stuff) on linux because everything else is either way too primitive, or uses libvte2, which does not implement some VT escape codes crucial to working on various network gear. I'd imagine since putty can be built using macports that pterm could be as well. Kinda sad that the most competent linux emulator now hales from a Windows port.

My preference would be for a) pass tests locally b) send a PR to a branch (the two can be flipped if the tests are run based on PRs) then c) initial light code review/revisions then d) merge to development/beta/testing/staging branch e) bleeding edge people can try it out and offer more code review then e) push to production. Step d) should pretty much happen as long as the code is not nefarious and fixes more than it is known to break and does not make a huge mess -- not all contributers to a project will have the patience to get code "perfect" so the standard should be "good enough." Even such people are more likely to return with refinements if they see their work accepted, but if they don't, if their patch is an improvement even if not thorough, the users win, and other developers will have less to fix. But, all this requires a certain minimum number of active developers.

Another critical difference between a linked list and an array is in its mutation operations, especially shifting. To shift an array (supposing "array" means approximately what it does in C) you have to move all the elements. To shift a linked list you simply re-point the head pointer elsewhere and throw away (or use) the removed elements. There are pros and cons to both of these structures when it comes to efficiency and thread-safety.

There are a lot of factors at a lot of levels. A completely interpreted language will be slower in general than a compiled language which in turn will be slower in common cases than a language that is compiled to an intermediate representation and utilizes runtime optimizations like JIT. At the same time, a language that is too bare bones may be very fast, but if it takes a lot of effort to write anything in it there will be less time/work left over to optimize it. A language that is bare bones but has a lot of libraries will often accumulate inefficiencies when interfacing between these libraries due to having to transcribe data formats or incompatible locking schemes. A language that is too abstract will have layers and layers of classes or constructs and eventually the compiler will find a reason not to optimize it, and the reasons will be buried too deep for mere mortals to fathom. Or, probably even more common, it will manage to bury locking mechanisms too deep inside the abstractions so the program will spend most of its time waiting for other parts of itself to do something. A language with a garbage collector will be faster than a reference counting language, except for the 100ms every second or so where it takes a pit stop and does nothing at all. Which will require it to have special intricacies and workarounds to handle real-time tasks. A functional or declarational language will usually stress immutability, and will burn through memory/cache if not coded with care of if the compiler is not up to snuff, and that will slow it down. An imperative/procedural language is more likely to encourage mutable objects, and then introduce more locking or copy-on-write mechanisms which will be more CPU intensive. So, I'll give you a much simpler answer: Good documentation makes a language fast, because it tells you how to write fast code, gives you a clear idea how and why things work, gives you pointers to educational material that helps you write better algorithms or avoid mistakes, and lets you find wheels before reinventing them.

Any static content that goes over the network will almost always benefit from being compressed. Dynamic content, however, will A) use CPU on the server side where it is precious and B) open you up to cryptographic attacks like BREACH/CRIME.

I learned in this order: BASIC, C, ASM, PASCAL, C++, ADA, AWK, Perl. Everything from C to ADA was in actual courses, the others were by myself. I have to say that although I would not start a new programmer on C, it was the one that taught me the most about data structures, and I learned the most about a wide variety of programming concepts from Perl. That's why I've participated (lightly) in the development of Perl 6, and I have to say, it has set itself up to be a fantastic learning language. For example, much of the typing system is optional, and you can get as strict as you want gradually, so you can start with easy code with just variables, then get into types and multi-dispatch as the students get more sophisticated.

I don't do web devel mostly. The few times I did write something, it struck me that the DOM tries to cram things into a tree which are not tree-like (no, sorry, arrays are not trees, if you treat them that way, your code gets really ugly and tedious.) To compensate for this, we end up with all sorts of crazy inheritance systems and an explosion of tags and things that are there but not really there or unenumerable because they instantiated from templates. Hopefully as webasm comes in, things will come to resemble a more conventional programming environment.

I would suggest before you learn to program, you learn how to use some of the tools used to program, like the command-line and a version control system like git. You can do this by contributing to a project that does not actually have code in it -- like a documentation or users-guide project. This way, you start to get a feel for the work-flow and it does not distract you while you are trying to concentrate on learning a language. If you feel like blogging about your experiences learning to write code, Perl 6 would love to have feedback about how easy it is to learn for a brand new programmer... though we don't quite have a "learning to program in" guide yet, https://perl6.org/getting-started/ might be enough. The community is very friendly and would probably even be extra friendly to someone who was helping to improve the documentation for new users.

emacs

There are programming fields i the gray area between programming and design work where math is not very important. There are also some business logic areas where all you need to know is basic logic and data types, so not very much in the way of math. What you cannot do without math is develop things like game physics engines, large-scale applications where complexity analysis is needed, and just about anything robotics related except for the mmore trivial things. Those that are very good at math generally consider jobs that do not involve math to be boring, so they won't compete for them -- but on the other hand, there are more people by definition competing for jobs that only require average math skills. You should still try to improve your math, especially since improving math improves your thinking, but concentrating on logic and understanding data types and representations (for example, knowing how floating point numbers work inside) can get you a long way.