3 ms·

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

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

darkmighty 13y ago
Let's not forget the principles though. Programming isn't magic; you still have to at least specify the intended behavior, even if without specifying the how. You could even specify approximately (or incompletely) the intended behavior of your system (and let another hypothetical system fill in the gaps), but that's not viable for every application in the future due to reliability. In the end this can't lead to something much different than saying "Sort this list" -- isn't that simply calling a sorting procedure?
lowmagnet 13y ago
I don't care if we're coding in procedures in the future, so long as the results are no longer stored in plain text files. The transparency is fine, but tools have to re-parse every time, and an AST allows tools to reason about the structure of the code.
- ericHosick 13y ago
  > 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.

darkmighty 13y ago

Let's not forget the principles though. Programming isn't magic; you still have to at least specify the intended behavior, even if without specifying the how. You could even specify approximately (or incompletely) the intended behavior of your system (and let another hypothetical system fill in the gaps), but that's not viable for every application in the future due to reliability. In the end this can't lead to something much different than saying "Sort this list" -- isn't that simply calling a sorting procedure?

lowmagnet 13y ago

I don't care if we're coding in procedures in the future, so long as the results are no longer stored in plain text files. The transparency is fine, but tools have to re-parse every time, and an AST allows tools to reason about the structure of the code.

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