Quote:

Original post by Antheus And those are just the most trivial examples. Sadly, parsing language to degree of ubiquitous storage is prohibitively expensive and complex. And in many cases simply cannot be done. The complication here comes from the parser being 99.9999% correct and 100% correct. Would you use a disk which on each write has 0.0001% chance of corrupting a file?

You are missing the point. I am not interested in parsing existing codebases and their myrad of idocracies, although having reasonable transition tools would be nice, of course.

I want to write my code while its tree structure is rigidly enforced, thats all. Of course I can save that, and of couse it is trivial to de-parse this into a plain old textfile, or even better, write a compiler which reads it directly. I dont want to edit plaintext, simply because its a limited and suboptimal way of displaying information. I want to hide tags of secondary importance behind context sensitive menus, be able to collapse branches of code (most IDEs attempt a limited version of this already), and not be able to misplace my closing brackets.

Another neat possible piece of (language independent) functionality that just occured to me:

You could create 'linked' snippets of code within the same document. Often you need to repeat a small piece of code twice, and it doesnt pay to create a complicated construct to enable code-reuse, but it is absolutely critical that they are identical. It would essentially be like a preprocessor/macro, pasting the same code in different places, except that your editor expands the macro already, so there is no ambiguity as to what it expands to, and you can edit it 'in place' instead of looking up the macro definition; there isnt any such thing in fact, just two references to the same branch in your program tree.

I can think of a lot of uses for that. Again, something you cannot do with plaintext.

(it probably should only be allowed within the same scope; doing so across scope boundaries would not make much sense and be poor programming practice imo, and it would be hard to explicitly visualize the link, which is quite important too)

If this still feels too macro-y for you: a more restricted but similar thing would be expansion of mixins. Instead of seeing 'mixin Foo<Bar>', you could opt to see what it evaluates to instead.

Quote:

Original post by Eelco I want to write my code while its tree structure is rigidly enforced, thats all.

Bad idea. One of the things I remember from my programming language theory class is that there have been experiments with source code editors that rigidly enforce the structure of a program, and those experiments all failed because of horrible usability problems. Programmers just don't think that way.

Unfortunately I don't have a link handy to any of that research as that class was a long time ago. Still, if you are hell-bent on trying something like that anyway, maybe you can try to find that research and see if they made some mistake. Learn from history and all that.

Personally, I find it much more plausible that enforcing the structure really is just a bad idea. When you reorganize the structure of code you really want as much freedom as you can get, which includes transitioning through illegal states.

Quote:

Original post by Prefect Quote: Original post by Eelco I want to write my code while its tree structure is rigidly enforced, thats all. Bad idea. One of the things I remember from my programming language theory class is that there have been experiments with source code editors that rigidly enforce the structure of a program, and those experiments all failed because of horrible usability problems. Programmers just don't think that way. Unfortunately I don't have a link handy to any of that research as that class was a long time ago. Still, if you are hell-bent on trying something like that anyway, maybe you can try to find that research and see if they made some mistake. Learn from history and all that. Personally, I find it much more plausible that enforcing the structure really is just a bad idea. When you reorganize the structure of code you really want as much freedom as you can get, which includes transitioning through illegal states.

Maybe you are right; I realize it would take a lot of getting used to. But I cannot think of any fundamentally compelling reason to recycle the closing bracket of a for loop I want to delete as the closing bracket of the function I was writing, even though thats what I might end up doing when allowed to.

As for simple expressions of the form x+y<(z+2)/3, they should definitely be freeform-typable; doing all that in an expression-tree editor would be madness; I have my equation-editing skillpoints maxed out, and its still a pain in the ass. Although being able to right-click such an expression and edit it in an expression-tree editor can be useful in some situations where you dont want to make your eyes bleed making sure all brackets are placed correctly.

But the coarse structure of your code; the class definitions, function definitions, loops, scopes; I really cant think of any good reason to have complete freedom there. Dont you hate it when you forgot one closing bracket somewhere; and thats all your compiler is able to tell you, usually indirectly by means of some end-of-file error?

I prefer C-style scope delimiting over BASIC because I hate writing more characters than necessary. On the other hand, I also hate ten consequtive closing brackets; 'Next i' may be a lot more typing, but what if that comes for free, with the identifier automatically updated, after merely typing 'for i', with the option to add break-conditions at the top AND bottom of your loop body, and the increment action at a default i++, in a logical place (besides your loop body), and being editable into a multiline statement? And who knows what other optional features hidden behind a mouseclick that will not tarnish the clarity of a simple loop but do increase my expressiveness?

Id say that improves both the clarity of my code AND my productivity. But I realize I might be wrong about the latter. Do you have any keywords to look up the research you mentioned?

Quote:

Original post by Eelco Id say that improves both the clarity of my code AND my productivity. But I realize I might be wrong about the latter. Do you have any keywords to look up the research you mentioned?

Unfortunately no, as I said the class was a long time ago.

It might also be that they required formulas to be written out consistently, it's something to check. I guess language design also plays a role. For example, it's pretty hard to get inconsistent scoping in Python ;) (except for forgetting a pass keyword somewhere).

Quote:

Original post by Prefect Quote: Original post by Eelco Id say that improves both the clarity of my code AND my productivity. But I realize I might be wrong about the latter. Do you have any keywords to look up the research you mentioned? Unfortunately no, as I said the class was a long time ago. It might also be that they required formulas to be written out consistently, it's something to check. I guess language design also plays a role. For example, it's pretty hard to get inconsistent scoping in Python ;) (except for forgetting a pass keyword somewhere).

Sure, python is more likely to compile when you fucked something up; but im pretty sure I dont consider that a good thing.

Are syntax errors a big concern? I don't typically have a problem with them. Mine is corner cases on logic. I'm finding functional languages to be the most productive for me for that reason.

Quote:

Original post by capn_midnight Are syntax errors a big concern? I don't typically have a problem with them. Mine is corner cases on logic. I'm finding functional languages to be the most productive for me for that reason.

They arnt the biggest problem. Although for some boilerplateish code, getting all the tabs, spaces, breaklines and braces in the right place IS the majority of effort to me. In general, having identation and other whitespace conventions as editor settings is just way more friggin elegant than having about half of all the characters in your textfile dedicated to some redundant hardly-mutable dance to achieve the same end.

What slows me down the most is getting lost in my own code as it expands. Hence, making better use of the available space and capabilities of your monitor, and showing more of what is relevant and less of what isnt, is a big deal to me. Merely a more clear highlighting of the coarse structure of my code would help a lot to me for my code to feel more like a recognizable pattern than a mess of characters, although doing so in a pure text editor isnt entirely impossible (though guaranteed to be cluncky and suboptimal).

What about smooth zooming, allowing you to see the big-picture structure and zooming in on relevant subsections as desired?

In working on a little demo (hacking WPF treeview templates to do the heavy lifting for me) because I seem to have a problem conveying my enthusiasm in plaintext (pun intended). Dont hold your breath though, I probably wont have time to get it anywhere near a usable state :).

I for one don't really see the need to get "big picture" views of my code. Ever.

If I have a function longer than one screen, I feel vaguely ill; generally I'll have factored it up into smaller functions long before it gets to that point. I can count on the fingers of one hand the number of places I've personally written code that needs to span more than one or two screens in the past, oh, five years or so. Usually when it happens it's a product of laziness, and it rarely lasts very long.

I don't deal with boilerplate code or comments, either; I use Visual Studio's snippet system for boilerplates on code, and a custom plugin to handle neat comment formatting. I don't worry about code structure because it's rare for me to test code more than two or three levels deep, and again, that's generally within one screen so it's easy to manage mentally.

I spend a small amount of effort keeping functions organized into related modules, even if that means a class is implemented across multiple files. I also divide things up into sections by functionality so I can easily know where I'm at in the code just by looking at the current function I'm in. With a tiny bit of discipline and a minuscule amount of up-front effort, I virtually never get "lost" in my code.

Combined with Visual Assist X and its auto-formatting features, I pretty much never worry about code formatting, layout, or visual structure anymore.


I guess my point is that the need for these kinds of tools is highly subjective. I would speculate that better programmers know their tools well enough (and, more importantly, extend their tools enough) that they don't see the need for this kind of thing, either... but that's getting into highly subjective territory and I certainly don't want to insinuate that wanting nicer editing facilities makes you a bad programmer [wink] But the bottom line for me is that it just isn't an issue in practical day-to-day work.

Quote:

Original post by Eelco What about smooth zooming, allowing you to see the big-picture structure and zooming in on relevant subsections as desired?

">Code canvas,

">Code Bubbles, and similar. A definitive crowd pleaser as a demo, but of next to no use in real world.

Anything that requires searching for stuff takes incredible mental tax. This is why so many hard-core developers swear by vi or emacs.

And sadly, both of the above tools are solving the wrong problem. Java and C# are both prone to absurd bloat of source code, resulting in millions of lines of code which could have been written considerably more succinctly.