Live data from Hacker News

Where is the casual programming?

iamsamy.blogspot.com

51–60 of 83 posts

Re: Where is the casual programming?

#52

Earlier 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…

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 so (and that's if they even realize programming is a possibility).

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?

#53

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…

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…

I have started to look into Unity3D the past couple of weeks and I'm impressed. Deliver to Android/iPhone/PC/mac/xbox etc. I have never felt so close to make my dream game.

Re: Where is the casual programming?

#54

Earlier 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…

You used to have to type in 1s and 0s on a keyboard, or cut little square holes in a piece of cardboard with an Exacto knife. You had to learn what opcodes were represented by those 1s and 0s, in which contexts, and reverently hand your stack of cards full of holes to the Keeper of the Card Reader. You had to really, really want to program, with books open on the desk and your lap, and a grilled cheese sandwich holding open the one on your lap. I don't know if that's formal, but it sure doesn't sound like a casual drive around the block to me.

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?

#55
post #13

He 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…

why don't more people do casual programming of any kind?

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?

#56
post #49
post #23

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.

> 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".

I have intelligent object method/property auto-completion in Python in Emacs.

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?

#59
post #33
post #4

Casual 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. :-)

Thats true, but people use other worksheets as kind of declarative IO areas (that they print). And Google Docs is a big improvement as your spreadsheets get URLs and so enter into the outside world.

Re: Where is the casual programming?

#60
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.

Post reply on HN