On Friday, 5 December 2014 at 18:46:12 UTC, Jonathan wrote:
>> JEE is the evolution of distributed CORBA applications in the enterprise, with .NET enterprise applications being the evolution of DCOM.
>>
>> Both games that C++ lost its place at.
>
> What about zeromq with C++ or even resorting to simple internal REST protocols. I've yet to see a valid argument that DCOM (not sure about COBRA) offer a tangible benefit over simpler approaches. Thoughts?

I am yet to enconter any project using zeromq.

The whole issue is the infrastructure you can get from such eco-systems for large scale deployments.

For example, you a standard way across multiple operating systems to:

- message queues, including mainframe systems
- monitoring
- scheduling
- user security, including integration with existing systems and multiple authentication levels
- database drivers
- package aplications and deliver them across the cluster
- load balancing schemes
- web development frameworks
- batch processing
- orms
- meta-programming
- cluster based cache systems
- web apis

In C++ you would need to cherry pick different sets of libraries, without guarantees of compatibilities across them, with different semantics.

And they still wouldn't cover the whole functionality.

Then you will be fighting with compilation times, memory errors and so on.

--
Paulo

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.

On Friday, 5 December 2014 at 21:21:49 UTC, Ola Fosheim Grøstad wrote:
> 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.

Btw, in most cases the last point does not apply. Compute Engine has a 16core/104GB option and I would be surprised if Azure and Amazon doesn't have a similar offer. You pay for at least 10 minutes and after that per minute at 0.8-1.2 USD/hour. So if the computation has to run for 30 minutes on 30 instances (Approx. the cpu power of 480 sandy bridge cores and 3 TB RAM) it will cost you ~18USD.

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.

On Friday, 5 December 2014 at 08:08:13 UTC, Ola Fosheim Grøstad
wrote:
> On Friday, 5 December 2014 at 07:33:21 UTC, Shammah Chancellor wrote:
>> On 2014-12-04 14:12:32 +0000, Ola Fosheim Grøstad said:
>>
>>> I did not find that odd, they are not perceived as stable and proven. Go is still working on finding the right GC solution.
>>
>> There are quite a few companies using Go in production.
>
> Yes, but I will not consider Go ready for production until they are out of Beta on Google App Engine. Google has to demonstrate that they believe in the capability of their own language ;-).
>
> https://cloud.google.com/appengine/docs/go/

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.

On 6/12/2014 11:28 a.m., Freddy wrote:
> 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.

You forgot type removal for generics during compilation.

On Sat, Dec 06, 2014 at 03:01:44PM +1300, Rikki Cattermole via Digitalmars-d wrote:
> On 6/12/2014 11:28 a.m., Freddy wrote:
> >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.
> 
> You forgot type removal for generics during compilation.

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.


T

-- 
"The number you have dialed is imaginary. Please rotate your phone 90 degrees and try again."

On 6/12/2014 3:12 p.m., H. S. Teoh via Digitalmars-d wrote:
> On Sat, Dec 06, 2014 at 03:01:44PM +1300, Rikki Cattermole via Digitalmars-d wrote:
>> On 6/12/2014 11:28 a.m., Freddy wrote:
>>> 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.
>>
>> You forgot type removal for generics during compilation.
>
> 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.
>
>
> T

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.

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

On Sat, Dec 06, 2014 at 03:49:35PM +1300, Rikki Cattermole via Digitalmars-d wrote:
> On 6/12/2014 3:12 p.m., H. S. Teoh via Digitalmars-d wrote:
> >On Sat, Dec 06, 2014 at 03:01:44PM +1300, Rikki Cattermole via Digitalmars-d wrote:
> >>On 6/12/2014 11:28 a.m., Freddy wrote:
[...]
> >>>My problems with java:
[...]
> >>>This is all i can remember.
> >>
> >>You forgot type removal for generics during compilation.
> >
> >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.
[...]
> 
> 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.
> 
> I really hope I'm wrong or its changed since then but who knows.

It's enterprise code. 'Nuff said. Even though "enterprise code" sounds so glamorous, in reality it has a high likelihood of being a rats' nest of spaghetti code with lasagna code layered on top, an accumulation of patches upon hacks to bandaids over bugs resulting from earlier pathces, with messy sauce leaking everywhere. I've seen enough examples of actual "enterprise code" to know better than the idealistic image they pretend to convey.

But anyway, that's beside the point. :-P  Type erasure does have its value -- for example, if you have a template class that represents a linked-list or tree or something like that, most of the code actually doesn't care about the type of the data at all. Code that swaps pointers to link / unlink nodes, or code that rebalances a tree, those pieces of code are mostly type-independent and can operate generically on lists or trees containing any type. Under D's template system, unless you manually factor it out, all of this code will be instantiated over and over again, once for every data type you might put into the list / tree. For non-trivial containers, the template bloat can be quite horrendous. Type erasure allows you to reuse a *single* copy of the code that handles every type of data contained.

However, having *only* type erasure like Java leads to problems in parts of the code that *do* need to know about the specifics of the data. Such as whether it's a by-value or by-reference type (AIUI Java generics requires you to box all POD types due to type erasure, which introduces an additional needless layer of indirection), the need for postblits, dtors, copy ctors, etc. (in Java they would be handled by virtual methods AIUI), or certain operations that can generically apply to a particular category of types (e.g., +, -, <, >, should in theory work for all numeric types, including built-in types). This is where D's template system shines, because it is able to eliminate boxing/unboxing and lots of indirections by taking advantage of type information, as well as not being subject to limitations of type erasure (e.g., Java can't have catch blocks that catch List<Integer> and List<String> separately, due to type erasure).

In an ideal world, we'd like to have the best of both worlds -- minimize template bloat by merging parts of the generic code that don't depend on the type, but retaining enough type information to be able to use it when needed.


T

-- 
Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG

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

-- 
Dmitry Olshansky