Coding interactively is a rather different experience than coding "off line" (as it were), then running source through a compiler, then testing the results. I learned to appreciate that difference early, as I had FORTRAN and PL/1 in my face even as I was using APL (Kenneth Iverson's) from the terminal.
Given how enamored I was with using an interactive shell, more like Logo's, it stands to reason I would follow the dBase "dot prompt" in the direction of FoxPro, and then Visual FoxPro (VFP), which the language eventually became under Microsoft's dominion.
However, those more well-versed and well-rounded, know it's not either/or, given Python itself is written in C, and extended in C++ and all that. The joy of running C code interactively is what Python is all about, one could say. Furthermore, it's somewhat inaccurate to say interactive languages don't feature a compilation step. We have the bytecode layer, and a virtual machine (such as Java's) to think about.
Be that as it may, I stayed with the more interactive environment, which has more recently evolved into the Notebook environment. Steve Holden was nudging me to look at those early on, and I did, but just a little. I've subsequently come to better appreciate their significance, along the lines of that article in Atlantic Monthly.
In addition to an interactive chat-like "dot prompt" or "prompted" environment (now sported by JavaScript thanks to Node, right?), another feature that makes language learning so much easier (in my experience) is something concrete and visual, in your face, to code against. I'm talking about everything from physical robots to virtual on-screen turtles. Just having something there in the sandbox to play with, that's palpable, is a big aid to comprehension.
Eventually, we come to see a lot of what we're controlling "inside our heads" (goes the expression) and so may be less dependent on training wheel visuals. If you're into rendering colorful geometries on screen, or fractals or what not, then "leaving the visualizations behind" is not a goal, let alone much of an option. Under visualization comes plotting (making plots, charts), so it's not like having colorful, shapely output is that esoteric a fascination.
I think a lot of us will agree that a sea-change occurred with the evolution of the web browser atop the internet, given tcp/ip works inhouse as much as publicly. Why not make the user GUI an HTML defined experience? Indeed, that would become the norm, even though the web browser itself is what we'd call a "thick" application. Given how it spreads to look through almost every API out there, we could call it "thin" (a lot for a little, more with less).
However, a subsequent revolution after that, was the evolution of the smartphone-based app. The general purpose browser is still there, but the special purpose client-side application is again a driving thing. I didn't jump into the app business. I'm not that fascinated by tiny screens. I stayed with Python, especially teaching it, while gradually moving more into video-casting as a medium. Given my focus on geometry, it makes sense that I'd gravitate to a "show and tell rectangle" more like a movie theater's.
Given how enamored I was with using an interactive shell, more like Logo's, it stands to reason I would follow the dBase "dot prompt" in the direction of FoxPro, and then Visual FoxPro (VFP), which the language eventually became under Microsoft's dominion.
However, those more well-versed and well-rounded, know it's not either/or, given Python itself is written in C, and extended in C++ and all that. The joy of running C code interactively is what Python is all about, one could say. Furthermore, it's somewhat inaccurate to say interactive languages don't feature a compilation step. We have the bytecode layer, and a virtual machine (such as Java's) to think about.
Be that as it may, I stayed with the more interactive environment, which has more recently evolved into the Notebook environment. Steve Holden was nudging me to look at those early on, and I did, but just a little. I've subsequently come to better appreciate their significance, along the lines of that article in Atlantic Monthly.
In addition to an interactive chat-like "dot prompt" or "prompted" environment (now sported by JavaScript thanks to Node, right?), another feature that makes language learning so much easier (in my experience) is something concrete and visual, in your face, to code against. I'm talking about everything from physical robots to virtual on-screen turtles. Just having something there in the sandbox to play with, that's palpable, is a big aid to comprehension.
Eventually, we come to see a lot of what we're controlling "inside our heads" (goes the expression) and so may be less dependent on training wheel visuals. If you're into rendering colorful geometries on screen, or fractals or what not, then "leaving the visualizations behind" is not a goal, let alone much of an option. Under visualization comes plotting (making plots, charts), so it's not like having colorful, shapely output is that esoteric a fascination.
I think a lot of us will agree that a sea-change occurred with the evolution of the web browser atop the internet, given tcp/ip works inhouse as much as publicly. Why not make the user GUI an HTML defined experience? Indeed, that would become the norm, even though the web browser itself is what we'd call a "thick" application. Given how it spreads to look through almost every API out there, we could call it "thin" (a lot for a little, more with less).
However, a subsequent revolution after that, was the evolution of the smartphone-based app. The general purpose browser is still there, but the special purpose client-side application is again a driving thing. I didn't jump into the app business. I'm not that fascinated by tiny screens. I stayed with Python, especially teaching it, while gradually moving more into video-casting as a medium. Given my focus on geometry, it makes sense that I'd gravitate to a "show and tell rectangle" more like a movie theater's.
