Comment by programminggeek | Hacker News Reader

Comment by programminggeek | Hacker News Reader

Parent Full thread

programminggeek

I'm pretty sure that our assumption that programming languages will look like programming languages in the future is sort of like the assumption that phones will always have buttons on them.

Once Apple and other companies showed what the world looks like when a phone is a giant touch screen + giant battery, phones with buttons become a niche, not the norm.

I don't know what the programming paradigm is that completely changes that, but I do know that I haven't seen it yet and everything we've done so far seems to completely miss the mark.

Someone is going to come along with some other radical assumption about what designing/implementing software really is about.

I know that it is not about static vs dynamic, functional vs. imperative, etc. like we've traditionally thought. Maybe it will be more like using Excel or Gmail. Maybe it will be more like flowcharts, or maybe just like sketching out a structure and the machine knows how to wire it together for you. Maybe humans won't be involved at all.

Speculation is endless, but nobody has had the iPhone unveil of new programming paradigms yet.

Speaking from personal experience, the thought: "Take away languages. Now what do I use instead?" can be paralyzing.

I'll suggest an alternative approach that might stimulate your neurons. Look back at the ways that your life is improved reading code today compared to twenty years ago. When I look back, the highlights for me are:

a) version control, and

b) automated tests

Forget all their benefits to the people writing code. For me, the guy with one afternoon to make a tweak to an alien codebase, it has been invaluable to have not just the current snapshot of a codebase but a story of its evolution so that I can see what the skeleton of the program used to look like in a simpler time, and gradually play enhancements forward atop it[1]. It has also been invaluable to be in situations where I can go, hmm why do I need _, why don't I just rewrite it as _, try it, and find a failing test with an enlightening name.

What's common to these two ideas is that they are additive. You don't have to give up programming languages. You just need new ways to share information between programmers besides just the code that runs "in production". My current favorite candidate for the next augmentation for codebases is logs. More info: http://akkartik.name/post/tracing-tests. If that whets your appetite feel free to get in touch. My email is in my profile.

[1] More details of how this helps: http://akkartik.name/post/wart-layers

I agree on readability as a prime area for improvement. Thats one of the things I tried to tackle in Obvious (http://retromocha.com/obvious/) but readability is a human/social/communication problem.

Programming as it is now is a 2 way communication mechanism, we are writing code for other humans to understand, but for a machine to translate into what we intend for the machine to execute.

So, your point of making code a better human to human communication mechanism is absolutely correct.

What I really wonder about is what set of tools could exist that could solve whole sets of low level problems that we are specifying now that we shouldn't. Sort of like, right now we have blueprints and so on, and then humans look at those and build a house. Yet, with 3-D printed houses, you feed a set of materials and specifications into a machine, and you get a house built for you.

What is the programming equivalent that would allow us to "3-D print" software, so to speak? For physical things, it seems to be the combination of 3-D CAD systems, 3-D printers, and maybe some thought about how things need to be designed to fit this approach.

I have no idea exactly, but I could see a future where instead of paying people to hand craft all the code, that a series of features, modules, structure, etc. are specified, and the software is just "built". There would be more effort in the specification, but less on the build.

I remember programming a Lego robot with this visual puzzle piece method as a kid. It was awesome. I have a feeling something similar already exists for general purpose programming. I can definitely see something visual-based that hides a lot of unnecessary details working for a lot of basic applications - at least to get the skeleton of an MVP up.

My guess is that one thing that future software will have is automatic generation of user interfaces.

I think "naked objects" or "apache isis" are the best examples we've got for that for now , but they are rooted in somewhat complex java code, instead of being rooted in an easy to use tool, such that lets the business analyst who had some course , sit with the client and fully define a running system , step by step. In some cases the auto-generated UI would be good as it is , and the system will be used as-is.

In other cases , we might need easy tools to customize the UI.

I saw apache is as mention.it nearly the same what i doing now.consider as code block-From database column can create application.Upon combobox figure come foreign key value.The reason i do this,client keep playing what if scenario form like this is this suppose to validate or not?Why code block instead of user define validation.They will some part wanted to customize triple field combobox filter.It cannot be done via user define column based rule.

The assumption that UI design must be done by hand is probably one of the most important "bottleneck" in software development.

When you think about it, the job of a designer is often quite systematic. You have some entities/data you need to communicate to the user, through whatever interface/device that's available to him. A touchscreen, a keyboard, knobs, LEDs, microphone, speaker, paper, etc.

When your "user" is a computer, JSON (while not perfect) seems to do the job as an interface. In the case of humans, JSON does a poor job at efficiently communicating information.

For humans:

- A calendar is better than "2012-11-05"

- A color is better than "#FF3300"

- An image is better than "http://example.com/image.png"

- A clickable link is better than "http://example.com/document.html"

The list goes on. We can easily generate a basic UI based on complex entities, and map specific types to custom/reusable templates if needed.

Now that your UI can automatically be generated from data, you can build an app (business model) once, and make it usable (and actually look and feel good/native) on any device. A smartwatch, a smartphone, a smarttv, etc.

Basically, the core of software development should be knowledge representation. Describe the world semantically (with RDF or similar technologies), and let the UI-compiler generate a UI for any given target platform, language, culture, user preferences. That's what responsive design should be all about.

What you're saying is reasonable, and there are lots of people attempting to make RAD systems. Unfortunately, they always place severe limitations on the kind of software that can be created with them, and hence none of them have become particularly popular.

It seems that there's something missing from all the existing implementations of your suggestion. Perhaps it is that the UI and data flow primitives that we have aren't flexible enough to express a lot of business models, thus requiring custom implementations.

Delphi, Visual Basic, FoxPro and Access were all extremely popular RAD tools exactly because they made creating a certain class of systems extremely easy.

I had the misfortune of using Visual FoxPro once upon a time. It was horrifyingly bad, but perhaps by that time (2002-2004) it was suffering serious impedance mismatch with the rest of technology which had moved on. Anyway, I wouldn't call it a good example :)

Regardless, that was kind of my point - all these systems are only good as long as you stay within their constraints. The unfortunate thing is that the constraints always end up being way too tight in practice.

Reply on news.ycombinator.com