Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I know there's a difference between the languages, such as classes etc.
What I wonder is this: If UnityScript is different from Javascript, why does the Unity3D documentation give you the options to pick between C# and JS when you look through it? Shouldn't it be a choice between C# and US?
Meanwhile, here on Stack Overflow, people generally make the effort to correct people who call it Javascript. Why is that?
Unity uses a custom JavaScript variant also known as UnityScript which it historically and still today commonly (but inconsistently) refers to as "JavaScript," including as you note in its own script documentation.
This is incorrect in terms of the meaning of the term "JavaScript" in the programming world at large (i.e. beyond the Unity community). UnityScript is definitely not JavaScript. They are incompatible languages with fundamental differences. From a strict correctness point of view, yes, Unity should use "UnityScript" in its documentation.
The incorrect usage doesn't tend to be problem within the Unity community, within which it is assumed that "JavaScript" means the JavaScript used by Unity. In fact, it's possible that using the term "UnityScript" could cause confusion within the Unity community, because the term "JavaScript" has historically been and continues to be more commonly used, and it's possible many non-programmers within the Unity community don't even realize Unity is actually using a variant JavaScript, as opposed to actual JavaScript.
However, outside of the Unity community, including here on Stack Overflow, using the term "JavaScript" to mean anything other than the actual JavaScript will cause confusion, which is why it's important to say "UnityScript" here.
Incidentally, Unity adds to the potential confusion, both within and without the Unity community, by not being consistent. In its release notes for version 5, it used both "JavaScript" and "UnityScript" interchangeably. In a blog entry about an important scripting change, it used the term "UnityScript-aka-Javascript."
Quote from Juhana, thank you for the answer.
JS and US have enough differences that it's important to distinguish
between them when you ask a question. Otherwise you might just waste
people's time when their answer is incompatible with what you're
actually using. On Unity's site on the other hand there's no danger of
confusion because it's obvious from the context that they're always
talking about Unity and never about non-Unity JavaScript.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am working on an update of a curriculum for teaching non technical students the basics of programming, esp. programming for the web.
I prefer coffeescript over javascript for the (most times) much shorter and - as I think - better readable code.
On the other hand there are thousands of examples written in Javascript which are harder to understand if you know only about Coffeescript.
For the last years I just told my students to use a split screen in the editor, code CS in one frame and see JS in the other to see what is the translation of the CS statements in JS. And I showed the how to use CS2JS and JS2CS converter. The idea behind this is to make things visible like what "for-each" or "for-in" statements of CS do, as they are shown in JS in an unfolded way.
(I know this example leaks a little bit as ECMA 5 is rolled out now for a little time, but I am doing this for didactic reasons for a little while now)
Another problem is that there a not so much code hinter etc. for CS then for JS available.
EDIT
As the community seams to see this question to be opinion based, I precise it:
What toolchain do you use to make an easy entrypoint available for newbees to learn CS?
My pipeline builds on brackets.io as a webservice, node, gerrit, gitlab, ungit, jenkins, jade, less, coffeescript, ...
I have the need to make everything available totally offline so I wrap the tools in docker containers and VMs.
Before this question is closed as opinion-based, which indeed it is, let me comment that I cannot imagine the value in teaching non-technical students about CS vs. JS transpilation issues. They must have MUCH better things to spend their time on. As lovely as CS is, it is a dialect. Teaching it is like teaching Cockney slang in an English class. Furthermore, notwithstanding all the great code written in CS and the great benefits in efficiency it brought to those who used it, for better or for worse it is now on its way out, superseded by ES6 and TypeScript and eventually ES7.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
For javascript there is buckets and for typescript typescript-collections. For a lot of the classes I see the advantage. But what is the advantage of using the Dictionary class over javascript associative arrays?
I'm not trying to denigrate either library, just to understand the difference so I will better understand javascript.
On the whole, when people use many languages they like to transfer patterns between those languages. It is a judgement call as to whether this is a good or bad thing - in many cases the feature being ported to the language comes from another paradigm and may actually grate with the language concepts it is being transferred to.
In bad cases, the transfer disrespects the target language (i.e. there are better ways to achieve the same result without writing unnecessary classes). In the worst cases, the transfer disrespects the source language. I have seen several attempts to transfer C# Linq extensions to JavaScript that all process Linq query immediately and store the results in a second array - one of the benefits of Linq is that it will process the query when the result is enumerated, which allows more data to be processed than can be stored in memory (as one example).
I have ported features before, mostly for fun because it is an interesting learning experience (for example, I wrote a Linq example to demonstrate the problem with other Linq examples that were being posted).
If a feature or pattern is being transferred to make the target language more familiar, it is probably being done for the wrong reason.
If it is being transferred because it adds a feature that is needed that is inspired by a good pattern from another language, that is fine. The acid test for this is whether it saves you from repeating boilerplate code, for example checking what is in an existing array before adding to it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am trying to learn Javascript.There are some excellent books and great authors that became standard in JS world - As I can see, they all have their own way of interpretation of language. It can be sometimes confusing for the novice in Javascript.I wonder, how usefull can be to learn directly from ECMAScript language specification as it was published by the authors of the language ?
It's probably much better to learn from the tutorials, as the specification is designed for people implementing JavaScript parsers/interpreters, not for people learning JavaScript itself.
If you want to learn from a reference, the MDN is a fantastic resource. There are also plenty of tutorials out there.
The specification is optimized for defining the language from the point of view of its implementors. It is not optimized for teaching it to someone that is new to the language.
A good learning reference has also many things that are not covered in the language spec, like common APIs (like the DOM and a JS framework) and common patterns (ex.: the module pattern, namespaces, etc...). While it is true that some people might have some coding practices you don't agree with you should not immetiately dismiss what they say, unless you really want to learn everything and fall into every trap yourself. As long as you have a mental framework of what you consider to be the best practices in general you should be able to identify what you agree with or not.
JavaScript is one of the most controversial languages in existence, there is no clear author and no clear documentation.
The best project I know of is Mozilla Developer Network (or MDN), it's pretty extensive and comprehensive.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Just had my mind going today. I spent some time in IE debug mode, browsing the web as usual, and oh boy do I see many errors :) Most of these errors are because some value are of a different type than expected (at least as far as I interpret the error messages).
What are the reasons JavaScript and similar scripting languages aren't strongly typed? Is it just to make the languages "easier" to understand and more accessable, or is the lack of a "compile-time" the real problem?
It should definitely have strong typing available. Actionscript 3 is strongly typed, but still has prototype inheritance and a wildcard type if you need dynamic objects.
There are no downsides to having that feature available, and I have to say, for a project of moderate to large size, strong typing prevents A TON of problems. To get the most out of it you need IDE support so it can report errors and provide autocomplete options, but Javascript would be in a whole new world if it had real classes and strong typing.
It gains flexibility from not being typed. I personally enjoy the weakly typed languages.
So the answer is there'd be benefits and drawbacks.
For people who want a strongly-typed language in the browser, GWT and Script# are available.
Would javascript and similar scripting languages benefit from being strongly typed?
Yes, they would, JavaScript 2.0 introduces a type system:
Type System
JavaScript 2.0 supports the notion of a type,
which can be thought of as a subset of all
possible values. There are some built-in
types such as Object, Number, and
String; each user-defined class (section 6)
is also a type.
Also see: http://timkadlec.com/2008/04/an-objective-look-at-javascript-2-0-strong-typing/
In general, support for strong typing provides many interesting opportunities for the compilation and optimization passes.
My own oppinion: You could parse scripts before executing them. This would catch most type-errors, and mean that the user doesn't have to see a partly-executed-then-terminated scriptresult. Even better, it would be a lot easier to debug the thing, if it had a parser :)
I like the weak typed aspects of most scripting languages for the most part. The only reason that I would want strongly typed, besides for performance, is that it is easier for tools to refactor strongly typed languages than weak.
I build a rapid prototype framework for eLearning in ActionScript 2 way back when. My biggest gripe was AS2 was not strongly typed and it causes me many a headache when debugging. I think that strongly typing things makes code easier to read. I think a weakly typed language offers more flexibility.
I lean more towards readability when i have to go back and figure out what the heck is going on in code i wrote 6 months ago.
Microsoft has gone a long way to solving strong typing the problem in the interim with typescript. Have a look:
http://www.typescriptlang.org/
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
If you look at the source of Google pages with JavaScript, you'll find that the JavaScript is clearly not readable -- or maintainable. For example, all variables and functions are one-letter named (at least, the first 26 are...); there are no extraneous white-spaces or linebreaks; there are no comments; and so on.
The benefits of this compiler are clear: pages load faster, JavaScript execution is faster, and as a bonus, competitors will have a hard time understanding your obfuscated code.
Clearly, Google is using some sort of a JavaScript-to-JavaScript compacting compiler. I am wondering if what they're using is an in-house tool? If not, what are they using? Are there any publicly available (ideally, free/open-source) tools of that sort?
YUI Compressor is a Java app that will compact and obfuscate your Javascript code. It is a Java app that you run from the command line (and would probably be part of a build process).
Another one is PHP Minify, which does a similar thing.
Another one is ShrinkSafe that is part of Dojo but may be used stand-alone (either in a build script, command line or at the website):
http://shrinksafe.dojotoolkit.org/
You may be looking for GWT - it's Java-to-JavaScript rather than JavaScript-to-JavaScript, but you may still find it useful.
I can't comment on what internal tool, if any, we use for JavaScript-to-JavaScript. (To be honest, I don't even know offhand... I'd have to look it up before explicitly not telling anyone :)
It's actually pretty unlikely to be JS->JS, much more so to be Java->JS. These days I believe the recommended JS compressor (for this is what they're called) is the YUI compressor, but others like /packer/ exist
Crockford.com's JSMin is one step in that direction, assuming you're only looking for minimization and not obfuscation.