
Ask HN: Why do we still need to “program/write code” ? - dmode
Of all the things programming has disrupted, the least impacted has to be the task of programming itself. I recently learned Swift after taking a break from coding for over a decade. And it took me just over a month to learn, because it is so similar to Java, which I had learned over 20 years back. I am still perplexed that so little has changed. Why do still have curly braces, and strange annotations to accomplish simple tasks ? Why do we still need to call strange methods like &quot;letTouchesBegin&quot; to achieve simple transactions ? Why do I need to implement Node.js + Mongo + Express + React + Postgres + Backbone + blah blah to send a message to another person ? In my mind, in the 21st century programming should have been essentially abstracted and behind the scenes, only a few experts need to know it and tweak it. For vast majority of us, we should be able to say to a bot like interface &quot;create a payment app that sends payments between two friends&quot; and that interface should be able to do the things that are needed behind the scenes. We should be able to create our business logic for our applications, not through complicated SQL statements and backend codes, but by simply training a model on expected behavior through examples or discrete visual rules. Why hasn&#x27;t that been accomplished it ? And is there someone working on actively disrupting programming itself ?
======
tsukikage
The hard part of programming is not the code.

It is understanding that there is a problem which is solvable, understanding
the shape of that problem well enough to arrive at a way to solve it, working
out that solution, and then expressing it clearly to another entity, whether
human or computer.

None of these things are special to programming; they are all specialized
skilled work that is still hard in fields that do not involve computers.

Mathematicians create and communicate theorems. Legislators create and
communicate law. Engineers create and communicate designs for mechanisms.
Chefs create and communicate recipes.

All but the most trivial fields involving one person talking to another rely
on a large body of knowledge shared by the participants, and use domain
specific language in order to communicate ideas clearly and unambiguously. It
is not absolutely required, but it saves an incredible amount of time,
misunderstanding and wasted effort. When discussing matters of any complexity,
clear communication is vital.

There is certainly room for the jargon and workflow to improve; for us to come
up with languages that are more expressive in their domain, and for processes
that are more intuitive - whether by being closer to what communicating your
ideas to another skilled human would be like, or some other way.

But the actually hard work can no more go away than in any other human
endeavour.

------
oldcynic
People have been trying to disrupt programming since my earliest memories of
computing in the 80s. There's been AI "solutions" aiming to simplify
programming, or enable non-programmers to participate since then too.
Memorably there was a program called "The Last One" that was going to put all
programmers out of work [1]

Much of what you seek is there. payment services, banks, networks have an API
or an SaaS (Stripe, Paypal etc) that mean you're dealing with much simpler
entities.

Back when I was first messing with code you'd first have to get the banks to
agree to allow access to account data. Then you'd probably be writing in C or
C++ to conform to whatever standard arose, perhaps over X25. There's libraries
and services covering so many of the basics, usually with a JSON API, now it's
sometimes hard to believe. You can be astonishingly productive building on
that.

What's left are the parts that are frequently going to be solution or
preference dependent. The unique to the app parts, and the code that glues
that and the building blocks, frameworks, and APIs together.

[1]
[https://en.wikipedia.org/wiki/The_Last_One_%28software%29](https://en.wikipedia.org/wiki/The_Last_One_%28software%29)

------
dragonwriter
> Of all the things programming has disrupted, the least impacted has to be
> the task of programming itself.

I disagree. It's just that the big disruptions in the task of programming
happened earlier than the other disruptions.

> In my mind, in the 21st century programming should have been essentially
> abstracted and behind the scenes, only a few experts need to know it and
> tweak it.

It is. That's why the interesting apps are so much more complex than they used
to be, and all the developers are working in highly-abstracted frameworks on
top of high-level language, and only a small minority are working even in C
(which wasn't considered a particularly low-level language in the 1980s.)

> We should be able to create our business logic for our applications, not
> through complicated SQL statements and backend codes, but by simply training
> a model on expected behavior through examples or discrete visual rules.

Sufficiently large training sets for complex applications don't exist, and for
complex business processes, we write detailed processes for humans, too, to
assure clarity of expectations. Why would we expect even with AI, which aims
ultimately to mimic human intelligence, to not need that?

------
kingbirdy
Customization. Your payment app, for example: should it have a social feed,
like venmo? Integrations with websites, like PayPal? Take credit cards, like
square? What payment methods will you support? How are user accounts handled?
Can they hold a balance in your app, or is it bank to bank? You could keep
asking questions forever. Ultimately, we still need programmers to implement
whatever answers we come up with to these questions.

However, much of it _is_ abstracted away now - if you're making a payment app,
you're probably going to use stripe, because that's a hell of a lot easier
than bootstrapping your own credit card processing system. If it has a web
version, you're probably going to use a js framework or two, to abstract away
boring things like handling state and manipulating the DOM.

Until a computer can read your mind to know __exactly __what program you want,
you 'll still need to do some programming

------
ry_ry
Obviously you get that programming is the process of telling the computer what
to do. Without being told what to do a computer is a very capable paperweight.

Frameworks, high level languages and other abstractions are supposed to make
it easier for us meatbags to compose and organise our instructions.

Somebody - be that a human, an AI or some other mechanism - still has to
compose those instructions in the first place. And if you remove humans from
the application programming side, you still need to create and maintain the
mechanism for figuring out what instructions to dispatch in any given
circumstance.

I think there is much more room to disrupt the _process_ of programming, to
remove much of the domain knowledge and break down barriers to entry, but
ultimately the core problem of telling a dumb machine which bits to flip won't
go away with current architecture.

