I have started to use Haxe to convert my ActionScript 3 projects into NME, but, I like to know please what is Neko in the world of Linux? I searched for it, I found its an animated cat!
Can any one please explain to me?
Neko for most people is nothing more than a Haxe target. That's not technically true (it does have its own language, and could potentially be a target for other languages), but for most people, Neko is one of the Haxe output targets.
In the same way the Java Virtual Machine (JVM) can be targeted from multiple languages (See the list on wikipedia), Neko is a bytecode format that can theoretically be written to from multiple languages. For Neko however, most people seem to use Haxe to create their *.n files.
For Haxe programmers, the Neko target lets you:
Write command line tools and utilities (for example, haxelib and haxedoc are written in Haxe targeting Neko)
Write web apps or dynamic web pages - using mod_neko (or mod_tora) you get a web processor with the same sort of capabilities as PHP, but a fair bit faster.
Create games with NME (which originally started with Neko, it stands for Neko Media Engine), and compile them quickly, having a target closer to what CPP has, but which compiles a lot faster and where the output is cross platform.
A runtime that is closely tied into Haxe and can be used from within macros etc - so you can use all of the neko.* classes inside Macros.
If you're only interested in targetting SWF or JS, you'll probably not have much need for Neko. But if you are writing server side code, you'll appreciate the performance, and if you are writing CPP, you may appreciate having a simple target that is dead easy and super quick to compile, and which behaves similarly to CPP.
Of course, outside of Haxe neko is it's own language... but to me at least it seems most people just use it with Haxe.
More Info:
If you want to write in the Neko language (See this tutorial) you might save your code as "myfile.neko" and compile with nekoc myfile.neko, which will compile a Neko bytecode file "myfile.n".
If you want to write in the Haxe language, you might save your file as "MyFile.hx" and compile with "haxe -neko myfile.n -main MyFile".
The "myfile.n" that is generated by both of these doesn't have human readable source code - this is the Neko bytecode. You can run it on any computer that has Neko installed by running neko myfile.n. You can turn it into an executable (that runs without Neko installed) for your platform/OS by running nekotools boot myfile.n.
Here is a tutorial on Getting Started With Neko, which covers both command line programs you write and (very very basic) web pages.
"Neko" is Japanese for "cat", which is probably why you found what you did.
Neko is also a virtual machine (a "VM") like the Java Virtual Machine ("JVM") or the .Net Common Language Runtime (".Net CLR").
Neko has a custom high-level language made as an easily targeted language backend (like C-- in a way, but not like LLVM, which is closer to an assembly language). In other words: It's something that a programming language can be translated into rather than a more involved "full" compilation (like to assembly, to bytecode, or to machine code). Neko's language can be translated into a bytecode, which is portable and is usually stored in a ".n" file.
Neko was made by Nicolas Cannasse (the same person that made the Haxe Programming language), which is probably why Haxe has a Neko target in its compiler, and the Haxe tools, such as "haxelib" use it. Because the tools are compiled into ".n" files, they only need to be built once, and then they work on any platform with the VM executable "neko" installed.
Perhaps a more interesting bit about neko, and why you should learn it for Haxe development is that it's the runtime used for compile-time macros. See this tutorial for how part of your program can be run at compile time with full access to the build machine, which means you could even do complex tasks, such as parse a data file, at compile time.
Neko provides a common runtime for several different languages, including javascript and haxe. the compiler converts a source file (.neko) into a bytecode file (.n) that can be executed with the virtual machine. you can use the compiler as standalone commandline executable separated from the virtual machine, or as a neko library to perform compile-and-run for interactive languages. neko was written by nicolas cannasse.
you can find Neko Tutorial here
Related
I know Jython and JRuby is ported to JVM, and scala/Clojure is native to JVM, what about Groovy? Groovy looks like a dynamic language, I guess it is ported, but it seems it could also be compiled.
For those language native to JVM such as Scala, is that some tool to decompile the code to the source code?
"Ported" usually means "retargeted to run on." Groovy was designed to bring dynamic features from languages like Python and Smalltalk to Java. It was designed to be an extension of Java and in that sense it's native to the JVM and to the Java language. (The Groovy language, object model, and run-time libraries are extensions of Java's.)
But it sounds like you're asking about whether Groovy is interpreted or compiled. You can use groovyc to compile Groovy source code to Java .class files and run them in the JVM (linking in some Groovy run-time libraries). Or you can run Groovy source code interactively in GroovyShell, but what that does is compile, load, and run code for you incrementally.
A web search for [groovy decompiler] returns some possibilities for you.
I'm not sure whether it answers the entirety of your question, but the vast majority of Groovy and Groovy-Eclipse compiler is written in java, as seen on both projects' GitHub repositories.
I've been looking through the sites of Haxe / OpenFL / Flixel but am struggling to understand what each one is for.
As I understand it:
Haxe is a language that can be deployed to multiple platforms.
OpenFL is something to do with Flash.
Flixel is a library to help you make games.
Could anyone correct me/make it clearer.
Haxe
To quote from haxe.org:
Haxe is an open source toolkit based on a modern, high level, strictly typed programming language, a cross-compiler, a complete cross-platform standard library and ways to access each platform's native capabilities.
Language:
Haxe is a programming language. It's similar to AS3, C# etc. It is strictly typed, but has great type inference. It has a lot of powerful features such as Pattern Matching, Enums (ADTs), Macros etc. These work no matter which target you compile to.
Standard Library:
Haxe can compile to JavaScript, C++, Flash, Java, C#, PHP, Neko, HashLink, Python and Lua. It has low level standard classes that work consistently across platforms, such as: String, Int, Float, Date, Map etc. It also has some useful cross platform code for things like Serialization, Xml, Json, Date formatting etc.
As a general rule, anything on api.haxe.org that is in the top level, or in the haxe package, is going to work whichever target you compile to.
Each target has its own package. These let you access native capabilities of that target via externs. Eg. js.html has DOM externs, flash has externs for the Flash API, etc.
There is the sys package, which is available on "backend" targets: C++, Java, Neko, HashLink, PHP, Python and Lua. It's also available on JavaScript/Node with the hxnodejs library.
Other stuff:
The Haxe compiler is super fast compared to a bunch of other compilers. That's a selling point in itself. There's also macros, which let you do a bunch of pre-processing in a really powerful way. Then there's tools like Haxelib which let you link in with 3rd party libraries.
OpenFL
When Haxe first started, Flash was still a big target, it was installed everywhere, and it was great for making games. A lot of Flash developers liked Haxe because it was fast, type safe, open source, and gave them more features. But the flash API (sprites, graphics, movie clips, events) only worked on Flash, not on mobile, or on HTML5 etc. Which was a problem once flash started becoming less popular.
What OpenFL does is make that Flash API work on other Haxe targets. So you wrote a Haxe game targeting the flash API using sprites and graphics and flash-style code. Then, you want to compile to C++ (for targeting mobile etc). OpenFL lets your Haxe code use the Flash API, even if targeting C++ or JavaScript. For example, OpenFL creates the flash.graphics.DisplayObject class not only for flash, but for C++ and JavaScript. So if you know how to write Flash games, you are close to writing OpenFL games already.
OpenFL also has some great tools for making it easier to deploy your games to specific platforms. Where Haxe targets are things like "JS", "SWF", "C++", OpenFL platforms are things like "iOS", "Android", "Switch", "HTML5", "Windows EXE" etc. When you hear about Haxe targeting mobile, a lot of the time it is OpenFL, because it works with Haxe to compile your code (into C++, JS, SWF or whatever) and then packages those binaries for mobile.
Flixel
Haxe is a language, compiler and standard library.
OpenFL builds on this and adds the Flash API working across targets.
HaxeFlixel builds on this even further and provides game specific APIs that work on OpenFL.
An example of how it all works together:
You create a game. All of it is written in Haxe. Things like player name, scores, and completion info all use data structures from the standard library. They'll work in your game, but you could also make them work on your PHP website.
Your game uses OpenFL to compile to Flash, HTML5, iOS and Android. As part of OpenFL, you also have access to standard Flash API classes, like the Stage and Buttons and MouseEvents, which you might use for your menu screen. Because OpenFL provides the flash.* classes for other targets, your app compiles to all different things.
For your actual game, performance is important, and the flash DisplayList approach is a bit slow and not optimised for gaming. HaxeFlixel is optimised for gaming, and is very fast. So you design your game with HaxeFlixel using their APIs.
Summary
Haxe is a language, compiler, toolkit and standard library. It provides the most basic tools for cross-platform code.
OpenFL is built on Haxe, and provides the Flash API to multiple targets (Flash, C++, JavaScript) and makes it easy to compile to a bunch of platforms: web, native, iOS, Android, Nintendo Switch etc.
HaxeFlixel is built on OpenFL - it uses the APIs provided by OpenFL to create a game specific framework that is high performance and easy to make 2D games.
I just recently discovered HaxeFlixel, and I LOVE it! I came from making games in AS3 using Flixel, and now I'll probably never go back!
So, to attempt to answer your question (and the way I understand it):
Haxe is sort of the bottom layer. It's the programing language that can be compiled into Flash, Windows, Android, iOS, etc, etc, etc.
OpenFL is a software development kit which uses Haxe to make it easier and smoother to get games to work via Haxe and allow you to easily harness the power of Haxe's compatibility while not having to deal with a lot of the hassle and problems that you can get into. It takes care of a lot of the basic stuff for you and makes it easier to code.
HaxeFlixel is a 2D Game framework based on a combination of Adam Atomic's Flixel for AS3 and Flixel Power Tools by Photon Storm. It makes it easier to make 2D games in almost the same type of code as in AS3/Flixel.
When just starting out, you should only need to worry about the highest level, which in your case is HaxeFlixel.
So, to summarize a bit: Haxe is a powerful programing language. You can try to figure out how to code with it 'as-is', which is complicated, or you can use one of a number of libraries to make it easier - OpenFL is one of these libraries.
You can use OpenFL on its own, and code a game with it, or you can use one of a number of different frameworks to make it easier - HaxeFlixel is one of these frameworks. There's also the Starling and HaxePunk frameworks which have their own pros and cons.
Opinion Time!
I highly recommend sticking with HaxeFlixel - since it was so similar to Flixel, I managed to pick it up and learn how to use it, and made this complete game in exactly 1 month and released a Flash, Windows, and Android version all on the same day - which is outstanding considering I had not touched Haxe before, and had never had time to even start looking at Android Development before. That game's source code, by the way, is completely open source, so feel free to dig in and see how I did stuff.
The community for HaxeFlixel is also pretty amazing and people will help you out and answer questions.
It's really not too hard to jump in and start working with HaxeFlixel:
http://haxeflixel.com/documentation/getting-started/
Follow those steps and you'll at least have a Hello, World! up and running in minutes (excluding the time it takes to download and install all the stuff). Like I mentioned earlier, until you're more comfortable with it, just follow the directions for Haxe and OpenFL but don't even think about it for now!
Good luck! And let me know if you make it anywhere or not!
Is there a programming language, having usable interactive interpreter, even as it can be compiled to machine code?
Compilation vs. "interpretation" is essentially a matter of implementation, not the language itself. For example, MRI Ruby 1.8 is interpreted, while MacRuby is compiled to native machine code. Both include an interactive REPL. All the languages I know that have at least one machine-code compiler and at least one REPL:
Ruby
Python
Almost all Lisps (Lisp was the language that pioneered this technique, AFAIK)
OCaml
Haskell
Forth
If we're counting compilation to bytecode as well as machine code, it's true of the vast majority of popular bytecode-compiled languages:
Java
Scala
Groovy
Erlang
C#
F#
Smalltalk
Haskell, using the Glasgow Haskell Compiler which has an interactive "shell" called GHCi.
Many flavors of Lisp offer both options, including Clojure.
Two come to my mind : ocaml and scala (~= java), but I'm sure there must be a lot more out there.
And here's another one to burn your house down:
x86 Assembly
Yup, there are interpreters for this as well.
Javascript x86 Assembly Interpreter
Jasmin
At this point you're really in emulator land, but it does meet the requirements you state.
I'm wondering if it's easier to name compiled languages that someone hasn't cobbled up a working interpreter for. :-)
Lua has an interactive mode for one-liners and experimentation. It normally compiles to bytecode for its VM for execution. LuaJIT is an independent implementation of a Lua VM that also does just-in-time compilation to 32-bit x86. Support for 64-bit is underway, and support for ARM is frequently requested.
Compilation to a bytecode is often a reasonable compromise between a pure interpreter and a pure compiler. The VM can be tuned to the needs of the language, and JIT techniques can analyze the VM code as it executes and concentrate on frequently executed code paths and inner loops.
As others have mentioned, OCaml.
If managed code (.NET CLI) is close enough to machine code, F# would be a candidate as well. There are probably other .NET/Mono languages which meet the requirement as well.
You may regret you asked:
C and C++.
Why?
Ch
CINT
EIC
picocc
and there are probably others out there as well.
Plenty of languages offer an implementation that both interacts and compiles to machine code, but it's rare to do both at once. Standard ML of New Jersey is one that has an interactive loop but no bytecode: it simply compiles to machine code in memory and then branches to it.
Not exactly machine code, but Java can be compiled and also used via BeanShell.
I've used Ruby with an interpreter, and there seems to be a compiler here.
Icon used to have a compiler, but it falls in and out of maintenence. It may still work.
Python can be compiled to windows executables.
C# can be compiled by using SnippetCompiler, maybe this would act as an interactive interpreter for you?
Your question is a bit vague. Even Java would fit it:
by interactive interpreter, i mean
shell-like environment, where you can
work in the runtime interactively.
Java has this, e.g. in the Eclipse "scrapbook pages", where you can enter Java expressions and have them evaluated right away. Java is of course also a compiled language (and while it's usually compiled to bytecode, there are various compilers that output machine code).
So what are you looking for? Maybe you could explain your problem or interest.
I tried using mono/.net for a bit and found random GC pauses to be disagreeable (at least on my crusty old laptop). I looked at using gambit-c an implementation of scheme that can compile to C but it seemed difficult to work with because the docs were somewhat limited and the packages where not very easy to install and use.
I usually just stick to having an interpreted language such as python bound to C/C++ which is more painful but at least I know what I am in for.
Can anyone point to programming language which has python-like syntax, but from the very beginning was designed to generate native code? I'm aware of Boo only, but it uses .net, not native code generation. Well, if nothing else than python-like languages which generate .net/java bytecode are fine too.
Cython might do -- the C code it generates is for Python extensions, but the whole thing can be packaged up and you'll be running native code throughout (after the 'import';-).
I must admit that I don't quite understand your question, for two reasons:
You are asking for a language with native code generation, but native code generation has nothing to do with the language, it is a trait of the implementation. Every language can have an implementation with native code generation. Several Python implementations have native code generation. There are C compilers that compile to JVM bytecode, CIL bytecode or even ECMAScript sourcecode. There are even C interpreters. There are also compilers that compile Java sourcecode or JVM bytecode to native code.
Why do you care about the syntax? It is probably the least important factor about choosing a programming language.
Anyway, Nim is a programming language which has an implementation which supports native code generation (or more precisely an implementation which supports C source code generation) and whose syntax is a hybrid between Wirthian style (by the looks of it the most important influences are Oberon and Delphi) and Python.
However, the fact that it has Pythonic syntax isn't going to help you at all if you don't like European style language design or Wirthian style OOP.
Also found today Delight applying Python syntax on a D back-end.
And Converge too.
Check out Cobra
It is strongly influenced by Python, C#, Eiffel, Objective-C and other programming languages. It supports both static and dynamic typing. It has first class support for unit tests and contracts. Cobra provides both rapid development and performance in the same language.
shedskin compiles Python to C++
From shedskin project page
Shed Skin is an experimental compiler,
that can translate pure, but
implicitly statically typed Python
programs into optimized C++. It can
generate stand-alone programs or
extension modules that can be imported
and used in larger Python programs.
Genie which is part of the gnome project: http://live.gnome.org/Genie
I think it's exactly what you're looking for.
If you are happy with something that compiles down to Java bytecode you could have a look at Jython. Quoting from their FAQ:
JPython is an implementation of the Python programming language which is designed to run on the Java(tm) Platform. It consists of a compiler to compile Python source code down to Java bytecodes which can run directly on a JVM, a set of support libraries which are used by the compiled Java bytecodes, and extra support to make it trivial to use Java packages from within JPython.
I've not actually used it yet but am considering it on some projects where I have to integrate with existing an Java codebase.
HTH
PyPy is a project to re-implement Python in Python. One of it's goals is to allow the use of multiple back-ends, including C. So you can take a pure Python program, convert it to C and compile it to native code. It is still a work in progress, so probably not suitable for production code.
You can find all of the previously mentioned languages, plus some more, here: http://wiki.python.org/moin/PythonImplementations
Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula.
https://nim-lang.org/
You can also investigate IronPython - a python inplementation on the .NET framework
You can try Genie. It's the same like Vala, but with Python-like syntax. If you want to develop apps for Linux with GTK, and you want to compile it to native app, Vala or Genie is really good choice.
I think that java executables (jar files) are trivial to decompile and get the source code.
What about other languages? .net and all?
Which all languages can compile only to a decompile-able code?
In general, languages like Java, C#, and VB.NET are relatively easy to decompile because they are compiled to an intermediary language, not pure machine language. In their IL form, they retain more metadata than C code does when compiled to machine language.
Technically you aren't getting the original source code out, but a variation on the source code that, when compiled, will give you the compiled code back. It isn't identical to the source code, as things like comments, annotations, and compiler directives usually aren't carried forward into the compiled code.
Managed languages can be easily decompiled because executable must contain a lot of metadata to support reflection.
Languages like C++ can be compiled to native code. Program structure can be totally changed during compilation\translation processes.
Compiler can easily replace\merge\delete parts of your code. There is no 1 to 1 relationship between original and compiled (native) code.
.NET is very easy to decompile. The best tool to do that would be the .NET reflector recently acquired by RedGate.
Most languages can be decompiled but some are easier to decompile than others. .Net and Java put more information about the original program in the executables (method names, variable names etc.) so you get more of your original information back.
C++ for example will translate variables and functions etc. to memory adresses (yeah I know this is a gross simplification) so the decompiler won't know what stuff was called. But you can still get some of the structure of the program back though.
VB6 if compiled to pcode is also possible to decompile to almost full source using P32Dasm, Flash (or actionscript) is also possible to decompile to full source using something like Flare