Java > Scala
Paulo Pinto
pjmlp at progtools.org
Wed Nov 30 12:52:49 PST 2011
Well doing lots of transactions per second while aggregating data
from network elements scattered across mobile network stations
seems quite a lot of work to me.
I worked in several projects from quite a few big mobile companies and I
can say that most code that runs on the network side doing analysis of
your mobile activities is either JVM or .Net based.
Since 2004 the middleware used by mobile operators has been being
migrated from C and C++ codebases mostly to Java and C#. Usually only
devices with hardware restrictions are left untouched.
Most of the operators software is now Web, Eclipse/Netbeans or Windows
Forms/WPF based.
Polyglot programming is preferred to one single language (hammer), and
as such, most project managers don't see as a downside that you need to
mix languages.
--
Paulo
Am 30.11.2011 16:38, schrieb Regan Heath:
> On Wed, 30 Nov 2011 14:46:10 -0000, Paulo Pinto <pjmlp at progtools.org>
> wrote:
>> I am with Russel here.
>>
>> I work mostly in JVM and .Net environments and although currently I am
>> the opinion that there are too many VM based applications, we hardly
>> have any performance issues.
>
> Then you're not doing enough :p
>
> Seriously tho, I think it's a fairly accurate (as generalisations go)
> statement that you /can/ get more performance out of natively compiled
> code. If you don't need that extra performance, ever, then you're not
> losing anything by using a virtual machine style language.
>
>> When they do happen we are able to track them mostly to bad coding
>> practices.
>
> Yeah, this is the more/most common cause of performance issues (in any
> language). Perhaps a useful measure of a language is how easy/hard it is
> to write bad performing code.
>
>> JNI or P/Invoke are seldom used for performance reasons and mostly to
>> integrate with some specific OS feature.
>
> This is one of the downsides to using JAVA or other sandboxed/JVM style
> languages, when you actually need bare metal access (and in some domains
> that is very rarely) you have to take a hit in performance and/or
> functionality. It's another cost you pay, but one which may not be
> relevant depending on the domain you're in.
>
> The ivory tower of performance with safety with quick development time
> with easy to understand code and tools is simply not possible, there are
> to many decisions in language development which boil down to a trade off
> between one or more of these ideals.
>
> Regan
More information about the Digitalmars-d
mailing list