I'm trying to move from TypeScript to Dart. TypeScript compiles almost immediately - Dart takes more than 5 seconds to compile a Hello World program! Am I missing something? Are there any possible ways to improve that?
This is usually not much of an issue when developing with Dart because Dartium, a Chromium derivative executes Dart directly.
Only for testing compatibility with other browsers and for deployment it is necessary to build to JavaScript.
pub serve a Dart development web server does dart-to-js compilation on-the-fly with a lot of caching which usually improves transpilation times for reloads (after some warmup time) if you need JS during development with non-Dartium browsers.
TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
So it (ts compiler) translates from a higher level programming language to a lower level programming language.
Dart is an open-source, scalable programming language, with robust libraries and runtimes.
So it (dart2js compiler) is a source-to-source compiler (transpiler) that takes the source code of a program written in one programming language as its input and produces the equivalent source code in another programming language.
I think that explains everything.
Related
So I see that unity has the support for c#, JS and Boo.
I could learn one of these but I would like to make a 'compiler' or something similar that would let me write ruby code and either output JS code or make a layer that could be read by the Unity compiler.
Is this even a possibility. Im willing to invest many hours in this and have a fair bit of experience.
If your question is actually "how do I compile Ruby to JavaScript" then that's easier to answer:
Opal: Ruby to JavaScript compiler
However, you're going to be mucher better off learning one of the supported languages. It's very hard to debug "your" code when what's running is a paraphrasing of the code in another language.
I'm not that familiar with C# but if it's anything like C, it's quite possible you could create bindings from Ruby to Unity and just use it directly. Likely you could even get some kind of community going. This would be much preferable to trying to auto-refactor languages.
I recommend the "play my code" site.
It is possible to "conpiles Ruby to JavaScript", to operate the Ruby Game in a browser, just as JS.
http://www.playmycode.com/build/edit/6172
Unity 3d doesn't use Javascript, i think unity corporation call it as javascript just for marketing purposes, Unity uses UnityScript which is Boo based implementation, you can see the source here https://github.com/bamboo/unityscript
So, even if you got some compilers ruby to javascript such as Opal, you'll still compile it to JavaScript and not UnityScript, there's a big diferences between them:
Javascript is a prototype based language, and UnityScript is an class based.
UnityScript is more JScript.NET than Javascript.
See more at http://wiki.unity3d.com/index.php?title=UnityScript_versus_JavaScript
I think the easily way to integrate ruby language rather to write a full compiler is integrate IronRuby, which is a Ruby implementation written in C#, which will generate bytecodes for CLR that Unity can read.
I did a similar project with python, which uses IronPython (https://github.com/cesardeazevedo/Unity3D-Python-Editor), it's still very limited, such you still have to call python code from C#, but it works and there's a interpreter that can help you in your development, if you want to create thousands of game objects with simple python commands.
Can GO be used as a scripting language within an application ? I can't find any informations about this: is there a dynamic link library version which could be interfaced from a Windows application with some standard methods such as Compile(), Execute and features such as callbacks, variables sharing etc ?
This might sound strange at first but go with me on this: I think it would be a perfect candidate for a scripting language because it's compile time is so fast....hear me out...
Most scripting languages are interpreted, and so they do not require (or even provide in some cases) compilation. However compiled languages are safer in general because they can catch certain errors at compile time, which is better than, for example, catching a syntax error at runtime.
With Go, the compile time is so speedy that whatever program is running your Go code (e.g. a web server) could hypothetically compile the code on-demand if the code has changed, and otherwise use the compiled version.
Actually if you check out Google App Engine and download their dev web server for Go (https://developers.google.com/appengine/) you'll notice that their web server does exactly this. If you run through their Hello World tutorial for Go you'll notice that if you make changes to your code you won't need to recompile the Go code in order for the changes to take affect.
Go is not a scripting language. Because Go is designed for fast compilation, there have been some attempts to use it as a scripting language. For example,
gorun
GoNow
In theory (and perhaps somewhere out there w/o me knowing), Go can be used as a script language. Just note that it makes as much sense as using e.g. C as a scripting language.
No. Go code cannot be used within a non-Go application unless Go is responsible for starting up the whole app.
I think I finally know what I want in a compiled programming language, a fast compiler. I get the feeling that this is a really superficial thing to care about but some time after switching from Java to Scala for a while I realized that being able to make a small change in code and immediately run the program is actually quite important to me. Besides Java and Go I don't know of any languages that really value compile speed.
Delphi/Object Pascal. Make a change, press F9 and it runs - you don't even notice the compile time. A full rebuild of a fairly substantial project that we run takes of the order of 10-20 seconds, even on a fairly wimpy machine
There's an open source variant available at www.freepascal.org. I've not messed with it but it reportedly is just as fast - it's the design of the Pascal language that allows this.
Java isn't fast for compiling. The feature you a looking for is probably a hot replacement/redeployment while coding. Eclipse recompiles just the files you changed.
You could try some interpreted languages. They usually don't require compiling at all.
I wouldn't choose a language based on compilation speed...
Java is not the fastest compiler out there.
Pascal (and its close relatives) is designed to be fast - it can be compiled in a single pass. Objective Caml is known for its compilation speed (and there is a REPL too).
On the other hand, what you really need is REPL, not a fast recompilation and re-linking of everything. So you may want to try a language which supports an incremental compilation. Clojure fits well (and it is built on top of the same JVM you're used to). Common Lisp is another option.
I'd like to add that there official compilers for languages and unofficial ones made by different people. Obviously because of this the performance changes per compiler.
If you were to talk just about the official compiler I'd say it's probably Fortran. It's very old but it's still used in most science and engineering projects because it is one of the fastest languages. C and C++ come probably tied in second because there also used in science and engineering.
Compiling a program to bytecode instead of native code enables a certain level of portability, so long a fitting Virtual Machine exists.
But I'm kinda wondering, why delay the compilation? Why not simply compile the byte code when installing an application?
And if that is done, why not adopt it to languages that directly compile to native code? Compile them to an intermediate format, distribute a "JIT" compiler with the installer and compile it on the target machine.
The only thing I can think of is runtime optimization. That's about the only major thing that can't be done at installation time. Thoughts?
Often it is precompiled. Consider, for example, precompiling .NET code with NGEN.
One reason for not precompiling everything would be extensibility. Consider those languages which allow use of reflection to load additional code at runtime.
Some JIT Compilers (Java HotSpot, for example) use type feedback based inlining. They track which types are actually used in the program, and inline function calls based on the assumption that what they saw earlier is what they will see later. In order for this to work, they need to run the program through a number of iterations of its "hot loop" in order to know what types are used.
This optimization is totally unavailable at install time.
The bytecode has been compiled just as well as the C++ code has been compiled.
Also the JIT compiler, i.e. .NET and the Java runtimes are massive and dynamic; And you can't foresee in a program which parts the apps use so you need the entire runtime.
Also one has to realize that a language targeted to a virtual machine has very different design goals than a language targeted to bare metal.
Take C++ vs. Java.
C++ wouldn't work on a VM, In particular a lot of the C++ language design is geared towards RAII.
Java wouldn't work on bare metal for so many reasons. primitive types for one.
EDIT: As delnan points out correctly; JIT and similar technologies, though hugely benificial to bytecode performance, would likely not be available at install time. Also compiling for a VM is very different from compiling to native code.
Programming Languages, Open source libraries and standards adopted to make Firefox works.
It's a large, long lived project, so it's got far too many to list. Especially when you consider ancillary technologies - for example, the Elkhound parser combined with their JavaScript engine creates Dehydra, used to perform static analysis and transform source code, used to bring the old XPCOM stuff up to more recent standards and update dependencies on JavaScript calls.
At the broadest level, the runtime consists of mostly C++ components, configured by XUL interface description language and scripted with JavaScript. IIRC, some of the JS engine code from Adobe is C rather than C++, as are some of the lower level networking libraries. Over recent years, some UI functions have moved from C++ into JS. Then there are the build support and debugging code, which can be Python, perl, make scripts, and so on.
Its all in here :-)
https://developer.mozilla.org/En