ericHosick

> I don't care if we're coding in procedures in the future

In my opinion, the procedure/sub-routine/method/function, and specifically these things with parameters, as an abstract concept is the reason why software engineering isn't maturing.

Procedures are difficult to use. You have to prepare to call them by obtaining all the information they require to be used (what you push into them via parameters), do something with the results and deal with any un-intended outcomes of using the procedure.

Procedures lead to specialization. In the world today, there are probably millions of procedures with unique signatures. Each time we create a new signature, we complicate the process by which our software framework(s) communicate. Specialization, in this case, is not good. It's makes using the frameworks more difficult.

Also, the procedural signature of any given behavior will be different based on the programmer who writes it and, even more so, the framework for which it is written. There is no way to easily assure, across the industry or even within a small group, that the signature of any given behavior will be the same.

> I do think that it would be kind of a shame if in forty years we're still coding in procedures...

I agree with this. Software frameworks have improved but are still unnecessarily complex.

As we build out a solid body of knowledge in software engineering, we will end up with frameworks that are much easier to use than what we have today.

In my opinion, such frameworks would support the composition of software, hooking up behavior, as opposed to the "coding" of software (calling procedures).

Most likely this composition would take place in some kind of visual development environment though it could still be "coded".

They also struggle with functions, parameters, pointers, scope and so on.

You don't need to pass parameters to your car to start it. You don't need to force yourself to only focus on the recipe (scope) when making dinner.

None of these things map very well with the real world and could also be considered additional mental overhead when learning. You don't need to know how to code to learn best known practices in building software.

My sentence was poorly written. I wanted to say "Programming is the critical thinking aspects of developing software and critical thinking is a skill that everyone should master: starting with children."

I don't want everyone to think like programmers. I want programmers to think like everyone else and hope some day that everyone can be programmers.

> It seems like you have a horse in this race.

Ya. We do. We've been working on a new development methodology and from that a visual object language and framework. Initially we coded against the framework but have found that you can visually represent usage of the framework equally well.

> really appropriate for programming beyond toys (or maybe data modeling, but not procedural programming)

Funny you say that. I also agree if you are using traditional approaches to software development (aka procedure programming). However, our framework does not use procedural programming per-se in that it has no paramaterized procedures/methods/functions/sub-routines.

> rely on using your own words

People used to say they would "program their VCR".

Also, I didn't in any way mean to imply that they were definitely different. I did say "I look at coding and programming as different things" as opposed to "Coding and programming are different things".

> Automator is not programming.

Automator is not coding.

> The difficulty in programming isn't the mechanical act of writing code;

I look at coding and programming as different things.

Programming is the critical thinking aspects of developing software and a skill that everyone should master: starting with children.

The act of writing code, and more specifically using frameworks designed with the intent of being coded against, is unnecessarily difficult.

I've always spent more time fighting with bad frameworks than I do implementing desired behavior.

Once I figure out the peculiarities of a compiler, I'm good to go. I can code fast. But, getting to that point takes a long time. It is especially difficult for people learning to program when they have to learn to code (edit: at the same time).

Software development is fundamentally broken and it frustrates me to no end.

> Is it possible that these students might have other types of intelligence?

It does make you wonder how many people would have made great programmers but gave up because they could not get past the step of learning how to code.

In general, nailing down requirements is a very tricky part of engineering.

Having a system/body of knowledge to map requirements to implementation is really important.

Specific to software engineering, this process is best supported with BDD and TDD (in my opinion). BDD gets you 100% coverage of behavior: what the "customer" wants. TDD helps you cover edge cases which improves on robustness (which is the process you are describing above).

Coding before you have behavior (what customer wants) is, in my opinion, a bad idea (product market fit first).

Any type of development approach, ill-relevant of it being coding or visually oriented, is going to be iffy without using best known practices.

Now, if you are doing R&D then I would ignore the above process of BDD/TDD with the understanding that any code/program written would be "thrown out" (not put into production).

What external APIs are working in Copper? Stripe? Twilio? etc.?

We are working on a fully composable frame and concurrency is done as follows (upper-case = Object, lower-case = property):

AsyncRun ( part SomeObject )

multiple items can run in parallel like this:

AsyncRun ( part SomeObjectA SomeObjectB .. )

synchronization:

AsyncSync ( part AsyncRun ( part SomeObjectA SomeObjectB .. ))

locking a property:

AsyncRun ( part AsyncLock ( lockName = "someName", part = SaveUser ( ... ) ) )

On main thread (for UI/UX):

MainThreadRun ( part SomeObject )

> This is probably why the grand-old parent recommends earplugs in addition.

Ya. Exactly. The noise cancellation works great to remove the engine noise. But as soon as you turn them on, high-pitch sounds become a lot more apparent. Earplugs help alleviate that.

The ear plugs get around the need for high volume.

Ear plugs and noise-canceling headphones (Bose QuietComfort for example) work really really well.

Turn up the music/white noise to get past the ear plugs just a little bit.

No sounds get past this.

> The market isn't "films". It is "entertainment".

Kevin Spacey on this subject: http://www.youtube.com/watch?v=P0ukYf_xvgc.

It also looks like, in an accident, the lights on the Tesla start to flash.

I really agree that the cost between off the shelf software and custom software is too large.

We are trying to solve this type of problem by providing a framework developers can use to create general purpose templates. Those templates, a long with help on how to configure them, can be used to "slap on a feature or two".

It is an interesting problem to solve.

Went to share this and following showed up:

"This website lets users to bla bla bla..." (cause og:description).

Just something to note.

> It comes down to the age-old problem of how to represent and store logic in a fashion that end users aren't afraid to manipulate.

I agree.

It's the difference between someone who builds a car and someone who drives it. Building the car using diagram-as-programming is probably going to be complex.

Using the car in a diagram/visual environment is, in my opinion, the sweet spot of such systems.

How much do you think a journalist license is going to cost and how many licenses will be offered every year?

What would have happened if the question had been rephrased to "Ok, you have stop car, start car and check car. What do you do to restart a car"? Perhaps they would have done a lot better because they have a better understanding of the car domain.

The purpose of a visual language is not to replace domain experience. If you put me in front of a drawing program with a pallet of red, blue and green and ask me to create the color cyan... Then we're gonna have a bad time.

Visual programming does not claim that critical thinking is not required: aka programming in this context.

We've chatted with people who've said "I can not get the coding thing. That has always been hard for me. Designing and taking bigger concepts and parts and putting them together: assembly. I get that." These people can solve problems, they understand critical thinking. They have expertise in their domain.

What they don't get is a mapping process of automating a real world system (what programming is) in a computing device by coding out the solution.

Don't even get me started on education where students are expected to learn how to think critically (do that mapping thing) and fight with, to them, totally nonsensical compiler errors as they try to learn coding and syntax.

In my opinion, a lot of brilliant future programmers are lost because they don't enjoy fighting the compiler/interpreter.

You make a fair point.

> why bother with the visual notation instead of just putting it in text they understand equally well?

Consistency of implementation - even across different domains.

Learning/Thinking - different people learn and think in different ways (Visual Learning - https://en.wikipedia.org/wiki/Visual_learning, Auditory Learning - https://en.wikipedia.org/wiki/Auditory_learning, Kinesthetic Learning - https://en.wikipedia.org/wiki/Kinesthetic_learning)

Ease of Use - It is not possible to have syntax errors. (Logical errors/misunderstandings of the problem being solved are still possible).

I'm not quite sure what "text they understand" means. Are you talking about natural language interpreters (as you mention above)? That would/will be some cool technology and my feeling is that it is a "next step" in software evolution. Maybe, more likely, the next step is a planned or constructed language interpreter (http://en.wikipedia.org/wiki/Constructed_language). Natural language is so tricky (but maybe not for very domain specific problems).

I've always liked Connections: https://en.wikipedia.org/wiki/Connections_(TV_series). What is so great about this show is that James Burke is able to point out how new and amazing ideas come about by connecting a few, seemingly unrelated, concepts to make a new idea.

In my opinion, the ability for someone to take a few observations about the world around them and turn it into something new and amazing is what makes them brilliant.

We are now at a point in history where a lot of people are able to take in a lot of different ideas leading to a lot of new discoveries (one of the reasons why I think new technology is now being created at an almost exponential rate).

You seem to be implying that a particular problem can't be solved because brilliant people in the past have not solved it yet. In my opinion, problems aren't solved yet because someone has not "connected the dots" yet.

> But there are many advanced techniques that only experienced developers will be able to grapple with.

At one time iterators were considered a technique and a design pattern. Now, they are a part of most languages. They are transparent. They are taken for granted.

Currently, programming takes place within the domain of software development. It is not surprising then that we value advanced techniques within the industry. Just like there are advanced techniques that are used within the domains of electrical engineering, mechanical engineering and biology (just to name a few).

As we get better at our job as programmers, we further make our "advanced techniques" transparent to those that use our systems. Sure, currently, these systems are usually very domain specific. However, there is nothing to say that we can not build better software development environments which are both non-domain specific and, at the same time, hide the underlying complexities that require experienced developers.

In my opinion, these development environments would use a type of visual language enabling a lot more people to program. I am biased because this is a problem I've been working on for quite a few years now.

>It's much easier to express yourself using language than by drawing.

I've done a lot of programming at the white board and it involved a lot of drawing. And I suck at drawing. But I was able to get my ideas across to others.

This might also be of interest: http://www.agilemodeling.com/essays/communication.htm.

You might also want to consider that people learn and communicate best in different ways:

* Visual Learning - https://en.wikipedia.org/wiki/Visual_learning * Auditory Learning - https://en.wikipedia.org/wiki/Auditory_learning * Kinesthetic Learning - https://en.wikipedia.org/wiki/Kinesthetic_learning

and others.

> If you tried to draw that it would be unreadable, but it is perfectly fine code

You seem to be implying that no one could figure out how to apply the "7 +/- 2 rule"(https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus...) to a visual programming language.

> And visual programming solves this how?

Every step in the development process moves those people with the domain-expertise/vision/creative process/etc. further from the solution. Removing steps, like coding, brings the solution closer to the domain experts/visions/create process/etc.

Visual programming makes it a lot easier for people to work collaboratively. For example, those with the domain-expertise can work closer with those that have programming experience in a visual language.

Just a few ways that visual languages could democratize programming.

> you spend all your time trying to fit things on a screen in a way that doesn't look like a tangled ball of yarn (hint, can't be done)

The way we code now leads to tangled balls of yarn. That won't be fixed by simply moving to a graphical (visual) programming language.

As some people have mentioned in this HN post, it is hard to define what programming means.

A program is the result of the automation of some process (system) that people have thought up (even things that couldn't exist before computers). Programming is the act of taking that process (system) and describing it in a computing device of some kind.

Programming currently requires some kind of mapping from the "real world" to the "computer world". The current mapping is done primarily with source code. So, it currently seems that people who are good at programming are good at mapping from the "real world" into the "computer world" via coding.

You seem to be making the point that some people are just good at programming because they can do things like "re-discover the bubble sort algorithm" or understand CAP theorem. These are very domain specific problems.

For people who are able to "re-discover inventory control management" they would do a great job of automating it (programming) if they had an easier way to map that process (system) to a computing device.

The ultimate goal (other than maybe AI) is a 1-to-1 mapping between a "real world" process (system) and a computing device that automates it.

Do you really think that in 20 to 40 years from now, we will still be hacking away in some computer language that only a very few "elite" people know?

Programming needs to be Democratized and I think one of the best ways to do this is by removing coding as a necessary step in programming process.