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.. >> 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. 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. >> type inference and dynamic code evaluation solves many problems but still a >> small part of the whole problem. - if anyone ever seen what VisualStudio is >> capable of doing for C# and what FDT and FlashDevelop does for ActionScript >> 3 you guys know what I mean... I really like JavaScript but sometimes I miss >> a good IDE. > > Aptana, Komodo, Netbeans... I use mainly Aptana 3 beta (since it doesn't "try" to check for errors, have a built-in terminal, cross-platform and I'm used to Eclipse) and Notepad++ (for simple things) and tried the other ones and can say that they are years behind FDT and VisualStudio, they are all OK but far from ideal... 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. > 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... cheers. 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... -- 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]
