Code as plain text? Plain wrong I say [modified]
-
The earlier thread about tabs/spaces/indentation just reminded how much I wish those things were not even topics in the software industry. If you could click your heels three times and the whole software industry could change, would you still keep plain text for your code? If the whole IDE, diff and the whole ecosystem could change, would you still keep things the same? I wouldn't. Well, not in plain text I directly work on. I would much prefer a system where I query for the code I want, in the form I want, and I get to edit it how I want, and it gets pushed back to the source code repo in a semantic way. Sure there are wrinkles, and a thousand and one corner cases of "what if I rename this, and that, and do this, it just won't work!", but for me, if those problems could be solved, my work day would be so much simpler. Want to annotate code with diagrams? Not be limited to just half-arsed xml to document your work? Be able to add meaningful links between code that are retained across changes. View flow charts of code, and even modify code with flow charts. View your class with methods ordered any way that suits your style. Coworkers don't have to work the same way. I think there was a "Code Bubbles"[^] thing a while back that touched on much of this, but for Java code, and it looked pretty sweet. Wishful thinking? You bet.
modified on Wednesday, January 19, 2011 10:13 PM
Where I work now, a "rules-based" system is in place. There is a GUI interface and you define an application by dragging and dropping rules and setting properties. You can even define "sets" of rules as larger pieces of an application. But eventually you have to write some actual code to implement the rules, even if it's basically just an
if. That's my argument against what you describe -- at the lowest level, there must be actual code in some language that can be compiled to machine instructions. Can you store that any way other than as plain text? Will you simply store each plain text statement separately?<Program Language="BASIC">
<Statement Line="10" Comment="Assign the value 42 to the variable X">LET X = 42</Statement>
<Statement Line="20" Comment="Assign the value 3.145 to the variable Y">LET Y = 3.145</Statement>
<Statement Line="30" Comment="Display the product of X and Y">PRINT X * Y</Statement>
<Statement Line="40" Comment="Terminate the program">END</Statement>
</Program>or maybe the other way around would work better?
<Statement Line="10" Code="LET X = 42">Assign the value 42 to the variable X</Statement>
The code is still simple plain text; it's just stored differently. And you know that no one will write and maintain the comment properly. No, sir, I'll stick with code in plain text thank you very much. (And they can have my text editor when they pry it from my cold dead hands.)
modified on Thursday, January 20, 2011 1:00 AM
-
While 'GUI' coding seems to make sense, it fails to scale completely.
leppie wrote:
it fails to scale completely
Or does it completely fail to scale?
-
leppie wrote:
it fails to scale completely
Or does it completely fail to scale?
PIEBALDconsult wrote:
Or does it completely fail to scale?
Yeah, that one, sorry, my mind is still stuck in native language so early in the morning. ;P
-
PIEBALDconsult wrote:
Or does it completely fail to scale?
Yeah, that one, sorry, my mind is still stuck in native language so early in the morning. ;P
x86?
-
x86?
-
The earlier thread about tabs/spaces/indentation just reminded how much I wish those things were not even topics in the software industry. If you could click your heels three times and the whole software industry could change, would you still keep plain text for your code? If the whole IDE, diff and the whole ecosystem could change, would you still keep things the same? I wouldn't. Well, not in plain text I directly work on. I would much prefer a system where I query for the code I want, in the form I want, and I get to edit it how I want, and it gets pushed back to the source code repo in a semantic way. Sure there are wrinkles, and a thousand and one corner cases of "what if I rename this, and that, and do this, it just won't work!", but for me, if those problems could be solved, my work day would be so much simpler. Want to annotate code with diagrams? Not be limited to just half-arsed xml to document your work? Be able to add meaningful links between code that are retained across changes. View flow charts of code, and even modify code with flow charts. View your class with methods ordered any way that suits your style. Coworkers don't have to work the same way. I think there was a "Code Bubbles"[^] thing a while back that touched on much of this, but for Java code, and it looked pretty sweet. Wishful thinking? You bet.
modified on Wednesday, January 19, 2011 10:13 PM
IBM had something a few year back that tried to do something like what I think you are suggesting - it obviously never took off, but I think it would be good if it was done 'right' Have you seen things like the Lego MindStorm (I think that's the name) which uses a flowchart/icon/boxes and lines paradigm to program quite complex behavior. It would be fascinating to develop something like that for business programming!
___________________________________________ .\\axxx (That's an 'M')
-
While 'GUI' coding seems to make sense, it fails to scale completely.
I don't want GUI coding, I want more intelligent code storage.
-
Where I work now, a "rules-based" system is in place. There is a GUI interface and you define an application by dragging and dropping rules and setting properties. You can even define "sets" of rules as larger pieces of an application. But eventually you have to write some actual code to implement the rules, even if it's basically just an
if. That's my argument against what you describe -- at the lowest level, there must be actual code in some language that can be compiled to machine instructions. Can you store that any way other than as plain text? Will you simply store each plain text statement separately?<Program Language="BASIC">
<Statement Line="10" Comment="Assign the value 42 to the variable X">LET X = 42</Statement>
<Statement Line="20" Comment="Assign the value 3.145 to the variable Y">LET Y = 3.145</Statement>
<Statement Line="30" Comment="Display the product of X and Y">PRINT X * Y</Statement>
<Statement Line="40" Comment="Terminate the program">END</Statement>
</Program>or maybe the other way around would work better?
<Statement Line="10" Code="LET X = 42">Assign the value 42 to the variable X</Statement>
The code is still simple plain text; it's just stored differently. And you know that no one will write and maintain the comment properly. No, sir, I'll stick with code in plain text thank you very much. (And they can have my text editor when they pry it from my cold dead hands.)
modified on Thursday, January 20, 2011 1:00 AM
I want my text editor. Noone will ever take that away from me. Just let them try and I'll go all John Simmons on them :) I just want my code stored in a more flexible way that lets me put more than just text in there, and when I do ask for code, it spits it out in a form I want to read it in, not some form someone else thought was good at the time.
-
IBM had something a few year back that tried to do something like what I think you are suggesting - it obviously never took off, but I think it would be good if it was done 'right' Have you seen things like the Lego MindStorm (I think that's the name) which uses a flowchart/icon/boxes and lines paradigm to program quite complex behavior. It would be fascinating to develop something like that for business programming!
___________________________________________ .\\axxx (That's an 'M')
Yeah, the Lego Mindstorms are interesting, though I've never used them "seriously", just had a look. I used labView for a while, and it was nice as far as it went, but just was not as quick to implement things as writing code. I think it just boils down to me knowing that I don't want things the way they are now, but I also don't know what I'd really like :)
-
The earlier thread about tabs/spaces/indentation just reminded how much I wish those things were not even topics in the software industry. If you could click your heels three times and the whole software industry could change, would you still keep plain text for your code? If the whole IDE, diff and the whole ecosystem could change, would you still keep things the same? I wouldn't. Well, not in plain text I directly work on. I would much prefer a system where I query for the code I want, in the form I want, and I get to edit it how I want, and it gets pushed back to the source code repo in a semantic way. Sure there are wrinkles, and a thousand and one corner cases of "what if I rename this, and that, and do this, it just won't work!", but for me, if those problems could be solved, my work day would be so much simpler. Want to annotate code with diagrams? Not be limited to just half-arsed xml to document your work? Be able to add meaningful links between code that are retained across changes. View flow charts of code, and even modify code with flow charts. View your class with methods ordered any way that suits your style. Coworkers don't have to work the same way. I think there was a "Code Bubbles"[^] thing a while back that touched on much of this, but for Java code, and it looked pretty sweet. Wishful thinking? You bet.
modified on Wednesday, January 19, 2011 10:13 PM
- Text as base format - Full syntax parser / DOM library included with the IDE - Code Bubbles for navigation
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
- Text as base format - Full syntax parser / DOM library included with the IDE - Code Bubbles for navigation
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyYes please. Could you have done by Monday pretty please? :)
-
Yes please. Could you have done by Monday pretty please? :)
Sorry, I have an... appointment on Saturday, and a life on Sunday. Maybe next week.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy