> Maybe I should invent a programming language in which color has semantic
> value. And fonts. :-P

Why stop here? Go paint your programs in Piet. ;)


> Fixing const issues in Phobos would be as simple as
> selecting the entire source code and changing the font to italics. :-P

I suggest a special font designed just for D. ;)
Bold for const, Black for immutable, UltraLight for volatile, keywords written in Small Caps, comments in Script (must look handwritten)...

Colours, as you mention would replace safe, pure, nothrow.
Of course a special obligatory colour palette will be created.

And as we're at it, it's time to go one step further in creating code friendlier to read, and get those APL keyboards back from the attic, so they can be useful once again. :D

On Thu, Jan 17, 2013 at 08:26:16AM +0100, Era Scarecrow wrote:
> On Thursday, 17 January 2013 at 06:52:39 UTC, H. S. Teoh wrote:
> >On Thu, Jan 17, 2013 at 06:28:30AM +0100, deadalnix wrote:
> >>We are using writing to communicate between people for thousands of year now. This is clearly the most efficient way to express idea, including to a computer.
> >
> >Not to mention, linear writing developed *from* 2D drawings.
> 
>  Somehow what seems like would work good is a card-file system.
> Assuming the order of functions/declarations don't matter and you
> let the editor deal with where it places things (say, alphabetically
> or by attributes like private, pure, etc), then having a partial 3d
> view where you can flip through various function definitions &
> header documentation, then open only the function(s) of interest in
> question, hiding anything unrelated. If there's anything global or
> variables it accesses those could be listed too along with their
> type, and perhaps where the type's definition comes from for
> reference; and any functions it calls along with others with the
> same overloading name.
[...]

That sounds like a very good idea. In fact, Vim has a feature called folding, where parts of the file are folded into a single line, to be expanded/collapsed at will. Properly configured, this can be made to auto-collapse all functions, nested blocks, etc., to be expanded at will. This makes long source code much more navigable (though it doesn't change sorting order -- I can see where that may be useful).


T

-- 
In theory, software is implemented according to the design that has been carefully worked out beforehand. In practice, design documents are written after the fact to describe the sorry mess that has gone on before.

> On Thu, Jan 17, 2013 at 08:26:16AM +0100, Era Scarecrow wrote:
>> Somehow what seems like would work good is a card-file system. Assuming the order of functions/declarations don't matter and you let the editor deal with where it places things (say, alphabetically or by attributes like private, pure, etc), then having a partial 3d view where you can flip through various function definitions & header documentation, then open only the function(s) of interest in question, hiding anything unrelated. If there's anything global or variables it accesses those could be listed too along with their type, and perhaps where the type's definition comes from for reference; and any functions it calls along with others with the same overloading name.
> [...]
>
> That sounds like a very good idea. In fact, Vim has a feature called folding, where parts of the file are folded into a single line, to be expanded/collapsed at will. Properly configured, this can be made to auto-collapse all functions, nested blocks, etc., to be expanded at will. This makes long source code much more navigable (though it doesn't change sorting order -- I can see where that may be useful).

 NotePad++ does this too. However you are still managing the order of the functions, obviously in structs the order of variables matter (but not anywhere else), so if the editor handled where it was placed you'd always have a consistant layout. This likely would help quite a bit with managing source code.

 Course alphabetical could be a default after any other specialized functions are done. Examples are I'd want front/popFront next to eachother in the list, back/popBack, length, opIndex, opIndexAssign, all the slices together along with opDollar. Etc. Probably also have them in in multiple fold-outs where it's sorted by some criteria (unittests, public API, templates, pure/@safe).

 Could also have different operators and function predefined (but in grey for example), then enabling it gives you a default basic skeleton in which to add your operator specific code.

 All of this is what you could do without actually needing the compiler (but probably needs proper syntax checking).

On Thursday, 17 January 2013 at 16:25:11 UTC, Era Scarecrow wrote:
>> On Thu, Jan 17, 2013 at 08:26:16AM +0100, Era Scarecrow wrote:
>>> Somehow what seems like would work good is a card-file system. Assuming the order of functions/declarations don't matter and you let the editor deal with where it places things (say, alphabetically or by attributes like private, pure, etc), then having a partial 3d view where you can flip through various function definitions & header documentation, then open only the function(s) of interest in question, hiding anything unrelated. If there's anything global or variables it accesses those could be listed too along with their type, and perhaps where the type's definition comes from for reference; and any functions it calls along with others with the same overloading name.
>> [...]
>>
>> That sounds like a very good idea. In fact, Vim has a feature called folding, where parts of the file are folded into a single line, to be expanded/collapsed at will. Properly configured, this can be made to auto-collapse all functions, nested blocks, etc., to be expanded at will. This makes long source code much more navigable (though it doesn't change sorting order -- I can see where that may be useful).
>
>  NotePad++ does this too. However you are still managing the order of the functions, obviously in structs the order of variables matter (but not anywhere else), so if the editor handled where it was placed you'd always have a consistant layout. This likely would help quite a bit with managing source code.
>
>  Course alphabetical could be a default after any other specialized functions are done. Examples are I'd want front/popFront next to eachother in the list, back/popBack, length, opIndex, opIndexAssign, all the slices together along with opDollar. Etc. Probably also have them in in multiple fold-outs where it's sorted by some criteria (unittests, public API, templates, pure/@safe).
>
>  Could also have different operators and function predefined (but in grey for example), then enabling it gives you a default basic skeleton in which to add your operator specific code.
>
>  All of this is what you could do without actually needing the compiler (but probably needs proper syntax checking).


Ditto with SciTE (which uses the same editing component, Scintilla, as Notepad++)

On 17/01/2013 12:30, Jeff Nowakowski wrote:
> On 01/15/2013 08:29 PM, H. S. Teoh wrote:
>>
>> It's paradoxical that a 1D (i.e. linear) representation is more useful
>> for capturing the complexity of programming as opposed to, say, a 2D
>> graphical representation
>
> Typical code is 2d because of line-oriented statements and indented
> block structure. Reading a truly linear file of code in 1d would be
> quite a nightmare.

It depends on how you look at it.

Mathematically, a curve is considered a one-dimensional object, regardless of whether the space in which it is embedded has two, three or more dimensions.  (I'm ignoring fractals here for simplicity.)  If you consider the shape of the indented block structure to be a curve, then it's still one-dimensional in this respect.

And in most languages, a program/module is essentially just a sequence of tokens, and as such is one-dimensional.  We might look at it in a two-dimensional form, but this two-dimensional layout means nothing as far as the program structure and semantics are concerned.  And again, you could think of it as a curve, passing from the beginning of each line to the end and then to the beginning of the next line.

OTOH, because we tend to view code in a two-dimensional form, and even rely on line breaks and block indentation to make code readable, I can understand people thinking of code as 2D.

And there are languages in which the code structure is inherently two-dimensional, e.g. Befunge.

Stewart.

On Thursday, 17 January 2013 at 20:17:06 UTC, Stewart Gordon wrote:
> And in most languages, a program/module is essentially just a sequence of tokens, and as such is one-dimensional.  We might look at it in a two-dimensional form, but this two-dimensional layout means nothing as far as the program structure and semantics are concerned.  And again, you could think of it as a curve, passing from the beginning of each line to the end and then to the beginning of the next line.

 As I recall for the compilers very early on, all comments and unneeded whitespace were simply removed before compiling, leaving you with one very long command string. The /**/ comment syntax makes perfect sense in this case; Later tools more memory and hardware power make it more manageable; but // requires 2d code to properly compile until the comments are stripped.

// c example, originally isprime and main don't have
// return types, defaulting to int instead.
int isprime(int n){int cnt=2;if(n<2)return 0;for(;cnt<n;cnt++)if((n%cnt)==0)return 0;return 1;}int main(){int cnt=2;for(;cnt<1000000;cnt++)if (isprime(cnt))printf("%d \n", cnt);}

 It's one of the reasons the syntax requires a semicolon after each statement so it can tell obviously where something ends.

On Thursday, 17 January 2013 at 20:17:06 UTC, Stewart Gordon wrote:
> OTOH, because we tend to view code in a two-dimensional form, and even rely on line breaks and block indentation to make code readable, I can understand people thinking of code as 2D.
>
> And there are languages in which the code structure is inherently two-dimensional, e.g. Befunge.
>
> Stewart.

So far we have not considered what happens when we get into parallel programming. It seems that the old ways of viewing code breaks down. We have to represent in text form not just one thing happening at one time, but many things happening at the same time, so the dimensions increase and the interactions between simultaneous cooperating components often becomes unpredictable in ways that cannot be represented very well in text form. You can still represent the code in text form, but I wonder how effective that is compared with a graphical approach to the problem, i.e., simulating the programming model graphically in 2 or 3D space.

--rt

On Thu, Jan 17, 2013 at 11:43:33PM +0100, Rob T wrote:
> On Thursday, 17 January 2013 at 20:17:06 UTC, Stewart Gordon wrote:
> >OTOH, because we tend to view code in a two-dimensional form, and even rely on line breaks and block indentation to make code readable, I can understand people thinking of code as 2D.
> >
> >And there are languages in which the code structure is inherently two-dimensional, e.g. Befunge.
> >
> >Stewart.
> 
> So far we have not considered what happens when we get into parallel programming. It seems that the old ways of viewing code breaks down. We have to represent in text form not just one thing happening at one time, but many things happening at the same time, so the dimensions increase and the interactions between simultaneous cooperating components often becomes unpredictable in ways that cannot be represented very well in text form. You can still represent the code in text form, but I wonder how effective that is compared with a graphical approach to the problem, i.e., simulating the programming model graphically in 2 or 3D space.
[...]

It's easy to represent in 2D or 3D a *simulation* of program execution (i.e., a particular instance of execution), but how do you represent concurrent program *logic*?

For example, consider this: you have a program in which up to 5 threads may be running at the same time, and they access a number of shared variables.  In order to fully capture the semantics of the program (w.r.t. to concurrency), you'd have to somehow depict *all possible interleavings* of the 5 threads, including parallel executions. How would such a thing be depicted in 2D or 3D?

Furthermore, if you're going to be mapping degrees of freedom in state space (which is essentially what you're doing if you want to capture the interactions between simultaneous cooperating components) into Euclidean space, then 3D is, in general, going to be far too few dimensions to fully represent the program. Non-trivial concurrent programs have far too many degrees of freedom to capture in a mere handful of dimensions. You'll need to be able to display (*and* visualize) spaces of arbitrary dimensionality (anywhere from 4D to, say, 237D, or 10423D for large projects) to be able to work with such a programming model.


T

-- 
"A man's wife has more power over him than the state has." -- Ralph Emerson

On Thursday, 17 January 2013 at 23:35:37 UTC, H. S. Teoh wrote:

> It's easy to represent in 2D or 3D a *simulation* of program execution (I.e., a particular instance of execution), but how do you represent concurrent program *logic*?
>
> For example, consider this: you have a program in which up to 5 threads may be running at the same time, and they access a number of shared variables.  In order to fully capture the semantics of the program (w.r.t. to concurrency), you'd have to somehow depict *all possible interleavings* of the 5 threads, including parallel executions. How would such a thing be depicted in 2D or 3D?
>
> Furthermore, if you're going to be mapping degrees of freedom in state space (which is essentially what you're doing if you want to capture the interactions between simultaneous cooperating components) into Euclidean space, then 3D is, in general, going to be far too few dimensions to fully represent the program. Non-trivial concurrent programs have far too many degrees of freedom to capture in a mere handful of dimensions. You'll need to be able to display (*and* visualize) spaces of arbitrary dimensionality (anywhere from 4D to, say, 237D, or 10423D for large projects) to be able to work with such a programming model.

 I can only think that each thread would be a window (or 3d box), and have no immediate connections. Then you enable specific references of what you're interested in (sorta like the sorting vs container model where they are separated, make x sorters + y containers, not x*y combinations).

 If they get re-ordered based on what's selected/available then it would have to find the best fit to represent the connections between data, depending on how many blocks there are (VS table layout? Or similar to circuit boards) which then gives you a semi 2d/3d view.

 If instead it say connects using wires showing certain connectivity (with id tags or something) then you just specify what variables, structures, or specific threads that are directly related (use one as a parent which then spreads out) and it hides the unneeded information until requested.

 But that's just how I see it with a debugger. Although I can dream it, I don't know if I could write it. Might get some game programmers to make the GUI interface.

 Hmmm programming and using a controller to navigate the views from the compiler/debugger...

On 1/14/2013 3:19 PM, Timon Gehr wrote:
> It is funny how statements about beauty of code tend to overemphasize the
> importance of trivial formatting rules. This is completely irrational.
> Formatting is a part of the process that could be trivially automated. It is not
> what the substance is.

Pedantically, you are correct.

But in practice, I find over and over again that carefully formatted code tends to go hand in hand with well designed code.

It's like internet postings. If you see a posting in ALL CAPS, or all lower case, or sloppy grammar/spelling, or long runon sentences, or no paragraph breaks, etc., it's almost certainly devoid of interesting content. If you see an electronics board with a rat's nest of wires and sloppy construction, odds are high it won't work. If you see a neatly laid out board, odds are it works.

And so on for just about every engineering/construction work.