31–40 of 83 posts
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()" or ".__doc__"
oh yeah, and there is auto-complete. and syntax highlighting.
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.
It is what it is today, merely because it is what it is.
Casual programming happens in Excel every day.
The great thing about functional languages is they have no side-effects. The lousy thing about functional languages is they have no side-effects. :-)
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.
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" f…
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 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…
You do realize that this is like saying "certainly two times N is smaller than two to the Nth power"? ;)
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 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…
But computing problems _have changed_. Not necessarily in areas like problem size (although that has happened) but also in areas of usability and convenience.
A much more apt analogy would be: the problem of stopping at the grocery store after work is 50 years old, why can't I get an optimal set of directions that accounts for rush hour traffic in 2012? I can give you any number of reasons: we've built more roads, there are more drivers, travelling salesman turned out to be a hard problem, game theory is hard, etc. In some dimensions (cranking the car, proclivity of gas stations, etc.) the situation has improved, but solving some problems re-emphasize the ones we haven't solved.
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 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…
Further, a car is simple to use out of the box, but customization beyond do-dads and bling? Nope, not really easier than it ever was. Different tools? sure. Different base skills? not really. Anyone can do it? Not so much.
And before I go into tech equivalencies here, if you think cars are pretty much the same and can be abstracted to "the car" for the purposes of this discussion, go buy a van or pick up truck. Watch your social graph get all buzzy and see the request pour in for help, turns out your form of tradeoff in "car" are very very useful to people, and suddenly a car isn't just a car.
Further, I would argue that we have done wonders for the tech equivalent of "car". We have amazing computation devices in our pocket that just do what people never knew they wanted to do in the form of "phone". We have awesome abilities to have web presence unthinkable (outside of internet famous blog machines) 10 years ago, in the form "social graph". These are great and just work for most people, until they need something different...
In the infrastructure department: the ability to do semi-custom stuff has grown in ways unimaginable in the car world. Need a website to do your magic? Here are a bunch of platforms like app engine or heroku, all you need to do is get your custom stuff in place, don't worry about the machinery to feed it. Up and down the customization level there are more entry points as well. Going back to the car world, how easy is it really to get a ricer put together? How easy is it to put in crazy hydrolics or a good thumping stereo system? Need to rip off the doors, reshape the body and put in a different engine? Good luck getting a doctor to just do that without serious learning curve.
Basically, my point here is that hard stuff is hard. If it isn't your specific field, it is easy to just blow off the stuff that caters to the masses as "they made it easy", and at the same time, it is easy to blow off the stuff in your field which caters to the masses as "not done well".
Final thought: a lot of people look at cars and computers the same way, as soon as the littlest thing goes wrong, they freak. or they take it to the mechanic who asks "why haven't you changed the oil in 7 years? (c.f. our IT guys who ask why they don't have anti-virus installed).
Earlier quoted context omitted.
(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…
Are you prolific or at least very capable at using grep, sed, awk, tr, sort, uniq, cut, wc, and cat? I don't think you need to read a book about shell scripting, but I think if you are familiar with these tools, there's a whole lot of things you can do with pipes. If you are opposed to learning them (and regular expressions), then there's no language that will ever please you. Most importantly, except for some caveat…
IMO a truly casual programming tool is about the quickest route from "need" to "working code".
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.