What I mean is, there's not going to be a big fundamental shift in how interfaces for programming work, like there has been for, say, how databases work, or how file managers work, or things like that. We'll still be typing things into buffers.
I don't agree with you, and I've considered several replies about IDE's and what programming really is (data entry is not the definition of programming), etc, etc but you'll probably say Emacs is an IDE, which avoids the point, and talk about the fact that you can't program without data entry, which also avoids the point, so, well. *shrug* I've already argued with your simulation in my head and we didn't get anywhere. Is that messed up or what?
Programming may not be data entry, but the interface for programming certainly is. The interface for anything is. And there's simply no other way to enter programs that's fundamentally better than Emacs. All the other things that I've used are refinements to Emacs.
If you define programming as "typing", then, as I said, you've avoided the point. Plus, I certainly hope there IS a fundamental change such that we might, following your pattern, define programming as "talking" in the near future, or maybe as "connecting lines and boxes with some typing" or perhaps even as "thinking".
There are opportunities for a fundamental change at the level you define it, and using a more robust definition of programming, there already have been and will continue to be major improvements over how things used to work 20-30 years ago when vi and emacs were state of the art. Just the simple ability to lay out a user interface graphically is one good example of doing something other than typing. In Visual Studio, there are a significant number of things that can be done, from the creation of classes and the insertion of new functions and variables that do not involve seeing the actual screen buffer of the code. There are other visually oriented tools such as autocomplete, graphical debugging interfaces and UML modeling which all involve a lot more than simply typing. Plus, why do we even need to see text buffered in the manner we currently see it? Why exactly should we be bound to the physical file representation that we currently use? More fundamental changes to programming.
Yes, but like I keep saying, I am not defining programming. I am defining the interface for programming. I find that a lot of the criticisms people have of Emacs, and my liking it, results from them not having used Emacs. So I'll wait here while you go download a copy of Emacs, a recent version, and use it some. Then you'll know that it can do things like autocomplete and graphical debugging. As for UI layout, it's only so capable, and it only ever will be. While it's good for generating code for some things, most things of any real complexity you'll be typing text into a buffer.
What constitutes programming? Is the editing of resources (say, scooching a checkbox down a few pixels) programming? Is adding a button to a dialog programming? Is it only programming if you modify the resource files directly, instead of in an IDE? Does the use of a program like Klik 'n' Play count as programming? Is defining a macro in an office suite "programming"? Does it matter what kind of macro it is?
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2005-09-13 03:33 pm (UTC)no subject
Date: 2005-09-13 03:41 pm (UTC)no subject
Date: 2005-09-13 07:07 pm (UTC)no subject
Date: 2005-09-13 08:40 pm (UTC)no subject
Date: 2005-09-13 09:23 pm (UTC)no subject
Date: 2005-09-14 02:25 pm (UTC)If you define programming as "typing", then, as I said, you've avoided the point. Plus, I certainly hope there IS a fundamental change such that we might, following your pattern, define programming as "talking" in the near future, or maybe as "connecting lines and boxes with some typing" or perhaps even as "thinking".
There are opportunities for a fundamental change at the level you define it, and using a more robust definition of programming, there already have been and will continue to be major improvements over how things used to work 20-30 years ago when vi and emacs were state of the art. Just the simple ability to lay out a user interface graphically is one good example of doing something other than typing. In Visual Studio, there are a significant number of things that can be done, from the creation of classes and the insertion of new functions and variables that do not involve seeing the actual screen buffer of the code. There are other visually oriented tools such as autocomplete, graphical debugging interfaces and UML modeling which all involve a lot more than simply typing. Plus, why do we even need to see text buffered in the manner we currently see it? Why exactly should we be bound to the physical file representation that we currently use? More fundamental changes to programming.
no subject
Date: 2005-09-14 03:28 pm (UTC)I find that a lot of the criticisms people have of Emacs, and my liking it, results from them not having used Emacs. So I'll wait here while you go download a copy of Emacs, a recent version, and use it some. Then you'll know that it can do things like autocomplete and graphical debugging.
As for UI layout, it's only so capable, and it only ever will be. While it's good for generating code for some things, most things of any real complexity you'll be typing text into a buffer.
no subject
Date: 2005-09-14 04:18 am (UTC)