matlab has a lot of these features, and so did genera for lisp machines. Proprietary development stacks win when it comes to solid documentation.
Where is the casual programming?
41–50 of 83 posts
Re: Where is the casual programming?
#42He wants a fucking ide for casual programming.
Then he dismisses all of the actual causal programming -- which happens in shell these days -- and marches on to blather about gui toolkits.
This man is a clod.
Re: Where is the casual programming?
#43I 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.
For us, but not for people who don't program otherwise, yet would like to casually do more with their computers than what the installed apps do. Thinking of what you want to do is the more important part of doing something; it seems like, in the spirit of the OP's post, you shouldn't have to make such a large leap from what you want to how to do it. It is what it is today, merely because it is what it is.
Thinking of what you want to do is the more important part of doing something;
Agreed, and those who don't program otherwise are at the cognitive mercy of the metaphors defined by a "user-friendly" abstraction. Of course, there is always a balancing act; we all rely on abstractions, but at some level a user has to understand how a system works in order to adequately conceptualize the task they want to execute.
This isn't to say that we should expect anyone who wants to get more out of their machine to learn shell scripting or that we can't make things easier for non-programmers, but just like playing an instrument or writing a book, hobbyists should readily expect that they won't be able to do much unless they take the time to learn the system and the tools.
Re: Where is the casual programming?
#44It'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…
No, you did a very good job of explaining this. Just wanted to let you know.
Re: Where is the casual programming?
#45with ipython you do get some of that auto completion for python. It'll autocomplete the module name for you, but you do have to figure out you want that module first, so you'd need to google and realize you want shutil for dealing with files. I use it a lot when I'm interacting with new APIs or even just for writing the code as I go. In [1]: import sh sha shelve shlex shutil In [1]: import shutil In [2]: shutil. ...…
check out path.py
https://github.com/dottedmag/path.py
it's awesome for dealing with paths instead of having to do stuff like
os.path.abspath(os.path.join(os.path.join(x,y),z)) path('/home/me').files('*.jpg')Re: Where is the casual programming?
#46with ipython you do get some of that auto completion for python. It'll autocomplete the module name for you, but you do have to figure out you want that module first, so you'd need to google and realize you want shutil for dealing with files. I use it a lot when I'm interacting with new APIs or even just for writing the code as I go. In [1]: import sh sha shelve shlex shutil In [1]: import shutil In [2]: shutil. ...…
check out path.py https://github.com/dottedmag/path.py it's awesome for dealing with paths instead of having to do stuff like os.path.abspath(os.path.join(os.path.join(x,y),z)) everytime, it gives you nice abstractions like path('/home/me').files('*.jpg')
Os.path.join can take more than two arguments. So it's not as bad as that example.
Re: Where is the casual programming?
#47Earlier 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…
I'm sorry, but this analogy is awful. Getting from coast to coast certainly HAS changed in the last 100 years. 100 years ago, you had railroads or mostly dirt roads. A crap ton of infrastructure has been put into it (interstates and the intensely complex logistics of maintaining them). A pile of services exists around this problem (airlines, and the even more complex logistics of keeping them running safely and profi…
"Further, a car is simple to use out of the box"
Exactly my point. They didn't use to be simple. Crank, choke, throttle, water in the battery, where's the next fuel repository, where are my goggles, where is the rug for my legs, etc. Now they are, and you just think of moving your body from here to there, and almost not at all about how to make your car help you do that. Now people use a car casually.
It's that kind of change, only much more profound and difficult to achieve, that will be needed before people can "program" (if we still call it that) computers casually.
Re: Where is the casual programming?
#48I 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.
I've been programming since I was in 6th grade and I still want to cause physical harm to myself instead of write a shell script for any shell.
Re: Where is the casual programming?
#49It'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.
> var n = 42; n.[[TAB]]
No auto-complete. It's severely limited to only live objects. Which may be an argument for REPL, but it's not an argument for "dynamic languages can have autocomplete".
Re: Where is the casual programming?
#50It seems like you literally are describing Processing. I'm not sure if you've heard of it: http://processing.org
It is designed for non programmers – artists and designers, so do a lot of things you are asking for.