On 12/5/2014 10:12 PM, H. S. Teoh via Digitalmars-d wrote:
> On Fri, Dec 05, 2014 at 04:49:02AM +0200, ketmar via Digitalmars-d wrote:
>> On Fri, 05 Dec 2014 02:39:49 +0000
>> deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> [...]
>>> Also relevant:
>>> http://wiki.jetbrains.net/intellij/Developing_and_running_a_Java_EE_Hello_World_application
>> i didn't make it past the contents. too hard for silly me.
>
> Whoa. Thanks for the link -- I was actually at some point considering
> maybe to get into the Java field instead of being stuck with C/C++ at
> work, but after reading that page, I was completely dispelled of the
> notion. I think I would lose my sanity after 5 minutes of clicking
> through those endless submenus, typing out XML by hand (argh), and
> writing 50 pages of Java legalese and setting up 17 pieces of
> scaffolding just to get a Hello World program to run. Whoa! I think I
> need therapy just skimming over that page. This is sooo over-engineered
> it's not even funny. For all their flaws, C/C++ at least doesn't require
> that level of inanity...
>

I really don't think a Hello World example is representative of the usefulness of Java in the web. I don't see it as being over-engineered at at all (though that is a disease Java programmers are often afflicted with). The XML configuration allows you to be portable across web containers and application servers, while using only the bits of the JEE specification that you need. Anyone doing serious Java web dev, from servlets to full-blown JEE stacks, is going to be using a Java IDE that generates much of what is needed anyway, and will only need to tweak the config files for customization.

I've done Java backends on a contract basis in the past. If I needed to whip up a web app today, I'd still choose Java.

On Friday, 5 December 2014 at 21:21:49 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 5 December 2014 at 20:32:54 UTC, H. S. Teoh via Digitalmars-d wrote:
>> I agree. It's not just about conservation of resources and power,
>> though. It's also about maximizing the utility of our assets and
>> extending our reach.
>>
>> If I were a business and I invested $10,000 in servers, wouldn't I want
>> to maximize the amount of computation I can get from these servers
>> before I need to shell out money for more servers?
>
> Those $10,000 in servers is a small investment compared to the cost of the inhouse IT department to run them… Which is why the cloud make sense. Why have all that unused capacity inhouse (say >90% idle over 24/7) and pay someone to make it work, when you can put it in the cloud where you get load balancing, have a 99,999% stable environment and can cut down on the IT staff?
>
>> There are also certain large computational problems that basically need
>> every last drop of juice you can get in order to have any fighting
>> chance to solve them.
>
> Sure, but then you should run it on SIMD processors (GPUs) anyway. And if you only run a couple of times a month, it still makes sense to run it on more servers using map-reduce in the cloud where you only pay for CPU time.
>
> The only situation where you truly need dedicated servers is where you have real time requirements, a constant high load or where you need a lot of RAM because you cannot partition the dataset.

Big simulations still benefit from dedicated clusters. Good performance often requires uniformly extremely low latencies between nodes, as well as the very fastest in distributed storage (read *and* write).

P.S. GPUs are not a panacea for all hpc problems. For example, rdma is only a recent thing for GPUs across different nodes. In general there is a communication bandwidth and latency issue: the more power you pack in each compute unit (GPU or CPU or whatever), the more bandwidth you need connecting them.

On Saturday, 6 December 2014 at 09:07:34 UTC, Dmitry Olshansky wrote:
> 06-Dec-2014 01:28, Freddy пишет:
>> On Thursday, 4 December 2014 at 13:48:04 UTC, Russel Winder via
>> Digitalmars-d wrote:
>>> It's an argument for Java over Python specifically but a bit more
>>> general in reality. This stood out for me:
>>>
>>>
>>> !…other languages like D and Go are too new to bet my work on."
>>>
>>>
>>> http://www.teamten.com/lawrence/writings/java-for-everything.html
>>
>> My problems with java:
>>   no unsigned ints
>>   primitive are passed by value; arrays and user defined types are
>> passed by reference only (killing memory usage)
>>   no operator overloading(looks at java.util.ArrayList)
>>   no templates
>>   no property syntax(getters and setters are used instead even if
>> you know the field is never going to be dynamic)
>>   only and exactly one class per file(ALL THE IMPORTS)
>>   every thing must be inside a class(globals and free functions
>> are static fields in a class)
>> This is all i can remember.
>
>
> Solved in Scala:
> - operator overloading
> - properties - that + optional (), a library writer still can enforce () to be used
> - only and exactly one class - any number in any combination
> - everything class - sort of, it has 'object' clause (just like 'class') that can be thought as a kind of namespace or a singleton if you love OOP.
>
> Not fixed:
>  - unsigend types - nothing here unless Java adds support
>  - pasing by value - there are immutable and value types (e.g. Tuples) but I think they are references behind the scenes
>  - no templates, but you may use AST macros which is even more powerful

Some form of unsigned arithmetic exists since Java 8.

For example,

https://docs.oracle.com/javase/8/docs/api/java/lang/Byte.html#toUnsignedInt-byte-

https://docs.oracle.com/javase/8/docs/api/java/lang/Integer.html#remainderUnsigned-int-int-

There many more methods available.

On Friday, 5 December 2014 at 23:09:56 UTC, deadalnix wrote:
> Go is more mature than D. They have at least 2 implementation and
> well fleshed out specs.
>
> Granted, it is easier in Go as the language is smaller.

Yes, the Go feature set is relative mature and they have stable releases, but Google has advertisers as their customers so they can drop tools any time the feel like with no effect on customers. Chrome, Dart and PNaCl is all about securing Google Search, providing tools for developers is a by product…

I don't trust Google until they commit to making Go available as a supported tool to customers that they make revenue from. Google will probably evolve Go until it fits their own needs, but once they make it available as a supported tool on AppEngine they will have to commit to maintaining it as a stable release. It does say something that it has been in experimental/beta state for years on AppEngine. At Cppcon representatives from Google clearly stated that they could not see Go replace C++ any time soon. Overall that sounds like Google internally does not view Go as complete even though the Go authors think it is…

On Saturday, 6 December 2014 at 09:24:57 UTC, John Colvin wrote:
> Big simulations still benefit from dedicated clusters. Good performance often requires uniformly extremely low latencies between nodes, as well as the very fastest in distributed storage (read *and* write).

The question is not performance between nodes if you can partition the dataset (which I made a requirement), but how much you pay in total for getting the job done.  So you can have inefficiency and still profit by renting CPU time because the total cost of ownership from having a local under-utilized server farm can be quite high.

But if the simulation requires a NUMA-like architecture… then you don't have a dataset that you can partition and solve in a map-reduce style.

> P.S. GPUs are not a panacea for all hpc problems. For example, rdma is only a recent thing for GPUs across different nodes. In general there is a communication bandwidth and latency issue: the more power you pack in each compute unit (GPU or CPU or whatever), the more bandwidth you need connecting them.

HPC is a special case and different architectures will suit different problems, so you have to tailor the hardware architecture to the problems you want to solve, but then we are not talking $10.000 servers… If you need RDMA, then you are basically in NUMA land, which is not really suitable for a generic cloud solution in the first place?

On Saturday, 6 December 2014 at 12:04:48 UTC, Ola Fosheim Grøstad wrote:
> not talking $10.000 servers… If you need RDMA, then you are basically in NUMA land, which is not really suitable for a generic cloud solution in the first place?


Actually, Microsoft Azure provides InfiniBand RDMA for 4.47USD/hour for their A8 and A9 nodes:

http://azure.microsoft.com/en-us/pricing/details/virtual-machines/#Linux

On Fri, 2014-12-05 at 20:56 +0000, paulo pinto via Digitalmars-d wrote:
> 
[…]
> I am yet to enconter any project using zeromq.
[…]

Many of the financial institutions in London are using ZeroMQ for a lot of their projects. It does it's job very well.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Fri, 2014-12-05 at 22:28 +0000, Freddy via Digitalmars-d wrote:
> 
[…]
> My problems with java:
>    no unsigned ints

Indeed, right pain in the @@@@.

>    primitive are passed by value; arrays and user defined types are
> passed by reference only (killing memory usage)

Primitive types are scheduled for removal, leaving only reference types.

>    no operator overloading(looks at java.util.ArrayList)

Biggest mistake The Green Team made. Fixed by Groovy. Oh and Scala, Ceylon, Kotlin.

> 
>    no templates

Why would you want them for a JVM-based machine, there is no possibility of reification of type parameters, type erasure and all that mess. Scala, Kotlin, etc. have to create a vast infrastructure to deal with this.

>    no property syntax(getters and setters are used instead even if
> you know the field is never going to be dynamic)

Setters, getters and mutable properties are, or should be, anathema. They turn an object oriented programming language into an imperative procedural one without encapsulation.

>    only and exactly one class per file(ALL THE IMPORTS)

You can have as many classes as you want per file, but only one of them can be public.

>    every thing must be inside a class(globals and free functions
> are static fields in a class)

In Java. And Scala. Groovy, Kotlin, and Ceylon do things differently, the programmer can treat the JVM as having top-level functions.

> […]
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sat, Dec 06, 2014 at 03:26:08PM +0000, Russel Winder via Digitalmars-d wrote: [...]
> >    primitive are passed by value; arrays and user defined types are
> > passed by reference only (killing memory usage)
> 
> Primitive types are scheduled for removal, leaving only reference types.
[...]

Whoa. So they're basically going to rely on JIT to convert those boxed Integers into hardware ints for performance? Sounds like I will never consider Java for computation-heavy tasks then...


T

-- 
Marketing: the art of convincing people to pay for what they didn't need before which you can't deliver after.

On Sat, 2014-12-06 at 15:49 +1300, Rikki Cattermole via Digitalmars-d wrote:
> On 6/12/2014 3:12 p.m., H. S. Teoh via Digitalmars-d wrote:

> > I dunno, while type erasure is certainly annoying when you actually need information about the type, it's also eliminates template bloat. I think the ideal system should be somewhere in between, where type erasure is actively performed by the compiler where the type information is not needed, while template instantiations are retained when it is needed. This should keep template bloat under control while still offering full template capabilities. D currently leans on the template bloat end of the spectrum; I think there is much room for improvement.

The best solution is to not have generics, just like Javas 0 to 1.4. Every container is a container of references to Object. OK so Go has a quite neat solution.

(OK this is part troll. Given all the Java, D, Go, Python,… discussions of generics I see the whole topic is beginning not to get me worked up at all.)
> 
> Its a bit more then annoying. What happened when it was originally
> implemented was basically hacking of the compiler to support it,
> type erasure wasn't a design decision to my understanding.
> Then again the last time I checked Java's reference compiler / jvm
> source code it was a real mess to say the least.
> If I remember right an xml parser lib was at the same level in the
> repo as the compiler and nothing else at that level. This was only a
> few years ago now.

Erasure originally arose because the generics team were told they couldn't change the JVM: the JVM definition was sacrosanct on the altar of backward compatibility. Of course the Annotations team were told the same thing and then changed the JVM definition anyway.

So type erasure was a hack.

Since then many people, probably suffering from Stockholm Syndrome, or being Scala type management infrastructure folk, no believe type erasure is the right thing for the JVM. There is a vocal contingent pushing for type parameter reification, as was done in CLR, but I think there are too many influential people saying "won't happen" for it to happen.

Java 9 should see a far better structured JVM source code and runtime system.

> I really hope I'm wrong or its changed since then but who knows.

Some things have changed. Some would say not enough. The LJC (of which I am a member) is on the JCP EC so we get to vote. We are generally on the side of "no corporate politicking, get stuff done to help Java programmers". cf. the rewrite of the OpenJDK build system, the AdoptAJSR and AdoptJDK programs which have been hugely successful. More user groups are getting more stuff into OpenJDK than ever before. Obviously though Oracle and IBM are still the main players.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder