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: > > >> The same way that is way easier to create a XML parser than an HTML parser. > > > No, this analogy does not fit XML/HTML are not programming languages. > > Plus the rules for parsing HTML are well defined and don 't need a run- > > time check. > > I still believe that this analogy fits well.. XML is stricter than HTML and > have simpler rules (all tags open and close on a sane order) and because of > that is easier to parse..
Regardless of the parsing simplicity, it has nothing to do with static/ dynamic in relation to IDEs. > >> 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. > 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. > 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. 1. Rename Package N/A as there are no packages 2. Implement all unimplemented members N/A as there are no abstract types or contracts 3. Add missing import Possible depending on how the IDE manages project files 4. Create Interface N/A 5. Create event listener Already possible in many existing HTML IDEs 6. Create constant Ok 7. Add parameter to function Ok 8. Create local variable Ok (let vs var) 9. Create field variable Ok 10. Create new Class N/A (create new Constructor) 11. Add method to Class N/A (add to Constructor prototype) 12. Add method with parameters to Class N/A (add to Constructor prototype) 13. Add variables to Class N/A (Add variables to Constructor) 14. Create methods Ok 15. Create methods with parameters Ok 16. Create methods with return type N/A (the return type is inferred) 17. Change method's return type N/A (the return type is inferred) 18. Cast method or variable N/A (the return type is inferred) 19. Getter / Setter generation Ok > > The biggest problem is that there hasn't been a significant effort in > > this space yet IMO, not due to some inherent difficulty in the > > language. > > indeed, a lot of things can be improved without changing the language and I > hope they do it, a good IDE helps a lot, but I really believe that it is way > harder to implement the same kind of features for dynamic languages without > enforcing stricter ways of programming... This is true, but with the large number of design patterns already in wide use, it may not be such a bad thing (design patterns are often a sign of language deficiency) > PS: strong-typed / strict languages only made sense to me after I started > using tools that helped the development process, before that it was just way > more verbose without any real gain. I really hope to be using the same kind > of features soon for JS without extra verbosity, I believe that ES5 "use > strict" will be the savior... Here's what the future may hold: http://wiki.ecmascript.org/doku.php?id=strawman:strawman -- 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]
