Java Script Sucks

JavaScript never ceases to disappoint. Although it was launched with great expectations and has found reasonable penetration, both JavaScript authors and their (sometimes unwilling) users find something to dislike about most every deployment. This is most certainly due to either the clash of titans that surrounded its birth or the wallowing of low-lifes that turn everything into spam. This page contains mostly bickering about the extent of this tragedy. A future refactoring will draw some lessons from the experience and maybe even point toward alternate futures. -- WardCunningham
JavaScript may suck. Many people do tremendously awful things with it.

JavaScript is used in web pages. Usually it sucks there. It is painful to write there, and people do annoying things with it, like popup ads, security breaches, etc.

JavaScript is also a system ScriptingLanguage on windows.

JavaScript is also embedded into Discreet's Combustion video wonderbox software.

JavaScript is used in places that perhaps it was not intended to be used, such as SystemsSoftware.

JavaScript uses "type-tags" instead of value-based typing, and has too many "special values", such as NaN and Null. See ColdFusionLanguageTypeSystem to contrast. I like dynamic languages, but JS used the wrong kind of typing system in my opinion.
	 utility / complexity > K
{Please explain what value based typing is, and why tagging down a type is not basing something on a value. All type systems determine something from a value at some point, as the value has to be of some type. Is the goal of value based typing to reparse the value each time, instead of storing the type information in some structure or tag for future use? What do you gain from this?}

I believe most of these are answered in ColdFusionLanguageTypeSystem.

Unless you've actually personally read the cold fusion source code yourself, I'm afraid you haven't a clue what you're on about. Without deep knowledge of cold fusion compiler/interpreter internals, you don't know what they use to store type information at different points in time while parsing/interpreting/compiling. Whether or not a compiler/interpreter stores type information in structs, records, databases, tags (whatever the hell they are), shouldn't even be of concern to the typical person. That's a fucking implementation detail - I've never ONCE concerned myself with whether a language uses tags or not - in fact I'm not even sure if TAG has any meaning whatsoever. If a compiler uses a C struct to store some type information while parsing/compiling, do you consider this struct a tag? Please describe what a tag is, what value based is.. using more formal precise language.

Since most languages are implemented in C, I'd bet you good money that some sort of C struct is used at some point to store information about types. Is this C struct the tag you are speaking of? I don't even know what a tag is. If it's just one of these illusions you have going on in your head, or an abstract concept, I'm afraid there is no way of confirming which languages use tags and which ones don't, because an illusion or abstract concept that exists only in Topmind's head, cannot be found in reality. In reality, you'd have to look for something more concrete, something that actually exists.. like a C struct that stores information in the compiler/parser about types. Maybe the Perl source code would be a good place to start, to see how perl stores type information (I'd guess it is some kind of C data structure). Do you consider Perl to be tag-free, value based? Or is it tag based? Since I'm a smart guy, and I can't figure out whether perl is tag based, value based, or Moose-Shit-Fecal based, and since I don't care or give a damn and never have - I'm wondering why anyone else would care, and why you would choose a language based on this one fact (or lack of fact)? Even if I found out exactly how type info is stored in some particular dynamic language, why would this implementation detail be of concern to me as a layman choosing a language? I would not choose a language based on whether it does or does not use C structs for some things.

The "side tag" model is a model. It's not necessarily meant to mirror a particular compiler/interpreter implementation. (All ColdFusion interpreters from different vendors/makers hopefully produce the same results.) And we can study the behavior of the compiler/interpreter (output) to see if the tag model is a good fit or not. When people "reason" about types, it's nice the have a model about how they work (or don't work) to reduce the need to run gazillion tests or write overly-defensive code. The model doesn't have to reflect the actual c/i implementation, it only has to have prediction value about expression and/or program output to serve our purposes. If it happens to mirror implementation, that's just a nice bonus, not a prerequisite. Related: EmpiricalTypeBehaviorAnalysis and ApplyingTheSideTagTypingModel.

JavaScript "acts" like it has side type flags while CF acts like it doesn't. Put another way, JavaScript results fit a model having side flags (separate from "value" by associated with) while CF doesn't.

{At best, the "side tag" 'model' refers to an implementation strategy sometimes called a "type tag" employed by a number of programming languages. Unless it's documented elsewhere, I've never seen any set of rules that describes how the "side tag model" may be used to predict behaviour. The pages cited (EmpiricalTypeBehaviorAnalysis and ApplyingTheSideTagTypingModel) seem to employ rules that appear to exist in the "side tag" author's mind (or somewhere else unspecified) or merely reiterate common understanding of dynamic and static typing implementations, with the term "side tag" arbitrarily injected in place of "associated with a type" (or other familiar phrases commonly used to indicate a concept associated with a type.)}

A specific example of why it might matter? A language with a side tag may be have a zero length variable if a length() function is used to test, yet ALSO be null, or something else "funny". In a language without side tags, we know that one variable that results a zero length is going to act like another variable with zero length. There are less variations and hidden surprises. Tag-based languages allow situations where a variable can be "two things" at the same time. This complicates programming because we have to consider more cases. I can explain to somebody why this is happening using the tag model, but the other models either cannot, or take too many steps to do it.

{It matters because "side tag" complicates a simple idea, that "<x> is of type <y>", with a complex one that "<x> has a side tag <t> that indicates it is of type <y>". See how the phrase "has a side tag <t> that indicates it" is not needed?}

No, it's conceptually simpler because the "type" has a representation that we can describe and draw. It's no longer ethereal. How do you illustrate "is of" or "associated with a type"? (Perhaps linguistic thinkers like it that way for some reason that escapes me, but I am not a linguistic thinker and neither is the entire population.)

{If necessary, draw a diagram and draw an arrow to indicate an association. However, such explanatory illustrations do not a model make! Note (in particular) the distinct lack of any stated rules for how these "side tags" are applied.}

Yes, but that tends to get messy and confusing: pasta-like. As far as stated rules, they are generally language-dependent. Plus, tags are closer to the actual implementation. All else being equal, the model that's a closer fit to implementation is generally better. And it better matches program output. It's difficult to print references as arrows without adding graphics libraries.

{My objections to the "side tag" notion are well-documented in the TypesAndSideFlagsDiscussion. No need to repeat them here.}

Example Debra:

 print(x); // result is "123"
 print(x + 3); // result is "126"

// Alternative run:

print(x); // result is "123" print(x + 3); // result is "1233"
It's possible to get two different answers because one has a "tag" of "string" and the other a tag of "number". This kind of thing never happens in a tag-free language. If it prints/displays a given way it behaves a given way. There's no hidden ghost-like behavior. One can output/analyze the tag in tag langs, but it's double the work and code because you have to inspect/print both the value and tag (type name) to know its full nature. If there was a clear benefit of a compound system, I might live with this extra complexity. But nobody has shown the benefits are common and strong for a majority of domains and situations.

You can get one output result that looks a given way (assuming no spaces), yet behaves different depending on different operations done after in tag langs. But there is no way to get this in CF or Perl that I am aware of.

It's WYSIWYG because it's tag-free (at the scalar level). This makes life easier in my opinion because I don't have to worry if it looks like a string but is really a number under the hood (different tag). There is only the value to reason about and worry about, not a hidden tag.

Will return true. If you're using liberal throws to step through confusing jasmine tests, this line will cause your tests to pass.
I just got done pulling my hair out over this kind of thing:, ...);
It simply did nothing. No error message or warning of any kind in both IE and FireFox. A normal language would say, "Variable Foo is not defined". I had to get a pencil out and compare the variable name character for character by crossing each letter out before I finally found the subtle misspelling, something like an "l" instead of "1" ("ell" versus one). (In hindsight I should have pasted in the good copy of the name.)

JavaScriptSucks! Geeeez! JS is the HollerithPunchCard of the internet age (which made me want to both holler and punch 'em.)

[I was surprised to find that this is a fairly recent edit, because these days all you need to do is pop open your browser's JS console. Any undefined variables will show a ReferenceError in there, plus the Debugger panel in Firefox (or the Sources panel in Chrome) lets you throw down breakpoints, jump around in the callstack, and inspect locals from any level of lexical scope. JS errors in browsers are silenced by default probably due to backwards compatibility, since there're so many old sites out there with bad scripts; if your code isn't working, there're sophisticated debugging tools you should be turning to immediately. -DavidMcLean?]

Rest of discussion moved to JavaScriptSucksInBrowsers.

EditText of this page (last edited February 1, 2014) or FindPage with title or text search