Hacker News Reader

Yup, it's kind of tedious seeing these types of article / blog post. As anyone that works as a programmer knows, it's not the grammar of programming that is hard. It's understanding the hardware and what it can do that is hard. It's encoding nebulous and sometimes conflicting business requirements into something a computer can understand that is hard. It's taking into account all of the different error states that a process can get into that is hard. Learning the syntax of a programming language? Not hard.

We as programmers have weird brains, compared to most of the population. You give a programmer the list of road rules, and they will probably immediately identify, instinctively, several rules that are mutually exclusive / in conflict with each other. You're able to understand how a home entertainment system needs to be set up, even though that's really not what most programmers do. You identify loopholes in legal frameworks / contracts, because the lawyers that wrote them aren't used to thinking about what has to happen for edge cases.

I agree with all the things you say are hard: understanding computation, encoding complex requirements, handling edge cases; but typing code into an editor and then re-running your application doesn't provide much support for making them easier. Better tools could help programmers and non-programmers alike work with that complexity much more effectively.

Tools are designed for certain requirements. As the commenter, antimagic, noted, these requirements can conflict. A better tool would definitely have to sort out those conflicts, but at this point we're talking about something like AI.

To talk down the scope of lots of projects, I've always educated a client by saying if certain types of thinking were automated then we'd have to say we were creating AI and that the cost of the project would grow exponentially.

They could, but those two sets of tools would be completely different and would be built based on completely different principles.

You identify loopholes in legal frameworks / contracts, because the lawyers that wrote them aren't used to thinking about what has to happen for edge cases.

The lawyers do understand, and did it on purpose. Programmers just think similarly enough to lawyers that they can sometimes find things that were meant to be hidden from the general public (and from the junior lawyers who work for the competition). :)

I don't find these articles tedious. I think it awesome that people want to solve more problems with computers. The more people that can solve problems, the more people that will solve problems, the more problems that get solved. People want to use the power of computers to solve problems, and that is hard to do. Until it is easy (never) these articles will continue.

I honestly don't think you can make it much simpler. That is not to say it is simple, just that it is by nature not simple. You can dress the concepts up, make them look nice with a graphical front end, but really the complexity comes from the abstract notions implicit in functions to be performed. You can tailor things by building libraries of functions to perform common tasks, but these abstractions are never going to be sufficient. What is required is a method of translating from the world we are most familiar with, described by our natural language, into the world described by the language of the computer. The translator needs to understand the context of the natural language requirement and find its correct representation in binary. This is the job of the programmer. An automated solution may well be able to pass the Turing test. That being said, I often think about how to leverage machine learning to help bridge the language gap. Evolving an application is an interesting idea, where the requirements are drip fed to the system through the language of the UI the program should present. Translations from some physical representation, cogs, roads, queues, etc might be useful since it is instinctive to many people yet more precise in its descriptive power than spoken language.

The belief that better tools will obsolete the need for all that coding effort is probably as old as computer programming itself.

Fred Brooks, author of The Mythical Man-Month, dismissed the idea in his 1986 paper No Silver Bullet:

"... building software will always be hard. There is no silver bullet."

http://en.wikipedia.org/wiki/No_silver_bullet

It's certainly at lest 30 years old. Before my voice changed I went to my first computer conference. People were selling tools there that would let business types do "programming" via just writing what they want in English. For minicomputers.

Of course, they had to write in a minimal, highly structured pseudo-English. And the problem domain was highly restricted. So it was basically programming, except less effective.

A fine example of the phenomenon that if enough people want something, somebody will come along and sell it to them, whether or not it actually works. I used to think this was malice, but as far as I can tell, greed, narcissism, and the Dunning-Kruger effect can explain it perfectly well.

It's probably good to try every so often, anyway, even though it's impossible. :-)

Trying is excellent. Trying and failing is also excellent, in that it's how we learn. Trying and failing and then selling the product as if it's a success? Less excellent. :-)

Exactly. I remember, once a friend wanted to create a tool for designers to use for creating HTML+CSS visually, without having to know actual CSS properties and such.

Then I explained, the hard part of laying out webpages is not the basic layout -- it's how layout reflows when text overflows, when the browser window is too narrow, when image sizes change, what things maintain alignment and what things don't -- and that by the time you've added all these options to your visual tool, the visual tool is now equally complicated as CSS, so you've defeated the whole purpose.

At its heart, it's the fact that the specification of the program is the program. The devil is always in the details. (Which, incidentally, is why it's so hard to estimate development time accurately.)

But we have some such better tools! E.g. Chrome's developer tools let you edit CSS properties and the document structure live, seeing results instantly. It's fantastically more efficient that coding and refreshing the page. Tools that better match the problem domain matter so much precisely because of the domain complexities like overflowing and arbitrary data.

It's a small step. I can easily imagine bigger ones.

The idea is to build a tool that better fits the problem domain. In this example a visual tool lifts the burden of remembering specific CSS syntax, HEX codes or browser inconsistencies. In turn it's easier for a designer to worry about more interesting stuff, like reflows or responsive layouts. I have great hopes for visual web tools, such as Macaw. I think it will really take off when we get reusable HTML/JS components.

But that doesn't mean we need to reinvent the wheel every single time. Now look at something like Macaw and tell me that doesn't look like a useful tool: http://macaw.co/peek/

It's a good thing you talked your friend down from creating something. The world has too many creators as it is. Don't they know that everything good has been created already? If it hasn't been done then it isn't possible!

Did you have a point here? Do you think he should have just said "sure man, sounds great, go for it!" Did you know that a lot of non-programmers have a lot of great ideas, and that educating them about the difficulties of implementing those ideas isn't actually a bad thing?

The particular app in question has been tried a million times and countless hours have been invested into it, perhaps learning from that body of work would be helpful? But hey, maybe that guy is The One who will come out of nowhere and solve the problem in a completely new manner (half-serious - it's technically possible, but I don't think it's useful to put our eggs in that basket).

Yes! Those exact words. "Sure man, sounds great, go for it!"

General rule of thumb, if your friend wants to achieve something, help them do it. Don't sit there telling them why they're going to fail. It almost doesn't matter what it is. They want to start a business, be a brain surgeon, jump the grand canyon on a motorcycle, whatever, believe in them and help them succeed. If you don't believe in them, what kind of friend are you really?

I do believe that there is an amazing HTML/CSS design tool waiting to be created. I don't know what it is, and I don't know if that guy would have been the one to create it, but I love to see people try. He probably would have learned a lot even if he failed.

That negative attitude just really gets my goat in real life. There's one guy at work on whom I can count to shit all over any idea I bring him. There's another guy who always gets excited about trying new things. Guess which one I would happily give a recommendation, and which one I wouldn't care if he fell out a third story window?

> Do you think he should have just said "sure man, sounds great, go for it!"

His friend would have made a lot of personal progress in their understanding and abilities.

Learning from your own mistakes is effective, but not efficient. Sometimes it's the best you can do, but when you can learn from other people's mistakes instead, that's a lot better.

You were able to read the website? All I see is:

Error establishing a database connection

Maybe the OP should hire a coder to fix his site?

I'm on it. Meanwhile, cache is http://webcache.googleusercontent.com/search?q=cache:qjCebmD...

Do as everyone does; keep reloading; you'll catch it :) Besides it being the reason the db is not responding.

It is funny to me that people extrapolate "code" as just our best way of representing computational instructions we want done that we can express in natural language. I agree with you that sometimes this isn't true. Sometimes I read code and I can't express what it does in English. I could roughly describe what it does, but I can't communicate all of its subtlety. The limitations of "no code" isn't the theoretical limits of AI it's human!

Poorly-written code (especially if the reader doesn't have a good grasp of the coding language) can be very confusing, but it will still almost never be ambiguous.

If you try taking some well-written code and converting it to natural language with utterly no ambiguity, you'll quickly find that:

- the natural language version is far, far longer and harder to read - it takes a lot of work to remove all ambiguities, and you will find yourself wanting to put a dictionary with strict rules and extensions -- totally unlike a REAL dictionary.

=> Word "allow" will always mean generally the 1st (verb) definition in Mirriam-Webster online, and will further imply that if the subsequent test (see below for definition) succeeds (definition below), then execution (see below) will continue; if the test fails (see below) then standard error (see below) handling procedure (see below) will be followed, in which...

It's ridiculous, isn't it?

You'd be inventing a new (but probably horrible) coding language, not using natural language at all any more.

The thing about natural language code -- it does exist, sort of. Think about the checklists that airline pilots run through before takeoff, for a good example.

That's sort of natural language process execution... but it's the same every time, the context is known (it's being executed by an airline pilot sitting in the cockpit of a specific airplane), the pilot is trained such that s/he has practiced running the checklist many, many times before doing it "for real". And: it's a friggin' checklist. Is logic in there whatsoever, beyond "if this is true, continue; if not, abort"?

The limitations on it are incredible, and we still have human beings executing that "code"; they are not automated. The answer to one of the questions might unexpectedly be "sort of", or "yes, value in the safe range, but why is it steadily dropping?"

Legal language is the canonical example of what happens at the end of that process.

Code can certainly be ambiguous. We call it unspecified behavior, undefined behavior, or race conditions, depending.

A race condition is a set of (possibly very many) very well defined states - or at least defined as well as everything else in the program. Someone should discover some algebra for working with concurrent processes and the race conditions would go away!

(the second sentence is a joke.)

A simple data race in C11/C++11 is undefined behavior, it doesn't have to result in any well-defined state that you might get by interleaving the execution of threads.

I think this has been on HN already: http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/why_undef.ht...

Essentially it has to be that way, or on some architectures every access to a potentially shared variable would have to be wrapped in fences by the compiler.

Strictly speaking, it could be implementation-defined behavior.

Ambiguity is quite frequently between several well-defined states. A significant difference between race conditions and natural language ambiguity is that in the latter we typically expect resolution to happen favorably when the interaction is cooperative - which is not a feature of race conditions in the general or typical case. I think it's still fair to say that this is not an essential feature of ambiguity, though, which is why I included it as an example. In the case of a race condition, the relevant pieces of the language do not uniquely define a single result - additional context may.

Right. By the time this problem is truly solved with software sophisticated enough to eliminate the need for programmers, most people will be fairly useless in any endeavor.

Code will disappear just as quickly as legalese disappeared after we were able to write clear and concise agreements in common, natural language.