Quote:Original post by Antheus

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.

Yeah, searching for stuff requires incredible mental tax. Thats why id like tools to make it easier. Im quite unsure how a stack of tabs wider than my screen and an autogenerated index bloated with irrelevant stuff is any help there though.

Java and C# are what they are. Im not talking about redesigning languages.

Code canvas looks pretty cool to me; thanks for the link. Its essentially doing what im talking about indeed, only just for classes, whereas id like to extend that to a much finer-grained level of code structure. I like the visual layout, I think it would work well for me. It is simply making good use of the way your neurons are allocated. We have a large visual/spatial cortex anyway navigating that way can be done in parralel with thinking about your code, instead of making your eyes bleed parsing code to find out where the hell you are.

Quote:Original post by ApochPiQ
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.

Ok, so you already have spent a lot of time and effort developing habits and a toolchain to adress these problems, and as such, the marginal benefit of new tools with large feature overlap is small at best.

I would be inclined to say new programmers would be more drawn to a well implemented version of what im talking about than your way of doing things. But again, I could be wrong.

Quote:Original post by Eelco

Yeah, searching for stuff requires incredible mental tax. Thats why id like tools to make it easier. Im quite unsure how a stack of tabs wider than my screen and an autogenerated index bloated with irrelevant stuff is any help there though.

Searching for things to click on. Navigation of mouse requires conscious coordination between hands and eyes. This may not seem like a big deal, but here is a comparison. Imagine your keys on keyboard would reposition themselves. Each time you had to press a key, it would require looking down, finding the key and moving your finger towards it.

This is why for any serious work, permanently fixed controls are a must. CLI is several orders of magnitude less taxing for some/many tasks. As long as coding involves typing, visual tools will not win out. And if this ever changes, it will not be done using mouse-driven interface since it suffers from same problem - it requires feedback. Keyboard shortcuts do not, there exist keyboards without labels and it's possible to use CLI without a screen.

Quote:We have a large visual/spatial cortex anyway navigating that way can be done in parralel with thinking about your code

Experiments in driving show otherwise. Person that needs to respond to visual input is incapable of doing anything else. There were plenty of tests done regarding traffic safety (not talking Mythbusters here), and even at low speeds, person talking (in person, not on phone) or trying to think about what they say loses almost all perception of surroundings. Only the things that brain has learned to do subconsciously (right foot gas, left foot break, shifting, turn signals) are done in parallel. This is why interfaces that adapt on-the-fly are considerably less practical - they cannot be learned. To take any action, one must coordinate hands and eyes every single time.

Quote:Original post by Antheus

Quote:Original post by Eelco

Yeah, searching for stuff requires incredible mental tax. Thats why id like tools to make it easier. Im quite unsure how a stack of tabs wider than my screen and an autogenerated index bloated with irrelevant stuff is any help there though.

Searching for things to click on. Navigation of mouse requires conscious coordination between hands and eyes. This may not seem like a big deal, but here is a comparison. Imagine your keys on keyboard would reposition themselves. Each time you had to press a key, it would require looking down, finding the key and moving your finger towards it.

This is why for any serious work, permanently fixed controls are a must. CLI is several orders of magnitude less taxing for some/many tasks. As long as coding involves typing, visual tools will not win out. And if this ever changes, it will not be done using mouse-driven interface since it suffers from same problem - it requires feedback. Keyboard shortcuts do not, there exist keyboards without labels and it's possible to use CLI without a screen.

I agree; the vast majority of operations should be possible by keyboard. OTOH, I use my mouse more than my keyboard in MSVS, but maybe thats just my noobness; either way, it beats any barebones texteditor by orders of magnitude, so sacrificing keyboard use isnt a fundamentally bad tradeoff. Besides, navigating a tree structure using keyboard is intuitive, and much faster than doing so in plain text. If I want my cursor at the other end of my screen, I use my mouse currently; in a tree it will usually be only a few keytaps away.

Quote:

Quote:We have a large visual/spatial cortex anyway navigating that way can be done in parralel with thinking about your code

Experiments in driving show otherwise. Person that needs to respond to visual input is incapable of doing anything else. There were plenty of tests done regarding traffic safety (not talking Mythbusters here), and even at low speeds, person talking (in person, not on phone) or trying to think about what they say loses almost all perception of surroundings. Only the things that brain has learned to do subconsciously (right foot gas, left foot break, shifting, turn signals) are done in parallel. This is why interfaces that adapt on-the-fly are considerably less practical - they cannot be learned. To take any action, one must coordinate hands and eyes every single time.

How is coding not 'responding to visual input', either way? I never do anything without the feedback of my eyes on my screen. If you have read about feynmans counting experiments, it would suggest these things can be rather personal.

Just giving all scopes a faint but clear border with a color depending on its type (class, function, loop, whatever) will allow me to triangulate my position in my code with certainty 99% of the time, without ever needing to parse a single character; indeed a function that claims a lot of mental resources.

I have no doubt that languages and IDEs will move in this direction. Even if you are very good at organizing code into files, you're limited by the linear nature of them. Code can be sliced along many independent axes. If I'm working with a geometry library, I might want to see all the functions that take a circle as an argument, or all intersection functions, or all functions that return line segments. It's impossible to structure your files according to all these criteria, but a database can easily support these queries.

And decoupling code storage from concrete syntax opens the door for different views of the code. For example, views of code that use mathematical notations might be more understandable to scientists who aren't programmers (Fortress already supports this). Or maybe this could finally end all the debates on proper indentation style by allowing programmers to view all code in their preferred style (as long as you don't look at code on someone else's monitor).

And imagine all the benefits of having version control built right into the language. Look at Starcraft 2. Blizzard finally added the ability to view old replays that were recorded on a different version of the executable, but they did so by keeping a full copy of every past version of the executable on the user's harddrive, along with supporting DLLs. Not only is this a massive waste of space, but it means that people viewing old replays don't get the benefit of recent bug fixes and improvements to areas that don't affect the game logic, like the UI or renderer. But honestly, it's hard to blame them, given the current state of affairs.

Now imagine that Blizzard was using this language of the future. They could just keep some metadata about what versions of code have been released, match up the replay file version with the corresponding version of the code tree, and invoke that version of the gameplay logic and file parser to process that replay.