On Mon, 2 Apr 2012 19:57:20 +0000 Thibault Raffaillac <t...@kth.se> wrote:
> Bump! > > Let me renew my interest in contributing through GSoC with post-compilation > feedback (This was not an early april joke). Do you think it could lead to an > acceptable GSoC proposal? (mentor interested?) Feedback can be scarce, but don't let that stop you from submitting a proposal. Either way, can you keep me informed about any progress? I might wish to help though that would probably be later in the cycle (got a lot queued up for the comming months). > @Tomasz: > On the interaction side I totally agree that communication between compiler > and > programmer is scarce (and there is room for improvement). Focusing too soon on > the editor would overlook the vast users needs though, as: > _ some users do not use an IDE (and will kindly refuse); > _ some users do not need more communication, as they already know what GCC can > and cannot do; > _ some users do not want more communication, as they have other business to > focus on; Sure, I'm one of the people who don't use an IDE as it causes more issues than it solves for me. This isn't meant for everyone the same way anything else isn't, it just can't;p Still looking at it, other languages, different IDEs, I'd say my way of tackling the issues is more usable and useful than most other, and could easily see wider adoption. Btw my experience is mostly in low-level kernel/driver programming, 2/3d graphics, games. > I think the editor being split from the compiler is good thing. There still > exist tools to expose static analysis data from the compiler (and choose the > editor to visualize it with), but fundamentally they are assisting him/her > rather than helping him/her improve. Instead of gathering loads of data on the > optimizations/analysis performed, and filtering it for visualization by the > user, we could relate the optimization technique used so that the user truly > knows what GCC is capable of (instead of guessing by observation). Great that's exactly what I'm aiming at:) It's not just presenting the results of static analysis in real-time, as I actually dislike most kinds of it like finding memory leaks, to me that seems like an attempt to make the computer do what it's really bad at (understanding the code). I just want to give the programmer the fullest picture of the situation but at the same time make it so it doesn't become noise that interferes. More or less you can say the goal is "To provide feedback that allows the user to extend his understanding of the program". That mostly means giving access to all the information that can be unambiguously concluded from the code by the computer. To what degree we carry it and how much the compiler is involved is only a question of practicality and performance. > My proposal is thus not to be confused with a static analysis visualization: > the programmer learns what techniques are implemented in GCC (or in compilers > in general), how to write code that is more easily compiled, and can further > browse the Intwawaernet for detailed theory on the techniques involved. Perfect! However, how to do that so that it actually works seems a bit complex. The first (practically unsolvable) issue is what actually constitutes better code, as given two pieces one may be faster in some cirtumstances while the other in different. But as I understand that's not really what we're trying to tell the user, rather we want him to explore for himself what's possible and what are the results and why they are the way they are? I'm guessing this will unfortunately (or fortunately) require him to actually see and undestand the intermediate code, see how it changes after different optimizations, and see the output assembly. Personally I really need/want that;) Though my end target is a bit more to "broaden" the abstraction when programming (both up and down), so not to just show what's happening with the code but also allow the programmer to interact with it on that lower level. LLVM seems like the perfect fit for that but I've got some gripes with it, and that is still far away in the future. > The point on the possible-optimizations-which-could-be-enabled-if-specific- > -constraint-is-lifted is particularly interesting, but is also extremely risky > if the compiler makes a stupid remark on a constraint which can "obviously" > (for the programmer) not be lifted. If ever, I would introduce it with a LOT > of > care. Yes and no. First of all I don't necessarily mean for the compiler/editor to suggest anything to the programmer, rather if the programmer asks just say what's physically possible, and not what's right, since if the compiler could do that it would just perform the optimization. Furthermore the situation with my source code is that I can probably make all this in such a form that it is actually usable and useful which seems to me close to impossible with normal languages. I can also with almost no effort store within the source code the "dialogue" between the programmer and compiler, whether he analyzed something allow him to make a quick "don't report this ever again" note with a reason for other developers. Also I personally think that if a programmer wants to shoot himself in the foot he should be allowed to do that as soon/fast as possible as that is the most important learning tool, though warnings are obviously still very much welcome. > Thibault > ps: As for an editor with real-time feedback on static analysis and more, I am > 100% with you :) (and there are some promising prototypes, like in this talk: > http://vimeo.com/36579366) > Unfortunately I only saw 36m of it as it broke and seeking doesn't work on vimeo for me, so I'll watch the rest later. To me it touches on some of the right issues/concepts but in slightly the wrong way, and it completely ignores some issues. First of all the exact things he's showing are extremely limited in their applicability. The graphical and circuit stuff is very domain specific and mostly already done, the issue with them usually boils down to performance and it's the same issue we hit with giant IDEs. That's also an issue I'm adressing with my language and the prognosis for the future looks very promising as it does often more than xcode/eclipse and can be faster than simple text editors like geany/kate. Also the kind of instant he's showing (the video might be partly to blame) is a bit far from my definition of instant, I've used xcode and it isn't instant even in the most basic operations like switching between files. The example with the animation of the leaf, highlights an important issue that very often you know exactly what you want/need but don't know how to get it. With programming I very often hit a situation where I know what the assembly could look like, but have no idea how to make gcc output it like that or even whether it is like that since checking would take too long. The more immediate problem to me is of scale, as no one has a problem with those kinds of code or circuits or whatever. The question is how do you improve your performance and quality of output when you're dealing with between 50k and 10m lines of code. And to me that is for the most part by givin the programmer exactly the information he is looking for immediately when he needs it, without slowing down the basic tasks or interrupting the workflow. The main difference with his demos or other IDEs and what I'm doing is that it's still just a layer above the source code, just a feature added ad-hoc after designing the language. What I'm doing is actually part of the language, in my solution the information stored as the source code can itself be presented as text, graphs, trees, tables or whatever happens to be most efficient for the task at hand. To give the most basic (to the point of primitiveness) example when you're working with an application that has let's say 50 different kinds of objects it displays on the screen and those are arranged in a certain hierarchy of classes, you'll usually organize the code to match that hierarchy (meaning just bundle the methods and types together). But at the same time all of them have stuff cross-cutting between them like the mechanism for printing them on screen, or handling mouse/keyboard input. So depending whether you are changing/adding a new object or a mechanism for working on/between them, you'll want to organize the source code differently, and that's trivially simple with my solution as you can have as many perspectives as you wish, either manual or automatic like call-graphs. Keep in mind that's just one very tiny part of the whole, meaning I'm not saying that solves all the issues in the world;p -- Tomasz Borowik
