On Jan 16, 2011, at 9:30 PM, Michael Haufe (TNO) wrote: > On Jan 16, 7:45 pm, Miller Medeiros <[email protected]> wrote: >> On Jan 16, 2011, at 6:44 PM, Michael Haufe (TNO) wrote: >> >>> On Jan 16, 3:17 pm, Miller Medeiros <[email protected]> wrote: >>>> and if the objects you are using are stored on a different JS file from a >>>> 3rd party library loaded dynamically? >>> Irrelevant, the 3rd party script can be parsed just as well. The only >>> difficulty would be meta-tricks with properties pulled from IO an as >>> they cannot be resolved statically (usually). The examples you've >>> given though don't fall under that category. >> >> I don't agree, first thing is that you don't know when the script will be >> available, were it is coming from and what it does. > > What does that have to do with an IDE? I'd assume you'd have the > source code available in your project if you're building something on > top of it. Every significant JS IDE I've seen includes popular > libraries. > Even if you were developing with partial source, a decent IDE would > flag all the problems if you didn't at least have a stub.
not all the code that you may need to use is from popular libraries and not all code will be static or reside on your own server, some code may be added during execution, some scripts inside your project folder may only be available inside certain pages or after certain moments, etc. On static/compiled languages you know what can be accessed from that scope because you "usually" don't include random things during execution... adding some sort of metadata may help (like comments at the begin of the file), but by the language itself and the way it is used, it is hard to infer this kind of stuff. > >> It's like when you use Google Closure Compiler with "advanced mode" and you >> have to add "externs"... in many cases it can be an exhausting and boring >> process.. and some times not that helpful for error checking since nothing >> guarantees that the externs will really be available and have the provided >> API. > > You use Google Closure for debugging? Either way, once again a decent > IDE would flag this. If you use "advanced compilation" on closure compiler it does type checking depending on how you annotate your code and some other stuff, it doesn't replace JSLint though: http://code.google.com/closure/compiler/docs/api-tutorial3.html - I've tried it for a couple projects but now I stopped since it wasn't solving that many problems and the amount of work required was way bigger than the advantages (on my specific case), but I'm sure on other scenarios it may make total sense. > >> watch this quick video about one of the many features of FDT: >> http://www.vimeo.com/16225086 - note that you basically don't have to type >> that much and the autocomplete is smart enough to do most of the heavy >> lifting for you and fix most errors automatically... now imagine doing all >> this using a text editor.. no way that using a static language would be >> better than a dynamic language, the extra amount of work simply doesn't >> payoff. >> >> I can write AS3 code using FDT for a full day without ever compiling and >> there is a big chance that it will actually work as expected.. while in JS >> if I code for more than 1-2 hours there is a big chance that I have some >> stupid typo error or some variable/method name that I renamed and forgot to >> change somewhere, specially when the code is split between multiple files. > > Similar things could be done with an IDE for JS. but you should take > into consideration the fact that many of these features are irrelevant > to JS. > I know that. I'm just saying that most of the features are way easier to implement on static languages since you have less freedom to do things on a different way and you have way more metadata to help. I also wanted to show how helpful those things are, since you stop loosing time with dumb problems and spot/fix them right away. My intention with the previous replies wasn't to nitpick or to say that the dynamic approach is wrong - if I didn't liked dynamic languages I wouldn't be focusing on JS since the past couple years - but to try to explain my point-of-view since I really miss some of those features and that I really think that no one done it yet since it would require an insane amount of work and it seems way harder to do. Maybe the amount of work required is way bigger than the amount of people that would actually benefit/want/pay for those features, since most JS developers are probably working on projects that has less than 10.000 lines of JS... - but again, that's just an assumption. Maybe the editors doesn't even need to be that smart, maybe it is just me that want this kind of stuff. Best regards. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
