Being confidently programming language agnostic

> Students expect to be able to get help when they have problems. There is a good chance no member of staff knows Julia / Moonscript / ...

For this I have two answers. Past the first year people shouldn't be getting help with "my code won't compile". They should be able to develop the skills needed to search that on google and find SOF links.

The second answer is a question: Why don't members of staff know "Julia / Moonscript / ..." and if they don't why can't they logically reason about what's going on in the language without having used it? I don't know Go but when people have asked me to look at some Go code to see there is a bug I can still reason about what's happening. Isn't that what this article is about? All languages are just mix-matches of common idioms with new ways of expressing them. If the best of the best, those who are teaching the future generations of computer scientists, can't do this it would seems strange to me.

> Some languages make tasks trivial -- while this is nice when you are in the real world, if I want to test student's ability to create something I don't want some students missing most of the work. How do I then mark it?

If the student understands how to use the abstraction then they have likely learned something far more valuable. If you're assigning labs that consist of basic idioms that can be whisked away by common library functions then you might consider changing your curriculum to focus more on solving problems rather then codifying solutions.

> Similarly, if the question was "implement a malloc-like memory manager", well you really have to do that in C,C++,Objective-C, maybe Rust, but it makes less sense in python.

I see no reason why you'd have to write that in C/C++/Objective-C/Rust. If you're going after the idea of writing a working memory manager, and not write me a kernel that has a memory manager, then Python would work great for it. Here is an example:

   class Allocation: 
           def __init__(self, start, size):
                   self.start = start 
                   self.size = size
   
           @property
           def end():
                   return self.start + self.size + 1

   class FirstFit:
           def __init__(self, total_memory):
                   self.allocations = []
                   self.total_memory = total_memory
   
           def alloc(self, size):
                   if not self.allocations:
                           allocation = Allocation(0, size)
                   else:
                           allocation = None 
                           for i in range(len(self.allocations)):
                                   current = self.allocations[i]  
   
                                   if i + 1 = size:
                                                   continue
                                   else:
                                           # Check to see if we can fit inbetween this end allocation and the end of memory
                                           if not self.total_memory - current.end >= size:
                                                   continue 

                                   # We can so allocate
                                   allocation = Allocation(current.end, size)

                           if not allocation: # We can't so return NULL
                                   return None

                   self.allocations.push(allocation) # Store this allocation in our memory allocation table 
                   return allocation[0]
           def free(self, start): 
                   for i in self.allocations:
                           if self.allocations[i].start == start: # Find out pointer
                                   self.allocations = self.allocations[:i] + self.allocations[i + 1:] # Slice it out
                                   return True # We made it!
                   return False # We couldn't find this! PANIC!

This is crappy code but it can be done very eligently and I think this gets across the theory better then doing this in C. In this you can also experiment is far more complex datastructures easily. (What if I think of memroy as a Tree and divide the value of my node by 2 every time it's size is too big?)

> Also, getting a "quick tour" of (say) C++ isn't really useful, students who try to pick it up by just googling are likely to write terrible code. Learning a language properly takes work.

I'd say that's just because of the poor design of modern C++. You can do a quick tour of python and easily get basics, of C and easily get the basiscs, of Java and get the basics, of Common Lisp and get the basics. You don't need to master a language to see where it is applicable.

I'd hope that with embedded DSLs we can get closer. People are already doing lots of it in Haskell, including domains you listed. Of course there is always the risk that one invents an "inner language" with poorer semantics and tools.

This is also true, I would say it's a combo of the two. The more new things at once the more likely it is that you'll be working with something without a good correlation to something in your previous experience. But at the same time having a broader and richer base of experience will make it more likely that you'll have an easier go of it for any of those individual things.

> junior software engineers would be able to write and optimize C++ without much supervision

"Junior" and "optimize c++" just do not typically go together. Even more so if you're talking about deep optimizations like cache hit misses, and not just algorithm decisions or breaking down problems properly.

Just FYI, you can remove all the parameters from Amazon URLs and they still work. EG: https://www.amazon.com/Fluent-Python-Concise-Effective-Progr...

You can also emit the title: https://www.amazon.com/dp/1491946008/ works fine.