View mode: basic / threaded / horizontal-split · Log in · Help
January 17, 2013
Re: Exceptional coding style
> 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
January 17, 2013
Re: Exceptional coding style
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.
January 17, 2013
Re: Exceptional coding style
> 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).
January 17, 2013
Re: Exceptional coding style
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++)
January 17, 2013
Dimensionality of program code (was: Exceptional coding style)
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.
January 17, 2013
Re: Dimensionality of program code (was: Exceptional coding style)
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.
January 17, 2013
Re: Dimensionality of program code (was: Exceptional coding style)
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
January 17, 2013
Re: Dimensionality of program code (was: Exceptional coding style)
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
January 17, 2013
Re: Dimensionality of program code (was: Exceptional coding style)
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...
January 18, 2013
Re: Exceptional coding style
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.
10 11 12 13 14 15 16 17 18
Top | Discussion index | About this forum | D home