[ericHosick]

> create an industry standard plugin protocol.

I feel that Software Engineering/Science is lacking a body of knowledge: something which is basically required in other professional industries (architecture, medical, physics, electrical engineering), etc.

Software Engineering/Science is at a disadvantage because there is no limitation placed on us by nature: an EE can't simply change the brightness of the sun to meet a requirement. We can.

To create an industry standard plugin is really saying we need to create a common way to communicate information between systems and sub-systems in software. I feel we have not really figured out the best way to do this yet. Our industry is still young.

I've put a lot of thought (about 6 years now) into a way to standardization communication between software systems and even parts of software. It's a hard problem to crack.

> common protocol between user environment and code transformer

I feel that once we crack the problem of communication between software parts, this will come naturally.

[mdaniel]

FWIW, there is a SEBOK ( https://en.wikipedia.org/wiki/Software_Engineering_Body_of_K... ) but I doubt it is what you had in mind.

[jimbokun]

"I've put a lot of thought (about 6 years now) into a way to standardization communication between software systems and even parts of software. It's a hard problem to crack."

HTTP?

It's not perfect, but it seems to be what our industry has settled on as the universal way for pieces of software to talk to each other.

If you are thinking in terms of the payload, JSON seems to be filling that role.

[robert-wallis]

Unix communicates via text, stdin stdout stderr. That's pretty much a standard.

Windows PowerShell communicates with typed objects. COM components and .NET components are a Windows standard way of communicating between software parts. COM has been around for a long time.

Between computers, TCP/IP is a standard way of communicating. But without good documentation of the protocol adding an HTTP layer on top makes it easier to understand. But without good documentation of the protocol RESTful APIs makes it easier to understand. But without good documentation of the protocol WADL...

However I do agree about HTTP. Because I imagine there are more devs that understand HTTP than higher or lower protocols.

[ericHosick]

Http is a protocol we use to communicate between systems, that is true, but not the parts of software. For example, to print "Hello World" on the screen, we use a sub-routine like WriteLine. The standard we use to communicate between software sub-systems, in this case, is a function with parameters. So, WriteLine ("Hello World") pushes the text "Hello World" into the sub-routine WriteLine.

Parameters are, for basically all languages, the means by which information is communicated between sub-systems.

The thing is, it is really hard to standardize the communication between sub-systems because sub-routines can vary widely in how they are defined (the possible combination of parameters and types is quite high). In fact, you can end up with thousands of different sub-routines: even in the same program. Each one unique and thus "non-standard".

This is the problem we need to crack. How do we create frameworks that don't lead to thousands of specialized interfaces: each one making the framework that much harder to use.

[Nzen]

Four months ago, Bret Victor published his "Future of Programming" Talk. The most inspiring part to me was his 'prediction' of discarding brittle api`s for systems that negotiate a communication protocol dynamically. (Toy example: modem filter negotiation) http://vimeo.com/71278954 Relevant explanation @ 13:30-16:30.

[ericHosick]

Ya. I saw that and it was awesome.

> api`s for systems that negotiate a communication protocol dynamically

I think the first step is to find a very easy way to describe communication between sub-routines/processes. Once people can hook things up and compose the interaction of software with foreign/unknown systems (all in real time while the software is running) then we can get systems to start doing it dynamically (run on sentence but ya).

[gngeal]

an EE can't simply change the brightness of the sun to meet a requirement. We can.

Wow, you can change the brightness of the sun to meet a requirement?

BTW, there are quite a few limitations placed on you by nature: uncomputable numbers, NP-completness, ...

[Guvante]

> BTW, there are quite a few limitations placed on you by nature: uncomputable numbers, NP-completness, ...

Not really, NP-completness is only important if you want perfect solutions, which aren't necessary. Uncomputable numbers have no usage in real world scenarios.

Finally it is important to note that while a physical turing machine cannot exist due to lack of infinite tape, real machines are also more powerful than turing machines, for instance by having a real time clock and communication abilities.

For these reasons saying what we can and cannot do is quite complicated. For almost every situation possible, the only answer that is negative about capabilities is "it will take a while".

[ericHosick]

> Wow, you can change the brightness of the sun to meet a requirement?

Sure, why not? sun.brightness = sun.brightness * 2.0f;

In fact, a lot of games play with physics to get cool behavior. I can adjust the "constant" G in my game to be something other than 9.8 m/s to make it interesting.

One moment the G vector may be down and then suddenly it flips up. Why not?