Hacker News new | ask | show | jobs
by shaper_pmp 6018 days ago
Hi there - article author here. ;)

> I don't like idea that you should keep inconvenience in place to keep of idiots. Idiots won't succeed anyway but inconveniences harm professionals and novices.

I think you've misunderstood - the argument is not to keep inconvenience in, it's to avoid taking things out which aren't actually a problem in practice.

As you rightly said, "human languages are geared towards interactive communication not towards describing problems and solutions precisely". Therefore any attempt to turn a programming language into English is not going to address the real difficulties of programming - specifying the problem and solution in enough detail, modelling the desired system in your head, avoiding/considering/handling edge-cases, etc.

All it's going to do is to make the experience of programming fractionally easier for people with effectively zero programming skills, and hence give them unwarranted self-confidence.

It's like making a bike easier to ride by gluing the rider to the seat - sure it's technically "harder to fall off", but the problem isn't usually the rider falling off the seat - it's the whole bike falling over, taking the rider with it.

Likewise, the hard part of programming isn't remembering precise and finicky syntax - it's making sure your own thinking is precise and finicky enough that you can accurately express it in such a finicky, precise language.

I'm not arguing in favour of long function names (I'm not entirely sure how you got that from my post) - I'm arguing against people who think that by changing "print('Hi there');" to "print 'Hi there'" they've somehow solved the problem of "programming being hard to do".

1 comments

> I think you've misunderstood - the argument is not to keep inconvenience in, it's to avoid taking things out which aren't actually a problem in practice.

I really don't know what can be kept because it's not the problem, because I tried to get into programming and I succeeded. All barriers were passed. But the same barriers that I've passed without noticing may effectively discourage someone else.

Programming language is just UI of the complex automation system. It should be as easy, clear and intuitive as it can be. In my opinion same general rules should apply to computer languages design as to UI design. Designing good language is not about how to enable programmer to use hashmap (or whatever) with fewer keystrokes but how to make a man that has never seen a hashmap before to know at first glance that it might be solution to his problem and how to use it.

> Therefore any attempt to turn a programming language into English is not going to address the real difficulties of programming

Turning words into English is not gonna help much. But finding metaphors for programming concepts (for example dictionary instead of map) that are less mathematical and more similar to concepts encountered in everyday life might improve accessibility of the programming world.

I also think that computer should try to guess what you mean by what you are writing not give you a finger over a missing semicolon or quote. If there is ambiguity in what you have written he should ask you additional questions to establish what you want.

> It's like making a bike easier to ride by gluing the rider to the seat - sure it's technically "harder to fall off", but the problem isn't usually the rider falling off the seat - it's the whole bike falling over, taking the rider with it.

I see simple programming languages and systems more as a training wheels that protect you from falling off with the bike and never trying again. They introduce you to concepts of pedaling and steering so you can get some fun out of this activity and eventually teaching you how to keep balance by not punishing you too severely for loosing it.

> Likewise, the hard part of programming isn't remembering precise and finicky syntax - it's making sure your own thinking is precise and finicky enough that you can accurately express it in such a finicky, precise language.

Right. Even if you know exactly what is the datatype that you want to define you may have a hard time expressing it properly in C even if you are pretty good novice programmer.

That is just anecdotal example of syntax that can be obstacle even for smart people. We might have no idea what syntax might be obstacle for less mathematically inclined.

> I'm not arguing in favour of long function names (I'm not entirely sure how you got that from my post) -

Sorry. I mentioned PHP and that particular function because PHP is often perceived as too easy language that enables people who don't get the programming concepts to program and make a mess. I strongly disagree with that notion. I think that PHP's popularity is due to some very good decisions simplifying design (like single datatype to express various lists, dictionaries, arrays, lack of need for conversions between strings and numbers, run and forget model without long lived server side entities) and it's security issues are due to some very bad design decisions (one of them being the one I mentioned).

> I'm arguing against people who think that by changing "print('Hi there');" to "print 'Hi there'" they've somehow solved the problem of "programming being hard to do".

Claiming that such operation solves the problem of "programming being hard to do" is just silly because making programming easier is much harder thing that involves some real research on how people learn how to program.

But I think that this improves things slightly. Every unnecessary operation that has nothing to with you goal and lies between you and your goal is bad. Same as in UI design. All this ( ) ; is strange crap for graphic designer who wants his Flash flick to go to given page after clicking on it.