On Fri, 2014-12-05 at 22:19 -0800, H. S. Teoh via Digitalmars-d wrote:
> 
[…]
> 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.

Most "enterprise software" is written by "average programmers", and to be honest, the average programmer really is not that good. Which means I am always surprised anything works, and never surprised at the crap I see/use.

> 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.

Type erasure is a total waste, reify the type parameter. If you actually want type erasure then just use Object as the type, job done. As the Java Platform API and Scala have proven you have to do a lot of work to manage type parameter under type erasure. With type reification, erasure is just one model of use.

> 
[…]
-- 
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, 2014-12-06 at 07:33 -0800, H. S. Teoh via Digitalmars-d wrote:
> 
[…]
> 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...
> 
Exactly the opposite, the JVM and JIT technology is getting to the stage where boxing and hence unboxing happens less and less. For most computationally intensive tasks there will be no boxing and unboxing at all.

Currently I still have to use primitive types to get Java to be faster than C and C++, but there are hints that the next round of JIT technology and JVM improvements will make that unnecessary.

Of course there are elements in the JVM-verse who think that primitive types are the only way of doing this and that relying on JVM/JIT technology is anathema. This is still a moot point, no decisions as yet.

-- 
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 2014-12-05 03:39, deadalnix wrote:

> Also relevant:
> http://wiki.jetbrains.net/intellij/Developing_and_running_a_Java_EE_Hello_World_application

Haha, I saw how small the scroll bar was and didn't bother reading any more than the title.

-- 
/Jacob Carlborg

On Saturday, 6 December 2014 at 15:35:57 UTC, H. S. Teoh via Digitalmars-d wrote:
> 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

It the same approach taken by .NET, Eiffel and many other languages.

Just because it looks like an object to the eyes of the programmer, it doesn't mean it is one.

So when Java finally gets value types (either on 9 or 10 if the effort is too much), then primitives might become alias just like in .NET.

--
Paulo

On Saturday, 6 December 2014 at 09:07:34 UTC, Dmitry Olshansky wrote:
> 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

Scala tries to make things nicer by providing higher level abstractions but with tiny bit more poking JVM origins still are unpleasantly notable. The whole Function1 .. Function22 trait thing has made me laugh very hard when reading the spec originally :)

On Sunday, 7 December 2014 at 13:39:38 UTC, Dicebot wrote:
> On Saturday, 6 December 2014 at 09:07:34 UTC, Dmitry Olshansky wrote:
>> 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
>
> Scala tries to make things nicer by providing higher level abstractions but with tiny bit more poking JVM origins still are unpleasantly notable. The whole Function1 .. Function22 trait thing has made me laugh very hard when reading the spec originally :)

.NET is no different

http://msdn.microsoft.com/en-us/library/dd402872%28v=vs.110%29.aspx

This is what happens when generics don't support variable number of types.

--
Paulo

07-Dec-2014 16:39, Dicebot пишет:
> On Saturday, 6 December 2014 at 09:07:34 UTC, Dmitry Olshansky wrote:
>> 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
>
> Scala tries to make things nicer by providing higher level abstractions
> but with tiny bit more poking JVM origins still are unpleasantly
> notable.

It actually quite successful at making things more coherent and extensible (something directly opposite to original Java).

There are downsides, type erasure is the most unavoidable trait.

> The whole Function1 .. Function22 trait thing has made me laugh
> very hard when reading the spec originally :)

Aye. The good things is that while e.g. (Int,Int) has type Tuple2![Int,Int] it's at least compiler-generated.

-- 
Dmitry Olshansky

06-Dec-2014 18:33, H. S. Teoh via Digitalmars-d пишет:
> 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?

With great success.

> Sounds like I will never
> consider Java for computation-heavy tasks then...

Interestingly working with JVM for the last 2 years the only problem I've found is memory usage overhead of collections and non-trivial objects. In my tests performance of simple numeric code was actually better with Scala (not even plain Java) then with D (LDC), for instance.

-- 
Dmitry Olshansky

On Sunday, 7 December 2014 at 19:56:49 UTC, Dmitry Olshansky wrote:
> 06-Dec-2014 18:33, H. S. Teoh via Digitalmars-d пишет:
>> 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?
>
> With great success.
>
>> Sounds like I will never
>> consider Java for computation-heavy tasks then...
>
> Interestingly working with JVM for the last 2 years the only problem I've found is memory usage overhead of collections and non-trivial objects. In my tests performance of simple numeric code was actually better with Scala (not even plain Java) then with D (LDC), for instance.

Got an example? I'd be interested to see a numerical-code example where the JVM can beat the llvm/gcc backends on a real calculation (even if it's a small one).

On Sat, Dec 6, 2014 at 7:26 AM, Russel Winder via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
> Primitive types are scheduled for removal, leaving only reference types.
>
>
Are you referring to: http://openjdk.java.net/jeps/169 ?