Plurality - Modular Code Editor
-
The paradigms you are holding up are all heavy on the drag-and-drop and other mousing / touching ... perhaps "too heavy" except for beginners. Just as some prefer XAML / HTML over the designers.
Quote:
The paradigms you are holding up are all heavy on the drag-and-drop and other mousing / touching ... perhaps "too heavy" except for beginners. Just as some prefer XAML / HTML over the designers.
The paradigm I am discussing is exactly this: can be advanced to create the code from scratch, but it is not smart to do this more than once. A beginner who uses a very well-implemented script, he is a professional much more advanced than another that creates a "jerry-rig" from scratch, or loses all afternoon to try reinvent the wheel. That is, are the "results", is the "solution of problems" that define what is advanced or beginner, efficient or only waste of time. Anyway, when they invented the writing they said the same: This will leave people without memory. Truth. But, that's the way humanity goes.
-
The paradigms you are holding up are all heavy on the drag-and-drop and other mousing / touching ... perhaps "too heavy" except for beginners. Just as some prefer XAML / HTML over the designers.
The paradigm: Can be advanced to create the code from scratch, but it is not smart to do this more than once. A beginner who uses a very well-implemented script, he is a professional much more advanced than another that creates a jerry rig from scratch, or loses all afternoon to try reinvent the wheel. That is, are the "results", is the "solution of problems" that define what is advanced or beginner, efficient or only waste of time. Anyway, when they invented the writing they said the same: This will leave people without memory. Truth. But, that's the way humanity goes.
-
Hello. I'm not sure if this is the appropriate topic, but the insights of this subject are valid. What do you think about an code editor like this: Image 01 Image 02 Image 03 Premise: "typing the same code twice is work for robots. Each time you do that, humanity ceases to evolve - and you mainly". The idea here is to abolish the organization of files and folders. Files e folders, It is like machine language, does not interest to current programmers. The project organization can be done only inside the Code Editor. If the files are all exported within a single folder, or hundreds of folders, or the entire file is a single file, this does not matter to the programmer. After exporting the file, what matters is mainly performance. And the performance can not be compromised by our desorganization, habits and addictions when write code. And to maintain the code, what matters is mainly an organized project and expandable. Then, more useful is to have a "virtualized image" of the file, composed of the modules that make up this file and the entire program. A example in HTML5: Virtualized file inside Code Editor: (index.html) (init) (head) (body) (end) Spaghetti that does not matter: folder/index.html
<!-- Init -->
<!DOCTYPE html>
<html lang="en"><!-- head -->
<head>
<meta charset="utf-8">
<title>title</title>
<link rel="stylesheet" href="style.css">
<script src="script.js"></script>
</head><!-- body -->
<body>
<!-- page content -->
</body><!-- end -->
</html>So you can create a "code block" for index.html, only once. And, if this is already part of the Code Editor library, you just search: index, and drag the block to the project. You do not need of a dumbsense or keyboard shortcuts that you do not remember or even know exist, nor do you need to be consulted documentation at all times to do
Gurigraphics wrote:
If the files are all exported within a single folder, or hundreds of folders, or the entire file is a single file, this does not matter to the programmer.
Matters to me. Folders provide a way to categorize and thus group code that relates to each other while separating it from other code that doesn't.
Gurigraphics wrote:
After exporting the file, what matters is mainly performance. And the performance can not be compromised by our desorganization, habits and addictions when write code.
If someone has a measurable performance problem because of their code organization when developing then my expectation would be that it is a design/architecture problem. It has nothing to do with the underlying persistence mechanism of the code.
Gurigraphics wrote:
The idea here is to abolish the organization of files and folders
Rather certain this has been tried multiple times before. Idioms that are successful rapidly take over in the world and continue to be used long after that. Those that do not work do not. You might want to research past experiments which had larger market attempts to sell them to see why they failed to take off.
-
Gurigraphics wrote:
If the files are all exported within a single folder, or hundreds of folders, or the entire file is a single file, this does not matter to the programmer.
Matters to me. Folders provide a way to categorize and thus group code that relates to each other while separating it from other code that doesn't.
Gurigraphics wrote:
After exporting the file, what matters is mainly performance. And the performance can not be compromised by our desorganization, habits and addictions when write code.
If someone has a measurable performance problem because of their code organization when developing then my expectation would be that it is a design/architecture problem. It has nothing to do with the underlying persistence mechanism of the code.
Gurigraphics wrote:
The idea here is to abolish the organization of files and folders
Rather certain this has been tried multiple times before. Idioms that are successful rapidly take over in the world and continue to be used long after that. Those that do not work do not. You might want to research past experiments which had larger market attempts to sell them to see why they failed to take off.
Quote:
Matters to me. Folders provide a way to categorize and thus group code that relates to each other while separating it from other code that doesn't.
Currently is that so. But, I think (by practical experience with Stencyl) that if the project is organized inside the editor, that's all that matters for the programmer. In this other paradigm, continue to use files and folders is how you prefer to have hundreds of files for the objects, lighting, shaders, colors, layers, etc, of a graphic project, rather than a single PSD file. It is not a matter of agreeing or not. It is a matter of wanting it or not. I explained the idea better in this text: https://forums.tigsource.com/index.php?topic=59097.0
-
Quote:
Matters to me. Folders provide a way to categorize and thus group code that relates to each other while separating it from other code that doesn't.
Currently is that so. But, I think (by practical experience with Stencyl) that if the project is organized inside the editor, that's all that matters for the programmer. In this other paradigm, continue to use files and folders is how you prefer to have hundreds of files for the objects, lighting, shaders, colors, layers, etc, of a graphic project, rather than a single PSD file. It is not a matter of agreeing or not. It is a matter of wanting it or not. I explained the idea better in this text: https://forums.tigsource.com/index.php?topic=59097.0
Gurigraphics wrote:
Currently is that so. But, I think (by practical experience with Stencyl) that if the project is organized inside the editor, that's all that matters for the programmer.
That's not true. What matters also includes things like how you keep your code in source control, how easy it is to code review and so on. If you have one big file then reviewing changes is a lot harder than smaller, isolated files that have a single class (or equivalent) inside them. It's certainly easier to use GIT if you have multiple files, rather than one all-encompassing one.
This space for rent
-
Gurigraphics wrote:
Currently is that so. But, I think (by practical experience with Stencyl) that if the project is organized inside the editor, that's all that matters for the programmer.
That's not true. What matters also includes things like how you keep your code in source control, how easy it is to code review and so on. If you have one big file then reviewing changes is a lot harder than smaller, isolated files that have a single class (or equivalent) inside them. It's certainly easier to use GIT if you have multiple files, rather than one all-encompassing one.
This space for rent
I'm not sure you've read everything I've written about. Because what you say seems so obvious. Imagine GIT inside a Multiplayer-Realtime-Editor, and you have an idea of what I say about external file does not import.
-
I'm not sure you've read everything I've written about. Because what you say seems so obvious. Imagine GIT inside a Multiplayer-Realtime-Editor, and you have an idea of what I say about external file does not import.
"Folders and files" are a convenient "mental model"; you're confusing them with reality. The VS solution explorer is a "virtual file system" (which includes "file access" to: TFS; SVN; Git; NuGet) and which scales a lot better than "one big ball of stuff". It parallels "outlining" as found in Word and Excel; something that "users" are also comfortable and familiar with. I sometimes have flashes of deep insight into some "new" thing; but they go away after the effects wear off.
-
Hello. I'm not sure if this is the appropriate topic, but the insights of this subject are valid. What do you think about an code editor like this: Image 01 Image 02 Image 03 Premise: "typing the same code twice is work for robots. Each time you do that, humanity ceases to evolve - and you mainly". The idea here is to abolish the organization of files and folders. Files e folders, It is like machine language, does not interest to current programmers. The project organization can be done only inside the Code Editor. If the files are all exported within a single folder, or hundreds of folders, or the entire file is a single file, this does not matter to the programmer. After exporting the file, what matters is mainly performance. And the performance can not be compromised by our desorganization, habits and addictions when write code. And to maintain the code, what matters is mainly an organized project and expandable. Then, more useful is to have a "virtualized image" of the file, composed of the modules that make up this file and the entire program. A example in HTML5: Virtualized file inside Code Editor: (index.html) (init) (head) (body) (end) Spaghetti that does not matter: folder/index.html
<!-- Init -->
<!DOCTYPE html>
<html lang="en"><!-- head -->
<head>
<meta charset="utf-8">
<title>title</title>
<link rel="stylesheet" href="style.css">
<script src="script.js"></script>
</head><!-- body -->
<body>
<!-- page content -->
</body><!-- end -->
</html>So you can create a "code block" for index.html, only once. And, if this is already part of the Code Editor library, you just search: index, and drag the block to the project. You do not need of a dumbsense or keyboard shortcuts that you do not remember or even know exist, nor do you need to be consulted documentation at all times to do
Gurigraphics wrote:
What do you think about an code editor like this
Looks good on a C64.
Gurigraphics wrote:
Premise: "typing the same code twice is work for robots. Each time you do that, humanity ceases to evolve - and you mainly".
That's why any good editor provides some kind of macro-functionality*.
Gurigraphics wrote:
The idea here is to abolish the organization of files and folders. Files e folders, It is like machine language, does not interest to current programmers.
You're better of ASKING a programmer what interest them.
Gurigraphics wrote:
You do not need of a dumbsense or keyboard shortcuts that you do not remember or even know exist, nor do you need to be consulted documentation at all times to do simple things.
I don't need those in VS. But for complex tasks, the keyboard shortcuts that I know make me a lot more productive than anyone in notepad.
Gurigraphics wrote:
And the goal is to find a middle ground between written and visual programming.
If you were trying to improve the current state of affairs, I'd be enthousiastic, but you've already picked a solution without checking whether it will fit the problem. Is written information suddenly non-visible information that you feel the need to specify "visual programming" as a separate entity? *) Don't even get me started on Darwin and how you "devolve".
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
"Folders and files" are a convenient "mental model"; you're confusing them with reality. The VS solution explorer is a "virtual file system" (which includes "file access" to: TFS; SVN; Git; NuGet) and which scales a lot better than "one big ball of stuff". It parallels "outlining" as found in Word and Excel; something that "users" are also comfortable and familiar with. I sometimes have flashes of deep insight into some "new" thing; but they go away after the effects wear off.
Making comparisons with VS does not change anything. Whoever prefers this approach simply uses it If this possibility exists. It is not a question of better or worse. It's a matter of wanting. https://forums.tigsource.com/index.php?topic=59097.0
-
Gurigraphics wrote:
What do you think about an code editor like this
Looks good on a C64.
Gurigraphics wrote:
Premise: "typing the same code twice is work for robots. Each time you do that, humanity ceases to evolve - and you mainly".
That's why any good editor provides some kind of macro-functionality*.
Gurigraphics wrote:
The idea here is to abolish the organization of files and folders. Files e folders, It is like machine language, does not interest to current programmers.
You're better of ASKING a programmer what interest them.
Gurigraphics wrote:
You do not need of a dumbsense or keyboard shortcuts that you do not remember or even know exist, nor do you need to be consulted documentation at all times to do simple things.
I don't need those in VS. But for complex tasks, the keyboard shortcuts that I know make me a lot more productive than anyone in notepad.
Gurigraphics wrote:
And the goal is to find a middle ground between written and visual programming.
If you were trying to improve the current state of affairs, I'd be enthousiastic, but you've already picked a solution without checking whether it will fit the problem. Is written information suddenly non-visible information that you feel the need to specify "visual programming" as a separate entity? *) Don't even get me started on Darwin and how you "devolve".
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
Making comparisons with VS does not change anything. Whoever prefers this approach simply uses it If this possibility exists. It is not a question of better or worse. It's a matter of wanting. https://forums.tigsource.com/index.php?topic=59097.0
-
Making comparisons with VS does not change anything. Whoever prefers this approach simply uses it If this possibility exists. It is not a question of better or worse. It's a matter of wanting. https://forums.tigsource.com/index.php?topic=59097.0
-
Truth. For each type of work and need there is a more suitable tool.
-
Truth. For each type of work and need there is a more suitable tool .
-
Truth. For each type of work and need there is a more suitable tool . This forum is bug ¬¬
-
Truth. For each type of work and need there is a more suitable tool . This forum is bug ¬¬
-
Truth. For each type of work and need there is a more suitable tool.
-
Gurigraphics wrote:
This forum is bug
Then report it in the proper place. However, it is more likely that your message got picked up by the Spam filter, and had to be released by someone with the right authority.
Okay. I post in one place and it appears in another. Thanks.
-
Sounds like you are looking for a problem to your solution. Yeah. The same problem solved by Stencyl, Scratch, Google Blockly, Game Maker, Unreal Engine and others visual editors.
-
Me too. That is why I often prefer Sublime than VS.
-
Me too. That is why I often prefer Sublime than VS.