www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Some features should NOT include from GO/Java.

reply Matthew Ong <ongbp yahoo.com> writes:
Hi All,

The reason I am starting this thread is to gather some valid/experience that
people do not like about using Go or even Java. Naturally D-programming might
not wants to repeat the same error.

Java:
1) Swing API --- The inheritance tree is too deep. New OO encourages
   flatten object (1-2 level inheritance) for easy memory management from the
JVM/GC.
2) final --- does not protect the content of the LinkedList/Hashmap.
   I think immutable keywords managed that? Informed me if I am wrong.
3) Do not have keywords to allow conditional compilation like version in D.
4) Threads are rather heavy and synchronization, that is why people introduced
   kilim. Something like the fiber-thread concept.
5) No marco-preprocessor like in C #define, when the limitations of the
   syntax is met. Sometime, that allows
6) No void* to allow passing of function pointer into any method to be
   called. That can be tricked:
   by using
   interface F1<R,P>{
    R func1(P p1);
   }
7) No closure...Or lamda J.
8) No clear IPC like COM+, DCOM. Need to do networks sockets with full stack
overheads.
9) GUI inter-component messaging is complex and can only do share memory.
   I hope that is defined with D. Yes, there MVC, but how to inter-comm
   without exposing too much info, there should be a way to do in-memory JMS
   model.


GO:
1) No while/do-while/foreach... ONLY for loop.
2) Only Public/private scope... That claim is semi-true.
   It allowed to have method introduction to a library defined type. And
   allows user of that type to use the new method without knowing.
3) there is no auto promotion of data type even when it is safe.
   int does not go into long automatically. byte to int...etc (Aiks!!!)

Both,
There is no way to have a centralized Exception handling routine that
allow routing of error message & filtering for both language like in the JSP.
JSP.

Over all, those are modeling issues that I do see.

Matthew Ong
ongbp yahoo.com
May 16 2011
parent reply Matthew Ong <ongbp yahoo.com> writes:
On 5/16/2011 10:37 PM, Matthew Ong wrote:

 Hi All,

 The reason I am starting this thread is to gather some valid/experience that
 people do not like about using Go or even Java. Naturally D-programming might
 not wants to repeat the same error.

 Java:
 1) Swing API --- The inheritance tree is too deep. New OO encourages
     flatten object (1-2 level inheritance) for easy memory management from the
 JVM/GC.




 2) final --- does not protect the content of the LinkedList/Hashmap.
     I think immutable keywords managed that? Informed me if I am wrong.




 3) Do not have keywords to allow conditional compilation like version in D.





 4) Threads are rather heavy and synchronization, that is why people introduced
     kilim. Something like the fiber-thread concept.



in some weaknesses of JVM and claimed to be addressed by Go(shown on a 
video) about using multi-threads for multi-core CPU. There is no built 
in Java standard Thread Pool Manager at the JVM level but left to the 
J2EE container to implements. J2EE is sometime too complex to junior 
developers and writing our own container is a hard thing.

I have seen in languages like prolog and perhaps others, that the thread
are managed with options, perhaps some sort of built in library that 
does seemed to allow management.

http://www.swi-prolog.org/man/threads.html
clicked on 8.7.2.


 5) No marco-preprocessor like in C #define, when the limitations of the
     syntax is met. Sometime, that allows



does allow me to define up to level of content of a class but is not 
class itself.

mixin template AType(T){ // but does not seems to allow me to inherit 
ClassC this level.
private:
    T value;
public:
    this(){...}
    void print(){...}
}

class ClassB : ClassC{ // ClassC Inheritance/Interface must only be done 
at this level?
    mixin AType!(string); // content
}

Perhaps I am missing something here.


 6) No void* to allow passing of function pointer into any method to be
     called. That can be tricked:
     by using
     interface F1<R,P>{
      R func1(P p1);
     }




 7) No closure...Or lamda J.




 8) No clear IPC like COM+, DCOM. Need to do networks sockets with full stack
 overheads.



C# does has that ability by nature. Java has to make use of JCom to 
bridge within windows. But RMI from java makes use of network sockets 
full stack. Since D is system level API, I am wondering if there is a 
solution?



 9) GUI inter-component messaging is complex and can only do share memory.
     I hope that is defined with D. Yes, there MVC, but how to inter-comm
     without exposing too much info, there should be a way to do in-memory JMS
     model.






 GO:
 1) No while/do-while/foreach... ONLY for loop.
 2) Only Public/private scope... That claim is semi-true.
     It allowed to have method introduction to a library defined type. And
     allows user of that type to use the new method without knowing.
 3) there is no auto promotion of data type even when it is safe.
     int does not go into long automatically. byte to int...etc (Aiks!!!)

 Both,
 There is no way to have a centralized Exception handling routine that
 allow routing of error message&  filtering for both language like in the JSP.
 JSP.

 Over all, those are modeling issues that I do see.

 Matthew Ong
 ongbp yahoo.com




-- 
Matthew Ong
email: ongbp yahoo.com
May 18 2011
parent reply Don <nospam nospam.com> writes:
Matthew Ong wrote:

 On 5/16/2011 10:37 PM, Matthew Ong wrote:

 Hi All,

 The reason I am starting this thread is to gather some 
 valid/experience that
 people do not like about using Go or even Java. Naturally 
 D-programming might
 not wants to repeat the same error.

 Java:
 1) Swing API --- The inheritance tree is too deep. New OO encourages
     flatten object (1-2 level inheritance) for easy memory management 
 from the
 JVM/GC.




 2) final --- does not protect the content of the LinkedList/Hashmap.
     I think immutable keywords managed that? Informed me if I am wrong.




 3) Do not have keywords to allow conditional compilation like version 
 in D.



 

 4) Threads are rather heavy and synchronization, that is why people 
 introduced
     kilim. Something like the fiber-thread concept.



 in some weaknesses of JVM and claimed to be addressed by Go(shown on a 
 video) about using multi-threads for multi-core CPU. There is no built 
 in Java standard Thread Pool Manager at the JVM level but left to the 
 J2EE container to implements. J2EE is sometime too complex to junior 
 developers and writing our own container is a hard thing.
 
 I have seen in languages like prolog and perhaps others, that the thread
 are managed with options, perhaps some sort of built in library that 
 does seemed to allow management.
 
 http://www.swi-prolog.org/man/threads.html
 clicked on 8.7.2.
 

 5) No marco-preprocessor like in C #define, when the limitations of the
     syntax is met. Sometime, that allows



 does allow me to define up to level of content of a class but is not 
 class itself.
 
 mixin template AType(T){ // but does not seems to allow me to inherit 
 ClassC this level.
 private:
    T value;
 public:
    this(){...}
    void print(){...}
 }
 
 class ClassB : ClassC{ // ClassC Inheritance/Interface must only be done 
 at this level?
    mixin AType!(string); // content
 }
 
 Perhaps I am missing something here.



You're missing string mixins (which are totally different from string 
mixins).


 

 6) No void* to allow passing of function pointer into any method to be
     called. That can be tricked:
     by using
     interface F1<R,P>{
      R func1(P p1);
     }




 7) No closure...Or lamda J.




 8) No clear IPC like COM+, DCOM. Need to do networks sockets with full 
 stack
 overheads.



 C# does has that ability by nature. Java has to make use of JCom to 
 bridge within windows. But RMI from java makes use of network sockets 
 full stack. Since D is system level API, I am wondering if there is a 
 solution?
 
 

 9) GUI inter-component messaging is complex and can only do share memory.
     I hope that is defined with D. Yes, there MVC, but how to inter-comm
     without exposing too much info, there should be a way to do 
 in-memory JMS
     model.



 
 

 GO:
 1) No while/do-while/foreach... ONLY for loop.
 2) Only Public/private scope... That claim is semi-true.
     It allowed to have method introduction to a library defined type. And
     allows user of that type to use the new method without knowing.
 3) there is no auto promotion of data type even when it is safe.
     int does not go into long automatically. byte to int...etc (Aiks!!!)

 Both,
 There is no way to have a centralized Exception handling routine that
 allow routing of error message&  filtering for both language like in 
 the JSP.
 JSP.

 Over all, those are modeling issues that I do see.

 Matthew Ong
 ongbp yahoo.com
May 20 2011
parent dennis luehring <dl.soluz gmx.net> writes:
Am 20.05.2011 12:39, schrieb Don:

 You're missing string mixins (which are totally different from string
 mixins).



links

"mixins" aka "string mixins"
http://www.digitalmars.com/d/2.0/mixin.html

template-mixin
http://www.digitalmars.com/d/2.0/template-mixin.html
May 20 2011