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.
The Nature of Intelligence
In my last post I wrote an epic review of two books that delved into the nature of intelligence and the limits of computation: Gödel, Escher, Bach and The Annotated Turing. Both books sparked all kinds of new ideas about artificial intelligence (AI), especially GEB. I tried to stick to the material in the books for the review, but now it's time to dig in and explore some of the ideas those books spawned in my mind about AI. These ideas boil down to three main questions that define the scope of issues surrounding AI.
The implications of these questions are fascinating. The answers to the first question will define how we would recognize intelligence and what we're aiming for with AGI. The answer to the second question is almost certainly yes, but much more is behind it than a simple yes/no answer. The emergence of an AGI that meets the answers to the first question would show the positive result of the second question. The answer to the third question is extremely hard to foresee, and the possibilities get extremely gnarly when coupled with the property of exponential growth. The actual result will most likely determine our future as a species. Heavy thoughts. We'll dig into the first question in this post and cover the other two in subsequent posts.
- What is the nature of intelligence?
- Is artificial general intelligence possible?
- What could happen if we create AGI?
The implications of these questions are fascinating. The answers to the first question will define how we would recognize intelligence and what we're aiming for with AGI. The answer to the second question is almost certainly yes, but much more is behind it than a simple yes/no answer. The emergence of an AGI that meets the answers to the first question would show the positive result of the second question. The answer to the third question is extremely hard to foresee, and the possibilities get extremely gnarly when coupled with the property of exponential growth. The actual result will most likely determine our future as a species. Heavy thoughts. We'll dig into the first question in this post and cover the other two in subsequent posts.
Subscribe to:
Posts (Atom)