What is the fastest language that runs on the JVM [closed] - jvm

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 months ago.
Improve this question
What is the fastest language that runs on the JVM?
Scala? Groovy? JRuby?

See the Computer Language Benchmarks Game:
Java is very fast.
Scala almost as fast.
JRuby is 10-30 times slower.
Groovy is slow too.

Java.
Really, though, for the most part the speed difference will be negligible. Static languages will be faster than dynamic languages, but not by much.

As Anthony says, Java is the fastest language.
Languages with static typing (Java, Scala) are faster than dynamic ones (Groovy, JRuby).

You have to be careful what you're comparing.
As well as the "it depends what you're doing with it" that others have mentioned it also depends how you do it.
For example, a language like Scala can allow you to naturally express idioms and algorithms that you'd probably take a longer way around to do in Java. That's not to say that you couldn't match Scala's performance at doing the same thing - just that it may become an ugly workaround in one language to match the natural idioms in another (note I'm not saying I believe Scala is actually faster than Java at anything specifically - I have no data on that - other than that Scala is designed with scalability in mind - hence the name).
In other words, performance is usually about the algorithms and often the choice of algorithms are about ease of expression. So "use the right tools for the job" applies here - whether that tool happens to be Java, Scala, JRuby or whatever (although I doubt there are any situations where a dynamic language is faster than a static one without being pathological).
Of course we could also talk about profiling before optimising etc, but that doesn't directly address the question.

Answer: bash !?
This may be not a direct answer to the question, but if 'fast' is related to the startup time, bashj (bash with java support, https://sourceforge.net/projects/bashj/) provides excellent startup time. Here is a comparison of "Hello World" from java, bash, and bashj. The bashj version uses a hidden JVM server, called to display the msg.
minimum (msec) median (msec)
bash 2 6
bashj 7 11
java 72 80
Executing a java program from its main() entrypoint is faster with bashj than with java itself !
Here is the bashj source code:
#!/usr/bin/bashj
#!java
static void hello() {System.out.println("Hello, world !");}
#!bashj
j.hello()
For general java method calls, the bashj time is the JVM execution time plus ~1msec

I think it would depend on what you mean by faster, and how well the language is written for performance.
For example, if you are doing something math intensive then Scala will be faster than Java.
But, if you avoid functions that are slow in java and use final in all places where it makes sense, you can get Java to run faster than Scala, from what I was told recently at an interview.
So, this is a hard question to answer in generalities, as people will show instances where Scala or Java will be faster.
But, I believe that Scala will generally be faster, if you are not using vars, but val instead.

Any language that compiles to bytecodes will run equally fast on a JVM with JIT.

Related

Can any language be used to program in any paradigm? [closed]

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
Can any language be used to program in any paradigm? For example C doesn't have classes but s it is possible to program in OOP. There are some languages (such as assembly) I can't see using OOP in.
Yes, simply due to the fact you can implement an interpreter for your $favorite $paradigm in the host language.
Practically though, this is not feasible, efficient or right.
C++ is ultimately assembly, you just have a compiler to write the assembly for you from a nicer description. So sure you can do OOP in assembly, just as you can do OOP in C; it's just that a lot of the OO concepts end up being implemented with convention and programmer discipline rather than being forced by the structure of the language, with the result that huge classes of bugs become possible that your language tools probably won't be very good at helping you find.
Similar arguments follow for most paradigm/language mismatches. Lots of object-oriented programs have been written in C this way, so it can even be a somewhat practical thing to do, not just an academic matter.
It can be a little harder when what you want is to remove restrictions rather than add them.
In purity-enforced languages such as Haskell and Mercury you can't suddenly break out object-oriented style packets-of-encapsulated-mutable-state in the middle of arbitrary pure code (at least not without using "all bets are off" features like unsafePerformIO in Haskell or promise_pure in Mercury to lie to the compiler, at which point your program may well completely fail to work unless you can wrap a pure interface around the regions in which you do this). However you can write whole programs in procedural or object-oriented style in these languages, by never leaving the mechanism they use to do IO.
Likewise, if you consider the use of duck typing in dynamic languages to be a paradigm, it's pretty painful to get something similar in languages with static typing, but you can always find a way to represent your dynamic types as data. But you again find yourself doing thing with convention and reimplementation that you would get for free if you were really using a duck typing language.
I'm pretty sure it would be hard to find a language (usable for writing general purpose programs) that can't be adapted to write code in any paradigm you like. The adaptation may not produce very efficient code (sometimes it can though; adapting C or assembly to any paradigm can usually be made pretty much as efficient as if you had a language tuned for that paradigm), and it will almost certainly be horribly inefficient in terms of programmer time.
No, not all languages can be used to program in any paradigm. However, the more popular ones - python, c++, etc all allows you to chose how you want to program. Even php is adding OO support.

AutoIt best practices / coding style [closed]

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 last year.
Improve this question
I maintain Autoit project used for automated testing of swing app. Those tests have now about 70 files. It's get pretty hard to maintain all this code without following some "best practices" I'm trying to create as much functions as possible (because of duplicate code) and constants (frequent changes) bud it doesn't seem enough.
I have generally this types of functions:
Some general functions (insert text with logging, select or read from combobox.. )
Some screen specific functions (fill one form.. )
Some data/logic function - testing of app logic and data processing
Test case functions - combines previous 3 to implement some test scenario
AutoIt does not have classes => no inheritance => OOP principles are hard to aplicate ( :D clearly)
Does somebody have some experince with larger applications written in AutoIt? My opinion is, that AutoIt is for scripts < 500 lines and it wasn't good choice for this big project.
It's a shame, that AutoIt doesn't have some useful IDE.
AutoIt developers want to make sure that any functions written in AutoIt that are part of the core library (in short: UDFs) are subject to a certain code style. You can find this standard here: http://www.autoitscript.com/autoit3/udfs/UDF_Standards.htm Many programmers in the community write all AutoIt code in this standard.
On the subject of IDE. SciTE is a time-tested code editor, but as IDE it performs adequate. There are two other IDEs which are developed and maintained by the community:
A graphical debugger (F10 step next functionality) http://www.autoitscript.com/forum/topic/21834-graphical-autoit-debugger/
ISN AutoIt studio http://www.autoitscript.com/forum/topic/136766-isn-autoit-studio/
The last one is fairly new, but it looks extremely promising and it may work better for your project.
Finally, I have a note of warning. You say "OOP principles are hard to apply", but even as an OO programmer you should have a strong core idea of how to write non-OO code before you even learned OOP. Most OO languages are imperative at their core, so you should be an excellent imperative coder already. AutoIt is imperative as well.
A useful IDE will not solve your problems! But it will make them slightly easier to manage.
I don't know where you heard that AutoIt only performs well for scripts for under 500 lines, but every time you #include one of the default libraries you are adding ~10000 lines of code. If you can write proper code, you will build your own libraries without adding complexity to the rest of your code.
As AutoIt doesn't have (as you mentioned) the enabling characteristics of an OO language I think part of an answer here is to look at what AutoIt has and what paradigm best fits it. It's clear to me that AutoIt is a language meant to done using procedural programming methods. For me, it's actually a bit of fun to go back to those methods that way of thinking. My large programs end up, with an an emphasis on correctly defining computation modules, what is passed into the module (and returned). If you are severely missing OO benefits I think the next thing to focus on would be scoping -- trying to keep that as tight as possible.
As a final note, I think using the procedural programming techniques does usually end up creating a separate task of re-factoring after the functionality is up and running.
A place to start...but this was the dominant paradigm for decades

Begin Lua-scripting [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I'm at a stage where I am forced to learn Lua, so do you have any suggestions on how I do this? I don't have a lot of experience with any other scripting languages than PHP.
So, some suggestions on "head start Lua"-pages?
EDIT
As an addition to the wonderful tutorial pages, could you please suggest any "programs" I could make that will help me learn Lua? Imagine I would want to learn Pointers in C++, I'd make a Linked List. I want to touch the basics in Lua but meanwhile be open to pretty advanced stuff.
First of all work your way through the Programming in Lua, it should take you a day or two to get the gist of Lua.
However I can tell you right away on your first time through ignore coroutines and metatables, they are very powerful, but take a while to grasp. First learn the syntax, scoping (same as PHP luckily for you) and the standard libraries.
After that go back to coroutines and metatables, read them try them and by the third time through you might get it. Unless you have a very good CS background these are complex topics
Edit: The book is free online == website. Besides it is the best tutorial out there on Lua, everyone learns Lua with it.
Also: If you're purpose is Lua for World of Warcraft (probably not but just in case) you can check out this tutorial
And: Here is a tips and tricks thread on StackOverflow, might help give you some ideas of what to expect from Lua
Suggested Programs/Exercises:
Since you're initially looking at Lua for web development try to understand and improve the Data Description example in PIL. It'll give you a few good ideas and a nice feel for the power or Lua.
Then you might want to try out playing with the Data Structures chapter, although Lua has a single complex data-type, the Table, that chapter will show you Lua-like ways to make a table do anything you need.
Finally once you begin to grok metatables you should design a class system (yes with Lua you decide how your class system works). I'm sure everyone that knows Lua has made a dozen class systems, a good chapter to get you started on a class system is Object-Oriented Programming
And if you got time and know C or something like that (C# and Java included) try extending an application with Lua, but that'll take a week or two to do
Funny to see all these elaborate lists (though they are certainly correct). Back in 2002, I read about the first 20+ pages of the Lua reference manual, and started using it. It really is that simple. Lua (and ANSI C) are of the few languages that really fit in one's mind all at once - and stay there. For the others, at least I need to constantly do some relearning.
Be aware that getting to think in Lua will take time. I think mine was 6 months or so. When coming from C/C++, we tend to solve problems in certain ways. Lua might offer better means (i.e. via use of tables) but it takes a while to start seeing those. This transition to a higher abstraction level is similar to the Assembler->C shift in the 1980's. Many people still coded a while in C as if it only were a portable assembler.
There is also a large body of projects related to Lua at LuaForge.
If you happen to use Windows as your day-to-day platform, then I would recommend getting the Lua for Windows package as a nice starting point. It includes a wide array of useful modules all prebuilt and installed together with the Lua interpreter.
After your first pass through PiL and the reference manual, you will want to read Lua Programming Gems which is currently only available in a paper edition.
<plug> Do consider buying the books through the associate links at Lua's books page or LuaForge to support the projects. </plug>
Edit: As for ideas for programming projects where Lua is suited, look for problems where the table provides leverage. Tables are central to Lua, since even the global variables are just fields in a table. Tables can be indexed by values of any data type except nil, but have an especially efficient implementation if used as arrays.
One quirk that trips up people coming from a C-like background is that all things in Lua are naturally indexed starting from 1. Strings are indexed from 1, arrays start at 1, etc. Don't worry about it too much, there is nothing wrong with using a[0], but the length of the array given by #a is defined assuming that the array began with a[1].
Another quirk is that functions don't really have names. They are first class values that are usually stored in some variable that has a name. Syntax sugar makes it look like they have names, but that is just a convenience.
Metatables are a particularly Lua-ish feature of tables (and other types, but that is a really advanced topic) that are the basis for most of the schemes for doing object-oriented things in Lua.
Closures and true tail calls are other features of Lua that aren't often found in small scripting languages that can really make some idioms easy to implement.
In addition to the suggestions above, there's also the Lua wiki which is well worth a browse. There are a tremendous number of code snippets and small recipes there which can be useful.
I wrote a short quick-start guide to Lua for people using it on a project I was working on.
If you are familiar with other scripting languages it may get you up and running quickly.
The docs on Lua.org are very good and should cover most everything else you need. Lua is a pretty small language and can be learned fairly quickly.
This is a pretty general recommendation, but if you want to get started in a new programming language as a software engineer, it's fun to start doing the problems found at Project Euler in your new programming language. I've been doing this with Python recently and found it to be inspiring and bring a lot of enthusiasm to the coding.
You could install World of Warcraft and make a mod for that (it uses Lua). Actually that's probably a bad idea.
Maybe try to integrate Lua into a .NET application (assuming you are a C# programmer) and do something 'fun' with it:
Using Lua with C#
Or just browse lua.org

Auto-vectorizing vs. vectorized code by hand [closed]

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 2 years ago.
Improve this question
Is it better in some sense to vectorize code by hand, using explicit pragmas or to rely on or use auto-vectorization? For optimum performance using auto-vectorization, one would have to monitor the compiler output to ensure that loops are being vectorized or modify them until they are vectorizable.
With hand coding, one is certain that the desired instructions are being emitted, but now the code is likely not portable (either to other architectures or other compilers).
Auto vectorization never worked out well for me. To me it seems like auto-vectorization only works for very trivial loops at the moment.
I use the pragma/intrinsic approach and take a look at the assembly. If the compiler generates bad code (like spilling SSE registes onto the stack or adding redundant moves) I use inline assembler for the whole loop body.
Portability is btw not a problem. Often you start with a C/C++ loop and optimize it using intrinsics. Just keep the old loop and use it as a unit-test / fallback for your SIMD implementation. Also it's always wise to be able to remove all SIMD code from a project via a compile-time define. Debugging an application is much easier that way. The same define can be used for cross-compilation.
I would never rely on automatic vectorization from any compiler. With gcc I would be doubly wary because the effects of gcc's optimizations always vary from version to version. Almost everyone I know who relies on special optimizations or gcc extensions has to deal with breakage when a new gcc version is released.
You can usually trust pragmas and intrinsics, but you should keep a sharp eye on release notes for new gcc versions, and you should tell your own users what gcc version is needed to compile your code.
Once or twice when vectorization really mattered, we've added something to the test suite to call objdump and verify that vector instructions are actually being used. It would be nice to be able to detect 'bad vector code' (as Nils describes) automatically as well, but we've never gotten that far.

First impressions of the Fantom programming language? [closed]

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
Has anyone here given the Fantom programming language a whirl? (pun intended).
My first impression:
I like the ability to have the code run on either the .NET or Java VM.
The syntax is nice and clean and does not try anything fancy.
I have a belief that "the library is the language" and the developers of Fan believe that their USP is their APIs:
But getting a language to run on both Java and .NET is the easy part - in fact there are many solutions to this problem. The hard part is getting portable APIs. Fan provides a set of APIs which abstract away the Java and .NET APIs. We actually consider this one of Fan's primary benefits, because it gives us a chance to develop a suite of system APIs that are elegant and easy to use compared to the Java and .NET counter parts.
Any other thoughts, first impressions, pros and cons?
It looks very inspired by Ruby. It says that it's RESTful but I don't see how exactly. Compare with boo, which is more mature yet similar in many ways (its syntax is Python inspired, though).
The design decisions to keep generics and namespaces very limited are questionable.
I think their explanation sums it up:
"The primary reason we created Fan is
to write software that can seamlessly
run on both the Java VM and the .NET
CLR. The reality is that many software
organizations are committed to one or
the other of these platforms."
It doesn't look better than all other non-JVM/.NET languages. In the absence of any information about them (their blog is just an error page), I see no reason why they would necessarily get this righter than others. Every language starts out fairly elegant for the set of things it was designed for (though I see some awkwardness in the little Fan code I looked at just now) -- the real question is how well it scales to completely new things, and we simply don't know that yet.
But if your organization has a rule that "everything must run on our VM", then it may be an acceptable compromise for you.
You're giving up an awful lot just for VM independence. For example, yours is the first Fan question here on SO -- a couple orders of magnitude fewer than Lisp.
For what problem is Fan the best solution? Python and Ruby can already run on both VMs (or neither), have big communities and big libraries, and seem to be about the same level of abstraction, but are far more mature.
I have never heard of Fan until a couple of weeks ago. From the web site, it is about one year old so still pretty young and unproven. There are a couple of interesting points however: First the language is tackling the problem of concurrency by providing an actor model (similar to erlang) and by supporting immutable objects. Second, the object follows the example of Scala with type inference. Type inference allows the programmer to omit type declarations but have it computed by the compiler providing the advantage of short and cleaner code as in a dynamically type language while preserving the efficiency of a statically type language. And last, it seems like a very fast language, nearly as fast as Java and really close or beating the second fastest language on the JM: scala. Benchmark showing the performance can be found at http://www.slideshare.net/michael.galpin/performance-comparisons-of-dynamic-languages-on-the-java-virtual-machine?type=powerpoint.
This is very interesting.
Java (or C#) was created in order to eliminate Platform dependency by creating a JVM (or CLR) that will compile the code into a specific machine code at run time.
Now , There is a languege which is Virtual Machine independent? umm .... what the hell?!?!
Again , this is a very interesting topic , That might be the future...:) going to one universal single languege
I think it looks like a great language feature-wise, but I'm not sure how useful it is. I don't think it is all that useful to target .NET and JVM. Java is already cross-platform, and .NET is too, with Mono. By targeting two VMs, you have to use only the APIs that are available on both. You can't use any of the great native APIs that are available for Java and .NET. I can't imagine that their API is anywhere near as complete as either Java's of .NET's.