There is indeed nothing magical about the C ABI. However the C ABI is still a bit special in that its a lingua franca. Processors know (and specify part of) the C ABI. The OS's system call interface is part of (I think) of the C ABI. FFI in most languages works because of the C ABI.

I guess what I wanted to say is that the C ABI is so often used that having a language that doesn't jump through hoops to "talk" it is an advantage.

I'm not exactly an expert in the field of sound but what's really appealing about this is that you can get a simple but boring generated sound with four lines in a browser console (of most browsers, see http://caniuse.com/#search=web%20audio):

var context = new AudioContext();
var on = context.createOscillator();
on.connect(context.destination);
on.start(0);

I'd argue that modern C++ with all it's RAII smart, scoped, whatever pointer classes and references is actually a lot more "memory-safe" than C. More towards Rust than C really.

C memory safety can really be a problem and unfortunately one that can't be fully protected against. However if you're willing to limit yourself to certain allocation/free patterns and have good unit tests running with dynamic memory checkers (e.g. Valgrind) it's not something that will make you sleep bad at night.

I do somewhat disagree though that memory safety is a performance sacrifice (yes, I noticed the "usually" ;)). If you use a garbage collector there is of course a price to pay. It wouldn't surprise me though if a lot of people avoid GCs more because they introduce unpredictable GC cycles than because it GC is significantly more expensive than malloc/free. Malloc/free is not as cheap as one might desire (which is why really performance intensive stuff tends to have custom allocators).

With the memory region stuff that's currently being championed by Rust though the performance sacrifice is likely to largely disappear. I wouldn't even be surprised if Rust's memory allocation overhead can be lower than C's due to the compiler having more information to optimize on and because Rust programmers seem to use less dynamic allocation than C.

C does have a few advantages though. For one it's the one language that everyone talks with. Processors have ABI's written to target C, pretty much every language supports FFI with C. Every platform (save perhaps Lisp machines) has a C compiler. That's a really huge advantage in many cases.

1. Neither really has compilers in the gcc sense since both languages are interpreted.

2. Both Perl and Python can be run as scripts. I would actually expect there to be relatively more Perl scripts than Python scripts since it's well suited for certain scripting tasks (sed/awk-ish stuff in particular is one of its major strengths).

3. In Python you can't avoid the indentation sensitivity, it's part of the core syntax of the language. Trying to avoid it with semicolons will just result in code that's hard for everyone else to read and that style checkers will complain endlessly about.

As for your main question, I would recommend learning both since they have different things to offer. Learning Python will teach you about writing clean and correct programs in an interpreted language (which has less "compile time" checks than C/C++). Learning Perl on the other hand will allow you to write quick text editing scripts for when you just need to get a job done.

Ruby, as suggested on this thread, is a bit of a mix of Perl and Python. It doesn't have the Python culture of cleanless but it doesn't have forced indenting. It's not as hard to read as Perl but it's less efficient in text manipulation. It does have extensive libraries like the other two so it's definitely a practical choice.

Oh, and I suggest not starting with PHP. PHP is better faced when knowing other languages so you already know which "features" make sense and which to avoid.

I think it actually is optimized. If you resize your browser screen the bitmap goes away (which is what you'd want on smaller devices) and the CSS uses the usual @media-type tricks.

A single smaller column is actually kind of common for desktop since it seems to read much easier than full width. Though I'd expect the column to be centered on the page, not put on the right side.

Sodium looks nice. Personally I like reactive-banana but that's mainly because it's the one I know and because it has more tutorials than Sodium. Unfortunately the FRP ecosystem still seems to still be in such flux that there's no up-to-date information on the differences between the available libraries.

It's interesting to compare the FRP situation in Haskell to that in OCaml. In OCaml there's one major well-documented FRP library (React) and only a few small competitors so the choice is much easier. And where in Haskell FRP libraries don't actually seem to be used much in other packages in OCaml the React library is used in utop (GHCI equivalent / advanced REPL) and the very widely used LWT (cooperative threads) library has special support for working with React.

No. Those are two concepts that are orthogonal to each other.

Lazy evaluation vs strict (non-lazy) evaluation affects when stuff gets computed. Lazyness doesn't really let you do anything you can't do with strict evaluation with one big exception. With lazy evaluation you can handle values that would cause problems (crashes, exceptions or infinite loops) if you were to evaluate them strictly. This is why with LINQ you can operate on an infinite collection of values as long as you only use a finite amount of them.

Lazy evaluation works best with a functional style of programming (LINQ really is a functional mini-language inside C#) as reasoning about what your program does becomes complicated if you combine lazy evaluation with mutation / setting variables. With lazy evaluation it becomes harder to know when a variable gets set and consequently what value a variable has at a given time. I suspect this is why the only popular language that's based on lazy evaluation (Haskell) also strongly discourages mutation.

Reactive programming is about things changing. In particular it's about propagating changes. The typical metaphor is that of a spreadsheet, you change the number in one cell and every cell that refers to the changed cell gets updated. In C# with Rx (reactive extensions) this is modeled through observables, which are really just the plain old observer pattern with some nice abstractions. Rx does use LINQ syntax btw, but don't be confused by that since it works on IObservable (reactive) instead of IEnumerable (lazy).

Reactive programming with observables can be thought of as changing a pull model to a push model. Where with enumerables you request (pull) the next value with an observable you get notified (push) when there's a new value.

The observer pattern is very much based on mutation (because you have to keep the list of observers) and therefore doesn't really work all that well with lazyness. There are other approaches to reactive programming that do, Functional Reactive Programming is a name for a collection of approaches to reactive programming that don't require mutation. Because they don't require mutation they work a lot better with lazyness, in fact most FRP libraries are written in "lazy" Haskell.

FRP is definitely an interesting concept. I believe http://elm-lang.org/ is currently one of the best practical examples of it (haven't used it myself though).

But only when it can. Do not blindly trust the -O3 generated assembler, you really must test it.

I agree, optimization can make code less efficient in odd cases. When improving performance one should always measure, measure and measure.

E.g. something I have learned is that your function must be written in such a way that the code that is used most of the time is in front of the code that will rarely be called.

What you describe sounds like the effects of branch misprediction and can be mitigated both by the compiler and the processor. I know that LLVM could move always executed code to the front of the function, or at least it has all the information needed to know if it's safe to do so. Modern processors try to do branch prediction where they optimistically work on instructions of the branch they think code will take. If somehow that process gets messed up you indeed lose performance.

Don't let the IL code fool you, when you look how the IL code gets translated into real machine code (assembler) then it is very close.

Yeah, I would expect that. The main difference (aside from the whole OO support) seems to be that processors have a few registers which are super fast to access for intermediate results while CIL uses a stack for that.

Come to think of it, there's another reason why writing assembly is sometimes useful. New processors sometimes have special instructions for very specific tasks and to use those it can be unavoidable to write assembly yourself (or use the assembly someone else has written). For example code that does a lot of matrix calculations can benefit from the use of SSE but I don't believe compilers often take advantage of that.

Well that and to actually use assembly you kinda have to know a bunch of things that C automagically does right. In particular (on unixy systems) you have to understand some stuff about how ELF works, calling conventions, system call conventions, etc.

I'd warn against thinking you can create more efficient assembly than a compiler though. Compilers at -O3 tend to produce very very efficient code as they're not bound by the limits of human sanity.

Also, for the people reading this who don't have as much experience, note that C# compiles to a bytecode (Common Intermediate Language), not to machine code. CIL, while looking assemblyish is actually quite a bit higher level since it has for example a built-in notion of objects. On the plus side CIL does have plenty of good documentation and is relatively readable so it's definitely a good place to start. For a (somewhat) similar assembly-like language closer "to the metal" I'd recommend LLVM IR.

The ISA documentation is really well written and quite readable even if you have little experience with assembly. What's quite interesting is how few instructions are actually needed. Just be aware that in actual RISC-V assembly there are quite a number of pseudo-instructions which expand to actual instructions, for example j (jump) is an alias for jalr (jump and put the address of the instruction following the jalr in a register, i.e. jump and keep track of where to return to) with destination register 0 (writing to register 0 is a noop). Unfortunately I've never found a good listing of those instructions which are used in the actual .S files.

An interesting aspect of MirageOS is how it approaches building for different platforms (unix, xen). You write your code to work with a specific interface for networking, files and such and at build time select the concrete implementation. So you can test in your normal unix environment and when satisfied can build a Xen kernel. Only the code that's actually used is included so the resulting binaries are pretty small for a kernel.

The mechanism used for the compile time selection of concrete module implementations is OCaml functors (not to be confused with Haskell functors). Few other languages have this feature and it leads to an interesting programming style. For example if you want to have a map with keys of your custom type you define a module and say type t = my_type, add a compare function to it and then say module MyMap = Map.Make(MyModule), the MyMap module will then have all the map functions specialized for your type.