Where is the casual programming?
21–30 of 83 posts
Re: Where is the casual programming?
#22Like anything else, things worth doing well take time to learn.
There are great tutorials out there to teach you the very basics of programming in a few hours. There are also great tutorials out there that teach you to play a basic song on the guitar in a few hours.
After that, its up to you. If it were easy, everyone would do it. I've been programming for close two two decades, and I still feel like I'm scratching the surface of programming. As various iterations of the saying go: The more I learn about programming, the more amazed I am that computers even boot up and function.
Re: Where is the casual programming?
#23It's a red herring to bring up the static vs dynamic typing issue, because both can readily support interactive autocompletion & documentation.
Even something as Spartan as the Javascript REPL in Chrome will do autocompletion of method names, despite being in a completely dynamically typed environment.
Re: Where is the casual programming?
#24I can't think of anything more casual than a shell script. Once you grok the syntax of the shell's control structures it becomes pretty easy to rig up just about any behavior one can imagine. I suppose some might consider the command line excluded from the category of casual by default but most of those people would be surprised at how insanely simple the command line actually is.
Re: Where is the casual programming?
#25There is one statically typed language with a nice toolchain that allows interactive (REPL) programming and scripting: F#. Try the steps here[1]. They're old, but still work, and work pretty well. It's fast; there's no need to create a project or solution. You can type your code all you want, use IntelliSense and all that, then select and Alt-Enter to execute it. If you don't want to load VS, you can just run "fsi" f…
And F# is not the only statically typed language with a (built-in or out of the box) REPL: ML, Haskell, OCaml, and Scala all have REPLs.
Some of these predate Java and C#, but I don't know what it is about those languages and the cultures around them that has ignored the value of a REPL. I guess part of it is just inertia at this point, but it's definitely one of the biggest things I miss when working in Java on Android.
Re: Where is the casual programming?
#26He sounds like's he's described VBA
Maybe, sorta.
Why don't people use VBA more for casual programming? Is it because it's Office-centric-ish?
Or, why don't more people do casual programming of any kind? Certainly lack of tools is one. Another is probably that most people don't exist in a culture where people do casual programming.
The biggest problem is that the things above the level of raw bits, the objects like documents and blog posts and check registers, are not themselves built to be manipulated in a casual environment. They're not built as part of a casually programmable environment. They're bits.
If you had a stack of books in English and Arabic and wanted to categorize them, you'd grab them and put them in their piles without thinking about it.
A blog post is nothing but bits. The only reason it's an English or Arabic post is that every program that touches it is required to, and agrees to, sniff it at a very low level and pretend that it's a blog post. The inside of a blog post looks exactly the same as the inside of a check register, and it's a huge leap from the bits that they are to the pseudo-objects that all relevant programs agree to pretend that they are. There is no casual middle ground, and so there's nothing that can be casually picked up and manipulated. You're a wizard, or an ardent apprentice, or you're nothing.
I think a real casual programming environment would look much less like app-centric VBA, or Excel (mentioned elsewhere), and more like Squeak (mentioned elsewhere). But it would work best if all the things on the system, at least the things that aren't dangerous to expose, are fundamentally casual objects. The browser window should be casual, as well as the post plugged into it.
Re: Where is the casual programming?
#27It's not as if Python or Ruby have set out to be deliberately difficult. They've grown difficulty because they're used to solve real problems, and real problems are hard. Implied inside your question is the idea that we can, in advance, choose the right level of abstraction. That we have a library / language / set of verbs that is neither too high level (like Automator) nor too low-level (like your bash script exampl…
"It's not as if Python or Ruby have set out to be deliberately difficult. They've grown difficulty because they're used to solve real problems, and real problems are hard."
The problem of getting from the East coast to the West coast has not changed in 100 years (move body until done), yet when was the last time you had to set the spark and choke and hand-crank a car? Cars solve real problems, and today's cars are sophisticated enough that essentially anyone can use one. To solve real problems.
Certainly the problems solved by a car are in a more narrow domain than programming languages. But cars themselves are in a narrower domain than internal combustion engines.
Edit: stealth.
Re: Where is the casual programming?
#28It's not as if Python or Ruby have set out to be deliberately difficult. They've grown difficulty because they're used to solve real problems, and real problems are hard. Implied inside your question is the idea that we can, in advance, choose the right level of abstraction. That we have a library / language / set of verbs that is neither too high level (like Automator) nor too low-level (like your bash script exampl…
The 3d-engine example is interesting, because I think there really have been huge improvements there in the past 5 years, through a mixture of UI and architecture. There are a wide range of "should be relatively simple" things that used to be unreasonably hard, but which with the advent of Unity3d are now much easier. Doesn't solve everything, but has given a several times improvement for a lot of low- to mid-hanging fruit.
Re: Where is the casual programming?
#29It's not as if Python or Ruby have set out to be deliberately difficult. They've grown difficulty because they're used to solve real problems, and real problems are hard. Implied inside your question is the idea that we can, in advance, choose the right level of abstraction. That we have a library / language / set of verbs that is neither too high level (like Automator) nor too low-level (like your bash script exampl…
"It's not as if Python or Ruby have set out to be deliberately difficult. They've grown difficulty because they're used to solve real problems, and real problems are hard." The problem of getting from the East coast to the West coast has not changed in 100 years (move body until done), yet when was the last time you had to set the spark and choke and hand-crank a car? Cars solve real problems, and today's cars are so…
Cars aren't used to cross the continent today, airplanes are. And most people have no idea how to use (pilot) an airplane, they pay someone else to do it for them.
Re: Where is the casual programming?
#30Earlier quoted context omitted.
"It's not as if Python or Ruby have set out to be deliberately difficult. They've grown difficulty because they're used to solve real problems, and real problems are hard." The problem of getting from the East coast to the West coast has not changed in 100 years (move body until done), yet when was the last time you had to set the spark and choke and hand-crank a car? Cars solve real problems, and today's cars are so…
Cars aren't used to cross the continent today, airplanes are. And most people have no idea how to use (pilot) an airplane, they pay someone else to do it for them.
For now.