Learning Without Understanding
It's funny what you can do without knowing what you're doing. For instance, I started programming in Lisp over a decade ago without even knowing it. I realized this, when a few months ago, I started learning the Scheme dialect of Lisp and things felt oddly familiar. I had seen function names like car, cdr, and cons before, along with all of those parentheses. It turns out that I had already learned another dialect of Lisp called SKILL, and I had had no idea what I was learning at the time. I wonder if I would have learned more and gained a wider understanding of the development environment I was working in had I understood what I was doing those many years ago.
Stepping back to the beginning, I was an intern at an Application-Specific Integrated Circuit (ASIC) design company when I was in college. We designed analog circuits combined with a simple embedded microcontroller that all went on the same semiconductor chip. We would make these ASICs to measure signals from various sensors and condition the output to clean up noise, amplify the signal, and convert the signal to different digital and analog formats. The CAD software that we used to design our ASICs was a monstrous, expensive, nearly industry-standard tool called Cadence, and it had a scripting language called SKILL that you could use to instrument and automate almost any aspect of the software, like eLisp does for Emacs.
Cadence was new to our design group, as we had recently been bought by a larger company that used Cadence, so now we used it, too. As an intern for this company, I was tasked with learning Cadence inside and out and finding ways to make life easier for our design group and the rest of the company. That meant learning SKILL and writing tools that could speed up schematic capture, layout, simulation, and design checking.
I dove into learning SKILL and using it to improve the design group's work flow without ever realizing how rich SKILL's heritage was. The only languages I had learned previously were C/C++, Java, and Pascal. If you know Lisp, then you know that it is very different from these languages, but SKILL happened to have a C-style function call syntax and C-style comments in addition to its Lisp syntax, so I gravitated towards the C-style syntax in my code. I remember thinking a lot of the basic function names were kind of weird. I mean, why 'car' and 'cdr' to get the first item and the rest of the items from a list? And why were there so many lists to begin with? Everywhere I looked there were lists. It ended up being a convenient way to represent things in the Cadence environment, and I could do a lot of things in not a lot of code. But I certainly didn't understand why.
I most likely was not using SKILL to its full potential because I didn't understand what made it tick. Yes, I was able to get stuff done, but maybe not as well as I could have. I spent plenty of time constricting the language into what I was comfortable with in C without ever gaining the understanding of how powerful Lisp can be. I completely shied away from the full force of functional programming, and I probably missed out as a result.
It wasn't until years later from reading the blogs of Steve Yegge, Joel Spolsky, and Paul Graham that I started to understand that some programming languages can be quite different from the common ones, and I started to learn about Lisp in particular. Granted, I still didn't learn Lisp. I was only learning about Lisp, that it was somehow special, and that it could change you as a programmer. I ended up exploring other languages first, including Ruby, Python, and JavaScript, before finally getting around to Lisp in the form of Scheme, but by the time I did come around, I feel that I had a good idea of what to expect.
I didn't reject Scheme out of hand because it looked different than other languages. In fact, it had an immediate familiarity to it because of the work I had previously done all those years ago in SKILL. I may not have been able to take advantage of the power of Lisp when I was programming in SKILL because of the mental blinders I had on back then, but SKILL certainly helped me be more open, accepting, and curious about Lisp later on. Now I'm diving in again and having a blast learning what makes Lisp and functional programming so powerful. I wouldn't say that I've attained Lisp enlightenment, yet. I have a ways to go for sure, but I'm well on my way.
I have learned one major thing from this meandering path towards understanding Lisp, and it is that some context can make all the difference when learning something new. When you are trying to wrap your head around something that you've never seen before, it's important to know where it fits into the bigger picture. Otherwise, you'll end up making associations to other things you know, like previously learned programming languages, that end up restricting your knowledge of the new thing instead of enhancing it.
If I had known that SKILL was a dialect of Lisp, an entirely different programming language based on lists and a functional programming paradigm that I had never seen before, I would have approached it differently. I would have spent more time trying to understand how to use functional programming to its best advantage. I may have been much more effective at creating those tools that I was making, and I would have had a much richer experience with Lisp earlier on. That's something I can take with me for whenever I'm learning new things in the future. Understanding how different a new concept is to things you already know, and how it is different, can mean the difference between a superficial knowledge that may get the job done and a deep understanding that can take you beyond all of your current capabilities.
Stepping back to the beginning, I was an intern at an Application-Specific Integrated Circuit (ASIC) design company when I was in college. We designed analog circuits combined with a simple embedded microcontroller that all went on the same semiconductor chip. We would make these ASICs to measure signals from various sensors and condition the output to clean up noise, amplify the signal, and convert the signal to different digital and analog formats. The CAD software that we used to design our ASICs was a monstrous, expensive, nearly industry-standard tool called Cadence, and it had a scripting language called SKILL that you could use to instrument and automate almost any aspect of the software, like eLisp does for Emacs.
Cadence was new to our design group, as we had recently been bought by a larger company that used Cadence, so now we used it, too. As an intern for this company, I was tasked with learning Cadence inside and out and finding ways to make life easier for our design group and the rest of the company. That meant learning SKILL and writing tools that could speed up schematic capture, layout, simulation, and design checking.
I dove into learning SKILL and using it to improve the design group's work flow without ever realizing how rich SKILL's heritage was. The only languages I had learned previously were C/C++, Java, and Pascal. If you know Lisp, then you know that it is very different from these languages, but SKILL happened to have a C-style function call syntax and C-style comments in addition to its Lisp syntax, so I gravitated towards the C-style syntax in my code. I remember thinking a lot of the basic function names were kind of weird. I mean, why 'car' and 'cdr' to get the first item and the rest of the items from a list? And why were there so many lists to begin with? Everywhere I looked there were lists. It ended up being a convenient way to represent things in the Cadence environment, and I could do a lot of things in not a lot of code. But I certainly didn't understand why.
I most likely was not using SKILL to its full potential because I didn't understand what made it tick. Yes, I was able to get stuff done, but maybe not as well as I could have. I spent plenty of time constricting the language into what I was comfortable with in C without ever gaining the understanding of how powerful Lisp can be. I completely shied away from the full force of functional programming, and I probably missed out as a result.
It wasn't until years later from reading the blogs of Steve Yegge, Joel Spolsky, and Paul Graham that I started to understand that some programming languages can be quite different from the common ones, and I started to learn about Lisp in particular. Granted, I still didn't learn Lisp. I was only learning about Lisp, that it was somehow special, and that it could change you as a programmer. I ended up exploring other languages first, including Ruby, Python, and JavaScript, before finally getting around to Lisp in the form of Scheme, but by the time I did come around, I feel that I had a good idea of what to expect.
I didn't reject Scheme out of hand because it looked different than other languages. In fact, it had an immediate familiarity to it because of the work I had previously done all those years ago in SKILL. I may not have been able to take advantage of the power of Lisp when I was programming in SKILL because of the mental blinders I had on back then, but SKILL certainly helped me be more open, accepting, and curious about Lisp later on. Now I'm diving in again and having a blast learning what makes Lisp and functional programming so powerful. I wouldn't say that I've attained Lisp enlightenment, yet. I have a ways to go for sure, but I'm well on my way.
I have learned one major thing from this meandering path towards understanding Lisp, and it is that some context can make all the difference when learning something new. When you are trying to wrap your head around something that you've never seen before, it's important to know where it fits into the bigger picture. Otherwise, you'll end up making associations to other things you know, like previously learned programming languages, that end up restricting your knowledge of the new thing instead of enhancing it.
If I had known that SKILL was a dialect of Lisp, an entirely different programming language based on lists and a functional programming paradigm that I had never seen before, I would have approached it differently. I would have spent more time trying to understand how to use functional programming to its best advantage. I may have been much more effective at creating those tools that I was making, and I would have had a much richer experience with Lisp earlier on. That's something I can take with me for whenever I'm learning new things in the future. Understanding how different a new concept is to things you already know, and how it is different, can mean the difference between a superficial knowledge that may get the job done and a deep understanding that can take you beyond all of your current capabilities.
0 Response to "Learning Without Understanding"
Post a Comment