Being confidently programming language agnostic(blog.bradfieldcs.com) |
Being confidently programming language agnostic(blog.bradfieldcs.com) |
I have fallen in love with Python because it's so damn easy to get productive, and I really want to be a great Python programmer. That takes a lot more time than the OP suggests, and requires you to immerse yourself in the patterns of the language and in the community, in my opinion. Not just dabble a bit and then check a box saying "I'm a polyglot!"
Its a wonderful read. Will really unleash the pythonista inside of all us!
If you really want to go deeper, I suggest these as well:
https://goo.gl/CY6zPu https://goo.gl/UbMrTb
Those shortened links take you to amazon (not affiliated in any way, FYI, just though the length of the URLs was obnoxious)
Those are the definitive python programming books I came up with anyway.
While we are at, I have to say once I learned to really code Pythonically I find that I can apply the PEP8 standards to almost any language. Admittedly, I, like John Siracusa, am a top level language debutante and don't live in C or C++ production code (I sometimes use objc but swift is...easier :). I remember learning C, and thanks to arduino I certainly using some varient of C/c++ there more heavily, but my coding style follows more or less the pythonic standard (with PEP8 being the backbone of that).
food for thought, people of hacker news!
Just FYI: Hacker News already shortens links, no need to pass them through a 3rd party service. I personally prefer seeing a readable domain name before clicking (as I'm sure many others do as well).
As the old "Real Programmers Don't Use PASCAL" article says,
> The determined Real Programmer can write FORTRAN programs in any language.
That's why Haskell exists. It's the computer scientists' best attempt so far to create a language in which it's impossible to write FORTRAN programs.
Don't try to be clever, do the simplest (and most readable) thing that will work.
Try "import this" in an interpreter to read a bit more on the above.
Apart from that... What's readable tends to be the best option.
My first Ruby programs were very Java like. I doubt that my first Java programs were C like, if you use classes and methods it just can't be. No problem with using Python and Ruby together. They are maybe like German and English, close but clearly distinguishable. And Javascript, Perl, PHP, Elixir... too long to write about.
A consequence of multilingualism is that one starts noticing the differences in the implementation of the same features in different languages. Some are smooth, others are frustratingly hard to use or to remember. A quick test on a trivial nuisance, you must not Google it: in Python it's array.join(",") or ",".join(array)? And "1,2,3".split(",") or ",".split("1,2,3")? I remember only that "," goes to the opposite ends in the two expressions and I can't understand why that should be good.
The second one is the typical OO pattern where you ask an object to perform some operation on itself. This is how split works in just about every OO language - if you have trouble remembering it, it might be helpful to remember split can be called without any parameters - in that case your alternative variant won't make any sense.
And for things like pattern matching, I've played around with doing similar things in Ruby, too. For example, in Elixir you might write a method that should only ever return `:ok`, and a pattern match like this...
# if :ok, nothing special happens
# if not :ok, "MatchError" is raised
:ok = Fooer.foo(foo)
def ok!(obj)
raise "match error" unless obj == :ok
end
# if :ok, nothing special happens
# if not :ok, "match error" is raised
ok! fooer.foo
If you want to split a given string into smaller strings with an arbitrary delimiter, which instance should you call the method on?
Like you, I'm basically a C programmer at heart. But, to get efficient at some of the Maple code I had to write for my graduate work, I learnt a number of their functional tools so I now think quite a bit about using some of those as part of my toolset. I'm still largely a C-style programmer, though.
Working with the SymPy project helped me in my Python style.
Universities tend to focus on paradigms and patterns, and typically force a student to learn at least 3 languages throughout their education (much more if they want to). Just in my undergrad I learned C, C++, C#, Objective C, Swift, assembler, Java, Go, Javascript, Python, and Haskell. My personal experience is that university grads are much better at adapting to new languages than someone with 4 years experience in only a single language.
That's of course not to say you can't do the exact same sort of education without going to school (and probably in less time).
I happily picked up the actual language very quickly. It was the surrounding ecosystem of compilers, build tools, debugging tools, libraries, standard patterns and best practises that was too deep for me to become proficient in.
That said. Learning every language you can is definitely beneficial. Just don't expect to hit the same level of productivity in all of them.
Try replacing shell, Structured Query Language, and C with the same language. I won't say that it can't be done, but I think you'll lose a lot if you succeed.
Pipe dream, it would seem, but: I feel like the energy spent picking up new things could be used so much better going deeper and building more with established tools--tools hardened by collective reuse.
What takes more time is the standard library, common libraries, tools. A good example of that is iOS development in Swift. Learning the language is almost negligible compared to learning all of the technologies and tools. But coming from Android, I think I'm close to about 50 % of full productivity after two weeks.
I never understood why there's so much focus on the "x years experience in y" in the industry. A solid developer should be able to become fluent in any language and technology within a month or two.
I don't think any developer can become fluent at a new language in 1-2 months. I have seen so much terrible code over the years the compiles and appears to run just fine but with massive performance issues, poor design, unreadable, security issues, memory leaks, etc. etc.
I see learning the syntax of a language to be something like 0-5% of the effort of mastering a language, knowing how to properly use a language really does take years. Although I agree that # of years of experience is not a perfect metric.
It's because grading CVs is hard.
In my current company they were looking for a Go programmer. I never wrote a single line Go before, yet they hired me and now I am writing Go. Then we had a deficit in the iOS team, so I learned Swift and now work on our app.
In that set of things, a new language is somewhere lower in the priority list for learning new things. Sry.
1. A great book that covers multiple paradigms of programming is Roy and Haridi's "Concepts, Techniques and Models of Computer Programming" https://mitpress.mit.edu/books/concepts-techniques-and-model... . This stands hand in hand with the better known SICP.
2. Folks in the CS and programming world seem to ignore bleeding edge work being done in the arts space. To get a broader view of languages than "characters that go into a plain text file", expose yourself to the live-ness of the following -
2.ø Smalltalk - one of the first fully available language and runtime that is still usable today.
2.a Max/MSP/Jitter - by David Zicrelli and Millet Pickette's - Visual data flow programming language with decades of dominance in the Computer Music scene.
2.b SuperCollider - for architecture lessons as well as another multi-paradigm language.
2.c Impromptu - a Scheme based live coding environment for music and visuals by Andrew Sorenson. Normal REPLs will bow in front of most "live coding" languages used for music.
2.d Ixilang by Thor Magnusson - another live coding language, where the language is in a sense inseparable from its run time environment. The current running behaviour of a textual program could also depend on how the program evolved.
In short, break out of normal modes of thinking and attain Turing nature, at which point you can proclaim that all languages have Turing nature and yet retain your discriminating view.
Any language is a means to an end, not the end itself.
Focusing on languages and language constructs is of value to those in academia and those working solely in the domains of computing and computer science. For the rest, it is the equivalent of navel gazing, the equivalent of focusing on grammar, when the task is authoring a novel.
But I actually think we (software devs) need to focus more on mastering languages as opposed to learning many languages at a surface level.
Books like "Effective C++" (https://www.amazon.ca/Effective-Specific-Improve-Programs-De...) really showed me the huge divide between knowing a language and mastering a language.
But software development is not about writing pure functions, it's about writing applications, so frameworks and good practices is more important than the language.
I recommend reading Exercises in Programming Style by Cristina Lopes as a good starting point.
CPU is managed by the Kernel, and Memory is managed by Perl/PHP/Python/Java;
C teaches you something very useful, which is how the computer works under the hood. Most things you do in C loosely match to what the computer does, and learning C helps you understanding the computer.
I'm not saying that it's a good language to start with, but it's okay. Unlike C++.
IMO, C++ is the worst possible language to start with. The reason for this is that C++ tries to support everything, often using handy but cryptic syntax. C++ doesn't guide you to program one way or another, it simply adapts to every possible way to solve the problem. This might be good on the hands of someone that already knows how to solve the problem, but it's completly overwhelming for a begginer. It feels like you're taking the wrong turn at every step.
A much better alternative would be JavaScript. Yes, it does have flaws, but it's much simpler and has personality.
I wasn't judging C++ as a beginner language. I wasn't judging C either.
As long as that's remembered, I think the opposite is probably true: knowing C helps a lot to learn C++ (and vice versa) as opposed to learning either from scratch.
Nah. Learn whatever takes your fancy. Or whatever you think will get you a job. Or learn whatever you can get tutored in because it's almost always easier to learn when you have someone you can ask questions to in person.
Learn structure and logic, but don't tell anyone they're less of a programmer because they use X instead of Y.
Scheme for beginners, Python for web scraping and data munging, C for concurrent network and systems programming, and some small exposure to Java, Haskell, Standard ML, awk, yacc/lex, C++, and your mobile environment of choice depending on which classes you took.
Many were upset by this "very theoretical" approach, as they'd prefer to have immediately employable skills in JS-framework-of-the-week. Instead they were taught how to think independently of a particular language, and to get comfortable with learning new ones.
From a programming craft perspective, it was a little disappointing that we were never focused on advanced language features or idiomatic code, but I felt I had a solid enough base to self-teach that sort of thing.
After I finished my undergrad degree I had an "exit interview" and I mentioned that this was one of the things I liked about the curriculum, because it helped me see that the abstract computing theory is what is important, and languages are largely a matter of syntax and convenience. The professor's response was that they so often hear the opposite, that students complain that they don't learn languages that employers want.
Also, if they need to quickly munge some text they'll have a dozen Java classes and several poms.
I think this has real practical consequences for decision making (not knowing alternatives etc).
I think the personal motivation that someone brings has a lot to do with how they fare short term and long term in this regard. Yes, a good University program will teach you the concepts and underlying theory expressed by language implementations; coming out of such a program you will absolutely have the jump on someone that jumped into JavaScript programming informally. You will adapt more quickly to other technologies faster, too, as you have the essentials to make that shift whereas the JS guy may not.
Having said that, if you attended and graduated college because it was something that you were "suppose to do" or because it would get you a good job and computer science was just a way to a good job after college (with no particular interest in the field otherwise)... over time the more personally interested developer that learned JS informally will likely catch up with you and overtake you.
My formal education is in music composition. However, I was programming assembly on the old 8bit machines when I was a kid. 20 years on as a technology professional, I devote large amounts of time to learning concepts and theory that aren't strictly necessary for me to program something that works well enough for my customers. I learn these things because I'm genuinely interested in the underpinnings of what I do and because I want to perfect my professional skills... not for an employer, but for my own edification: I care about what I produce because it's me producing it. There are many of my friends that did get formal education in computer science and I've surpassed them in both quality of output and overall understanding. (BTW... don't get me wrong, I have colleagues that have formal education in computer science AND the same sort of professional dedication I have... a good number of them far exceed my knowledge and understanding and I very much look up to them. Still, I'm glad I don't have to feel ashamed standing by their side professionally either).
Most of my classmates don't usually "learn" a language. They do an assignment by copying, hammering at the computer, or just asking for help. The basis of how university is set up is antithetical to the learning and exploration of new programming languages. This is based on one simple thing that most universities do and is very easy to fix.
Don't mandate a programming language for you assignments
If one of your projects is something like "scrape a webpage for X data" you wouldn't want to write that in a bash script (which I've been made to do [0]) I'd want to do that in Python with BS4. Or if your project is to write a parallel dot product function you wouldn't want to write that in C (which I've been made to do [1]). I'd want to write that in Julia.
Even in my class that I took for exploring programming languages we were forced to use C++. We were writing an interpreter using C++ which I'd rather have done in some Lisp-like languages.
Unfortunatly I've not been able to make the design decition to play with other language (in school) to see how they will better impact the development of these applications. I've not had to prototype stuff to see what language it will work best in (in school). These are decitions made for me.
I've found that this isn't how things work, at least for me, and I'm the one who is told "Do X" and I pick a way to do it. Whether it's by setting up a spreadsheet it a macro in it that generates the data or writing some real code. I get to choose the most elegant solution and I suffer the consequences then I didn't choose the most elegant solution since I have to my software when it breaks 2 years down the line.
[0] - https://web.njit.edu/~sohna/cs288/hw3.html [1] - https://web.njit.edu/~sohna/cs288/hw10.html
* Students expect to be able to get help when they have problems. There is a good chance no member of staff knows Julia / Moonscript / ...
* 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?
* 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.
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 do them all in highly optimised x86 Asm, just because I can. ;-)
Not all students start at the same level; making the choice of language a free-for-all is just going to stretch that disparity even more. The ones at the top will naturally find ways to entertain themselves more, and the ones at the bottom will have no less idea of how to do things than copy-pasting code they found somewhere else (if the language doesn't matter, it makes that even easier...)
We were writing an interpreter using C++ which I'd rather have done in some Lisp-like languages.
On the other hand, I believe that doing something in an "unconventional" language for it is one way of improving your skills since you have to then apply true creativity and knowledge instead of just following an existing solution. Using a language which makes the task easy or even trivial doesn't really benefit the learning process.
Years later when I had both enough experience to appreciate these things as well as interest in programming languages I did start to grok all of this but it certainly wasn't due to my education.
As far as the second one goes, I bet that has more to do with the professors particular familiarity with C than it does an understanding of what the best tool of the job for that is. I'll cede that point :)
These benefits seem dubious to me in the long term unless you plan to work on compilers and languages which is certainly a noble goal and is very much a hot area right now. Picking up brainfuck in a short period of time is not really noteworthy IMO. I am also struggling to come up with a way to present this to other people without coming off as an annoying know-it-all. Do we want to value the ability to sprint or the ability to finish a marathon?
Plus, your memory will deteriorate over time without constant practice. Am I really going to commit time to reviewing all languages I choose to learn every year or so? The article seems like a challenge-to-take more than career advice.
If someone doesn't immediately want to work with languages, I would rather teach them what might be analogous to the lay of the land in our industry:
- What tools do you use to make a desktop application on Windows/Linux/Mac?
- How do the different browsers (Edge/Chrome/Firefox) implement HTML/CSS/JS? Can you make a consistent behaving application for all of them? And why should you run far, far away from any company asking you to support IE8 in 2017?
- How would you make a cross-platform library for Windows/Linux/Mac?
- How would you make a mobile application?
- What are the most popular IDE options available?
- What are the different database options available?
The difference in opinion is exactly teaching more engineering vs. teaching more science, but also learning about the ecosystem that drives language choice and development. This knowledge contributes as much to "knowing the right tool to solve the problem" ability as diverse language knowledge.
We want to value the ability to finish the marathon, which is exactly why it's important to be able to adapt faster. The industry is constantly moving, and someone who can learn new languages and technologies easier/faster is at a huge advantage.
For a concrete example, take Objective-C and Swift. Apple has made it pretty clear that's were things are going, and a developer who has C#, Haskell, Objective-C, Python, Rust, and Ruby experience is going to make that transition much better than a developer with just Objective-C experience. This same thing even applies to frameworks within the same language (think React/Redux and functional programming experience).
> Am I really going to commit time to reviewing all languages I choose to learn every year or so?
Definitely not! You focus on the concepts in the language and don't worry about memorizing anything. Quite a few years ago I learned Go for fun. I basically ignored it after that, but when I needed it for a project recently it came back very quick.
Those other questions you pointed out are, of course, very important. I think you learn the answer to those as you learn languages as well.
In my experience, people with CS degrees do understand the low level mechanics statistically more often, on average, than people who don't have a formal education, or people who go to 2 year colleges or trade schools. There are definitely people who make it through a degree without thinking much about cache misses, but in my life I've seen far more programmers without an education fail to understand caching than programmers with an education.
I've never met anyone, educated or not, that doesn't care about performance at all. I do meet people that prioritize what they care about, and choose to weigh performance of the programmer over performance of the computer, choose to prefer working with valuable abstractions over milking every cycle out of the machine.
It depends on what you're doing. Usually, thinking about CPU cache misses in a web development environment is premature optimization and a massive waste of effort. Not always, but usually there are other more important performance considerations.
Those like myself doing compiler related classes got to additionally explore Forth, Oberon, Oberon-2, Active Oberon, Modula-2, Modula-3, Eiffel, Ada, Concurrent C, Objective-C, *Lisp, Sather, C+@ [1] among a few others I cannot remember now.
As Wirth puts it, it is all about algorithms and data structures, in an abstract way.
[1] - In case you never heard about this obscure relative of C++ at Bell Labs, http://www.drdobbs.com/article/print?articleId=184409085&sit...
What gets my goat is the idea that some recruiters have that I - as someone with mostly C# experience - would be completely useless in a Java environment.
Java and C# are so similar it's barely worth noticing. There'd be different IDEs and libraries in play - and sure, a lot of googling to remind myself of stuff in the first week. But that pales into the comparison to the amount of time I'll likely spend learning the business domain, or how the legacy code base works. That's the stuff that's truly important.
I worked for a company a few years back doing ASP.NET (my experience is mostly Linux based tech, but you can pick up a language, right?). The language was fine, the design patterns used all quite standard, but the project had an array of frameworks and libraries which made maintaining it painstaking.
In fact, I think you worked on it too.
IMO the largest issue is the breadth of one's experience, or lack thereof. And by that I don't mean simply the number of languages but how well versed one is in different languages and their surrounding ecosystems. For instance having good knowledge of both C# and Java isn't what I'm describing here.
Oh dear, what code of mine have you seen? :-) (email address is in my profile if it's not something publicly discussable)
I felt the same way trying to learn Haskell. The language itself isn't that hard to learn, but just try and go read some code for one of the large open source hs code bases (like Yesod, etc.) :)
I also remember being put on a C++ project after being away from the language for years (C++ 11 was... different from the C++ I used back in the early 2000s). I was completely lost for a while :O
On the other hand, some languages are easy to pick up quickly (like Go), and some just 'click' for some people (as Clojure did for me).
During my Master's (and my Ph.D.) I was using a finite element approach developed by a former Ph.D. of my supervisor(s). So, I asked for the code. I got back a mess of C++ and it was dependent on a linear algebra C++ library that wasn't around in the same form. I spent some time trying to reason out what he was trying to do, gave up and wrote my own in Fortran in about as much time as I spent trying to understand his.
Yes, those take a while. It's even harder if the new language is outside of paradigms you are familiar with. Eg Prolog or Haskell would be that for most people.
I’ve started coded C++/CX without noticeable degradation in productivity.
But when I need to code for e.g. linux, because of those tools and practices you’ve mentioned my productivity was much worse compared to using Visual Studio on Windows, even when using same standard C++.
And writing generators allows you to write simple code with them. I don't consider generators to be fancy - just a tool to pull out complexity into a small area and make the rest of the code readable.
Ruby's range must be converted to Array.
> (1..20).to_a.join(",")
"1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20"
> ",".join([str(i) for i in range(1,21)])
'1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20'IMO the problem isn't so much about learning C or not. It's about which other languages do you learn alongside it.
You need to practice in a language that encourages OOP and a little bit of functional programming, like JS or Ruby.
If you know Ruby and C already, using C++ well will be much easier :)
I also don't think anyone's programming "just" C# - I'm a web dev, so I'll do Javascript, Razor, HTML, C# and SQL as the situation requires.
There's also a huge difference between programming ASP.NET Web Forms and the latest version of WebAPI.
Clang modules are the beginning of something for the latter task. SWIG also has a lot of ideas that are usable -- and SWIG can handle the API description having classes and methods, since it handles C++. Though I would hesitate to make C++ headers the lingua-franca of code.
True, modern C++ is quite different. But, there's nothing from preventing a C programmer from starting as a "bad" C++ programmer and learning new techniques as they go.
You can also emit the title: https://www.amazon.com/dp/1491946008/ works fine.
'Teach how to program C, you will give them a job. Teach someone how to LISP, and they will keep learning forever'
We learned a lot of LISP and Functional based programming from this guy. I mean a lot. Fun times I do miss!
I'd love to see someone do this because I'd say it'll be harder to do assignments I'd give out in x86 assembly then probably i686 or even ARM.
Most people would likely do everything in the language they want to learn or will need in industry. If you're just messing around then write it all in some obscure architecture like AP-101 or PDP-8 or even 4004. Maybe I just love the classics.
> Not all students start at the same level; making the choice of language a free-for-all is just going to stretch that disparity even more
That's why I said they should first be introduced to languages. That should be the first thing, day one, and continue until they get a basic idea of all the common features in programming languages.
> On the other hand, I believe that doing something in an "unconventional" language for it is one way of improving your skills since you have to then apply true creativity and knowledge instead of just following an existing solution
It may be fun but I wouldn't want to do it in production or on my grade.
And of course, Haskell's type system is not endlessly flexible (yet..). Eg Haskell still struggles expressing relational programming or linear types / uniqueness.
The situation is similar to Lisp macros: yes, you can implement Prolog in Common Lisp in a few lines, but no, it won't be a fully featured and fast production system, unless you actually put in the work. (Paul Graham's 'On Lisp' makes these excellent points in the chapter on the Prolog interpreter.)
Of course, you might want to go all the way to dependent typing. I think one of Ysabelle or Idris actually compile to 'low-level' languages like Haskell by default?
The main benefit I would like to see in Haskell is totality / termination of programs by default, and hiding Turing completeness behind something like unsafePerformCompute. Similar, we could split IO into IOReadWrite and IOReadOnly.
The former would be the same as the old IO, the latter's actions could depend on the environment but wouldn't be allowed to influence it (or weaker: would at least require idempotence?)---thus allowing more scope for optimization and human understanding when reading code.
Haskell also appears to have a very interesting form of goto:
https://wiki.haskell.org/Compose#Using_Cont
With Haskell's advanced type system, could we recreate implicit int/real typing, and perhaps even EQUIVALENCE?
Bonus points for also implementing the ComeFrom interface from Python's comefrom joke package!
The point is, I don't care whether amzn.com really belongs to amazon.com or not. I want to check a domain quickly without having to research that kind of stuff.
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 < len(self.allocations):
# Check to see if we can fit inbetween this current allocation and the next
if not self.allocations[i + 1] - current.end >= 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!
> 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.
If the bug is a shallow/algorithmic bug, that's reasonable. Recently I was helping someone debug some javascript code. Eventually, we found the problem was that, in javascript, that [11] < [2]. I'm not particularly knowledgeable on javascript, so I didn't know it did < comparison of arrays by string comparison. That's the kind of thing that really needs.
> 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.
This I just have to disagree with. I think it's valuable for students to learn how to implement quick sort. It's useful to learn how to implement big-integer arithmetic. It's useful to learn how you can "fake" Java-style inheritance with structs and function pointers, so you really understand what's going on under the hood.
Of course long term, you wouldn't typically implement these things yourself, but understanding the fundamentals is important.
Also, if I set a practical which involves (for example) connecting to a HTTP server, intending them to do the raw connection themselves, and they use a 3 line python program, using the standard library, have they really learnt anything at all?
There certainly is a place for giving students more freedom, particularly in later years. It's clear the modern world is moving into "slap together 50 javascript/python packages with string" type programs (and that's because it's a great way to be productive quickly), which universities don't currently teach that well. But don't throw the baby out with the bathwater!
I'd rather the students kow how to implement large software architectures, keep line counts down, abstract problems correctly, and learn how things are done in the real world.
> It's useful to learn how to implement big-integer arithmetic
Not in my opinion. Maybe, maybe, show them how emulating FP math works but writing big-integer arithmatic functions is pretty useless for most people and is far too strait forward to require them to develop their skills of development software architectures.
> It's useful to learn how you can "fake" Java-style inheritance with structs and function pointers
You can't force them to learn patterns, you can only give them work that is better suited to using the patterns provided. You can even hint to your students "Hey you can make a get_car and get_bike and make a Drivable struct that has a Drivable->stear() and stear can be a function pointer!" Forcing them to use a pattern isn't useful.
> so you really understand what's going on under the hood
Using function pointers isn't really correct for how Java stores class/object information. This is kind of only used in virtual functions IIRC. When I've decompiled static bytecode you see stuff like LString(some function).
> Also, if I set a practical which involves (for example) connecting to a HTTP server, intending them to do the raw connection themselves, and they use a 3 line python program, using the standard library, have they really learnt anything at all?
You're assigning the wrong problem. Don't say "Make and HTTP request" say "implement an HTTP header parser". The problem is now language and abstraction agnostic and involves a much more complex problem who's complexity lays in the realm of the software organization. The HTTP Parser code can be used to read and write requests and the next lab can be to use your new library in a larger project. I think that is far more useful.
> There certainly is a place for giving students more freedom, particularly in later years. It's clear the modern world is moving into "slap together 50 javascript/python packages with string" type programs (and that's because it's a great way to be productive quickly), which universities don't currently teach that well. But don't throw the baby out with the bathwater!
There is a measurable reason for this and it's not because of productivity. It's about maintainableilty, consistency, and bug erradication. I'd love for you to read this paper Do Code Clones Matter? [0] to see what they have found.
Making it so people know how to:
* List all the featurs that a library will need
* Take those features and write them in a clean API
* Do it in the most clean language-specific way (ex Pythonic code)
* Distribution methodologies
* Maintainablilty and support of these libraries
* Using these, and others, libraries in larger applications
* Documentation & Technical writing
Personal experience. I've been trying to hire moderately competent, junior software engineers would be able to write and optimize C++ without much supervision. They're now more rare than the Sasquatch. Today, "caring about performance" means picking a language that's only 5x slower than C, rather than 100x slower. Hardly anyone even knows why alignment might be desirable, or how long it takes to fetch memory after a cache miss, or how concurrency primitives actually work. For my generation, "caring about performance" means that C compiler generates suboptimal assembly, and you handcode it because you know better and need that extra oomph.
> It depends on what you're doing
It sure does. You don't have to worry about the lower level stuff every day. We deal with extremely high performance code, and even _we_ don't think about it every day. But it definitely pays to know what's going on. Otherwise it's not software engineering, it's cargo cult science and rain dancing, prone to fall apart at the first sign of difficulty. It's like having a certified car mechanic who doesn't know how to open the hood. You can have a few of those to change tires and broken tail lights on the cheap, but you also need the dudes/dudettes who know what to do when "check engine" light comes on.
If you don't want to train them, pay the price for an experienced C++ developer instead.
"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.
They sure did in the early 1990s. That was the only way you could ship a working product.
Are you certain they're rare? As opposed to not responding to your hiring ads, for whatever reason?
I do think the percentage of programmers who care about CPU cycles has gone down; I would totally agree with that. Decades ago it used to be that you had to care, it wasn't an option. Today, for most work, it's simply no longer a requirement to worry about cycles. BUT, I've hired lots of kids in recent years who knew plenty about compilers and assembly and caching, so I have a general feeling that they're out there. I would speculate that a lot of the kids who can deal with C++ and performance issues are interested in games...
> ...it definitely pays to know what's going on. Otherwise it's not software engineering, it's cargo cult science and rain dancing, prone to fall apart at the first sign of difficulty. It's like having a certified car mechanic who doesn't know how to open the hood.
It does pay to know what's going on, I totally agree. In some sense literally, as the deeper you go, the more "expert" and "high paid" you will expect the technician to be.
Your analogy to car mechanics is apt in the sense that what you're talking about has already happened in both the auto industry and the tech industry due to increasing complexity of the systems over time -- the first line or two of support people don't fix the internals for you and often don't know how (yet they do "fix" most problems). Even the higher paid expert technicians at car dealers can't fix a huge portion of the problems anymore because the problems are software. Same goes for very smart and very capable QA engineers - they know how to test systems, they know how to find which system is broken, they know how to reproduce issues, but the system may still be a black box. And the engineers writing your core app code still can't generally fix issues in their libraries or operating systems. And so on. So, I personally wouldn't go so far as to say it's cargo cult science or lacking software engineering, we just have more layers than we used to. We can and do engineer at one layer on top of other layers that are black boxes, almost nobody can claim otherwise. But, as you pointed out, you do need people staffing those multiple layers.
Could be response rate, sure. Could be our proximity to Google, which manages to hire C++ devs just fine (fully a half of their codebase is C++).
We've managed to hire some folks after all, with some remedial training they're doing fine. I just wish it wasn't so hard to find them, and they wouldn't require months of close supervision after you hire them.
Many of our students go on to do PhDs. For that an understanding of deep algorithmics is much more important than being able to use and distribute a library, or building larger applications. They need, in their field of student, to be able to reimplement and understand many important difficult algorithms, not (for example) put together some node.js libraries.
However, there is a place for that kind of degree. Someone once said to me something which stuck with me: "You wouldn't try to merge a maths, and accounting degree, just because they both contain numbers", yet that's still what we do in computer science.
I just want to make sure, and state for everyone, that I'm far too lazy to do work that good. That's done by people much further along in their development of their profecian then I. Not my work just something that I think is good.
> Many of our students go on to do PhDs. For that an understanding of deep algorithmics is much more important than being able to use and distribute a library, or building larger applications
It depends on what their PhD or major is. Many CS majors here go into math and physics and they would have done better to learn how to write pythonic (or matlabic?) code and learn how to correcly design APIs. For instance, tonight I'm going to be rewriting a library from Python 2 to Python 3 and I have no way to tell if there's been any regression because of a lack of testing frameworks, consistentcy in APIs and lack of modularity. I'd be basically impossible for me to mock even single parts of this.
> They need, in their field of student, to be able to reimplement and understand many important difficult algorithms, not (for example) put together some node.js libraries.
I don't think left-pad is a good charictarization of my position here. I think that the hardest part of large scale software development is the architecture portion and that's mainly because very few people ever actually start large complex projects on their own and no universities offer courses in such a field that practicies that.
> However, there is a place for that kind of degree. Someone once said to me something which stuck with me: "You wouldn't try to merge a maths, and accounting degree, just because they both contain numbers", yet that's still what we do in computer science.
The moment you, or one of your coworkers, creates a major like that (Software Engineering and Developemnt or something) I'll be transfering over from my Computer Science degree. It's useless for anything but the name and the prestige that gets my foot in the door for a lot of very fun and interesting opportunities. I've had to hobcobble together everything I've needed to learn from a software perspective on reverse engineering, bare-metal systems devlopment, assembly, networking, game development, operating system development, web development, and many abstractions/patterns that go along with all of those. It was very difficult and I'd rather have given 30k/year over 4 years to a school who could teach me the "real" way from "professionals" and end up with a piece of extremely expensive framed paper that says my name and "degree" on it.
I'd also like for a school to hold my hand while exploring different paradigms.
Google is probably willing to train people too, which might be a difference for you. C++ isn't that fun of a language compared to others too.