On Tue, Apr 12, 2011 at 11:40 AM, Ian Davis <[email protected]> wrote:
> Code Bubbles has gone nowhere in years now, but I love the workflow and > idea. I think that if we stopped looking at application as a set of files > but rather as sets of functionality, the IDE can create the file grouping > behind the scenes. With ReSharper, I rarely find myself thinking in terms of > files. I bounce between sets of functionality, open them in multiple > windows, and use shortcuts to get the the classes/methods that I need. > > I think that Code Bubbles will never get anywhere, but not because of its > principles. Code Bubbles is an unfunded university project put together in > an ivory tower by college students; how much could any of us do, > realistically, when we were in college? > > As stated earlier, where files come in is when detecting changes. I don't > have any ideas or answers on this for now. > > For an integrated system, I think IntelliJ IDEA is the best model that I > have seen so far. Built as a polyglot system where all languages are plugins > with debugging, testing, editing, refactoring capabilities built in. > > I have not seen anything revolutionary in being able to build the code or > manage configurations. I think as a community we are moving toward language > based build systems: psake, rake, bake, fake which I believe is a great step > forward. I still feel sick every time I see NAnt scripts. I used to love > using FinalBuilder, but the more I use language based build scripts, the > more I think of FinalBuilder as a novelty. I would love to hit a hot key and > have my 'build script group' pop up and let me run through my build. > Abstracting the file system leads to some issues with portability of the > application in trying to target multiple environments. In time, I do see > this changing. > > If you look at Chome OS, the idea of an installed application is dying. > More and more we are moving toward an always-online environment where > everything we do is (forgive me) 'in the cloud' and our current development > systems will probably be relegated to server OS and development > environments. > > Building IDEs is moving into a markup system: Flex, Android, WPF, ASP.NETMVC, > WP7 all use markup for building the UI. I think this will continue > until we are left with a few renderers for our application's UI. > > There are many other issues including, but not limited to > > - How do we combine groups of functionality into a component? > - Source control integration > - Extensibility > - External dependencies (gems, nugets, bundles, assemblies) > > > -- > Ian Davis > http://innovatian.com Fantastic insights, Ian. I've remained quiet to sort of "listen in" on the conversation. I really appreciate Ian's summary. (At least, I think this is a nice summary of where the conversation lies.) I also agree with Mario, in that "I'm not a proponent for moving away from file-based approaches to managing code, building binaries, etc.. I would, however, love to use an editor that is more congruent with the way I work." I think that part of our problem generally trends from certain approaches we follow as "best practices" when they may not be so at all. 1. Every class in a separate file, with related namespaces as folders. Why? Why not a file per namespace/module, with all the related classes, utilities, etc. in one file? F# started off this way, then broke away from it. Python and Ruby generally follow this trend. Why might this be beneficial? Consider an IDE that treats a single underlying file as an environment. You could build up and IDE that sort of pulls up and highlights certain portions of the file, but not as vim or VS do today. Possibly more like Code Bubbles or even a SQL database diagram. When you write back to the environment, the IDE just writes back to that file. You could still share that with VS, vim, etc.; the only current issue would be that you might have more than one class, interface, etc. in the file. I suppose you might consider that 1 file per assembly if you are REALLY intense on factoring cleanly. 2. Build systems MS did one thing right with VS projects: the file is also the build for the project. The downside is that it is in XML. Yes, that's handy for a machine to manipulate. Why not just make the entire thing file based? "using Module1;" finds a sibling or GAC'd file or assembly and adds it to the compilation for that project. As for hooking up additional steps, I don't really know what's best there, though it would seem nice for the project system to provide hooks for additional callbacks. 3. Deployment No idea here, but a solid tool should provide a means for duplicating an environment, ensuring dependencies are available, etc. Ryan -- You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en.
