So far we've learned some absolute basics of using Vim, customized Vim to make it a little better for everyday coding, and gotten comfortable moving around quickly in a file. If you've stuck it out and practiced the movement and editing commands we've covered so far, you are probably starting to get a sense of the potential that Vim has. With a small set of one letter commands, you can get an awful lot done, and if you've practiced enough to make your use of the commands automatic, you can get stuff done wickedly fast.
It's time to shift into high gear and round out our Vim skills with a more complete set of editing functions. We don't want to always have to enter Insert Mode to make changes to our code. Sometimes we need to move large chunks of code around, change a bunch of variable names, or delete irrelevant code. These code editing tasks would be painful if we had to do them all in Insert Mode, but they can be positively trivial with Vim's powerful editing commands.
Learn Vim Fast: Moving In and Getting Around
If you started learning Vim with my last post, and you've been practicing the handful of commands we covered, then you're probably pretty tired of how you have to move around and edit things with only those rudimentary commands. It's time to expand our command set and crank up our efficiency in getting things done with Vim, but before we do that, let's take a look at how to make Vim a bit more comfortable to look at.
Learn Vim Fast: Quick Start Guide
I use a lot of different text editors for the various programming languages I write in. When doing embedded C/C++ programming, the IDE is almost always Eclipse based. When doing Python scripting, Python(x,y) with Spyder is a solid choice. When doing C# Windows programming, Visual Studio is almost a must. But my default editor when I need to knock out a quick little program, bring up some code for a second to check something, or work in Ruby or Javascript for any amount of time is Vim.
Every editor has its strengths, its weaknesses, and its warts. Vim is no exception. Its spartan interface is nearly impenetrable to the beginner, and it has a killer learning curve. I remember the first time I encountered Vim while in college. I was an intern at a small integrated circuit design company, and I was looking over someone's shoulder as he quickly jumped in and out of files from a Linux shell, darting around the files and making crazy edits without ever lifting his hands from the keyboard to reach for the mouse.
"What the hell kind of editor is that?!" I asked in awe.
"Oh, that's vi," he responded. "You don't want to use it. It's archaic and has a killer learning curve. You'll be happier with a modern editor."
Every editor has its strengths, its weaknesses, and its warts. Vim is no exception. Its spartan interface is nearly impenetrable to the beginner, and it has a killer learning curve. I remember the first time I encountered Vim while in college. I was an intern at a small integrated circuit design company, and I was looking over someone's shoulder as he quickly jumped in and out of files from a Linux shell, darting around the files and making crazy edits without ever lifting his hands from the keyboard to reach for the mouse.
"What the hell kind of editor is that?!" I asked in awe.
"Oh, that's vi," he responded. "You don't want to use it. It's archaic and has a killer learning curve. You'll be happier with a modern editor."
Reflections on Programming
My perspective on programming has changed quite a bit over the years. Even in the few years since I started this blog I've noticed that I look at programming differently than I used to. If there's anything people who work with technology need to get used to, it's change, and I expect that my perspective will continue to evolve in the years to come. This is an attempt to take a snapshot of how I look at programming right now and how it's different from the recent past. As for the future, I'm not capable of speculating. We'll have to see what I think when it gets here.
Tech Book Face Off: Practical Node.js Vs. Node.js the Right Way
I've recently gotten into some server-side JavaScript development at work, and I needed to take a crash course in Node.js to make better progress, so I did what I always do. I picked up a couple of books on the subject and dug in. I did some perusing of reviews on Amazon.com and settled on a couple of books that appeared to be solid: Practical Node.js by Azat Mardan and Node.js the Right Way by Jim R. Wilson.
The funny thing about Node.js (I'll refer to it as Node from now on) is that there's not that much to talk about, so you quickly move on to talking about all of the libraries that you can plug into Node to get stuff done. That's because Node isn't a framework like Ruby on Rails or ASP.NET MVC. Node is a runtime that runs on the Chrome V8 engine, and all it does is allow you to run JavaScript directly on any machine outside of a browser. It includes a small, tight collection of APIs for working with file systems, operating systems, and networking interfaces, and it establishes an asynchronous paradigm for writing and executing code.
This asynchronous paradigm takes a little getting used to. Basically, any function call that could block, be it a file system access, database access, or HTTP request, will take a callback function as its last parameter and return immediately. When the slower operation finally finishes, the callback will be executed with the response from the operation as its parameters. If you forget about this behavior, you'll very quickly run into situations where you're trying to read things out of a database that haven't been written into it yet, or getting empty responses from HTTP requests. Basically, all dependent code needs to be executed inside callbacks, and that leads to the well-known Node existence of Callback Hell. We'll talk more about how to deal with that in a minute, but that pretty much is Node in a nutshell. Let's take a look at the books.
The funny thing about Node.js (I'll refer to it as Node from now on) is that there's not that much to talk about, so you quickly move on to talking about all of the libraries that you can plug into Node to get stuff done. That's because Node isn't a framework like Ruby on Rails or ASP.NET MVC. Node is a runtime that runs on the Chrome V8 engine, and all it does is allow you to run JavaScript directly on any machine outside of a browser. It includes a small, tight collection of APIs for working with file systems, operating systems, and networking interfaces, and it establishes an asynchronous paradigm for writing and executing code.
This asynchronous paradigm takes a little getting used to. Basically, any function call that could block, be it a file system access, database access, or HTTP request, will take a callback function as its last parameter and return immediately. When the slower operation finally finishes, the callback will be executed with the response from the operation as its parameters. If you forget about this behavior, you'll very quickly run into situations where you're trying to read things out of a database that haven't been written into it yet, or getting empty responses from HTTP requests. Basically, all dependent code needs to be executed inside callbacks, and that leads to the well-known Node existence of Callback Hell. We'll talk more about how to deal with that in a minute, but that pretty much is Node in a nutshell. Let's take a look at the books.
 | VS. |  |
What Would Happen If We Created AGI?
This is the big question surrounding AI. In reality, nobody knows, and I'm not going to claim that I do either. I'm merely going to speculate, hopefully coherently, as to what I think could happen and what I think won't happen if we create AGI (Artificial General Intelligence). The predictions flying around out there are all over the map, so it's likely at least some people will be at least partially right, but things will likely go differently than anyone can possibly imagine simply due to the nature of what we're trying to predict.
This is the third post in this mini-series on AI, inspired by the excellent book Gödel, Escher, Bach by Douglas Hofstadter. In the first post, we defined what intelligence means in the context of developing an artificial intelligence and listed the traits of general intelligence. In the second post, we explored how the characteristics of intelligence enumerated in the first post might develop or emerge in an AGI. In this post we're going to dream. We're going to let our imaginations run a bit wild and try to think about what possibilities would arise with AGI. But first, let's get a little more context.
This is the third post in this mini-series on AI, inspired by the excellent book Gödel, Escher, Bach by Douglas Hofstadter. In the first post, we defined what intelligence means in the context of developing an artificial intelligence and listed the traits of general intelligence. In the second post, we explored how the characteristics of intelligence enumerated in the first post might develop or emerge in an AGI. In this post we're going to dream. We're going to let our imaginations run a bit wild and try to think about what possibilities would arise with AGI. But first, let's get a little more context.
Is Artificial General Intelligence Possible?
We all know that general intelligence is possible. We have living, breathing proof right in front of the mirror. Humans ask wide-ranging questions, solve general problems, and pursue knowledge with an unending passion. While billions of years of evolution has developed at least one instance of general intelligence, is it possible for that intelligence to create an artificial general intelligence (AGI) capable of similar feats of thought? Until now that is a problem that we have not proven to be solvable, but I am convinced that it is.
In my last post, I listed what I thought was a complete set of traits that defined intelligence. Without any one of these traits, intelligence would be questionable. With all of these traits present, we would almost certainly have intelligence. Now we'll explore these characteristics in more depth to see if and how it would be possible to develop them in an artificial intelligence. We'll start with what the AGI would use as input.
In my last post, I listed what I thought was a complete set of traits that defined intelligence. Without any one of these traits, intelligence would be questionable. With all of these traits present, we would almost certainly have intelligence. Now we'll explore these characteristics in more depth to see if and how it would be possible to develop them in an artificial intelligence. We'll start with what the AGI would use as input.
Subscribe to:
Posts (Atom)