I finished it last night and wrote a "review" in a mailing list, so I'm just gonna copy that "review" I sent last night if anyone's trying to figure out whether or not they should take this course:
I just finished it. It took me less than half an hour.
It was OK until I finished the 75% of the course. The last 25% were pretty repetitive: use nano to edit your bash config (they used .bash_profile as a config file), type something in it, close nano and use source to set the source of your bash config. I had to execute that same process at least five times and every single time the terminal session restarted so I couldn't use up and down keys to navigate between previous commands, so I had to type them again every single time. Plus there were constant bugs in the interface so I had to manually scroll the left sidebar to see the next task in like every challenge.
All in all, you're right, very basic, thorough, and a bit repetitive at the end. Nothing really left a wow effect to me, but I knew how to use 95% of those commands. Others might find it more useful.
P.S. I'm kind of surprised that they chose nano as a text editor. I expected vi, but I'm guessing they chose nano because it's more beginner-friendly.
Just putting this out there - as a teacher, I have seen the importance of repetition. My students would benefit from the repetition at the end of this.
The very reason that I became interested in programming is the ability to eliminate repetition. Instead of solving math problems, I could make a calculator program. Instead of typing something out many times, the computer would do it for me. Type once, run forever. That was an amazing revalation.
If I had learned programming through mindless repetition, through typing the same thing over and over again (As codecademy has students doing here), I would have quit early on.
Instead, I learned through solving problems. Diverse problems forced me to apply my newfound bits and pieces of knowledge in different ways. I always focused on eliminating repetition whenever I could. I had no interest in typing a lot.
There are different kinds of repetition. Practicing the elimination of repetition is the best repetition there is.
Finally, of all the computer-related tools out there, the command line is perhaps the best at aiding users in the elimination of repetition. With the ease of adding new commands, with programs like vi and cron at one's fingertips, there is so much even a beginning user can do to start eliminating his/her repetition. So to TEACH this tool as one of mindless typing is utterly abominable.
Everyone seems to be missing this bit - it is about those fundamentals first. The end goal is eliminating repetition. But it takes repetition to get to that point because that's how the human brain works.
I observe this with students who use IDEs in the beginning. Some "experienced" developer tells them they need to use an IDE because it "saves time."
Then the students tab-complete their way through code and don't really understand, or remember, what it is. The connections, the pathways to memory, aren't as great.
And not everyone learns this way. If your first program out of the gate was a program to do math for you, before previously learning anything about programming, then based on my experience you are an outlier, someone with a gift and natural affinity for this field.
Bottom line: if this was too repetitive for you, you weren't the target audience.
I'd say eliminating repetition is meta-programming, rather than programming. It is one of the things that set experienced programmers apart from beginners.
I believe in good repetition. But what is good repetition? Nano on a dot file 5 times? For the command line it should involve commands that will save people time. Teach them:
1. how to use find and grep, and other commonly used commands.
2. introducing them to vi and explaining why people use it (instead of nano)
3. user configuration with a brief on the FS structure (what is in etc, usr, opt, etc...)
4. lastly, but most importantly, how powerful and dangerous the unix command line is. Why you should learn shell scripting. And getting started with shell scripting.
To me, that list would go from beginner to intermediate++
Sorry, but your second item, using vi has nothing really to do with learning the command line. You just prefer vi as editor and didn't like them choosing nano. Quite a few don't use Vi but use the command line. Don't turn this into a discussion about why Vi is the better editor.
You do it as many times as it takes to become muscle memory. That's a lot of times for some people.
I suspect many on this thread have forgotten what it was like the first time they did command line stuff. I teach this stuff in a classroom setting twice a yeaer.
vim is available, and if you know how to use it, it doesn't seem to know what text editor you're using. At least, that was my experience.
But I'll also agree that the edit bash_profile stuff was repetitive. I might have preferred something in there about symbolic links or ownership and permissions.
No, it's not intended for me. I'm actually evaluating it for other people (I work with people that are totally lost in Unix shells) and playing with its terminal to see exactly what I've been given.
In the book, I use "adventures" to demonstrate Bash concepts, where I guide the reader through using the command line to answer questions such as: What's the average tip of a NYC cab driver? Is there a correlation between a country's GDP and life expectancy? etc
No bitcoin payment option? I'd take one right now! Get a free pay button there (https://goo.gl/QRtxwb)
*Edit, just noticed is some checkout system. Here is the payment http://ckte.me/wy7x3drq2ke PM me on twitter (@nvk) for the PIN with the link to PDF :)
Lately I've been butting heads with some seriously anti-command line people. I'm not sure if this is a growing sentiment, or I'm just advocating CLI usage more as time goes on.
Anyway, glad to see this. I'll be sure to recommend it to whomever I'm preaching.
I can often navigate to a file in a GUI faster than I can "cd users/Nadya/documents/work/2015/08/24/important/file.txt" [0]
Or I could open up my GUI, click "work" from my side nav selections and navigate through 2015/08/24/important/ and click my file to open it. I can even open two directories and ^x^v into another directory. Or drag/drop to move. Rather than "mv file.txt ../../25/file.txt"
I think it's important to show the more "cool" stuff you can do from CLI. Once you have them interested, explain the building blocks for how they can get there.
Explaining the building blocks to someone who doesn't see the benefits of the CLI will have them thinking about trivial problems and wonder why anyone would ever choose to use the CLI when the GUI is so much faster/easier/less memorization. When I was taught pwd/ls/cp/mv all I could ask myself is "....why? GUI is faster/easier/less memorization/no typos wasting time".
[0] To be fair, I can autocomplete a lot of that command. GUI is still faster though. "cd/us[tab]/N[tab]/doc[tab]/wo[tab]/2015/08/24/i[tab]/fi[tab].txt"
I don't think speed is the best argument pro the command line. If you're used to and proficient in a gui or cli, then it's going to feel like you're getting more done in your familiar environment.
To me the killer argument for cli is composability, combined with the cli history.
Most of us do a lot of things repeatedly, day in day out. For example I have to download one of the last files from an ftp server, open it, process it in some way, and possibly get some other files based on what's in the first file.
It's reasonable enough from the command line. But some of the operations are chainable with pipes, and all of them can be in a short shell script, so I only have to enter the one script name to get the whole thing done.
And it's in my cli history, so I only have to recall it, and change usually just one parameter.
I think I'd be hard pressed to do that from a gui. for one, I don't think there's a gui history. And how do you chain gui commands together? And then alter them with parameters?
"Write a $LANGUAGE script that you can double click on." Yes, but that's a higher barrier to entry, and it's in a completely different "language" than the gui language that you were working in when you discovered a series of tasks that you repeat. With a shell script you just pull together what you've already been doing, in the format that you've been doing it.
And then compose the shell script you wrote with other shell scripts that you wrote. Etc.
I double click on things too, and somethings it's merely a matter of whether I have my hand on the mouse or the keyboard. Not bashing gui's (pun intended).
> I think I'd be hard pressed to do that from a gui. for one, I don't think there's a gui history. And how do you chain gui commands together? And then alter them with parameters?
Some automation tool like (osx) Keyboard Maestro is pretty good for these kinds of things. Just started playing with it the last couple of weeks but it is very powerful.
Your GUI often includes shortcuts (e.g. to your "work" folder) and that functionality is accessed from the command line via symlinks. Your comparison is not really fair.
It's significantly faster (at least for me and most people I know) to type "cd ~/relevant-symlink" than it is to take my hands off the keyboard, switch to the mouse, and then go back to home row.
Seriously, if you have 'work' as a side nav, then you could have it as a symlink, which makes it about the same. But it's really the stuff like looping over operations, or rsync over ssh, etc that make reading & writing a bit more awesome than point & grunt.
Arrgh, you caught me! ;) Replace cd with nano and I'll try to avoid the text editing via GUI vs text editing via CLI debate.
As for symlinks, it's a fair point. But even typing the rest of that example it would be faster for me to use a GUI.
I agree on that point. CLI is much better for less trivial tasks - or making a trivial task possible. On Windows renaming files is bad, ending with an (n) structure. Where I want "file_1.txt, file_2.txt I get file (1).txt, file (2).txt. Or if I save a bunch of .jpf instead of .jpg I have to use the CLI to fix the extensions because it isn't possible in Windows otherwise.
But you won't convince a lot of people to use CLI if you're introducing them to pwd/ls/mv/cp instead of |'s, grep, scripting, etc.
CLI is better for when you know where you want to go, but it sucks for exploration. It takes much more effort to learn how a file tree is laid out using the CLI than it does using a GUI.
It's much simpler to move your mouse and click once than to use cd + ls. (Never-mind the fact that half the time I go to use ll and oops, this is a super-user so none of my aliases work.)
OTOH, if you're always moving files from /stage to /live or /db to /backup, CLI is more efficient, particularly once you write a script to capture what you need to do.
GUI also comes out on top for anything where the CLI ends up just being a mock-GUI. For example, on OS X, there's no reason to use top instead of Activity Monitor, since they do the same thing, and AM lets you click the column headers to re-order things. Also, I know people love vim/emacs, but those are both better as GUIs than as pure-terminal programs.
I'm actually shocked to see such a massive number of coders on HN (a skill that still somewhat eludes me) can't use the command line, which I consider a Step #0 type prerequisite.
It just hadn't even occurred to me that this might be a possibility. I'm not even sure how folks get started in the hobby/skill without the CLI background.
I'd be interested in hearing more about the skills progression of these folks, and how they got to the expertise they have today.
I started programming in PHP doing web development. I started on Windows ME/XP and primarily used FTP to a free PHP host. After a while I learned to setup PHP/Apache/MySQL on my desktop and continue withing just an editor. Never once really touched the Window cmd.exe. After playing with PHP for a long time I started learning about different frameworks. The one I picked up and used the CodeIgniter. The first time I really heard about using a CLI was when I was reading about frameworks and came across Zend. It was annoying to me that I needed to use some "weird" command line to generate files. Why couldn't I just make them in my editor?
It wasn't until I installed linux that I really started to play with any CLI. I honestly don't remember what got me into linux at the moment. I do remember one of the first things I did was learn to setup the system using a tutorial on howtoforge.com. I went through those tutorial many of times setting up my computer.
I was an avid gamer at the time, so I also had my desktop setup to dual boot Windows. After a while I got tired of switching between the two so I ended up taking an old Dell Optiplex 110 installing CentOS on it and trying to get Samba to work so I could mount my web directories on my Windows machine and still edit them, while having Apache serve them.
I did that for a while, then got a job and bought hosting with shell access.
The classic Mac OS did not even have a command line interface, so people who began their programming careers in the Apple world between 1984 and 2001-2002 would only have had reason to learn how to use one out of curiosity, or if they happened to be doing cross-platform work with a Unix system. I had a wee bit of Apple II experience prior to the Macintosh, and I suppose you could call the various BBS interfaces I used a form of "command line", but for the most part I never touched a command line as we know it today until the late '90s when I started messing around with Linux and with shell accounts on the Internet.
While I've never been part of the Windows world myself, it has always seemed to me that the DOS command line plays a much smaller role there than the shell does in the Unix world. From '97 or so onward it has always been possible to buy a copy of Visual Studio and use it to build software without ever touching a command line, and I'm sure a great many people have done so.
> While I've never been part of the Windows world myself, it has always seemed to me that the DOS command line plays a much smaller role there than the shell does in the Unix world.
Indeed. It was possible to meaningfully use the command line up through, say, Windows 98 SE or so, once Windows XP hit, it became a relic, stuck in the command.com era while the actual OS kernel moved away from the DOS-hybrid of the Windows 95 era with the shift to Windows NT-derived OSes.
Power Shell (or however that's branded... CamelCase? Alloneword? Hyphenated?) promises to make the Windows command line relevant again, but I honestly don't know if you can meaningfully use a Windows system from only the command line these days. You probably can't use a desktop Windows system that way, which means the command line is still effectively frozen out from the real world.
PowerShell is a really cool, powerful tool. Though, it's really more of what you'd consider a modern REPL to be than a conventional shell. It takes an OO approach to scripting as well.
For some reason, I seems like it's a hard sell for a lot of .NET developers. A substantial number never leave Visual Studio and old habits are hard to break. I left that ecosystem many years ago, but still try to keep up with it.
I use the shell every day, and I have mixed feelings.
1. The core concepts are beautiful.
Pipes are elegant. Simple programs that read and write text are one of the most enduring abstractions we've come up with.
I've used a single, surprisingly readable command that:
- dumps a database with mysqldump
- zips it
- sends it over to another server
- unzips it
- loads it into mysql
...in a single streaming operation, without creating any files! Making a lot of disparate programs, written decades apart, work together so seamlessly is simply impossible any other way. The shell is powerful.
2. The implementation is unnecessarily complex and fragmented
The standard commands all have cryptic names like `ls`, `cat`, and so on. They're second nature to us, but we've made the barrier unnecessarily high for new people who are just learning. Man pages suck (bro pages are much nicer). There are a lot of shells (bash, sh, zsh, etc). They're similar but subtly different. Standard commands like `ps` are incompatible between OSX and Linux, or even different flavors of Linux. Simple operations often require cryptic incantations. I type `tar -xzvf` at least once a week. The original Unix ideal is minimalist and beautiful, but the rest of the experience feels like it was crafted by neckbeards without regard for usability or learn-ability.
3. Shell scripts are terrible
A fresh, out of the box Ubuntu installation contains (very roughly) 100k lines of shell script, probably more.
For writing actual programs, `bash` is one of the worst programming languages that exist.
It makes languages like Perl or PHP look sane and principled.
Every time I use a solidly engineered system (say `buck` for building a large Java project) next to an equivalent shell-script-based system (say autogen + configure + make for a typical C++ project), I'm blown away at how much faster, cleaner, and more robust our software could be, and I feel sad that we've built so much on top of Rube Goldberg shell script contraptions.
---
I think there's room for a ground-up Unix, true to original principles. I would love to make a minimalist Linux distro that boots without executing a single line of shell script. Configuration would be via a small set of JSON files, not some Turing-complete hairball language. It would still have a shell, but it would be a minimal, sane shell. You'd be able to type `help` for a complete and concise listing of available commands, each with a one-line example.
We teach things like bash by assigning each user to a virtualized Linux server. That gets really expensive and hard to manage when you give one to every anonymous user who hits the site (especially when our courses pop up on sites like HN). With that said, I have been wanting to change the UI to be less intrusive, so you can better see what you're signing up for.
IMHO, A Linux VM for every user sounds like overkill. A separate *NIX user account should be sufficient for teaching things like "Navigating the Filesystem", "Configuring the Environment" etc.
Securing multiuser linux is not an easy thing.
Even if you set process limits, restrict permissions, etc. you can still be very easily hit with a priv escalation bug in a utility you allow users to run or even in bash itself.
At a previous job, we had a "technical task" which formed part of the interview process for junior sysadmins. It involved setting up a couple of servers, VPNing them together, and configuring appropriate routing so VPN clients could access a server on a remote network.
We used LXC for this, but that or docker is probably a sane approach. You get some (not all) of the separation you do from VMs with all the scarce resource requirements of different users. If you consider the implications carefully, you can even give users root inside these containers in certain circumstances.
I love using the command line on my Mac. I had to learn it when I decided to learn Rails. You really do feel like you have more power and control during development. Now I didn't use Codecademy, but I did learn from reading tutorials and watching a Lynda series taught by Kevin Skoglund. If you're in the process of learning the command line, definitely give it a whirl.
It's great to see a course to teach basic command line use, I tried this back when it was in beta and it was great. At the time I had also emailed their support team about some security concerns regarding the course and never heard back(I'm not infosec expert but I was surprised at a few things they allowed that would seem like security issues).
Not a fan of CodeCademy. Other than the obvious (look who's backing them) though unacknowledged objective of flooding the market with low-quality devs to suppress wages, I've seen too many complaints from users to the effect of "I completed all of the exercises, but I feel like I haven't really learned anything."
Too much hand-holding. A good book, a comprehensive tutorial, or even just reading the documentation still probably works best.
In fact, this training wheels-tutorial system, regardless of its effectiveness, fits perfectly with their goal of devaluing software engineers (whom they deign only to describe as coders); after all, if "Coding is sooo Easy!!!" it shouldn't require one to read dozens of thick books, right? Just playing a sort of game and "leveling up" every now and then should suffice. Then you too will be a coder - and Zuck will be richer.
Sure, you're not going to be a professional software engineer working on complex problems and scaling servers at Google, but you can learn a little something from their service. For beginners who have never programmed I think its great because you can program right in the browser; no need to install compilers/interpreters, text editors/IDEs, DBMSs or servers. These things can take well over an hour to install, configure, and learn how to navigate through. All of this getting thrown at a beginners face would do nothing but discourage them.
And even if you're a well experienced programmer, you can use Codecademy to get your feet wet in a new language. I don't see the harm in this.
tl;dr "omg I'm scared of new people learning how to program because it threatens my job. I learned the hard way looking through old textbooks and new entrants shouldn't get to use a nice new service to learn because I didn't have that available to me when I started!"
Programming has always been accessible to new people. The only way it couldn't be is if programmers had organized themselves into some sort of union and then sought and received for it a legal monopoly on their profession as enjoyed by the American Dental Association.
And yes, I am afraid of CodeCademy, bootcamps, H-1Bs visas, and any other scheme blessed by industry, the media, and government that seems tailor-made for reducing my wages and my prestige. Remember that it wasn't long ago that a massive wage suppression cartel in SV was exposed, and its architects were punished with mere wrist-slaps. Quite frankly, you're foolish if you're not afraid.
Further, who are these "new people" you speak of anyway? Most of the "old people" I've met in this industry are there because they love programming, with the high salary being something of a perk. That's why so many of them contribute to open source projects on the side. This new breed of bootcamp and CodeCademy graduates are thoroughly mercenary in character. One of CodeCademy's own success stories is from a lawyer who got into "coding" because the job market for lawyers was so poor - why should I contribute to my own marginalization by supporting people like him?
That's a really naive assessment of his comment. I share a similar sentiment as the OP here, programming (not coding) is hard. A lot of us get paid well to solve complex problems for clients who expect us to do the job right. Institutions like codecademy, and other "learn to code" incentives make it seem like you can just knock some achievements off a list and bang, you're on the way to being a programmer!
Having spent a lot of time around industry vets and people who started doing this stuff in the 80s, these "nice new services" aren't all they're cracked up to be. The freelance coder market is becoming an annoying thing for the reputation of programmers, consultants and companies who know their shit, and do a great job for their paying customers.
Also, as I stated in my post, I don't think CodeCademy actually works that well at all, so your suggestion that I'm envious of new people because they have access to CC when starting out while I didn't is groundless. I tried one of their courses two years ago and found it extremely shallow. If someone asked me today how to learn JavaScript, I would probably direct them to Mozilla's tutorial or to the Rhino book and wouldn't even mention CC.
The glut of free programming books and tutorials on the internet along with open source operating systems and development tools and the Stack Overflow and other Stack Exchange websites have collectively done much more programming and CS education than CC has done and likely ever will do.
So you don't personally like CC based on your experience of it 2 years ago, so what? You don't have to use it. It just so happens that a lot of people really like their service.
If it outputs bad candidates, as you claim, then you should have no problem beating them in job interviews.
"Coding education has taken off in recent years, driven by reports that the demand for quality programmers in America is drastically outpacing the supply. So everyone from the White House to Google has jumped on the coding bandwagon"
Funny, when demand outpaces supply, aren't prices supposed to rise?
In the past I've recapped some of these sorts of things but to me this is tediously slow - it's almost CLI for non-computer users. I'd like to check the later material to see that I'm au fait with all of it - sometimes one gets a gap in knowledge when learning piecemeal by oneself but it won't let me skip to the later lessons.
Ideally IMO there would be a simple test one could take that would open up the later lessons, like a short recap for each chapter rather than working through the whole ls, pwd, cd, ls, pwd, cd, cd .., mkdir, ls -a, ls -l ... at the start.
Yeah, I just meant for the nostalgia. As in, I don't usually use command line on my Mac but Linux more or less necessitates command line use at various points.
The tutorial I linked to is of very high quality. Who, based on the information content of my post or the obviously disposable nature of my account, would waste downvotes on it?
Just from the perspective of mapping sentence meanings to bash commands, that's a difficult thing to do. But going beyond that, I think there are issues having to do with the ambiguity of language that just aren't solvable, period.
Take your example: "Show me all my files, including my hidden ones". That, to me, should show all the files on the entire system where I am the owner. Even as someone who ostensibly knows some bash, you missed that you dropped some pieces of data which are relevant in bash terms. "my" indicates ownership, and nowhere in your sentence did you say to limit the function to the current directory. If you're making that mistake as an experienced user, what hope does a beginner have?
`ls -a` actually encodes a fairly complex query, which only becomes apparent when you attempt to really nail down what it does in a natural language. To produce `ls -a`, you would really have to type something like "List the names of all the files, folders, and symbolic links in the current directory that are visible to the current user." You could, of course, start making assumptions about certain parts of this, similar to how `ls` does, but then you get into users guessing which part of the sentences they can elide (why wouldn't we assume that "List the names of the files, folders, and symbolic links in the current directory" wouldn't show us all the files, folders, and symbolic links?). At that point, the user must learn the idiosyncrasies of which exact sentence they have to type in to get what they want: i.e. when they have to say "all", when saying "my" matters instead of saying "the", etc. At that point the natural language stuff is no longer a learning tool, it's a separate, very complicated thing for the student to learn in addition to what they are trying to learn.
As another example of this: if you're willing to accept some ambiguity, why did you choose `ls -a` instead of `find .`? Recognizing that `ls -a` and `find .` do very different things.
To summarize: I don't think it's a bad idea, just an impossible one. :)
I think there are issues having to do with the ambiguity of language that just aren't solvable, period.
This, absolutely. Once you've used a programming language enough, you'll find that natural languages are disturbingly ambiguous; it only works (most of the time, at least) for communicating with other humans because of implied context.
To me and a lot of people, the commandline is already natural language.
`ls -a` is just a contraction for "list all"
Your nine words aren't any more expressive than my two, and that's the problem. There's not much value in being able to express simple commands with long sentences (with often many interpretable meanings)
There _could be_ value in natural language processing for some very complicated commands, but it would have to be fairly intelligent before it would be useful.
A good NLP interface for files would look as different from a command-line as it would from a graphical file manager. You'd want something context-sensitive, with the ability to use pronouns and iterative refinement, some of which would take the place of simple scripting. You'd need to replace many commands with phrases, and many variations on phrases.
Whether you'd get any users is another question.
You might also consider what a command-line interface based on Dasher would look like. Probably not just a simple typing interface. You could extract a great deal of useful information from completion mechanisms, for instance.
> What do people think about wrapping a Natural Language Processing interface around the command line (for educational purposes)?
Fragile, verbose, and actively hostile to learning why anyone would actually use a command line shell to begin with. For example, how would your syntax support redirection?
Bourne shell syntax is hairy enough as it is. The quoting rules are rebarbative and dealing with whitespace can drive you to madness in some circumstances. Adding another thick layer of syntactic sugar onto that is only going to end in tears.
In many large web applications writing queries in your DBAL/whatever without being able to dive into the underlying query and understand what's going on, I'd say it's pretty crucial. For anything small (complexity or expected traffic) you can probably get by without?
I just finished it. It took me less than half an hour.
It was OK until I finished the 75% of the course. The last 25% were pretty repetitive: use nano to edit your bash config (they used .bash_profile as a config file), type something in it, close nano and use source to set the source of your bash config. I had to execute that same process at least five times and every single time the terminal session restarted so I couldn't use up and down keys to navigate between previous commands, so I had to type them again every single time. Plus there were constant bugs in the interface so I had to manually scroll the left sidebar to see the next task in like every challenge.
All in all, you're right, very basic, thorough, and a bit repetitive at the end. Nothing really left a wow effect to me, but I knew how to use 95% of those commands. Others might find it more useful.
P.S. I'm kind of surprised that they chose nano as a text editor. I expected vi, but I'm guessing they chose nano because it's more beginner-friendly.