There 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" for the interactive shell alone. You'll lose the full IntelliSense and colour highlighting, but you still get tab-completion. Plus, F#'s syntax is much lighter than C# or Java, so it's nicer for quick scripts.
Quite frankly, for any level of programming, I find having a REPL available is such a massive productivity boost. I shouldn't have to give up static type checking and a slick IDE to get it.
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.
Indeed -- as long as the problem domain is "strings and numbers", and doesn't require any I/O. That's a pretty small fraction of the things I actually need to do. What would his 7-line shell script look like in Excel?
The great thing about functional languages is they have no side-effects. The lousy thing about functional languages is they have no side-effects. :-)
As a direct answer to the question and based on the problems the author raises, OS X's "Automator" is just that. It's casual yet still pretty powerful automation/programming. It loads fast, it has a visual IDE of sorts, and it can do a lot of jobs you'd otherwise use shell scripts for.
(author here) I'm not a Mac user, but took a look at Automator now. It seems a big step in that direction. Still, I'm not sure it makes the casual programming problem solved. Maybe I misrepresented the problem; let me give some more examples on casual programs that could be made easier...
* Quickly testing small game ideas or demos (programming as self-expression).
* Solving an ACM problem or one of those programming job puzzles without too much setup.
* Writing the blog tagger example in the blog post, and other "do my web tasks for me" code.
I think a good casual IDE could be written for various types of needs, not just automating the OS or Apps..which are certainly an important part of the problem.
I 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.
It'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.
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".
I have found a great solution for this, but it is not an IDE(!)
It is the bpython CLI. (I hear ipython is good too)
When I forget some string method's name, I just type "str." and a dialog box appears with all the options. If I am learning a new module I use "help(<function>)" or "<function>.__doc__"
oh yeah, and there is auto-complete. and syntax highlighting.
Where is the casual carpentry? Why can't I make my own tables and chairs? How do I know which tools to buy? Why so many different types of screw heads with no clear indication in the box as to which kind should I use? Tapered shank what? How do rivets even work?!
And it's not like it's a new thing either we have had wood manufacture for millennia!
IMHO some things will never get past the hobbist-accessible stage.
I agree. If the OP was talking about mechanics, he could be saying: "I want to build a hotrod from scratch, but oh look so many little parts!".
I think that what many people fail to realize is that although the intended purpose seems simple enough, the tools to do it are sitting atop so many levels of abstractions that without prior knowledge you just have no way to figure where to start assembling the parts. The only way for a hobbist to manage that, would be with the right tools pre-assembled for some finite set of purposes that could guide most of the work.
I'm a little disappointed that none of the posts here actually discuss how these (pretty pertinent) issues might be solved in the future in any way different to how they are at present.
The issue of having to choose a combination of 1000 overlapping libraries and languages, for instance, is one that affects us all, and is actually pretty recent. Whats the best solution for the future? Surely its not just 'google them all'....
Languages and libraries are, after all, supposed to make the leap between the conception of a simple idea and its implementation easy. If they fail to do this something will change.
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.
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 example) to solve the problem. While I think we can improve a little bit on the set of abstractions that we have, I think a broad solution is naive.
As a point example, I used to be frustrated that so-called 3D engines tended to grow until they included the kitchen sink. Why do I need a menu system as part of my 3D engine? Why do I need a sound engine? Can't I just use system libraries like a sane person? etc. All I want is a set of primitives that let me render models to the screen. How hard can it be?
It turns out that the problem of rendering graphics to a screen quickly is so hard that it actually infects the hardness of other problems. Doing elastic collisions is a trivial thing that any first-year physics student can do. Until, that is, your game loop skips six frames because it's busy rendering graphics code, at which time you need to retroactively handle collisions that have occurred in the past. Now we're doing rocket science, and so your graphics library needs its own physics system, because you're not going to derive that stuff. And that, basically, is the story of every feature added to every serious game engine that exists today.
You see this problem everywhere you look, for example, at one point people thought POSIX and C were reasonable building blocks that everyone would use, and at another point people thought that about Java. At first, BSD sockets was the primitive, now we're starting to think about HTTP connections as the primitive, maybe we should work to make REST requests in Python not suck so damn much? But at this point SPDY looks like it might be turning into a thing, so maybe we should just build primitives for that instead? If you look at this staggering tower of abstractions you start to see things that seem crazy, like SPDY including its own flow control even though TCP already has it, because TCP has some bad assumptions that should be really be fixed at the network level, but will never be fixed there as a practical matter. I hope you followed Inception, because if not you're gonna have a bad time.
I'm doing a bad job of explaining this, but I had this insight first after reading an article by Kamp, the author of Varnish: https://www.varnish-cache.org/trac/wiki/ArchitectNotes. He makes the argument with a specific example that as we have moved to higher-level primitives, we've built an overly simplistic mental model of how the lower-level ones like OS and hardware work. As a result, we implement our own caching code, because we've forgotten that OSes were designed to do that for us. So in a sense we have more power because we have this nice set of high-level primitives, but in practice we've forgotten all the things that those primitives wrap, we've started to believe that they are simple because they look simple. And so, we muddy up our application code with all this stuff that has already been solved.
I doubt very much that there is any software program that people actually use that is not either undergoing a big refactor right now or has one scheduled, either to make things "simpler" (less abstraction) or "more powerful" (more abstraction). Just thumbing through the projects that I work on, I am adding features to a mental backlog for a future refactor for every single one of them. This seems to be like a fundamental problem that all software projects have, and creating a new set of primitives and saying "no seriously, that should do the trick" is at best going to yield a nice little language like Python or Ruby that somebody will post articles about on HN saying why it's so hard for casual use.
"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.
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.
The languages are mostly fine (until some next-gen language surprises us all); I think the current problems lie generally within tooling and infrastructure, which in turn come from our mentality and the existing workflow that we're used to.
That said, I enjoyed reading your very insightful post :)
with 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.
...
shutil.copy shutil.errno shutil.move
In [2]: help(shutil.move)
To do other more powerful automation kind of stuff, this is pretty nifty: http://sikuli.org/
Like 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.
>feels too much like piecing together jigsaw puzzles where you first have to know which pieces actually exist.
Well... that describes programming in many ways. That's not to say that shell scripting is the perfect casual programming environment - in fact, it certainly isn't! - but that anyone dabbling in things will certainly come to feel that problem. When I hacked in BASIC thirty years ago, then moved to Pascal, and then to C, that's largely how I felt the whole time.
I do not understand his first reason for understanding programming AT ALL.
He writes:
>To have an aid for thinking and expressing ideas. What Steve Jobs called "A bicycle for the mind".
But if he can't express any ideas due to trying to be "casual", how has he reached his goal in any way?
English is not my first language, yet I had to get a pretty firm grip on it in order to being able to express my ideas in English: there is no "casual English-learning", you either learn it or you don't.
The question is, do people at large even want to do casual programming?
Stepping back, what does "casual programming" mean anyway? Automate certain repetitive tasks? Do some complicated calculation? Write a two-player tic-tac-toe? Make a Sudoku solver?
For the most part, "casual programming" for people who are not into the abstraction layer have been mostly done in Excel/VBA. Most people just don't realize that IS a valid form of "programming" (albeit a very limited subset of it). It's like people who play Angry Birds/Farmville (or Minesweeper in the '90s) obsessively don't consider themselves as gamers, even though they might have spent more time "gaming" than most Counter Strike "gamers".
On the other hand, if you want to dig more into programming, tools like Lego Mindstorm or Scratch teach the concepts rather beautifully. It makes moving onto an actual general purpose programming language much easier.
It seems like one of the big things he is talking about is good documentation which includes usable example code.
Bash Shell scripting would be a lot simpler to use if each man page for a program or shell function had 10 or so examples with the most common command uses which were easy to paste into an editor.
Course my real preference would be the inverse. Search how to do something, return code in the specified language/shell to do it. Right now that's done by Google and other search engines, though rather poorly. Also google doesn't compare and contrast implentations.
The faster we can find a way to implement our goal, the greater our efficiency. That is something abstraction does of course , but we should remember that documentation also serves programmers.
I started programming with PHP, and I was easily able to apply all that knowledge of (rather basic) web-dev to the CLI. If I need a quick script my first instinct (besides bash) would be to fire up TextMate and write some PHP. As a beginner, whenever I needed to do something Google always had the right answer (e.g. "php check if string contains string"). This helped because I never felt like I was reading tons of documentation, and always gave me a quick answer. Once you use the same function a few times you generally remember it.
[+] [-] MichaelGG|14 years ago|reply
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" for the interactive shell alone. You'll lose the full IntelliSense and colour highlighting, but you still get tab-completion. Plus, F#'s syntax is much lighter than C# or Java, so it's nicer for quick scripts.
Quite frankly, for any level of programming, I find having a REPL available is such a massive productivity boost. I shouldn't have to give up static type checking and a slick IDE to get it.
http://blogs.msdn.com/b/jomo_fisher/archive/2008/08/25/f-scr...
[+] [-] spacemanaki|14 years ago|reply
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.
[+] [-] j_s|14 years ago|reply
[+] [-] zmj|14 years ago|reply
[+] [-] ken|14 years ago|reply
The great thing about functional languages is they have no side-effects. The lousy thing about functional languages is they have no side-effects. :-)
[+] [-] petercooper|14 years ago|reply
[+] [-] mohamedsa|14 years ago|reply
* Quickly testing small game ideas or demos (programming as self-expression).
* Solving an ACM problem or one of those programming job puzzles without too much setup.
* Writing the blog tagger example in the blog post, and other "do my web tasks for me" code.
I think a good casual IDE could be written for various types of needs, not just automating the OS or Apps..which are certainly an important part of the problem.
[+] [-] vectorpush|14 years ago|reply
[+] [-] read_wharf|14 years ago|reply
It is what it is today, merely because it is what it is.
[+] [-] drivebyacct2|14 years ago|reply
[+] [-] ef4|14 years ago|reply
Even something as Spartan as the Javascript REPL in Chrome will do autocompletion of method names, despite being in a completely dynamically typed environment.
[+] [-] strager|14 years ago|reply
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".
[+] [-] jisaacstone|14 years ago|reply
I have found a great solution for this, but it is not an IDE(!)
It is the bpython CLI. (I hear ipython is good too)
When I forget some string method's name, I just type "str." and a dialog box appears with all the options. If I am learning a new module I use "help(<function>)" or "<function>.__doc__"
oh yeah, and there is auto-complete. and syntax highlighting.
[+] [-] EdiX|14 years ago|reply
IMHO some things will never get past the hobbist-accessible stage.
[+] [-] ttt_|14 years ago|reply
I think that what many people fail to realize is that although the intended purpose seems simple enough, the tools to do it are sitting atop so many levels of abstractions that without prior knowledge you just have no way to figure where to start assembling the parts. The only way for a hobbist to manage that, would be with the right tools pre-assembled for some finite set of purposes that could guide most of the work.
[+] [-] twelvechairs|14 years ago|reply
The issue of having to choose a combination of 1000 overlapping libraries and languages, for instance, is one that affects us all, and is actually pretty recent. Whats the best solution for the future? Surely its not just 'google them all'....
Languages and libraries are, after all, supposed to make the leap between the conception of a simple idea and its implementation easy. If they fail to do this something will change.
[+] [-] drewcrawford|14 years ago|reply
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 example) to solve the problem. While I think we can improve a little bit on the set of abstractions that we have, I think a broad solution is naive.
As a point example, I used to be frustrated that so-called 3D engines tended to grow until they included the kitchen sink. Why do I need a menu system as part of my 3D engine? Why do I need a sound engine? Can't I just use system libraries like a sane person? etc. All I want is a set of primitives that let me render models to the screen. How hard can it be?
It turns out that the problem of rendering graphics to a screen quickly is so hard that it actually infects the hardness of other problems. Doing elastic collisions is a trivial thing that any first-year physics student can do. Until, that is, your game loop skips six frames because it's busy rendering graphics code, at which time you need to retroactively handle collisions that have occurred in the past. Now we're doing rocket science, and so your graphics library needs its own physics system, because you're not going to derive that stuff. And that, basically, is the story of every feature added to every serious game engine that exists today.
You see this problem everywhere you look, for example, at one point people thought POSIX and C were reasonable building blocks that everyone would use, and at another point people thought that about Java. At first, BSD sockets was the primitive, now we're starting to think about HTTP connections as the primitive, maybe we should work to make REST requests in Python not suck so damn much? But at this point SPDY looks like it might be turning into a thing, so maybe we should just build primitives for that instead? If you look at this staggering tower of abstractions you start to see things that seem crazy, like SPDY including its own flow control even though TCP already has it, because TCP has some bad assumptions that should be really be fixed at the network level, but will never be fixed there as a practical matter. I hope you followed Inception, because if not you're gonna have a bad time.
I'm doing a bad job of explaining this, but I had this insight first after reading an article by Kamp, the author of Varnish: https://www.varnish-cache.org/trac/wiki/ArchitectNotes. He makes the argument with a specific example that as we have moved to higher-level primitives, we've built an overly simplistic mental model of how the lower-level ones like OS and hardware work. As a result, we implement our own caching code, because we've forgotten that OSes were designed to do that for us. So in a sense we have more power because we have this nice set of high-level primitives, but in practice we've forgotten all the things that those primitives wrap, we've started to believe that they are simple because they look simple. And so, we muddy up our application code with all this stuff that has already been solved.
I doubt very much that there is any software program that people actually use that is not either undergoing a big refactor right now or has one scheduled, either to make things "simpler" (less abstraction) or "more powerful" (more abstraction). Just thumbing through the projects that I work on, I am adding features to a mental backlog for a future refactor for every single one of them. This seems to be like a fundamental problem that all software projects have, and creating a new set of primitives and saying "no seriously, that should do the trick" is at best going to yield a nice little language like Python or Ruby that somebody will post articles about on HN saying why it's so hard for casual use.
[+] [-] read_wharf|14 years ago|reply
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.
[+] [-] _delirium|14 years ago|reply
[+] [-] mohamedsa|14 years ago|reply
That said, I enjoyed reading your very insightful post :)
[+] [-] RollAHardSix|14 years ago|reply
[+] [-] uncr3ative|14 years ago|reply
[+] [-] kami8845|14 years ago|reply
https://github.com/dottedmag/path.py
it's awesome for dealing with paths instead of having to do stuff like
everytime, it gives you nice abstractions like[+] [-] aidenn0|14 years ago|reply
[+] [-] winkerVSbecks|14 years ago|reply
It is designed for non programmers – artists and designers, so do a lot of things you are asking for.
[+] [-] conductr|14 years ago|reply
edit: not saying that's a bad thing, IBM says 5 years to go http://mashable.com/2011/12/19/ibm-mind-reading/
[+] [-] irishcoffee|14 years ago|reply
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.
[+] [-] kylemaxwell|14 years ago|reply
Well... that describes programming in many ways. That's not to say that shell scripting is the perfect casual programming environment - in fact, it certainly isn't! - but that anyone dabbling in things will certainly come to feel that problem. When I hacked in BASIC thirty years ago, then moved to Pascal, and then to C, that's largely how I felt the whole time.
[+] [-] a_bonobo|14 years ago|reply
He writes: >To have an aid for thinking and expressing ideas. What Steve Jobs called "A bicycle for the mind".
But if he can't express any ideas due to trying to be "casual", how has he reached his goal in any way?
English is not my first language, yet I had to get a pretty firm grip on it in order to being able to express my ideas in English: there is no "casual English-learning", you either learn it or you don't.
[+] [-] ckpwong|14 years ago|reply
Stepping back, what does "casual programming" mean anyway? Automate certain repetitive tasks? Do some complicated calculation? Write a two-player tic-tac-toe? Make a Sudoku solver?
For the most part, "casual programming" for people who are not into the abstraction layer have been mostly done in Excel/VBA. Most people just don't realize that IS a valid form of "programming" (albeit a very limited subset of it). It's like people who play Angry Birds/Farmville (or Minesweeper in the '90s) obsessively don't consider themselves as gamers, even though they might have spent more time "gaming" than most Counter Strike "gamers".
On the other hand, if you want to dig more into programming, tools like Lego Mindstorm or Scratch teach the concepts rather beautifully. It makes moving onto an actual general purpose programming language much easier.
[+] [-] lsiebert|14 years ago|reply
Bash Shell scripting would be a lot simpler to use if each man page for a program or shell function had 10 or so examples with the most common command uses which were easy to paste into an editor.
Course my real preference would be the inverse. Search how to do something, return code in the specified language/shell to do it. Right now that's done by Google and other search engines, though rather poorly. Also google doesn't compare and contrast implentations.
The faster we can find a way to implement our goal, the greater our efficiency. That is something abstraction does of course , but we should remember that documentation also serves programmers.
[+] [-] _rs|14 years ago|reply
[+] [-] mvanveen|14 years ago|reply