Plurality - Modular Code Editor
-
That's the one. It looks like you're both investigating the same space.
This space for rent
Okay. Thank's. ^ ^
-
Quote:
My honest opinion? One of the ugliest UIs I have seen in years;
Yes, honest opinion. hehe This draft even resembles MS-DOS. In game development we call this style: pixel art. But this image is only a drawing PNG. Aesthetics is my last concern. Because it does not help to be beautiful if it's disorganized and does not work. As Steve Jobs said: "Design is how things work". This observation was relevant:
Quote:
The space for the edit windows is far too small
A solution: The "text-box" needs to be expandable and the columns self concealable. Those who have never used Google Blockly maybe not understand the idea. Here there is more information: https://github.com/Gurigraphics/plurality However, this is nothing definitive. And I still do not want to develop a useless prototype.
-
Gurigraphics wrote:
Aesthetics is my last concern.
Then I wonder why you showed those images that do not really mean anything. A more detailed description of what this editor is going to offer may have been a better idea.
Quote:
Then I wonder why you showed those images that do not really mean anything. A more detailed description of what this editor is going to offer may have been a better idea.
Because, fonts, colors, lines, image resolutions are not necessary to understand the idea. But, shapes, structures and positions are required. Because, what the program intends to do, can not be separated from how will do. Since, in the case of an editor, it is precisely the "how" that more interests us. Because, if it is not "practical," it is only "a bad experience" and no matter the outcome. But I understand what you mean. It was better for me to do an article introducing the idea, the problem, and the reason for it all, before showing any image. I did not do this because when is necessary to read too much, the "haters" also complain that this is at "a bad experience".
-
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
-
When one becomes sufficiently adept at the tools that are already available, one transcends any limitations of the IDE and becomes one with the project's mental model. Flow.
Quote:
When one becomes sufficiently adept at the tools that are already available, one transcends any limitations of the IDE and becomes one with the project's mental model. Flow.
Truth. In the world, there are those who accept the things as they are. That prefer to be dragged by a horse cart all life, because they are afraid to get off the ground. Others... "who see things differently. They're not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them. About the only thing you can't do is ignore them. Because they change things".
-
Quote:
When one becomes sufficiently adept at the tools that are already available, one transcends any limitations of the IDE and becomes one with the project's mental model. Flow.
Truth. In the world, there are those who accept the things as they are. That prefer to be dragged by a horse cart all life, because they are afraid to get off the ground. Others... "who see things differently. They're not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them. About the only thing you can't do is ignore them. Because they change things".
-
Quote:
I hardly consider VS as a "horse cart".
Well, at least "heavy" as a "horse cart" he is. :laugh: Anyway, there is nothing perfect for all cases. But, there is always more suitable or appropriate. A simple code, Sublime can be more suitable. For complex debugging, VS can be more appropriate. Better and worse depends on context. And so on.
-
Quote:
I hardly consider VS as a "horse cart".
Well, at least "heavy" as a "horse cart" he is. :laugh: Anyway, there is nothing perfect for all cases. But, there is always more suitable or appropriate. A simple code, Sublime can be more suitable. For complex debugging, VS can be more appropriate. Better and worse depends on context. And so on.
-
Yes; I remember when Visual Studio was "Programmer's Workbench". Don't think I want to go back though.
I do not have, same, so much power for that. I wrote better about the concept here: Plurality - Modular Code Editor[^]
-
I do not have, same, so much power for that. I wrote better about the concept here: 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