Where is the casual programming?
51–60 of 83 posts
Re: Where is the casual programming?
#52Earlier quoted context omitted.
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…
So, perhaps computers themselves have progressed much like cars. It is now possibly to use a computer casually. But programming per se is significantly less casual than it once was.
Re: Where is the casual programming?
#53It'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…
Re: Where is the casual programming?
#54Earlier quoted context omitted.
"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…
The difference is that it was easier in the past for people to program casually; it hasn't gotten easier. Consider the microcomputers of the 80's: it was very difficult to own one without knowing at least a bit of some BASIC dialect. Consider microcomputers now: most people get away without ever knowing what it's like to write a program. People who actually want to learn how to program must go out of their way to do…
I wouldn't know an opcode from a gerund, and I don't want to know.
Now I can Write a Program for Dummies, or I can write Python the Hard Way, or I can alert('hello world'), all as close as https://encrypted.google.com/search?hl=en&q=how%20do%20I... while holding a sandwich in one hand. That's not as casual as the OP would like, but it's pretty darn casual compared to The Day.
Edit: vocabulary.
Re: Where is the casual programming?
#55He 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 re…
I'm not sure I understood what the author meant by casual programming, but the first thing I thought of as I read your comment was HyperCard.
Re: Where is the casual programming?
#56It'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".
The argument for "dynamic languages can have autocomplete" is that they already do in a variety of modern editors (like Emacs) and IDEs (like PyCharm et al).
You're not only ignorant, but proudly so.
Re: Where is the casual programming?
#57Re: Where is the casual programming?
#58Re: Where is the casual programming?
#59Casual programming happens in Excel every day.
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. :-)
Re: Where is the casual programming?
#60Bash 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.