3 ms·

> create an industry standard plugin protocol. I feel that Software Engineering/Science is lacking a body of knowledge: something which is basically required i

> 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.

gngeal 13y ago
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 13y ago
  > 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 13y ago
  > 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?
mdaniel 13y ago
FWIW, there is a SEBOK ( https://en.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge https://en.wikipedia.org/wiki/Software_Engineering_Body_of_K... ) but I doubt it is what you had in mind.
jimbokun 13y ago
"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 13y ago
  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 13y ago
  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.
  - 13y ago

gngeal 13y ago

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 13y ago
> 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 13y ago
> 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?

mdaniel 13y ago

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

jimbokun 13y ago

"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 13y ago
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 13y ago
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.
- 13y ago