|
Hello,
there is the saying "one picture describes more than thousand words".
I also find myself in a situation, where an image inside the source code would describe the situation so much faster and easier, than text. Especially for non-technical domain code.
Therefore, I think enabling images inside source code would be a really awesome, helpfull extension. But as a matter of fact, this feature does not exitst. Am I maybe missing something here? What's your opinion on that topic?
regards
|
|
|
|
|
My opinion? It's stupid.
What would this picture describe in the code? Absolutely nothing.
Not to mention how you could be possible even "type" that code nor how it would even be saved.
The closest you can get to any kind of usable concept that resembles something like this would be an image in the project resources.
|
|
|
|
|
D4rkTrick wrote: What's your opinion on that topic?
There should not be any pictures, animated gifs, advertising-banners or flash in the source-code. It is plain text, editable in any text-editor.
I agree that a picture may explain a lot more and better, but source-code is not the documentation. See this[^] thread.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
I think, New Year party left you in a hangover or something like that. But, a programmer leaves billions of errors in just a few hundred lines of codes. What do you expect him to do in thousand words, moreover in the form of image.
Of course, there are some source codes where you can embed images, they are called HTML codes.
<p>
<img src="~/images/market-chart.png" alt="Description" />
</p>
You get to display a chart instead of a tabular or textual description. However, if you meant to create an image and have objects such as <p>, <img> etc in there. I won't necessarily support it.
Sorry.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
|
Instead of writing to every single person, I get the idea of a general opinion regarding that.
Therefore I might not put too much more effort in that project.
@Gerry
That was unexpected...and I was kind of laughing hard ... I'm probably easy minded 
Regards
Darktrick
|
|
|
|
|
You can still provide this sort of detail, though, by providing good technical documentation and referring to it in code comments. This example uses an HTML documentation so that you can couple the image with some textual context:
namespace MyNamespace {
public class MyClass {...}
}
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
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
<!--
<!DOCTYPE html>
<html lang="en">
<!--
<head>
<meta charset="utf-8">
<title>title</title>
<link rel="stylesheet" href="style.css">
<script src="script.js"></script>
</head>
<!--
<body>
<!--
</body>
<!--
</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 simple things. You do not even have to overload your memory with unnecessary information.
And the blocks can be organized into categories:
- Search word (index) in the category (canvas)
- Search word (index) in the category (web page)
- Search word (index) in the category (My project XYZ that I made for company XYZ)
- Search word (controls) in the category (My game XYZ)
"This is code reuse truly intelligent".
And all these blocks can be made up of blocks within blocks, like an array or complex module.
Another example:
You have changed the website address of your company. And you need to edit the comments for each code page in 50 projects. Total 500 files.
If your projects have the "block" (header-comments) on all pages, when you change the content of (header-comments), this will change in all projects.
You only open the projects: update, export and you're done.
And the same to correct errors, improve something, make implementations, include new modules, etc.
Some advantages:
Modular programming: a new conception of programming organization: using arrays and modules rather than separate folders and files. Files are generated only at the end.
Lightning maintenance: When correcting a error, or improve a snippet of code, all blocks of the program can be changed simultaneously.
Matrix Blocks: allows you to store 1,000 items in little space. And Matrix Blocks inside Matrix Blocks can store infinite information.
End of spaghetti code: The modules and blocks to organization is more intuitive.
Reuse and share code: Code blocks allows full reuse of code. And you can also share your blocks.
Code lib: The editor becomes a code library. You do not need to be always consulting the documentation and external files. Your notes and code samples are saved in blocks in the editor itself. This is also better than Intellisense and keyboard shortcuts.
Others:
The name Plurality is because the idea is to use the same logic of arrays and blocks to also write music (like music trackers) and texts (like script editors). (Also because I'm an Indie Game Developer)
This idea is inspired by Scratch - MIT Media Lab's, Google Blockly, Stencyl and other similar programs.
And the goal is to find a middle ground between written and visual programming.
P.s: These images are just to demonstrate the concept without having to write too much.
modified 20-Dec-16 22:12pm.
|
|
|
|
|
My honest opinion? One of the ugliest UIs I have seen in years; it looks like something out of MS-DOS 3. The space for the edit windows is far too small, and the rest of the boxes are just clutter. Unfortunately the rest of your "advantages" do not mean anything without further detail, as the images give no clue as to how they are implemented.
|
|
|
|
|
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".
|
|
|
|
|
You might want to look at the work @marc-clifton[^] is doing in this space. Check out his latest articles.
This space for rent
modified 20-Dec-16 6:21am.
|
|
|
|
|
About The Clifton Method?
I'll read it. Thanks
|
|
|
|
|
That's the one. It looks like you're both investigating the same space.
This space for rent
|
|
|
|
|
Okay. Thank's. ^ ^
modified 31-Dec-16 12:52pm.
|
|
|
|
|
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".
|
|
|
|
|
I hardly consider VS as a "horse cart".
|
|
|
|
|
Quote: I hardly consider VS as a "horse cart".
Well, at least "heavy" as a "horse cart" he is. 
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.
modified 21-Dec-16 19:37pm.
|
|
|
|
|
Yes; I remember when Visual Studio was "Programmer's Workbench".
Don't think I want to go back though.
|
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
