Will the failure of .NET kill Microsoft?
Chad Myers
"Jason Kratz" <e...@joes.com> wrote in message
news:aj1ge3$di7$1...@flood.xnet.com...
>
> "Chad Myers" <cmy...@N0.S.P4.M.austin.rr.com> wrote in message
> news:eB2j9I$PCHA.2576@tkmsftngp08...
> >
> >
> > This is very consistent with the rest of .NET, like I said.
> >
> > What about System.currentTimeMillis()? What the hell is that?
> >
>
> Its a class method to get the current time in milliseconds. That is
> difficult to grok?
Thank you, Capt. Obvious. But that wasn't what I was asking. I was
illustrating that the J2SE API is a cobbled mess and that for every
one inconsistency you might find in the .NET FCL, you can find 10
or more in the Java API, that was an example and I was asking why
they chose that over more standardized or consistent method naming
conventions. That is difficult to grok?
-c
John
"Anders Dahlberg" <andda71...@student.liu.tabort.se> wrote in message
news:aj15gs$1q9$1...@news.island.liu.se...
<snip>
> btw:
> * "Visual Studio" is still an IDE
> Compare Visual Studio to Eclipse,Netbeans,IDEA,etc and it will be
> "out-of-date" (where is the refactoring tools to name one thing?)
Where is the UML diagramming, database design tools and debugging tools in
Eclipse, Netbeans?
I have used Eclipse and it doesn't even come close to Visual
Studio.Net........yet......
Anders Dahlberg
> "Anders Dahlberg" <andda71...@student.liu.tabort.se> wrote in message
> news:aj15gs$1q9$1...@news.island.liu.se...
> <snip>
>
>>btw:
>>* "Visual Studio" is still an IDE
>>Compare Visual Studio to Eclipse,Netbeans,IDEA,etc and it will be
>>"out-of-date" (where is the refactoring tools to name one thing?)
>
>
> Where is the UML diagramming, database design tools and debugging tools in
> Eclipse, Netbeans?
All there...
(even though no self-respecting java programmer would use a database
design tool, if you're not talking about or-mapping though - which I
don't think... (?))
> I have used Eclipse and it doesn't even come close to Visual
> Studio.Net........yet......
Well, if you're never refactoring your code I can understand you (I does
that almost all the time - e.g. sometimes not any major refactorings,
instead maybe just changing a code block inside a method that have
growen to big to be a method of it's own etc etc)
--
When replying - ".tabort" is not needed
/Anders
Anders Dahlberg
You're problem lies in that you don't understand that
System.currentTimeMillis() has been in java since the beginning (e.g.
jdk1.0) - which was before the beans concept was introduced - thus no
"get" prefix - even though that method is *not* the preferred way of
using time functions:
E.g.
java.util.Calendar.getInstance().getTimeInMillis()
better?
Backward compability is *important*
Btw, any comment on that .NET still lacks app-servers?
> -c
tuttle
<snip>
> * Remove "delegate keyword" fluff that makes code harder to maintain
I agree that the delegate keyword is unnessecary. But it is not that
bad.
> * Remove "unsafe keyword" see above
Why? Most projects will never allow anybody to use the unsafe keyword,
so it does absolutely no harm. But if you want to do some low level
stuff, it is so much more convenient than JNI. I think we will see
device drivers and low level image manipulation methods written in C#.
You will never see any such thing in java.
> * Remove "structs" see above
I completely disagree. Structs are the only way to do something like
complex numbers effectively. And a programming language that does not
even allow you to define your own value types such as complex numbers
will (rightfully) be considered a joke by every c++ programmer. Did
you ever wonder why there is no "numerical recipes in java" despite
the huge popularity of java? That is why!
> * Remove "auto-boxing of primitives" see above
Auto-Boxing of primitives is extremely useful for using collections.
Being able to use integers directly as keys in a hashtable is
extremely useful. You might say that this is too complicated and leads
to errors, but then every single scripting language in the world is
too complicated. I have been teaching php classes, and I never, ever
found somebody who found associative arrays too complicated. Besides,
I do not want a programming language that has the basic assumption
that I do not know what I am doing. It should try to protect me from
errors, but not to the point where it is almost impossible to do what
I want.
> * Something similar to J2EE app-servers (á la transaction/security/etc
> framework *implementations*)
This has not been available when java 1.1 was released. It will be
available in no time at all. .NET has much better *infrastructure* for
powerful enterprise services than java has.
> * Standard organisation which everybody can join that handles the
> majority of the .NET platform (e.g. www.jcp.org)
I agree that microsoft should standardize more of the framework. But
ECMA is a much better standard institution than the jcp.
> * Similar open source offerings as those at jakarta.apache.org etc which
> provide alternative/new api's which you can use
There are plenty. I think that .NET will lead to a surge in open
source development, since .NET is so productive that you can write
very complex programs as a small team or even as an individual. Take a
look at SharpDevelop to see what a small, dedicated team can achieve
using c#. By the way: SharpDevelop performs *much better* than
JBuilder 6 on my older machine (K6-2 350Mhz, 196MB).
> * Less marketing, more *structured* documentation (á la
> http://java.sun.com/j2se/1.4.1/docs/api/index.html or www.dbdoc.org etc)
I agree completely.
> - no stupid ms windows help-program
Again, I agree. The java documentation is much better than the .NET
documentation.
> * Faster graphics performance, better/faster garbage collector,
Are you serious? Swing and Java2D is the slowest performing graphics
toolkit I ever saw. Just take a look at the absolutely horrible
graphics performance of JBuilder. This got a little bit better as of
java1.4, but it is still a disgrace.
> better/faster jit - all those three probably needs to be improved a lot
Have you ever tried .NET? I can see some room for improvement, but
especially the startup times are lightning fast compared to java. And
the execution speed is at the same level. And that with a much less
complicated and error-prone approach than hotspot.
> to come close to what is available in jre 1.4 today
> * Better IDE - Visual Studio doesn't even come close to IDEA in my
> opinion (e.g. refactoring, easy templates, easy key-shortcuts etc etc)
I agree that the interface is a bit cluttered. But the code completion
works really nice, and the debugger is excellent. The debugger is the
most important reason for me to use an IDE. Were it not for the
debugger, I would just keep using my favorite Text Editor.
You forgot to mention the lack of real layout management and the other
big deficits in Windows.Forms.
regards,
tuttle
John
"John" <ma...@easynet.nospamplz.co.uk> wrote in message
news:aiu9rn$aja$1...@reader1.tiscali.nl...
>
> "asj" <ka...@xxx.com> wrote in message news:3D5290...@xxx.com...
> <snip>
> >
> > ACTUAL usage...then j2ee on the server trumps .net on the server by a
> > VERY wide margin (maybe all those ASP sites won't upgrade after all? heh
> > heh, microsoft's nightmare).
> >
>
> URL to actual data, please.........?
>
Thought not.
John
> John wrote:
> > "Anders Dahlberg" <andda71...@student.liu.tabort.se> wrote in
message
> > news:aj15gs$1q9$1...@news.island.liu.se...
> > <snip>
> >
> >>btw:
> >>* "Visual Studio" is still an IDE
> >>Compare Visual Studio to Eclipse,Netbeans,IDEA,etc and it will be
> >>"out-of-date" (where is the refactoring tools to name one thing?)
> >
> >
> > Where is the UML diagramming, database design tools and debugging tools
in
> > Eclipse, Netbeans?
>
> All there...
>
> (even though no self-respecting java programmer would use a database
> design tool, if you're not talking about or-mapping though - which I
> don't think... (?))
>
URL to these?
tuttle
<snip>
> > horrible performance. In C# or C++ on the other hand, this is no big
> > deal. That is the reason Java3D is dead: It is just not possible to
> > write decent 3D applications in java.
>
>
> i think you'd better tell this to the many companies and organizations
> using java 3d:
> http://java.sun.com/products/java-media/3D/in_action/
Wow. That is a very impressive list (NOT). The number of people who
develop 3d applications using OpenGL/C++ or Direct3D/C++ would be a
few megabytes long.
You would be a lot more credible if you would agree that numerical
programming in java is impossible. A programming language that does
not let you define a complex number class is *not* a general purpose
programming language.
regards,
tuttle
tuttle
[snip]
> Look at System.IO.FileAttributes. Was that designed with any file systems
> other then the Windows ones in mind?
What is the problem? It has some members that are Windows specific
(e.g. FileAttributes.Offline), but it already has a member that is
Unix specific (FileAttributes.Device). AFAIK, there are no device
files in Windows.
They did not use the "lowest common denomitator" strategy, but that is
no big deal. If you want to program crossplatform, you simply only use
attributes that all filesystems have, e.g. ReadOnly etc.
The Windows.Forms namespace is much worse. The mono people have to
introduce the concept of handles just to implement Windows.Forms.
regards,
tuttle
asj
MORE than the total number of actual j2ee web apps right now? is that
what you're saying because you are obviously bonkers if you think this.
John wrote:
> >
>
> Thought not.
asj
i am all for open standards that benefit everyone (as opposed to
"standards" that benefit...microsoft)...btw, that list may not be as
long as for openGL, but i would not consider that "dead" by any sense of
the word.
organizations like the National Center for Supercomputing Applications
(NCSA) use java3D, which speaks for itself in terms of being capable
enough. it is also supported by the vendor whose standards gave way to
openGL.
also, there is work underway to "consolidate" and make sure the two
standards are compatible, which does not sound like vendors consider
java 3d to be "dead", but another competitive solution.
tuttle wrote:
> Wow. That is a very impressive list (NOT). The number of people who
> develop 3d applications using OpenGL/C++ or Direct3D/C++ would be a
> few megabytes long.
>
> regards,
>
> tuttle
tuttle
<snip>
> > .NET has a much cleaner API than the J2SE and J2EE apis which are,
> > at times completely inconsistent.
>
> In your opinion - Not in mine (e.g. System.Windows.Forms etc)
> For example: quick look at the msdn docs at System.Windows.Forms.Form
> (link at System.Windows.Forms frontpage) revealed a member called
> HScroll (e.g. in java a protected getProperty method as in getHScroll())
>
> Saved a couple of keystrokes there didn't they *sick*
>
I agree that the property should have been called HorizontalScroll.
But that is not that bad compared to the huge inconsistencies at the
*very* *core* classes of java. For example, the java.lang.Integer
class has constants MAX_VALUE and MIN_VALUE, which are the minimum and
maximum value an integer can have.
The class java.lang.Double also has two members MAX_VALUE and
MIN_VALUE, but the MIN_VALUE is the smallest *positive* number a
double can have. Stupid, isn't it? In .NET the constant for the
smallest possible positive number is called Epsilon, which makes a lot
more sense from a math point of view.
And this is only one of many examples for bad API design.
regards,
tuttle
Anders Dahlberg
> "Anders Dahlberg" <andda71...@student.liu.tabort.se> wrote in message
> news:aj2vg1$fjc$1...@news.island.liu.se...
>
>>John wrote:
>>
>>>"Anders Dahlberg" <andda71...@student.liu.tabort.se> wrote in
>>
> message
>
>>>news:aj15gs$1q9$1...@news.island.liu.se...
>>><snip>
>>>
>>>>btw:
>>>>* "Visual Studio" is still an IDE
>>>>Compare Visual Studio to Eclipse,Netbeans,IDEA,etc and it will be
>>>>"out-of-date" (where is the refactoring tools to name one thing?)
>>>
>>>
>>>Where is the UML diagramming, database design tools and debugging tools
>>
> in
>
>>>Eclipse, Netbeans?
>>
>>All there...
>>
>>(even though no self-respecting java programmer would use a database
>>design tool, if you're not talking about or-mapping though - which I
>>don't think... (?))
>>
>
>
> URL to these?
UML:
http://www.eclipse.org
http://www.rational.com/products/xde/javaed/index.jsp
http://www.eclipse.lu/jsp/plugin_detail.jsp?cat=30&id=59
...and many more (if you know how to browse the web, try a google
search!)
http://www.netbeans.org
http://www.gentleware.de/products/poseidonCE.php3
http://www.embarcadero.com/products/describe/index.asp
...and many more (if you know how to browse the web, try a google
search!)
Debugging:
http://www.eclipse.org
http://www.geocities.com/ceperez/eclipsedebugginwebservice_viewlet_swf.html
(eclipse webservice debugging demonstration)
http://www.netbeans.org
http://www.netbeans.org/about/ide/quicktour/debug.html
"Database design":
see or-mapping (try google)
Refactoring:
http://www.eclipse.org
http://www.netbeans.org
http://www.refactorit.com/
So where's the url to the supposed (probably non-existent) Visual Studio
uml, debuggin, refactoring, etc tools?
Have fun now...
Cameron Purdy
> most java techs were available in other languages
> even copied MS's MTS, ASP,ODBC to java equivalents
ASP and ODBC (JSP and JDBC) were started as copies. No doubt. The specs for
JDBC even said so. Those are good examples of "hugging and inheriting from".
The MTS and COM+ claims (see objectwatch.com for a sourpuss on this topic)
are a bit bogus. Microsoft was about 10 years behind on transaction managers
and distributed programming, including distributed transactions. JTS was a
direct map of OTS (CORBA), which (whether or not you like it) ran probably
90% to 95% of distributed transactions before J2EE came along. Actually,
it's not quite true to say that CORBA was running those, since most of the
TMs were pre-existing products that added CORBA interop, but they were
definitely in the CORBA camp, and that's the market that J2EE was targeting
to capture.
Peace,
Cameron Purdy
Tangosol, Inc.
.NET to J2EE porting service available
"Stefan Demetz" <st...@talk.com add 21 to talk> wrote in message
news:O#k5452PCHA.2696@tkmsftngp13...
>
Cameron Purdy
Just to be clear, there were a lot of people that claimed that VB was a
superior technology in 1996. I don't remember if you were one of them, but
it wouldn't surprise me. Building a limited proprietary toolset and runtime
that works only on Windows and is designed to script Office applications has
never been hard for Microsoft, apparently.
Peace,
Cameron Purdy
Tangosol, Inc.
.NET to J2EE porting service available
"tuttle" <mrwro...@yahoo.com> wrote in message
news:1006f17d.02080...@posting.google.com...
>
Cameron Purdy
> illustrating that the J2SE API is a cobbled mess and that for every
> one inconsistency you might find in the .NET FCL, you can find 10
> or more in the Java API
Makes you mad, doesn't it, that so many more people still prefer Java and
companies have no desire to do enterprise development in .NET?
Thankfully the typical CTO isn't as easily swayed by such simple and shallow
trivialities as you are. Otherwise companies would be re-implementing
entirely in Flash.
Peace,
Cameron Purdy
Tangosol, Inc.
.NET to J2EE porting service available
"Chad Myers" <cmy...@N0.SP.4M.austin.rr.com> wrote in message
news:x6059.61003$Yd.30...@twister.austin.rr.com...
>
Chad Myers
Sounds like you need add-ins to do most of it. How is this different
from Visual Studio? Visual Studio has more built-in than do the
aforementioned
IDEs, it seems.
You are a troll and are clueless, but here you go:
(URLS will probably wrap)
Application Design Modeling:
http://msdn.microsoft.com/vstudio/techinfo/articles/developerproductivity/mo
delsoftware.asp
Enterprise Templates:
http://msdn.microsoft.com/vstudio/techinfo/articles/developerproductivity/ef
t.asp
Database/Object-relational Modeling:
http://msdn.microsoft.com/vstudio/techinfo/articles/developerproductivity/or
m.asp
XML Web Services Design:
http://msdn.microsoft.com/vstudio/techinfo/articles/XMLwebservices/webservic
es.asp
Server Component RAD:
http://msdn.microsoft.com/vstudio/techinfo/articles/servers/radserver.asp
Multiple language unified IDE (without plugins):
http://msdn.microsoft.com/vstudio/techinfo/articles/developerproductivity/pr
oductivity.asp
Web Forms Designer and drag-and-drop componentized development:
http://msdn.microsoft.com/vstudio/techinfo/articles/clients/webforms.asp
Application performance testing and profiling:
http://msdn.microsoft.com/vstudio/techinfo/articles/developerproductivity/ap
ptesting.asp
Orchestrate business processes using BizTalk (plug-in):
http://msdn.microsoft.com/downloads/sample.asp?url=/msdn-files/027/001/870/m
sdncompositedoc.xml
Just to name a few
-c
Anders Dahlberg
> Anders Dahlberg <andda71...@student.liu.tabort.se> wrote in message news:<aj177m$26v$1...@news.island.liu.se>...
<snip>
>>* Remove "unsafe keyword" see above
>
> Why?
Look at the example ms gave to why unsafe code is needed - it *will* be
abused
> Most projects will never allow anybody to use the unsafe keyword,
> so it does absolutely no harm. But if you want to do some low level
> stuff, it is so much more convenient than JNI.
Yes, *much* more convenient which is exactly my point - it *will* be
abused by morons that think they'll get better "performance" by writing
most of their code in unsafe blocks *sigh*
Simple != better
> I think we will see
> device drivers and low level image manipulation methods written in C#.
Which imo is bad idea (use the correct tool for every problem, in the
above I would use C)
> You will never see any such thing in java.
Which is a good thing (even though "device drivers" exists in a more
pure form as jini devices)
>>* Remove "structs" see above
>
> I completely disagree. Structs are the only way to do something like
> complex numbers effectively. And a programming language that does not
> even allow you to define your own value types such as complex numbers
> will (rightfully) be considered a joke by every c++ programmer.
I agree with your last part (c++ programmers etc), but totally not with
your former - I agree that you *probably* need something like value
types to do efficient complex computations.
*But* my point is that .NET structs is a *very* poor implementation as
they are *far* to "look-a-like" with normal classes to not be abused.
If they redo the structs so that they become totally different in syntax
(as their use is totally different from normal references/classes), then
I'm ok with their inclusion.
Maybe some sort of compiler enforced naming convention + "as struct"
extension? lower case and "as struct" added for clearity?
E.g.
point position = point(5,4) as struct; // or similar
// very clear that the argument is passed as value
doSomething(position as struct);
public void doSomething(point pos as struct) { // very easy to spot
pos.x += 5;
pos.y += 3;
}
> Did
> you ever wonder why there is no "numerical recipes in java" despite
> the huge popularity of java? That is why!
Maybe - but I'm arguing against the structs (value objects)
implementation in .NET
>>* Remove "auto-boxing of primitives" see above
>
> Auto-Boxing of primitives is extremely useful for using collections.
new Integer(4) - very easy...
> Being able to use integers directly as keys in a hashtable is
> extremely useful.
Don't see your point here
> You might say that this is too complicated and leads
> to errors,
Exactly, and confusion as it leads to the same problem as the structs
.NET implementation - It's not evident that integers by design is
value-objects not reference!
> but then every single scripting language in the world is
> too complicated. I have been teaching php classes, and I never, ever
> found somebody who found associative arrays too complicated.
I'm not saying it's too complicated - I'm saying it's messy.
Look at for example ada for a strict clean language. (a bit too strict
IMHO though ;) Very easy to maintain, very "hard" to write (if you find
getting compiler errors "hard").
Where as python/ruby/perl is exactly the opposite - very easy to write,
harder to maintain.
IMO Java has got a very good mix of ada and python, detailed compiler
warnings but still not to rigid.
And I think structs and auto-boxing of primitives make .NET languages
(atleast C#) end up in the python/ruby/perl category without any of
their quick writing skills (e.g. C# got no blocks, less powerful
properties, no lambda etc etc)
> Besides,
> I do not want a programming language that has the basic assumption
> that I do not know what I am doing.
Then you really should stay as far away from Ada as you can ever get :)
I like that the compiler help's me from obvious problems (doesn't have
to "errors" - detecting "bad code" is just as important, and yes - I
hate the overloaded + operator for java Strings)
> It should try to protect me from
> errors, but not to the point where it is almost impossible to do what
> I want.
That depends on *what* you want - if you want to see code written as
below (e.g. 90% off all your felow employees that are fresh out of
school with no experience), be my guest:
List integers5 = ...
List integers4 = ...
List integers3 = ...
List integers2 = ...
// Could even be a linked list implementation - hua :(
List integers1 = ...
List list = new ArrayList();
for (int i = 0; i < ITERATIONS; i++) {
list.add(integers5.get(i)*5 + integers4.get(i)*4 +
integers3.get(i)*3 + integers2.get(i)*2 + integers1.get(i));
}
Where you'll *a lot* of auto-boxing to and from and it won't be obvious
(to your fellow inexperienced developers) that's it's a performance
nightmare.
>>* Something similar to J2EE app-servers (á la transaction/security/etc
>>framework *implementations*)
>
> This has not been available when java 1.1 was released. It will be
> available in no time at all.
True, but you did ask what additional things...?
I'm just giving my opinions on what *I* would want before I considered
using .NET
> .NET has much better *infrastructure* for
> powerful enterprise services than java has.
In your opinion, not in the opinion of the enterprise experts at
www.theserverside.com (who have actuall enterprise experience - e.g.
*scaling* big time - not necessarily response time)
>>* Standard organisation which everybody can join that handles the
>>majority of the .NET platform (e.g. www.jcp.org)
>
> I agree that microsoft should standardize more of the framework. But
> ECMA is a much better standard institution than the jcp.
Well, depends - it's an international standard if that what's you mean?
But my main point is that jcp allows *everybody* to participate and
discuss *all of* java - I would like .NET to have something similar
<snipped point about open source as I don't find it such a big deal that
.NET's support will take some time before it matches java's>
<snipped docs where we agreed>
>>* Faster graphics performance, better/faster garbage collector,
>
> Are you serious? Swing and Java2D is the slowest performing graphics
> toolkit I ever saw.
Java2D is dead fast - hardware accelerated, swing is slow if you write
it slow (it's not easy to write good performance gui-apps - I agree with
that)
> Just take a look at the absolutely horrible
> graphics performance of JBuilder. This got a little bit better as of
> java1.4, but it is still a disgrace.
Well, look at jedit, jdiskreport or others to see Swing performing good.
Try to write a 2d scroller game in java and C# today and compare the
results (I haven't got time for that)
>>better/faster jit - all those three probably needs to be improved a lot
>
> Have you ever tried .NET?
Yes.
> I can see some room for improvement, but
> especially the startup times are lightning fast compared to java.
Yes, I agree
> And
> the execution speed is at the same level.
I don't agree, as java jitters got a lot more features than what the
.NET one got today (ask eric gunnarson if you don't believe me, e.g.
recompiling after newly loaded class, optimizing etc etc)
> And that with a much less
> complicated and error-prone approach than hotspot.
Maybe - don't know exactly how any of them work/ are implemented - do
you? (I'm interested)
>>to come close to what is available in jre 1.4 today
>>* Better IDE - Visual Studio doesn't even come close to IDEA in my
>>opinion (e.g. refactoring, easy templates, easy key-shortcuts etc etc)
>
> I agree that the interface is a bit cluttered. But the code completion
> works really nice, and the debugger is excellent. The debugger is the
> most important reason for me to use an IDE. Were it not for the
> debugger, I would just keep using my favorite Text Editor.
Refactoring is my favourite today, followed close by code completion and
debugging on shared second.
> You forgot to mention the lack of real layout management and the other
> big deficits in Windows.Forms.
Haven't written more than one Windows.Forms program (hello world in
title with out any buttons ;)
>
> regards,
>
> tuttle
Nice to talk about how to improve something instead of bashing on what
already exists!
Chad Myers
> Chad Myers wrote:
> > "Jason Kratz" <e...@joes.com> wrote in message
> > news:aj1ge3$di7$1...@flood.xnet.com...
> >
> >>"Chad Myers" <cmy...@N0.S.P4.M.austin.rr.com> wrote in message
> >>news:eB2j9I$PCHA.2576@tkmsftngp08...
> >>
> >>>
> >>>This is very consistent with the rest of .NET, like I said.
> >>>
> >>>What about System.currentTimeMillis()? What the hell is that?
> >>>
> >>
> >>Its a class method to get the current time in milliseconds. That is
> >>difficult to grok?
> >
> >
> > Thank you, Capt. Obvious. But that wasn't what I was asking. I was
> > illustrating that the J2SE API is a cobbled mess and that for every
> > one inconsistency you might find in the .NET FCL, you can find 10
> > or more in the Java API, that was an example and I was asking why
> > they chose that over more standardized or consistent method naming
> > conventions. That is difficult to grok?
>
> You're problem lies in that you don't understand that
> System.currentTimeMillis() has been in java since the beginning (e.g.
> jdk1.0) - which was before the beans concept was introduced - thus no
> "get" prefix - even though that method is *not* the preferred way of
> using time functions:
I'm well aware of its history, however this doesn't provide a valid
excuse as to why the J2API is littered with obsolete kick-backs like
this and only lends further credence to my argument that the J2API
is far more inconsistent than the .NET FCL API. You have yet to
refute that.
> E.g.
>
> java.util.Calendar.getInstance().getTimeInMillis()
>
> better?
>
> Backward compability is *important*
>
> Btw, any comment on that .NET still lacks app-servers?
This is an invalid question because .NET isn't set up like
J2EE to require an app-server. IIS is the app server which
supports more than most J2EE app servers support.
(IIS + COM+ + MSMQ + MSDTC + .NET + WLB + MSCS + ADO.NET) >
J2EE APP SERVERs
-c
Anders Dahlberg
> tuttle wrote:
>
>> Anders Dahlberg <andda71...@student.liu.tabort.se> wrote in
>> message news:<aj177m$26v$1...@news.island.liu.se>...
<snip>
> *But* my point is that .NET structs is a *very* poor implementation as
> they are *far* to "look-a-like" with normal classes to not be abused.
>
> If they redo the structs so that they become totally different in syntax
> (as their use is totally different from normal references/classes), then
> I'm ok with their inclusion.
>
> Maybe some sort of compiler enforced naming convention + "as struct"
> extension? lower case and "as struct" added for clearity?
> E.g.
> point position = point(5,4) as struct; // or similar
>
> // very clear that the argument is passed as value
> doSomething(position as struct);
>
>
> public void doSomething(point pos as struct) { // very easy to spot
> pos.x += 5;
> pos.y += 3;
> }
>
dOOh, now even I have troubles with the struct mess *sigh*
Anders Dahlberg
<snip some largely strange evidence that java IDE's got less features than
.NET Visual Studio because Visual Studio also got the features java
IDE's got
except refactoring though, ehrm - wait a minute?>
>
> Just to name a few
So, Visual Studio *almost* got all the features java IDE's got (with or
without plugins which was not the question)? That's great...
Should we continue with this strange discussion any longer or have I
proven my point that Visual Studio (In my and many others opinion) in no
way is any better than current java IDE's?
> -c
Anders Dahlberg
> "Anders Dahlberg" <andda71...@student.liu.tabort.se> wrote in message
> news:aj2vph$fje$1...@news.island.liu.se...
>>You're problem lies in that you don't understand that
>>System.currentTimeMillis() has been in java since the beginning (e.g.
>>jdk1.0) - which was before the beans concept was introduced - thus no
>>"get" prefix - even though that method is *not* the preferred way of
>>using time functions:
>
>
> I'm well aware of its history, however this doesn't provide a valid
> excuse as to why the J2API is littered with obsolete kick-backs like
> this and only lends further credence to my argument that the J2API
> is far more inconsistent than the .NET FCL API.
repeat:
"Backwards compatibility is *important*"
a hundred times or so until you get it...
> You have yet to
> refute that.
I've already done that (IMO)
>>E.g.
>>
>>java.util.Calendar.getInstance().getTimeInMillis()
>>
>>better?
>>
>>Backward compability is *important*
>>
>>Btw, any comment on that .NET still lacks app-servers?
>
>
> This is an invalid question because .NET isn't set up like
> J2EE to require an app-server.
Ahh, so you can't use .NET in enterprise scenarios then?
> IIS is the app server which
> supports more than most J2EE app servers support.
No, IIS is a webserver with some *few* app-server features.
And judging by IIS security history (or not, as that maybe ain't fare?)
consider a big enterprise that want's to have their mission critical
services running on something as an app-server and due to security
reasons only want to run something a kin to an EJB-server (e.g. no
webserver, no extra service etc etc).
How would they do that with .NET?
>
> (IIS + COM+ + MSMQ + MSDTC + .NET + WLB + MSCS + ADO.NET) >
> J2EE APP SERVERs
So, take IIS out of the picture - where are you then? (and add things as
clustering etc etc)
Chad Myers
> Chad Myers wrote:
> > "Anders Dahlberg" <andda71...@student.liu.tabort.se> wrote in
message
> > news:aj3bi2$itn$1...@news.island.liu.se...
> <snip some largely strange evidence that java IDE's got less features than
> .NET Visual Studio because Visual Studio also got the features java
> IDE's got
> except refactoring though, ehrm - wait a minute?>
Thanks for snipping out the relevant parts, misquoting me, and them
ignorantly mis-summarizing my comments.
VS.NET does not have Refactoring, but then, VS.NET has many features which
most Jave IDEs don't have built in. VS.NET can have refactoring with
plug-ins,
and so the Java IDEs can have some of VS.NET's functionality with plug-ins.
The fact is, out of the box, VS.NET ships with many more features than
the Java IDEs do.
>
> >
> > Just to name a few
> So, Visual Studio *almost* got all the features java IDE's got (with or
> without plugins which was not the question)? That's great...
With no plug-ins, VS.NET beats all the Java IDEs in functionality.
With Plug-ins, Java IDEs approach VS.NET, but still, it's a cobbled
mess of inconsistent and largely incompatible plug-ins.
-c
Chad Myers
> Chad Myers wrote:
> > "Anders Dahlberg" <andda71...@student.liu.tabort.se> wrote in
message
> > news:aj2vph$fje$1...@news.island.liu.se...
> <snip>
>
> >>You're problem lies in that you don't understand that
> >>System.currentTimeMillis() has been in java since the beginning (e.g.
> >>jdk1.0) - which was before the beans concept was introduced - thus no
> >>"get" prefix - even though that method is *not* the preferred way of
> >>using time functions:
> >
> >
> > I'm well aware of its history, however this doesn't provide a valid
> > excuse as to why the J2API is littered with obsolete kick-backs like
> > this and only lends further credence to my argument that the J2API
> > is far more inconsistent than the .NET FCL API.
>
> repeat:
>
> "Backwards compatibility is *important*"
> a hundred times or so until you get it...
I get it, and it's a valid statement, but you seem to forget what
we were originally debating. Let me remind you for the fourth time.
You stated that the J2API was more consistent than the FCL, which is
patently false and this is but one example. You continually try to
distract from this fact by throwing out non-sequitors like
"backwards compatibility is *important*".
Who cares, that's irrelevant to this discussion. That backwards
compatibility causes inconsistencies which makes the J2API, as
I've said now several times, inconsistent.
Thus, by not debating the original point, you admit that the
J2API is less consistent than the .NET FCL API and you were
either lying or wrong when you said it wasn't.
-c
Anders Dahlberg
> "Anders Dahlberg" <andda71...@student.liu.tabort.se> wrote in message
> news:aj3ek6$l5m$1...@news.island.liu.se...
>
>>Chad Myers wrote:
>>
>>>"Anders Dahlberg" <andda71...@student.liu.tabort.se> wrote in
>>
> message
>
>>>news:aj3bi2$itn$1...@news.island.liu.se...
>>
>><snip some largely strange evidence that java IDE's got less features than
>> .NET Visual Studio because Visual Studio also got the features java
>>IDE's got
>>except refactoring though, ehrm - wait a minute?>
>
>
> Thanks for snipping out the relevant parts,
> misquoting me,
Didn't quote you at all above...
> and them
> ignorantly mis-summarizing my comments.
*"evidence that java IDE's got less features than
.NET Visual Studio because Visual Studio also got the features java
IDE's got except refactoring though"
* You provided implied
E.g. you shoved nothing that Java IDE's doesn't have, but you didn't
show any refactoring for Visual Studio (yes, it will come later - but
the point was *today*). E.g. what did you show exactly? My conclusion:
Visual Studio got a subset of the features Java IDE's got today
(mathematics 101).
Strangely I got somewhat of a "deja-vú" (or similar - my french aren't
that good ;) fealing now...
> VS.NET does not have Refactoring, but then, VS.NET has many features which
> most Jave IDEs don't have built in.
But as you conveniently snipped: that doesn't matter at all,
let me put it this way instead: "Visual Studio is bloated due to it
having a lot of extra fluff in it that would be better of as plugins"
(this is not my feelings on it though, just a twist on your argument)
> VS.NET can have refactoring with
> plug-ins,
> and so the Java IDEs can have some of VS.NET's functionality with plug-ins.
Java IDE's can also (and have *today*) *all of* and *more* features than
Visual Studio got...
>
> The fact is, out of the box, VS.NET ships with many more features than
> the Java IDEs do.
>
>
>>>Just to name a few
>>
>>So, Visual Studio *almost* got all the features java IDE's got (with or
>>without plugins which was not the question)? That's great...
>
>
> With no plug-ins, VS.NET beats all the Java IDEs in functionality.
Nah, still no refactoring (yes, I'm addicted - so will you be once you
start using it)...
> With Plug-ins, Java IDEs approach VS.NET, but still, it's a cobbled
> mess of inconsistent and largely incompatible plug-ins.
Ahh, now you're doing it again: bashing java without proff just based on
your (and seamingly very few others) personal opinions. E.g. you have
probably not even looked at the webservice debugging viewlet I provided
a link to.
tuttle
<snip>
Why are you ignoring my main complaint about java, namely that it is
impossible to write efficient value type classes such as complex
numbers?
You probably think that complex numbers and vectors are an obscure and
seldom-used concept, but you are in for a surprise if you ever do some
scientific computing. You can not even write decent image manipulation
programs without complex numbers.
Courageous
>Wow. That is a very impressive list (NOT).
Agree. Java/3d has a lonnng way to go.
>You would be a lot more credible if you would agree that numerical
>programming in java is impossible.
Eh? Tell that to Java Grande.
C//
Courageous
>"Backwards compatibility is *important*"
>a hundred times or so until you get it...
I find this whole sentiment to be wildly ironic. M$ basically liked
Java when it first came out, mostly because they found a great way
to make sure that they were backward compatible with their _VERY
EXTENSIVE_ component library (read: J/Direct). But Sun struck out
at the whole affair, assuring that M$ could NOT be backward compatible
with this prior base, which I might add, includes a simply enormous body
of 3rd party software.
Yes, backward compatibility is important. Like, duh. Now you know why
.net actually exists.
C//
Anders Dahlberg
> "Anders Dahlberg" <andda71...@student.liu.tabort.se> wrote in message
> news:aj3f2v$l5p$1...@news.island.liu.se...
>
>>Chad Myers wrote:
>>
>>>"Anders Dahlberg" <andda71...@student.liu.tabort.se> wrote in
>>
> message
>
>>>news:aj2vph$fje$1...@news.island.liu.se...
>>
>><snip>
>>
>>>>You're problem lies in that you don't understand that
>>>>System.currentTimeMillis() has been in java since the beginning (e.g.
>>>>jdk1.0) - which was before the beans concept was introduced - thus no
>>>>"get" prefix - even though that method is *not* the preferred way of
>>>>using time functions:
>>>
>>>
>>>I'm well aware of its history, however this doesn't provide a valid
>>>excuse as to why the J2API is littered with obsolete kick-backs like
>>>this and only lends further credence to my argument that the J2API
>>>is far more inconsistent than the .NET FCL API.
>>
>>repeat:
>>
>>"Backwards compatibility is *important*"
>>a hundred times or so until you get it...
>
>
> I get it, and it's a valid statement, but you seem to forget what
> we were originally debating.
Nope, we (I and most others in this part of the thread) are discussing:
"Oh shit. I did not notice that I crossposted to
comp.lang.java.advocacy. People in this group will probably not agree
with me :-) But just assume for a moment that .NET is the superior
technology compared to the Java platform. What additional things need
to happen in order for you to consider using it?
regards,
tuttle"
> Let me remind you for the fourth time.
Strange - you keep reminding *me* on what we're discussion when you even
can't keep up with what we're *actually* discussing?
> You stated that the J2API was more consistent than the FCL,
You conveniently left of something important: IMO
E.g. (if your memory is bad):
"* Cleaner api (no lsz etc stupid variabel names etc, addActionListener
wanted etc) "
and later
">.NET's FCL is far cleaner and more
>consistent than Java's.
In your opinion - not in mine... "
I've never claimed that FCL was less consistent than java api's..
> which is
> patently false and this is but one example.
You're either lying again ("proved" earlier with your problems with
keeping up with peoples opinions about mozilla stability) or you have
gotten things severly messed up.
> You continually try to
> distract from this fact by throwing out non-sequitors like
> "backwards compatibility is *important*".
What f*cking fact? You still haven't provided any "facts" - just your
own opinions! And yes, compatibility *is* important
>
> Who cares, that's irrelevant to this discussion.
No shit! You're entire post was irrelevant IMO
> That backwards
> compatibility causes inconsistencies which makes the J2API, as
> I've said now several times, inconsistent.
*IN YOUR OPINION*, I have no trouble avoiding use of deprecated or old
methods as I almost never code without access to required javadoc's
> Thus, by not debating the original point,
Which you are having trouble with
> you admit that the
> J2API is less consistent than the .NET FCL API and you were
> either lying or wrong when you said it wasn't.
Now, you're lying *again*
*I've never claimed that FCL was less consistent than java api's..*
And I don't even care if it was!
But still you snipped the part about .NET app-servers, found any yet?
(which btw was what I were discussing with you about - but you seem to
keep getting distracted by your imaginative other topics we are discussing!)
Anders Dahlberg
>>"Backwards compatibility is *important*"
>>a hundred times or so until you get it...
>
>
> I find this whole sentiment to be wildly ironic. M$ basically liked
> Java when it first came out, mostly because they found a great way
> to make sure that they were backward compatible with their _VERY
> EXTENSIVE_ component library (read: J/Direct).
Yes, very much so!
> But Sun struck out
> at the whole affair, assuring that M$ could NOT be backward compatible
> with this prior base, which I might add, includes a simply enormous body
> of 3rd party software.
Yes they could and that wasn't the problem...
Why do so many in these groups keep posting stuff as this without any
reason except making Sun look bad? Why not post stuff that's actually
true about Sun instead of these badly put lies with grains of truth in
them?
MS Made a "java" clone that didn't include rmi among other things and
had extra keywords as "delegate" etc that wasn't in the *java*
specification!
history 101 again I guess...
>
> Yes, backward compatibility is important. Like, duh.
Exactly my point!
> Now you know why
> .net actually exists.
There is probably more reasons than backward compatibility that
justifies .NET existens though
(otherwise I believe .NET being in big problems?)
> C//
Anders Dahlberg
> Courageous wrote:
>
>
> Yes they could and that wasn't the problem...
> Why do so many in these groups keep posting stuff as this without any
> reason except making Sun look bad? Why not post stuff that's actually
> true about Sun instead of these badly put lies with grains of truth in
> them?
>
Why posting lies about Sun, when there (most likely) exists true things
that accomplish the same thing?
This just makes people posting things like Courageous (no offense please
as I'm sure you didn't mean it anyway - just a random troll :) look
"stupid"?
The Ghost In The Machine
<cpu...@tangosol.com>
wrote
on Sat, 10 Aug 2002 11:57:08 -0400
<#lWQzZIQCHA.2456@tkmsftngp10>:
>> I think we can all agree that .NET is a superior technology.
>
> Just to be clear, there were a lot of people that claimed that VB was a
> superior technology in 1996.
It might be a superior technology for writing Basic code. :-)
However, I find Tcl a little more comprehensible (if a lot
stupider -- but the beauty of Tcl is that anyone can integrate
into it using fairly simple C). Of course Tcl != Java; Java has
even more capabilities than Tcl. Java (and Tcl) could use a
command processor with history a la Motif, although one can
hack up something using StringTokenizer and a List widget
in a pinch. Java could also use select(), although I've
not studied the java.nio.* hierarchy in 1.4.
But Java makes an excellent, if heavy, server language; Tcl
is a little too bare-bones protection wise. I don't know
how well Tcl defends against such things as buffer overflow
concerns -- a lot of nasties gain control that way.
And Visual Basic? Well, I do wonder how well those IIS/ASP
servers work at times. :-) But Nimda seems to have their
number if they're not patched.
> I don't remember if you were one of them, but
> it wouldn't surprise me. Building a limited proprietary
> toolset and runtime that works only on Windows and is
> designed to script Office applications has
> never been hard for Microsoft, apparently.
From the looks of it, it's a proven moneymaker. :-)
Of course, I'm not sure if that tells us more about
Microsoft being good at making money -- or us for
buying Microsoft stuff so that they can make money.
[.sigsnip]
--
#191, ewi...@earthlink.net
It's still legal to go .sigless.
-glenn-
-glenn-
"asj" <ka...@xxx.com> wrote in message news:3D5525...@xxx.com...
tuttle
[snip]
> >You would be a lot more credible if you would agree that numerical
> >programming in java is impossible.
>
> Eh? Tell that to Java Grande.
>
The java grande forum has been pushing for *years* for the inclusion
of some kind of value types into java. Without success, so far. So
much for the java community process.
I am certain that many of the java grande participants will jump ship
and switch to c# since it gives them the extensions they want.
regards,
tuttle
petilon
mrwro...@yahoo.com says...
>
>The java grande forum has been pushing for *years* for the inclusion
>of some kind of value types into java. Without success, so far. So
>much for the java community process.
>
>I am certain that many of the java grande participants will jump ship
>and switch to c# since it gives them the extensions they want.
>
Yeah, read about value types and those other extensions here:
http://www.geocities.com/csharpfaq
tuttle
> tuttle wrote:
> > Anders Dahlberg <andda71...@student.liu.tabort.se> wrote in message news:<aj177m$26v$1...@news.island.liu.se>...
>
> <snip>
> >>* Remove "unsafe keyword" see above
> >
> > Why?
>
> Look at the example ms gave to why unsafe code is needed - it *will* be
> abused
>
applications to be executed. So software makers will do everything
possible to avoid unsafe code, just like EJB coders may not use some
features (e.g. direct IO, threads).
> > Most projects will never allow anybody to use the unsafe keyword,
> > so it does absolutely no harm. But if you want to do some low level
> > stuff, it is so much more convenient than JNI.
>
> Yes, *much* more convenient which is exactly my point - it *will* be
> abused by morons that think they'll get better "performance" by writing
> most of their code in unsafe blocks *sigh*
>
People who do this will have the problem that their programs will not
run on most corporate networks => lost revenues.
> Simple != better
>
So you think we should make everything more complicated so that only
excellent developers use low level stuff?
> > I think we will see
> > device drivers and low level image manipulation methods written in C#.
> Which imo is bad idea (use the correct tool for every problem, in the
> above I would use C)
Are buffer overruns and memory holes in device drivers less critical
than in applications? Definitely not. I agree that the very low level
stuff such as the microkernel is probably best written in C. But the
more high-level parts of an operating system could benefit a lot from
a higher level language such as java or c#.
> > You will never see any such thing in java.
> Which is a good thing (even though "device drivers" exists in a more
> pure form as jini devices)
>
Unfortunately, I do not know anything about jini. But it seems that it
did not catch on. It was really hyped three years ago, and now things
calmed down quite a bit.
> >>* Remove "structs" see above
> >
> > I completely disagree. Structs are the only way to do something like
> > complex numbers effectively. And a programming language that does not
> > even allow you to define your own value types such as complex numbers
> > will (rightfully) be considered a joke by every c++ programmer.
> I agree with your last part (c++ programmers etc), but totally not with
> your former - I agree that you *probably* need something like value
> types to do efficient complex computations.
>
You *definitely* need some kind of value types to do efficient complex
or vector calculations, at least with current processors. Just think
about the cache consistency issues: An array of complex numbers in C#
is a single, non-fragmented block of memory. An array of complex
numbers in java would be an array of pointers and a huge number of
totally fragmented, tiny objects on the heap. The performance would be
horrible, that is why nobody is using java for this kind of stuff.
> *But* my point is that .NET structs is a *very* poor implementation as
> they are *far* to "look-a-like" with normal classes to not be abused.
>
In most cases normal developers will derive their classes from classes
defined in the framework or in some libraries. Since you can not
derive from structs, the probability that someone will use a struct
when he wants a class is almost nil.
Writing good and easy to use libraries in C# requires a programmer
that understands the difference between structs and classes. *Using*
these libraries is much simpler and does not require big skills.
That is similar to c++: Writing a good c++ library is *hard*, but
using a well-designed c++ library can be really easy. Take a look at
apps.kde.com to see what great programs beginner programmers can write
when they have a good library (Qt/KDE).
> If they redo the structs so that they become totally different in syntax
> (as their use is totally different from normal references/classes), then
> I'm ok with their inclusion.
>
If you use structs only for things (vectors, complex numbers etc.)
that behave like numbers, it should be simple to see the difference:
If it behaves like a number, it is a struct, otherwise it is a class.
> Maybe some sort of compiler enforced naming convention + "as struct"
> extension? lower case and "as struct" added for clearity?
> E.g.
> point position = point(5,4) as struct; // or similar
>
> // very clear that the argument is passed as value
> doSomething(position as struct);
>
>
> public void doSomething(point pos as struct) { // very easy to spot
> pos.x += 5;
> pos.y += 3;
> }
>
That would not work. The point is moved, but then it is thrown away
when the method returns. The original point would not be changed.
> > Did
> > you ever wonder why there is no "numerical recipes in java" despite
> > the huge popularity of java? That is why!
> Maybe - but I'm arguing against the structs (value objects)
> implementation in .NET
>
I really like it. The first application I wrote in C# was a complex
number struct and a mandelbrot set viewer to test it. The performance
is almost as good as in C++, and the iteration looks really clean:
Complex x,c;
...
x=x*x+c;
instead of
double xr,xi,cr,ci;
...
xr=xr*xr-xi*xi+cr;
xi=2*xr*xi+ci;
> >>* Remove "auto-boxing of primitives" see above
> >
> > Auto-Boxing of primitives is extremely useful for using collections.
>
> new Integer(4) - very easy...
>
But you get very long and ugly lines for things that are very simple.
See the code example below for what I mean:
((Integer)integers1.get(i)).intValue()! *UGLY*
[snip]
> > You might say that this is too complicated and leads
> > to errors,
> Exactly, and confusion as it leads to the same problem as the structs
> .NET implementation - It's not evident that integers by design is
> value-objects not reference!
>
Of course it is. Numbers always have a value semantic. You get used to
it in no time at all.
> > but then every single scripting language in the world is
> > too complicated. I have been teaching php classes, and I never, ever
> > found somebody who found associative arrays too complicated.
> I'm not saying it's too complicated - I'm saying it's messy.
> Look at for example ada for a strict clean language. (a bit too strict
> IMHO though ;) Very easy to maintain, very "hard" to write (if you find
> getting compiler errors "hard").
>
You can have ADA for the .NET platform. No problem. But for normal
applications I want a language that is easy to write in. Having to
write ten times as many characters does not make complex algorithms
easier to understand.
> Where as python/ruby/perl is exactly the opposite - very easy to write,
> harder to maintain.
>
I agree about perl, but you can write very clean and maintainable
python code. Of course you can write very obfuscated python code, but
you don't have to.
> IMO Java has got a very good mix of ada and python, detailed compiler
> warnings but still not to rigid.
>
You also get detailed complier warnings from C#. But java just won't
let me do many things at all. Of course code that is not written does
have no bugs, so yes, java is a very safe programming language.
> And I think structs and auto-boxing of primitives make .NET languages
> (atleast C#) end up in the python/ruby/perl category without any of
> their quick writing skills (e.g. C# got no blocks, less powerful
> properties, no lambda etc etc)
>
I can see your point with auto-boxing, even though I do not agree with
you. But value types are absolutely nessecary for so many things. If
java had value types, I would not even bother with C#. Operator
overloading would also be nice, but it is just syntactic sugar. But
structs are *essential* for me. Without structs, you will never see
"Numerical Recipes in Java".
> > Besides,
> > I do not want a programming language that has the basic assumption
> > that I do not know what I am doing.
> Then you really should stay as far away from Ada as you can ever get :)
If I ever write some code for space probes, I will consider using ada.
But for normal applications C# is safe enough. It is a lot safer than
C++, and still very easy and convenient to write in.
> I like that the compiler help's me from obvious problems (doesn't have
> to "errors" - detecting "bad code" is just as important,
The C# compiler does help me with obvious problems. But the bugs that
cost me the most time to fix are mostly very subtle bugs that no
compiler in the world could have found.
and yes - I
> hate the overloaded + operator for java Strings)
>
What would you suggest as an alternative? new String("A").append("B")
instead of "A"+"B"?
> > It should try to protect me from
> > errors, but not to the point where it is almost impossible to do what
> > I want.
> That depends on *what* you want - if you want to see code written as
> below (e.g. 90% off all your felow employees that are fresh out of
> school with no experience), be my guest:
>
> List integers5 = ...
> List integers4 = ...
> List integers3 = ...
> List integers2 = ...
> // Could even be a linked list implementation - hua :(
> List integers1 = ...
> List list = new ArrayList();
> for (int i = 0; i < ITERATIONS; i++) {
> list.add(integers5.get(i)*5 + integers4.get(i)*4 +
> integers3.get(i)*3 + integers2.get(i)*2 + integers1.get(i));
> }
>
> Where you'll *a lot* of auto-boxing to and from and it won't be obvious
> (to your fellow inexperienced developers) that's it's a performance
> nightmare.
>
Storing numbers in List collections is a bad idea anyway. A simple
int[] would be much, much faster. But the performance will probably be
just fine. Lets test it.
(starting visual C# .net standard edition and jbuilder 7 personal on
my windows machine...)
Here is the C# code:
<Class1.cs>
using System;
using System.Diagnostics;
using System.Collections;
namespace ConsoleApplication1
{
class Class1
{
//Use lots of iterations to give the JIT
//time to do its job!
const int Iterations=100000;
[STAThread]
static void Main(string[] args)
{
IList integers1=new ArrayList();
IList integers2=new ArrayList();
IList integers3=new ArrayList();
IList integers4=new ArrayList();
IList integers5=new ArrayList();
IList list=new ArrayList();
for(int i=0;i<Iterations;i++)
{
integers1.Add(i);
integers2.Add(i);
integers3.Add(i);
integers4.Add(i);
integers5.Add(i);
}
DateTime time0=DateTime.Now;
for(int i=0;i<Iterations;i++)
{
list.Add(
(int)integers1[i]+
(int)integers2[i]*2+
(int)integers3[i]*3+
(int)integers4[i]*4+
(int)integers5[i]*5
);
}
TimeSpan delta=DateTime.Now-time0;
Trace.WriteLine(""+
integers1.Count/delta.TotalSeconds+
" adds per second");
}
}
}
</Class1.cs>
Here is the output when running the above program:
<cs.log>
'DefaultDomain': Loaded
'c:\winnt\microsoft.net\framework\v1.0.3705\mscorlib.dll', No symbols
loaded.
'ConsoleApplication1': Loaded 'C:\Dokumente und Einstellungen\Peter
Müller.LAPTOP\Eigene Dateien\Visual Studio
Projects\ConsoleApplication1\bin\Release\ConsoleApplication1.exe', No
symbols loaded.
'ConsoleApplication1.exe': Loaded
'c:\winnt\assembly\gac\system\1.0.3300.0__b77a5c561934e089\system.dll',
No symbols loaded.
'ConsoleApplication1.exe': Loaded
'c:\winnt\assembly\gac\system.xml\1.0.3300.0__b77a5c561934e089\system.xml.dll',
No symbols loaded.
1248202,58827289 adds per second
The program '[116] ConsoleApplication1.exe' has exited with code 0
(0x0).
</cs.log>
Now the same for java:
<Untitled1.java>
package untitled1;
import java.util.*;
public class Untitled1 {
//use lots of iterations to give the JIT Compiler time to do its
job!
public static final int ITERATIONS=100000;
public static void main(String[] args) {
List integers1=new ArrayList();
List integers2=new ArrayList();
List integers3=new ArrayList();
List integers4=new ArrayList();
List integers5=new ArrayList();
List list=new ArrayList();
for(int i=0;i<ITERATIONS;i++)
{
integers1.add(new Integer(i));
integers2.add(new Integer(i));
integers3.add(new Integer(i));
integers4.add(new Integer(i));
integers5.add(new Integer(i));
}
long t0=System.currentTimeMillis();
for(int i=0;i<ITERATIONS;i++)
{
list.add(
new Integer(
((Integer)integers1.get(i)).intValue()+
((Integer)integers2.get(i)).intValue()*2+
((Integer)integers3.get(i)).intValue()*3+
((Integer)integers4.get(i)).intValue()*4+
((Integer)integers5.get(i)).intValue()*5
)
);
}
long delta=System.currentTimeMillis()-t0;
System.out.println(""+integers1.size()*1000.0/delta+" adds per
second!");
}
}
</Untitled1.java>
Here is the output when running the above program:
<java.log>
C:\Programme\j2sdk1.4.0_01\bin\javaw -classpath "C:\Dokumente und
Einstellungen\Peter Müller.LAPTOP\jbproject\untitled1\classes;C:\Programme\j2sdk1.4.0_01\demo\jfc\Java2D\Java2Demo.jar;C:\Programme\j2sdk1.4.0_01\demo\plugin\jfc\Java2D\Java2Demo.jar;C:\Programme\j2sdk1.4.0_01\docs\guide\imf\spi-sample\CityIM.jar;C:\Programme\j2sdk1.4.0_01\jre\lib\charsets.jar;C:\Programme\j2sdk1.4.0_01\jre\lib\ext\dnsns.jar;C:\Programme\j2sdk1.4.0_01\jre\lib\ext\ldapsec.jar;C:\Pr
gramme\j2sdk1.4.0_01\jre\lib\ext\localedata.jar;C:\Programme\j2sdk1.4.0_01\jre\lib\ext\sunjce_provider.jar;C:\Programme\j2sdk1.4.0_01\jre\lib\jaws.jar;C:\Programme\j2sdk1.4.0_01\jre\lib\jce.jar;C:\Programme\j2sdk1.4.0_01\jre\lib\jsse.jar;C:\Programme\j2sdk1.4.0_01\jre\lib\rt.jar;C:\Programme\j2sdk1.4.0_01\jre\lib\sunrsasign.jar;C:\Programme\j2sdk1.4.0_01\lib\dt.jar;C:\Programme\j2sdk1.4.0_01\lib\h
mlconverter.jar;C:\Programme\j2sdk1.4.0_01\lib\tools.jar"
untitled1.Untitled1
526315.7894736842 adds per second!
</java.log>
The result is clearer than I thought it would be:
C# 1248202,58827289
Java: 526315.7894736842
The C# version is more than twice as fast, and looks much cleaner. My
windows machine is a pentium III with 1.1GHz and 256Megs.
[snip]
> > .NET has much better *infrastructure* for
> > powerful enterprise services than java has.
> In your opinion, not in the opinion of the enterprise experts at
> www.theserverside.com (who have actuall enterprise experience - e.g.
> *scaling* big time - not necessarily response time)
>
The java vm does not even have the ability to remove a thread group
cleanly without killing the VM. .NET has the concept of AppContexts,
i.e. you can have many completely separated AppContexts on one VM, and
you can remove one of them without affecting the others. This is very
useful for large, failure-tolerant systems. And that is just one of
many examples for enterprise features lacking in the java vm.
> >>* Standard organisation which everybody can join that handles the
> >>majority of the .NET platform (e.g. www.jcp.org)
> >
> > I agree that microsoft should standardize more of the framework. But
> > ECMA is a much better standard institution than the jcp.
> Well, depends - it's an international standard if that what's you mean?
> But my main point is that jcp allows *everybody* to participate and
> discuss *all of* java - I would like .NET to have something similar
>
You can discuss as long as you want, but in the end it is still sun
who decides what gets implemented. The java grande forum has tried for
many years to get some kind of value types into java to increase
performance, but sun just did not do it.
[snip]
> >>* Faster graphics performance, better/faster garbage collector,
> >
> > Are you serious? Swing and Java2D is the slowest performing graphics
> > toolkit I ever saw.
>
> Java2D is dead fast - hardware accelerated, swing is slow if you write
> it slow (it's not easy to write good performance gui-apps - I agree with
> that)
>
I think the developers of jbuilder are quite competent. JBuilder7 is
really an excellent IDE. In fact it is IMHO superior to VS.Net. But
still the performance of jbuilder (which is written in swing, which in
turn uses java2d) is mediocre at best. I run it on a PIII/1.1GHz with
256Megs of Ram. The performance is acceptable, but I would not call it
fast. The programs you mentioned (jEdit etc.) are nice, but not really
complex client programs.
<snip>
> Try to write a 2d scroller game in java and C# today and compare the
> results (I haven't got time for that)
>
Me neither. But I have written some java game applets in the past.
Take a look at <www.gamemakers.de>. Writing high performance graphics
stuff in java is a nightmare, since you always have to make sure that
you do not create too many temporary objects. The absense of structs
makes this almost impossible. Another big advantage of structs: they
live on the stack and do not need garbage collection!
> >>better/faster jit - all those three probably needs to be improved a lot
> >
> > Have you ever tried .NET?
> Yes.
> > I can see some room for improvement, but
> > especially the startup times are lightning fast compared to java.
> Yes, I agree
> > And
> > the execution speed is at the same level.
> I don't agree, as java jitters got a lot more features than what the
> .NET one got today (ask eric gunnarson if you don't believe me, e.g.
> recompiling after newly loaded class, optimizing etc etc)
>
> > And that with a much less
> > complicated and error-prone approach than hotspot.
> Maybe - don't know exactly how any of them work/ are implemented - do
> you? (I'm interested)
>
Modern java VMs are really complex beasts: when they first load the
code, they interpret it. After interpreting it for some time they find
out which parts of the code are run the most. Then they concentrate on
compiling these so called "hot spots" to machine code, hence the name
"hotspot".
The jit itself is also very sophisticated: It can for example do
inlining of virtual methods when the virtual method call always
results in the same method body being called. Basically, it observes
how the code is being executed and then does some speculative
inlining. Sometimes it has to de-inline the code when something
unusual happens.
All this is really nice, but unfortunately it has a lot of overhead,
and it takes some time to have an effect. You can see that when
running jBuilder. It runs really slow at first, and then it gets
noticeably faster.
The .NET VM on the other hand is very simple. When a method is called,
it is immediately compiled to machine code and then executed. Since
the .NET VM does not know as much about the code as the java VM does,
it can not do many of the more sophisticated optimizations like
virtual method inlining. But the advantage is that you can precompile
MSIL code to machine code and cache the result on disk. Therefore the
very large .NET class library (mscorlib.dll) and other often-used
libraries are already compiled to machine code when you start your
program, so only the code of your program itself has to be JITed. In
java on the other hand, every class in the class library that you use
has to be JITed each and every time you start your program. When you
start JBuilder (which probably uses almost every class in the java
class library), the poor java hotspot VM has to JIT-compile the
*whole* *class* *library*. And you know how large that is. This is
really braindead: when you start two java programs using swing, you
have two java VMs running on your system that do almost exactly the
same work (jiting the javax.swing.* classes). Sun promised to do
something about this, but they did not deliver.
> >>to come close to what is available in jre 1.4 today
> >>* Better IDE - Visual Studio doesn't even come close to IDEA in my
> >>opinion (e.g. refactoring, easy templates, easy key-shortcuts etc etc)
> >
> > I agree that the interface is a bit cluttered. But the code completion
> > works really nice, and the debugger is excellent. The debugger is the
> > most important reason for me to use an IDE. Were it not for the
> > debugger, I would just keep using my favorite Text Editor.
>
> Refactoring is my favourite today, followed close by code completion and
> debugging on shared second.
>
I think there will soon be refactoring support in SharpDevelop, and it
is very easy to write your own plugins for Visual Studio. But IDEs are
almost like text editors: features that some people love make other
people sick. Just look at the eternal EMacs vs. VI flamewar.
I will not base the choice of the platform I use on the IDE. I am sure
that I could be more productive in C# with textpad than in java with
jbuilder :-)
> > You forgot to mention the lack of real layout management and the other
> > big deficits in Windows.Forms.
> Haven't written more than one Windows.Forms program (hello world in
> title with out any buttons ;)
>
The lack of layout management in Windows.Forms is, at least for me,
the biggest deficiency of the .NET library. The Windows.Forms
namespace is basically just a thin wrapper around the windows widget
and drawing system. There are plenty of methods that actually need a
handle, and the class Windows.Forms.Control actually has a property to
get the handle of the corresponding window! I really wish the mono
people good luck porting this mess to Unix.
> Nice to talk about how to improve something instead of bashing on what
> already exists!
Yeah. It takes more time, but it is a lot more interesting than the
flamewars.
regards,
tuttle
tuttle
[snip]
> Yeah, read about value types and those other extensions here:
> http://www.geocities.com/csharpfaq
Using C# features in a completely braindead way does not prove that
these features are useless.
How would you write a complex number class in a language without value
types such as java? I am not asking for something complicated. Even a
talented 8th grader can write a well-performing and easy to use
complex number class in C++ or C#. But can you do it in java? Not?
Well I guess complex numbers and vectors are not that important
then...
regards,
tuttle
petilon
>> http://www.geocities.com/csharpfaq
>
>Using C# features in a completely braindead way does not prove that
>these features are useless.
Have you browsed through the sample code that is distributed with the
.NET Framework SDK? It is just as "braindead".
>How would you write a complex number class in a language without value
>types such as java? I am not asking for something complicated. Even a
>talented 8th grader can write a well-performing and easy to use
>complex number class in C++ or C#. But can you do it in java? Not?
>Well I guess complex numbers and vectors are not that important
>then...
It is funny. Any time you ask why C# has ref parameters, C# supporters
refer to swap method. Then you point to all the problems caused by ref
parameters, they say justify it by saying ref parameters are rarely
used any way. Any time you ask why C# has structs, C# supporters refer
to complex type. Then you point to all the problems caused by structs
they say user-defined types are rarely used any way. (I am of course
refering to Eric Gunnerson, among others -- I can post google links to
their posts if neeed.) So it appears the designer of C# fucked up the
language for a couple of rarely needed features.
Courageous
>> at the whole affair, assuring that M$ could NOT be backward compatible
>> with this prior base, which I might add, includes a simply enormous body
>> of 3rd party software.
>
Excuse me? How?
C//
tuttle
[snip]
> >How would you write a complex number class in a language without value
> >types such as java? I am not asking for something complicated. Even a
> >talented 8th grader can write a well-performing and easy to use
> >complex number class in C++ or C#. But can you do it in java? Not?
> >Well I guess complex numbers and vectors are not that important
> >then...
>
> It is funny. Any time you ask why C# has ref parameters, C# supporters
> refer to swap method. Then you point to all the problems caused by ref
> parameters, they say justify it by saying ref parameters are rarely
> used any way. Any time you ask why C# has structs, C# supporters refer
> to complex type. Then you point to all the problems caused by structs
> they say user-defined types are rarely used any way.
You would not recognize irony if it hits you on the head, wouldn't
you? Complex numbers are the very basis of many parts of scientific
computing. They are most definitely not "seldom used". The same goes
for vectors. A language that can not handle complex numbers and
vectors efficiently is a *joke*. Just because you don't know how to
use features like ref parameters and structs does not mean that they
are useless. Maybe instead of bashing advanced features, you should
try to learn programming.
tuttle
Dan Johnson
news:1006f17d.02081...@posting.google.com...
> > Look at the example ms gave to why unsafe code is needed - it *will* be
> > abused
> >
> Most admins in big companies will simply not allow unsafe third party
> applications to be executed. So software makers will do everything
> possible to avoid unsafe code, just like EJB coders may not use some
> features (e.g. direct IO, threads).
It may be worth point out that Visual Studio .NET by default
prohibits unsafe code in C#. You have to turn it on in the project
properties or the compiler will moan at you if you try to do it.
[snip]
> You *definitely* need some kind of value types to do efficient complex
> or vector calculations, at least with current processors. Just think
> about the cache consistency issues: An array of complex numbers in C#
> is a single, non-fragmented block of memory. An array of complex
> numbers in java would be an array of pointers and a huge number of
> totally fragmented, tiny objects on the heap. The performance would be
> horrible, that is why nobody is using java for this kind of stuff.
It is true that value types help a lot with performance
for certain kinds of code; in theory, of course, you only need
a compiler that can perform the same optimization without
hints, but those turn out to be very hard to implement.
On the other hand, value types do have, um, value- even if you
ignore performance. Sometimes values are what you want,
and if you are stuck with objects, you have to resort to various
nasty hacks to make them work like values instead of the objects
they really are.
I won'd reproduce it here, but I've got a rant on this subject
up on my website: http://www.vzavenue.net/~danieljohnson/
[snip]
> Writing good and easy to use libraries in C# requires a programmer
> that understands the difference between structs and classes. *Using*
> these libraries is much simpler and does not require big skills.
>
> That is similar to c++: Writing a good c++ library is *hard*, but
> using a well-designed c++ library can be really easy. Take a look at
> apps.kde.com to see what great programs beginner programmers can write
> when they have a good library (Qt/KDE).
This is a very good point. But I'd suggest that writing a good
C# class library is much easier than doing it in C++.
You do have to decide when to use structs and when to use
classes, so there are two mistakes you can make.
Using a struct where you should have used a class is a mistake
that is fairly easy detect Often there will be compiler errors as
you try to compare the things against null, or give them superclasses,
or something. Nothing could be more obvious. Even the more
subtle symptoms of this mistake are not very subtle; structs copy
on every assignment or cast, and if this was not intended it breaks
things in a big way.
The reverse error, using a class for a struct, is actually much more
difficult to find. When you do this, you get aliasing, where two
variables that may be widely separated can affect each other;
if you do this in error you presumably don't realize it, and it can be
a lot of fun trying to figure out why thus-and-such a private variable
changed, if you do not realize you've aliased it.
However, we couldn't get by without classes very well, so
even Petilon would not suggest removing them just to
eliminate this error.
> > If they redo the structs so that they become totally different in syntax
> > (as their use is totally different from normal references/classes), then
> > I'm ok with their inclusion.
> >
> If you use structs only for things (vectors, complex numbers etc.)
> that behave like numbers, it should be simple to see the difference:
> If it behaves like a number, it is a struct, otherwise it is a class.
It's not a problem in practice, of course, evne if you use it
for things like Size and Rectangle, which are not numbers.
Though IMHO it would be better to have used a common
naming convention for all structs, and to make it different
from classes. It's better to be on the safe side, if it's cheap
to do so- and anyway C# could use a more consistant
approach to this.
C# uses "all lower case" for primitives (and string
and object!), and "word initial caps" for both non-primitive
structs and classes. This is a distinction that hides more than
it reveals; primitives are in almost all respects just like
structures, and unlike both string and object and any other
class.
I don't see a need for more than a naming convention
though, and it's clear we can get along without even
that.
[snp]
> > Exactly, and confusion as it leads to the same problem as the structs
> > .NET implementation - It's not evident that integers by design is
> > value-objects not reference!
> >
> Of course it is. Numbers always have a value semantic. You get used to
> it in no time at all.
Indeed, even if they are implemented as objects they need
to be made to look like values or people will screw them up
no end. Even Smalltalk, surely the purest "everything is an object"
language does this.
Java gets into trouble on this point, as it's hard to make
objects look like values without the ability to overload ==,
and the Java class libraries also do not do this very well;
they have some "value objects" that are mutable, and others
that are immutable. The mutable ones are trouble, as it's
all to easy to form aliases to instances of those types, and have
distant bits of your program interact through them.
[snip]
> > And I think structs and auto-boxing of primitives make .NET languages
> > (atleast C#) end up in the python/ruby/perl category without any of
> > their quick writing skills (e.g. C# got no blocks, less powerful
> > properties, no lambda etc etc)
> >
> I can see your point with auto-boxing, even though I do not agree with
> you.
I think auto-boxing might be dispensed with when genericity
makes it into the language. There could be a compiler switch
that makes it a warning, for instance, once it got to the point
that you rarely needed it.
[snip]
> The java vm does not even have the ability to remove a thread group
> cleanly without killing the VM. .NET has the concept of AppContexts,
> i.e. you can have many completely separated AppContexts on one VM, and
> you can remove one of them without affecting the others. This is very
> useful for large, failure-tolerant systems. And that is just one of
> many examples for enterprise features lacking in the java vm.
I believe you mean "AppDomain" not "AppContext";
an "AppDomain" is an isolated environment where assemblies
may be loaded and run, which has its own security configuration.
In .NET, you load assemblies into app domains, but you can only
unload the whole app domain.
[snip]
> The lack of layout management in Windows.Forms is, at least for me,
> the biggest deficiency of the .NET library.
Which is odd, because Windows Forms *does have* layout
management. Look at the Dock and Anchor properties. It's really
very nice, and much simpler to use that Java layout objects.
> The Windows.Forms
> namespace is basically just a thin wrapper around the windows widget
> and drawing system.
That isn't even vaguely true of Windows.Forms. System.Drawing is
a thin wrapper around GDI+, but Windows.Forms is not thin at all,
and it includes significant functionality not found in USER32.DLL:
like layout management.
> There are plenty of methods that actually need a
> handle,
No, there are not. Not in Windows Forms.
> and the class Windows.Forms.Control actually has a property to
> get the handle of the corresponding window!
This part is true. The reason for having this is so that you can
use Win32 directly with your Windows Form app. Not because
you need that handle to do anything inside of Windows Forms:
you don't.
> I really wish the mono people good luck porting this mess to
> Unix.
It was certainly not meant to be so ported; it presume the
UI will look just like windows, with the same collection of
widgets that Win32 has.
But it does not seem impossible. They just have a lot of
Win32 functionality to implement on Unix to do it, I think.
[snip]
soft-eng
> Courageous wrote:
> >>"Backwards compatibility is *important*"
> >>a hundred times or so until you get it...
> >
> >
> > I find this whole sentiment to be wildly ironic. M$ basically liked
> > Java when it first came out, mostly because they found a great way
> > to make sure that they were backward compatible with their _VERY
> > EXTENSIVE_ component library (read: J/Direct).
>
> Yes, very much so!
>
> > But Sun struck out
> > at the whole affair, assuring that M$ could NOT be backward compatible
> > with this prior base, which I might add, includes a simply enormous body
> > of 3rd party software.
>
> Yes they could and that wasn't the problem...
> Why do so many in these groups keep posting stuff as this without any
> reason except making Sun look bad? Why not post stuff that's actually
> true about Sun instead of these badly put lies with grains of truth in
> them?
>
> MS Made a "java" clone that didn't include rmi among other things and
> had extra keywords as "delegate" etc that wasn't in the *java*
> specification!
That is typical, similar things were done to C++ and C by most
vendors. Some of these "extra"s ended up in the specs, some
got ignored... For instance, there used to be an "__asm"
keyword that was not in C specs, but was very
useful when you needed it.
petilon
>> refer to swap method. Then you point to all the problems caused by ref
>> parameters, they say justify it by saying ref parameters are rarely
>> used any way. Any time you ask why C# has structs, C# supporters refer
>> to complex type. Then you point to all the problems caused by structs
>> they say user-defined types are rarely used any way.
>
>You would not recognize irony if it hits you on the head, wouldn't
>you? Complex numbers are the very basis of many parts of scientific
>computing. They are most definitely not "seldom used". The same goes
>for vectors. A language that can not handle complex numbers and
>vectors efficiently is a *joke*. Just because you don't know how to
>use features like ref parameters and structs does not mean that they
>are useless. Maybe instead of bashing advanced features, you should
>try to learn programming.
I presume your comments are directed to Eric Gunnerson, because he is
the one who, when asked about the flaws in the design of ref parameter,
structs, and other "advanced features", tried to escape by claiming
that those features are seldom used any way!
___________________________________________________
Read the C# FAQ: http://www.geocities.com/csharpfaq
Chad Myers
"petilon" <petilo...@yahoo.com.invalid> wrote in message
There are valid uses for the ref parameter. As opposed to the
Java-way-of-things which is, to say, don't let anybody do anything
that might make them more productive, the ref parameter was included
because someone might need it and there were valid uses for it.
Can it get you into trouble? Sure. But then, the + operator can get
you into trouble if you don't use it right. In fact, programming
is a logical operation and if it isn't programmed correctly, you
will get bugs (duh!). So you assertion that something is bad because
it MAY or POSSIBLY could cause problem doesn't really fly.
Is it bad practice to use structs? In some cases yes, in some no.
You listed the no's, but there are some yes's. Same for ref.
Petilon, I'd like to see you write up all the bad things about
Java. There are quite a few design choices that many would disagree
with.
I doubt you'll do it, because you're really just a MS-bashing troll.
-c
Jim Sculley
<snip>
>
> Petilon, I'd like to see you write up all the bad things about
> Java. There are quite a few design choices that many would disagree
> with.
Petilon has voiced several complaints about Java in the past. Perhaps
you should look them up.
Jim S.
Jim Sculley
<snip>
> How would you write a complex number class in a language without value
> types such as java?
It is trivial to do so.
> I am not asking for something complicated. Even a
> talented 8th grader can write a well-performing and easy to use
> complex number class in C++ or C#. But can you do it in java?
Of course you can. Java is Turing complete.
> Well I guess complex numbers and vectors are not that important
> then...
I didn't have any trouble porting Eric Gunnerson's 'collide' code (which
uses several value types) to Java.
Jim S.
Jim Sculley
> A language that can not handle complex numbers and
> vectors efficiently is a *joke*.
What evidence do you have to indicate that Java cannot handle complex
numbers and vectors efficiently?
Jim S.
petilon
>
>There are valid uses for the ref parameter. As opposed to the
>Java-way-of-things which is, to say, don't let anybody do anything
>that might make them more productive, the ref parameter was included
>because someone might need it and there were valid uses for it.
This is the attitude that leads to bloat and complexity. The designer
of Java had exactly the wrong attitude -- don't put anything in unless
there it is absolutely needed. Here's what he said about simplification:
http://groups.google.com/groups?selm=a9ljkd094g%40drn.newsguy.com
Prof. C.A.R. Hoare once said, "Without simplicity, even the language
designer himself cannot evaluate the consequences of his design
decisions." This has certainly proved true in the case of C#. It has
been publicly demonstrated that even one of the designers of C# could
not answer a simple questions about a short C# statement. (Ask me for
details about this, if you like.)
>
>Can it get you into trouble? Sure. But then, the + operator can get
>you into trouble if you don't use it right. In fact, programming
>is a logical operation and if it isn't programmed correctly, you
>will get bugs (duh!). So you assertion that something is bad because
>it MAY or POSSIBLY could cause problem doesn't really fly.
>
>Is it bad practice to use structs? In some cases yes, in some no.
>You listed the no's, but there are some yes's. Same for ref.
>
>Petilon, I'd like to see you write up all the bad things about
>Java. There are quite a few design choices that many would disagree
>with.
>
>I doubt you'll do it, because you're really just a MS-bashing troll.
>
Nonsense. I don't think Java is perfect at all. I have complained
many times about the awful design of inner classes, for example. But
overall, I have far fewer complaints about Java than about C#,
that's true. If that makes me an MS-bashing troll, fine.
Jason Kratz
"Chad Myers" <cmy...@N0.SP.4M.austin.rr.com> wrote in message
news:x6059.61003$Yd.30...@twister.austin.rr.com...
>
> "Jason Kratz" <e...@joes.com> wrote in message
> news:aj1ge3$di7$1...@flood.xnet.com...
> >
> > "Chad Myers" <cmy...@N0.S.P4.M.austin.rr.com> wrote in message
> > news:eB2j9I$PCHA.2576@tkmsftngp08...
> > >
> > >
> > > This is very consistent with the rest of .NET, like I said.
> > >
> > > What about System.currentTimeMillis()? What the hell is that?
> > >
> >
> > Its a class method to get the current time in milliseconds. That is
> > difficult to grok?
>
> Thank you, Capt. Obvious. But that wasn't what I was asking. I was
> illustrating that the J2SE API is a cobbled mess and that for every
> one inconsistency you might find in the .NET FCL, you can find 10
> or more in the Java API, that was an example and I was asking why
> they chose that over more standardized or consistent method naming
> conventions. That is difficult to grok?
>
Yes it is actually. It is totally obvious what the method does and I don't
see how its part of a 'cobbled mess'. What 'standardized or consisten
naming convention' would you have them use?
Jason Kratz
> mess of inconsistent and largely incompatible plug-ins.
>
This is some of the funniest stuff i've ever read. Like it makes any damn
difference whether Java IDEs or VS.NET is better. That being said I'll add
one more thing. Oracle JDeveloper. Has UML, has some refactoring support,
has some form of db tools, etc.
As to the comment of 'inconsistent and largely imcompatible plug-ins' what
the hell does that mean? Why would plug-ins have to be consisent with each
other or compatible with each other?
Jim Sculley
<snip>
>
> You *definitely* need some kind of value types to do efficient complex
> or vector calculations, at least with current processors. Just think
> about the cache consistency issues: An array of complex numbers in C#
> is a single, non-fragmented block of memory. An array of complex
> numbers in java would be an array of pointers and a huge number of
> totally fragmented, tiny objects on the heap. The performance would be
> horrible, that is why nobody is using java for this kind of stuff.
Java typically uses a generational garbage collector. A generational GC
allocates new objects in a nursery, and these allocations are typically
contiguous, and extremly fast, much like stack allocated objects.
Objects that live past the nursery stage are transferred elsewhere on
the heap. The HotSpot VM is fully accurate which means that *all*
objects can be relocated, which allows the GC to control heap
fragmentation. See:
http://java.sun.com/products/hotspot/docs/whitepaper/Java_HotSpot_WP_Final_4_30_01.html
<snip>
>>
>
> I really like it. The first application I wrote in C# was a complex
> number struct and a mandelbrot set viewer to test it. The performance
> is almost as good as in C++, and the iteration looks really clean:
>
> Complex x,c;
> ...
> x=x*x+c;
>
> instead of
>
> double xr,xi,cr,ci;
> ...
> xr=xr*xr-xi*xi+cr;
> xi=2*xr*xi+ci;
Why would you write it this way? It can certainly be much improved
without the use of user defined value types.
Would you be willing to post your code to the above Complex struct and
Mandelbrot viewer? I would be happy to port it to Java for the purpose
of determining if your claims about the necessity of value types for
this type of work are true. I will post the resulting Java code which
anyone can compile and use to form their own opinion. Publishing
results would violate the .NET SDK EULA, but there is nothing
prohibiting the creation of such comparable code.
<snip>
>
> You can have ADA for the .NET platform. No problem. But for normal
> applications I want a language that is easy to write in. Having to
> write ten times as many characters does not make complex algorithms
> easier to understand.
I doubt that ten times the characters are required. A well designed
class based implementation can be fairly easy to read and write.
<snip>
>
> I can see your point with auto-boxing, even though I do not agree with
> you. But value types are absolutely nessecary for so many things. If
> java had value types, I would not even bother with C#. Operator
> overloading would also be nice, but it is just syntactic sugar. But
> structs are *essential* for me. Without structs, you will never see
> "Numerical Recipes in Java".
<EULA violating text snipped>
> The result is clearer than I thought it would be:
C# xxxxxxxxxxxxxxxxx
Java: 526315.7894736842
Considering I get > 580K/sec for Java on my 400MHz Pentium II with JDK
1.4.0 beta 3, I'd say your results are less than conclusive. The IBM
1.3 VM yields 1,250,000 per second on the same machine.
>
> [snip]
>
>>>.NET has much better *infrastructure* for
>>>powerful enterprise services than java has.
>>
>>In your opinion, not in the opinion of the enterprise experts at
>>www.theserverside.com (who have actuall enterprise experience - e.g.
>>*scaling* big time - not necessarily response time)
>>
>
> The java vm does not even have the ability to remove a thread group
> cleanly without killing the VM.
Evidence of this please...
> .NET has the concept of AppContexts,
> i.e. you can have many completely separated AppContexts on one VM, and
> you can remove one of them without affecting the others. This is very
> useful for large, failure-tolerant systems. And that is just one of
> many examples for enterprise features lacking in the java vm.
There is no such thing as 'the Java VM'. For example:
=================================
The Janos Virtual Machine (JanosVM) is an Open Source virtual machine
for executing Java bytecodes. Unlike any available virtual machine,
the JanosVM supports multiple, separate process-like entities (called
"teams" in the JanosVM) within a single VM, without reliance on any
underlying OS or hardware support for such separation. The JanosVM
supports separate per-team heaps, per-team garbage collection threads,
inter-team thread migration, safe cross-team reference objects, and a
spiffy tutorial. Designed to support asynchronous termination of
buggy, uncooperative, or malicious Java bytecode applications, the
JanosVM provides robust and scalable multi-process support within a
single virtual machine.
===================================
<snip>
>
> Me neither. But I have written some java game applets in the past.
> Take a look at <www.gamemakers.de>. Writing high performance graphics
> stuff in java is a nightmare, since you always have to make sure that
> you do not create too many temporary objects. The absense of structs
> makes this almost impossible.
How so? The scoping rules in Java are quite well defined and easily
understood. Any temporary objects are eligible for GC as soon as they
are out of scope and unreachable.
> Another big advantage of structs: they
> live on the stack and do not need garbage collection!
A generational collector can allocate contiguously with stack-like
speed. Why is immediate deallocation of structs significant?
<snip Hotspot description>
>
> All this is really nice, but unfortunately it has a lot of overhead,
> and it takes some time to have an effect.
Evidence of this? As a counterexample, you can set the threshold at
which compilation begins in the IBM VM. In the Sun VM you can tell it
to compiler everything up frotn with the -Xcomp switch. Surprise,
surprise, doing so hurts startup time.
<snip>
>
> The .NET VM on the other hand is very simple. When a method is called,
> it is immediately compiled to machine code and then executed.
And how long does this compilation take versus interpreting the code?
> Since
> the .NET VM does not know as much about the code as the java VM does,
> it can not do many of the more sophisticated optimizations like
> virtual method inlining. But the advantage is that you can precompile
> MSIL code to machine code and cache the result on disk.
To my knowledge, there is nothing preventing the existence of a caching
JIT for Java.
> Therefore the
> very large .NET class library (mscorlib.dll) and other often-used
> libraries are already compiled to machine code when you start your
> program, so only the code of your program itself has to be JITed. In
> java on the other hand, every class in the class library that you use
> has to be JITed each and every time you start your program. When you
> start JBuilder (which probably uses almost every class in the java
> class library), the poor java hotspot VM has to JIT-compile the
> *whole* *class* *library*.
No it doesn't. Your own description of HotSpot above says as much.
> And you know how large that is. This is
> really braindead: when you start two java programs using swing, you
> have two java VMs running on your system that do almost exactly the
> same work (jiting the javax.swing.* classes). Sun promised to do
> something about this, but they did not deliver.
Where did they make such a promise? Incidentally, I believe that the
MacOS VM has such a feature.
<snip>
Jim S.
Chad Myers
Once again you manage to completely miss the subject of the current
part of this thread.
Someone suggested that the .NET FCL was more inconsistent than the
J2API. I argued this and said that it wasn't and cited several
examples, one of which was the currentTimeMillis. This is inconsistent
with the rest of the API. Yes, Jason, it's obvious what it does,
but it's not consistent with the Get/Set pattern, or any of the other
patterns that are used in the API. That makes it "inconsistent".
http://www.dictionary.com/search?q=Inconsistent
-c
Chad Myers
Why would they have to be consistent? Because it provides a consistent
usability and interface of the application as a whole.
Let's see, I can use VS.NET which has a consistent flow of work,
or an IDE with a bunch of independently written plug-ins each with their
own quirks and inconsistencies. This slows down productivity. It's
pretty simple stuff to understand really, I'm suprised you are so blinded
by your Java blinders that you can't see simple concepts for what
they are.
-c
Jason Kratz
I have no Java blinders (the majority of my daytime work has nothing to do
with Java). I can also see simple concepts quite easily however that
requires that they make sense. You aren't making any sense. Apparently
your VS.NET blinders are making you have issues with typing or something.
Can you point us to the plugins youre referring to? I'd be curious to see
just what quirks and inconsistencies youre referring to. For example I
use JEdit (http://www.jedit.org) for all my coding needs. It relies
extensively on plugins and has a nice plugin API yet somehow I'm not seeing
the quirks and inconsistencies you're talking about. Or is this just
another instance where you have no idea wtf you're talking about and are
just making things up for the sake of argument?
asj
>
> I have no Java blinders (the majority of my daytime work has nothing to do
> with Java). I can also see simple concepts quite easily however that
> requires that they make sense. You aren't making any sense. Apparently
> your VS.NET blinders are making you have issues with typing or something.
> Can you point us to the plugins youre referring to? I'd be curious to see
> just what quirks and inconsistencies youre referring to. For example I
> use JEdit (http://www.jedit.org) for all my coding needs. It relies
> extensively on plugins and has a nice plugin API yet somehow I'm not seeing
> the quirks and inconsistencies you're talking about. Or is this just
> another instance where you have no idea wtf you're talking about and are
> just making things up for the sake of argument?
he has no idea wtf he's talking about. i've yet to see these "quirks and
inconsistencies" he's been hallucinating about, and i use several
different editors at work and at home. if you look at chad's arguments
about ECMA, you'll notice his views don't necessarily coincide with
reality.
Chad Myers
You defend currentTimeMillis as consistent. You defend patchwork Java
IDEs as consistent. You have Java blinders.
> I can also see simple concepts quite easily however that
> requires that they make sense.
Well, you completely missed the whole argument. That was a pretty
simple concept...
> You aren't making any sense. Apparently
> your VS.NET blinders are making you have issues with typing or something.
There are better IDEs for VS.NET, just not any Java IDE's I've seen.
> Can you point us to the plugins youre referring to? I'd be curious to see
> just what quirks and inconsistencies youre referring to. For example I
> use JEdit (http://www.jedit.org) for all my coding needs. It relies
> extensively on plugins and has a nice plugin API yet somehow I'm not
seeing
> the quirks and inconsistencies you're talking about.
I use jEdit frequently as well, and it is the prime example of what
I'm talking about. If you don't know what I'm talking about, then
either a.) You haven't actually used jEdit, b.) You've never used
a jEdit plugin, or c.) You're bullshitting.
Ok, let's fire up jEdit shall we? Version 4.1pre2. 5 minutes later after
it's loaded, go to Utilities->Global Options.
Expand Plugins and click around. You'll see a hodgepodge of various
plugin configuration UIs all with various quirks.
Note that the memento, Spell Check, and SQL plugins have a "NO LABEL
PROPERTY" prefix. Great consistency there. Some displays are
vertical-aligned top, some middle, some bottom.
Go to the LookAndFeel plugin, select Oyoha as the L&F. Notice
the two textboxes that appear. Notice the text running off the right
hand side of the dialog, requiring a resize to see it.
Look hard and see the one or two tiny little buttons to the right
of the textboxes. Using significant dexterity, click on the buttons.
The one on the left should open a file dialog (about 20 seconds
later), the one on the right says:
The {0} look and feel will now be installed.
What's the {0} look and feel? Why is it being installed? Is
the tiny, unlabled button the "Install" button? What the hell
is going on here.
Now, please demonstrate several examples of this kind of
inconsistency and poor programming in VS.NET.
> Or is this just another instance where you have no idea wtf
> you're talking about and are just making things up for the
> sake of argument?
Another? When was the first? Given the very specific and
poignant examples above, I think it's safe so say that you're
the one with no clue and who makes things up or conveniently
ignores arguments to keep the blinders going full bore.
-c
>
>
petilon
>
>In article <#iFBR9gQCHA.4228@tkmsftngp08>, "Chad says...
>>
>>There are valid uses for the ref parameter. As opposed to the
>>Java-way-of-things which is, to say, don't let anybody do anything
>>that might make them more productive, the ref parameter was included
>>because someone might need it and there were valid uses for it.
>
>This is the attitude that leads to bloat and complexity. The designer
>of Java had exactly the wrong attitude -- don't put anything in unless
I meant opposite.
Dan Johnson
> In article <#iFBR9gQCHA.4228@tkmsftngp08>, "Chad says...
> of Java had exactly the wrong attitude -- don't put anything in unless
> there it is absolutely needed. Here's what he said about simplification:
> http://groups.google.com/groups?selm=a9ljkd094g%40drn.newsguy.com
This would seem to endorse having structs. You'll definitely
use them in the first month, if you use C# in an even vaguely
normal way. :D
You, on the other hand, would seem to favor going a bit
father, and removing the stuff you use every day, too. :D
> Prof. C.A.R. Hoare once said, "Without simplicity, even the language
> designer himself cannot evaluate the consequences of his design
> decisions."
Come on. If you really favored simplicilty, you'd be hawking
Smalltalk or FORTH. Java is many things, but it is only simple
compared to C++.
> This has certainly proved true in the case of C#. It has
> been publicly demonstrated that even one of the designers of C# could
> not answer a simple questions about a short C# statement. (Ask me for
> details about this, if you like.)
Come on, Petilon, even you should realize that nobody has
been impressed by your ability to write unclear code in C#.
There has never been a language where that was impossible,
including Java.
[snip]
> >I doubt you'll do it, because you're really just a MS-bashing troll.
>
> Nonsense. I don't think Java is perfect at all. I have complained
> many times about the awful design of inner classes, for example. But
> overall, I have far fewer complaints about Java than about C#,
> that's true. If that makes me an MS-bashing troll, fine.
You seem to favor, with very few exceptions, the original Java 1.0;
and you damn anything that deviates from that even slightly, even if
the deviation is to obviate a well know problem with Java.
That includes later version of Java, too. Which suggests
to me that while you're certainly an MS bashing troll, but
that's not really explaination enough for your attitude about
C#.
Jason Kratz
You refute that currentTimeMillis existed before the JavaBeans API (and the
standard of get/set). You can't come up with any reasons as to how IDEs are
patchwork and inconsistent. You have VS.NET blinders.
> > I can also see simple concepts quite easily however that
> > requires that they make sense.
>
> Well, you completely missed the whole argument. That was a pretty
> simple concept...
>
Funny coming from the guy who makes up facts, presents opinion as fact, or
gets lost in his own arguments. Youre a funny guy.
> > You aren't making any sense. Apparently
> > your VS.NET blinders are making you have issues with typing or
something.
>
> There are better IDEs for VS.NET, just not any Java IDE's I've seen.
>
Oh are there? Care to point them out and why?
> > Can you point us to the plugins youre referring to? I'd be curious to
see
> > just what quirks and inconsistencies youre referring to. For example
I
> > use JEdit (http://www.jedit.org) for all my coding needs. It relies
> > extensively on plugins and has a nice plugin API yet somehow I'm not
> seeing
> > the quirks and inconsistencies you're talking about.
>
> I use jEdit frequently as well, and it is the prime example of what
> I'm talking about. If you don't know what I'm talking about, then
> either a.) You haven't actually used jEdit, b.) You've never used
> a jEdit plugin, or c.) You're bullshitting.
>
Ah. So your evidence is that solid huh? I have no clue what you're talking
about. I use JEdit every single day for Cold Fusion programming, Perl, and
PL/SQL. Would you like the list of JEdit plugins I use too? I'm kind of
curious...why would someone who is raving about VS.NET, .NET in general and
who apparently doesn't do any Java programming anymore using JEdit? Did you
just download it for the sake of arguing?
> Ok, let's fire up jEdit shall we? Version 4.1pre2. 5 minutes later after
> it's loaded, go to Utilities->Global Options.
>
Apparently you have something less than a P3-500 notebook with 256mb of RAM.
Only took 20 seconds for JEdit to fire up here (v 4.0).
> Expand Plugins and click around. You'll see a hodgepodge of various
> plugin configuration UIs all with various quirks.
>
Funny. I see various UIs that all use the same set of UI widgets in pretty
much the same way (checkboxes, dropdowns, etc). Also funny that once I've
gone thru them and set up the options I like I don't have to do it again.
Where is the drop in productivity?
> Note that the memento, Spell Check, and SQL plugins have a "NO LABEL
> PROPERTY" prefix. Great consistency there. Some displays are
> vertical-aligned top, some middle, some bottom.
>
Don't use any of those but I just downloaded the SQL plugin and SpellCheck
and I still have no idea wtf you're talking about. Are you seriously
telling me that alignment problems cause a drop in productivity?
> Go to the LookAndFeel plugin, select Oyoha as the L&F. Notice
> the two textboxes that appear. Notice the text running off the right
> hand side of the dialog, requiring a resize to see it.
>
Yep. Don't see that as a productivity sink.
> Look hard and see the one or two tiny little buttons to the right
> of the textboxes. Using significant dexterity, click on the buttons.
> The one on the left should open a file dialog (about 20 seconds
> later), the one on the right says:
>
3 seconds here. You must be suffering from using a really slow machine.
Apparently you have one big productivity sink: a slow machine. I thought my
notebook was slow.
> The {0} look and feel will now be installed.
>
Yep.
> What's the {0} look and feel? Why is it being installed? Is
> the tiny, unlabled button the "Install" button? What the hell
> is going on here.
>
Unfinished plugin? Where has my productivity been slowed?
> Now, please demonstrate several examples of this kind of
> inconsistency and poor programming in VS.NET.
>
Can't and never said I could. Haven't used VS.NET ever and am not planning
on it anytime soon. What plugins are available for VS.NET from a third
party with their own config UI? If I wanted to test VS.NET in the manner
you just did for JEdit I'd have to have the same ability of course. We need
to compare apples to apples. Of course you didn't really give me what I was
asking for (not that it surprises me). Here is what you stated before and
I quote:
"Let's see, I can use VS.NET which has a consistent flow of work, or an IDE
with a bunch of independently written plug-ins each with their own quirks
and inconsistencies. This slows down productivity."
Even giving you the courtesy of saying you were right about the issues you
discussed (which I don't) I have yet to see how any inconsistencies in the
options UI of plugins either changes the flow of work in JEdit or slows down
productivity. Care to explain?
>
> Another? When was the first? Given the very specific and
> poignant examples above, I think it's safe so say that you're
> the one with no clue and who makes things up or conveniently
> ignores arguments to keep the blinders going full bore.
>
Dude...you've been spewing garbage in every thread you're involved in. The
best part was when you said I should read Ayn Rand. That was the absolute
best. Of course you assumed that I hadn't read Ayn Rand but that is just a
nit. I'm not ignoring anything but the opinion you're trying to pass off as
fact. Your 'very specific and poignant examples' still didn't show any
inconsistency that causes interruption to work flow or slows down
productivity. You also ignore that the various plugin UIs all have their
options entered in a consistent manner via a standard plugin UI/API (as a
regular JEdit user I'm sure you know what I'm referring to) but hey...who
cares right? Long as you can advocate VS.NET....
Chad Myers
It's sad to watch you keep beating your head against a door.
Simply because I state that currentTimeMillis is completely inconsistent
with the rest of the J2API does not mean I have VS.NET anything.
It is inconsistent, why can't you simply admit that fact?
Sure, it was around before. But why is it still there? Sun has
deprecated many methods for many reasons, why not this one?
There's no good reason you might answer. Ok, fair enough, but my
statement that it's inconsistent still remains. Sun has had the
opportunity to make it more consistent, yet they have not.
Back to the original argument which you conveniently ignore,
the .NET FCL is not as inconsistent as the J2API. I didn't
say it was better or worse or whatever, just that it's
not as inconsistent. Anders (I believe his name was) argued
that the FCL was inconsistent and that the J2API was not.
>
> > > I can also see simple concepts quite easily however that
> > > requires that they make sense.
> >
> > Well, you completely missed the whole argument. That was a pretty
> > simple concept...
> >
>
> Funny coming from the guy who makes up facts, presents opinion as fact, or
> gets lost in his own arguments. Youre a funny guy.
Makes up facts? Cite please. Presents opinion as fact? Cite please?
All I see from you is bs and more bs and amusing defenses for Java's
quirks and inconsistencies and blind statements about how evil
Microsoft is without every one piece of evidence to back it up.
I have presented pieces of evidence and you don't even refute them,
you make excuses and apologize for Sun and Java. You are a Sun/Java
apologist and you have blinders. Just admit it. Admitting you have
a problem is the first step to being cured.
>
> > > You aren't making any sense. Apparently
> > > your VS.NET blinders are making you have issues with typing or
> something.
> >
> > There are better IDEs for VS.NET, just not any Java IDE's I've seen.
> >
>
> Oh are there? Care to point them out and why?
Let me rephrase, I'm sure that VS.NET is not the best IDE that
ever existed and there are certainly IDEs that will be better in
the future. There probably are today, but I don't know of any off
the top of my head.
I, unlike others *cough*you*cough* am not so arrogant to think
that my IDE is the best ever and none could ever be better.
I do happen to know for a fact, that no Java IDE matches the
level of functionality, consistency, productivity and integration
that VS.NET offers. Yes, VS.NET does not have refactoring currently,
but it still outnumbers all Java IDEs (that I've seen so far)
with features.
>
> > > Can you point us to the plugins youre referring to? I'd be curious to
> see
> > > just what quirks and inconsistencies youre referring to. For
example
> I
> > > use JEdit (http://www.jedit.org) for all my coding needs. It relies
> > > extensively on plugins and has a nice plugin API yet somehow I'm not
> > seeing
> > > the quirks and inconsistencies you're talking about.
> >
> > I use jEdit frequently as well, and it is the prime example of what
> > I'm talking about. If you don't know what I'm talking about, then
> > either a.) You haven't actually used jEdit, b.) You've never used
> > a jEdit plugin, or c.) You're bullshitting.
> >
>
> Ah. So your evidence is that solid huh?
See below. It is obvious as water is wet that jEdit has many quirks,
bugs, and inconsistencies. Your attempts to dispute this are
simply amusing.
> I have no clue what you're talking about.
Case in point.
> I use JEdit every single day for Cold Fusion programming, Perl, and
> PL/SQL.
Cold Fusion "programming" huh? That's a laugh.
> Would you like the list of JEdit plugins I use too? I'm kind of
> curious...why would someone who is raving about VS.NET, .NET in general
and
> who apparently doesn't do any Java programming anymore using JEdit? Did
you
> just download it for the sake of arguing?
No. I used it daily for a little over 2 years. I still use it, though
not quite daily. It is too slow and cumbersome compared to VS.NET.
>
> > Ok, let's fire up jEdit shall we? Version 4.1pre2. 5 minutes later after
> > it's loaded, go to Utilities->Global Options.
> >
>
> Apparently you have something less than a P3-500 notebook with 256mb of
RAM.
> Only took 20 seconds for JEdit to fire up here (v 4.0).
5 minutes was an exaggeration, but on my P3-533 with 256, it certainly
takes much longer than 20 seconds. From dbl-click to typing, my
experience was around 40 seconds (41 to be exact). And that was
after I had already loaded it earlier today. When I'm off a reboot,
it takes longer on first startup. Probably something like 50 seconds,
but I haven't clocked it. At any rate, that's not what I was arguing,
whether it takes 1 second or 100, it still has inconsistencies.
>
> > Expand Plugins and click around. You'll see a hodgepodge of various
> > plugin configuration UIs all with various quirks.
> >
>
> Funny. I see various UIs that all use the same set of UI widgets in
pretty
> much the same way (checkboxes, dropdowns, etc). Also funny that once
I've
> gone thru them and set up the options I like I don't have to do it again.
> Where is the drop in productivity?
So, using checkboxes and buttons in various configurations, layouts,
alignments, etc is consistent to you?
Therefore, by your definition, the Mac UI and the Windows UI are
consistent because they use buttons and checkboxes? Absurd. Now you're
being ridiculous and your apologies are nothing less than completely
amusing.
>
> > Note that the memento, Spell Check, and SQL plugins have a "NO LABEL
> > PROPERTY" prefix. Great consistency there. Some displays are
> > vertical-aligned top, some middle, some bottom.
> >
>
> Don't use any of those but I just downloaded the SQL plugin and SpellCheck
> and I still have no idea wtf you're talking about. Are you seriously
> telling me that alignment problems cause a drop in productivity?
Slightly, yes. However, the point is, the plugins are inconsistent due
to lack of programmer discipline. This type of inconsistency throughs
off motor memory and encourages errors and user mistakes. I suggest
you read a book on UI design. However, such books will probably burn
the hands of a Java developer.
> > Go to the LookAndFeel plugin, select Oyoha as the L&F. Notice
> > the two textboxes that appear. Notice the text running off the right
> > hand side of the dialog, requiring a resize to see it.
> >
>
> Yep. Don't see that as a productivity sink.
Look, if you're unwilling to face hard facts and keep your hands over
your eyes, I can't help you. No amount of common sense and facts
will illustrate to you that Java IDEs just don't compare with
VS.NET.
<SNIP More demonstrations which were ignored and blinded by
the Jason's blinders>
> > Now, please demonstrate several examples of this kind of
> > inconsistency and poor programming in VS.NET.
> >
>
> Can't and never said I could. Haven't used VS.NET ever and am not
planning
> on it anytime soon.
And there we have it. Argument from ignorance. You have argued this
whole time that Java IDEs are better than VS.NET, yet you HAVEN'T EVEN
USED IT?
> > Another? When was the first? Given the very specific and
> > poignant examples above, I think it's safe so say that you're
> > the one with no clue and who makes things up or conveniently
> > ignores arguments to keep the blinders going full bore.
> >
>
> Dude...you've been spewing garbage in every thread you're involved in.
Ah, as opposed to the insightful, fact filled embarassment you just
committed the past 3-4 posts in this thread?
If you call that fact, I'm happy that you call what I say Garbage.
In Kratese, that means fact, I guess.
> The best part was when you said I should read Ayn Rand.
Or anything, really. Your distored world view, or lack thereof
is disturbing.
To think that there are so horribly undereducated unintelligent
people voting for the people that charge me taxes and make the
laws that I must follow is horrifying to me.
To think that you would rather than the government run everything
for us and tuck us in at night, despite all the lessons we
have learned for thousands of years of government abuse and
human corruption makes me doubt humanity as a whole.
The fact that you dismiss intellectual discourse out of hand
is equally as shocking.
> That was the absolute best. Of course you assumed that I hadn't read
> Ayn Rand but that is just a nit.
I doubt that you've read anything.
> I'm not ignoring anything but the opinion you're trying to pass off as
> fact.
Ah, and which is that? Opinion? You mean the several explicit examples
of evidence I gave supporting the other facts I talked about, as
opposed to your simple and ignorant dismissals in the face of common
sense?
Again, if evidence is opinion in your world, then I'll be happy to
be called an opinionated person by you.
> Your 'very specific and poignant examples' still didn't show any
> inconsistency that causes interruption to work flow or slows down
> productivity.
If you can't see it, I don't know what will prove it to you. In fact,
I suspect that you are incapable of seeing any fact. Your constant
recitations of "Java is King. Must hate Microsoft" only drone on
and lend you no credibility.
> You also ignore that the various plugin UIs all have their
> options entered in a consistent manner via a standard plugin UI/API (as a
> regular JEdit user I'm sure you know what I'm referring to) but hey...who
> cares right? Long as you can advocate VS.NET....
I didn't say that consistent plugins didn't exist, I just said that
they are most inconsistent and indeed, most of the plugins were
inconsistent with themselves, and most certainly with the rest of the
UI.
In some places there are graphical buttons, in some places there
aren't. In some places widgets behave differently than in other
places, etc.
Deny if you wish, but it doesn't change the facts that are so
obvious to everyone else.
-c
tuttle
[snip]
> > You *definitely* need some kind of value types to do efficient complex
> > or vector calculations, at least with current processors. Just think
> > about the cache consistency issues: An array of complex numbers in C#
> > is a single, non-fragmented block of memory. An array of complex
> > numbers in java would be an array of pointers and a huge number of
> > totally fragmented, tiny objects on the heap. The performance would be
> > horrible, that is why nobody is using java for this kind of stuff.
>
> It is true that value types help a lot with performance
> for certain kinds of code; in theory, of course, you only need
> a compiler that can perform the same optimization without
> hints, but those turn out to be very hard to implement.
>
Such compilers are not available and will not be available for some
time. There has been some talk at sun about automatically creating
short-lived objects on the stack. But only talk so far, and this is
only a tiny part of the problem.
[snipped lots of stuff where we agreed]
> The reverse error, using a class for a struct, is actually much more
> difficult to find. When you do this, you get aliasing, where two
> variables that may be widely separated can affect each other;
> if you do this in error you presumably don't realize it, and it can be
> a lot of fun trying to figure out why thus-and-such a private variable
> changed, if you do not realize you've aliased it.
>
People will rarely have the need to define their own complex
value-types. And if they do they probably know exactly the difference
between struct and class. Most people who develop scientific and
graphics software are very competent and have no problems at all with
this issue. After all most of them understand c++, and that has a lot
more complex issues. Most people who do more mundane stuff will always
use class, just like in java.
[snip]
> Though IMHO it would be better to have used a common
> naming convention for all structs, and to make it different
> from classes. It's better to be on the safe side, if it's cheap
> to do so- and anyway C# could use a more consistant
> approach to this.
>
> C# uses "all lower case" for primitives (and string
> and object!), and "word initial caps" for both non-primitive
I never really understood why string and object are lower-case. Making
only value-types such as int lower case would make a lot more sense.
Adding an S just like adding I for Interfaces also could not help. But
the language designers probably thought that structs will be used only
in cases where it is obvious for everyone (except asj and petilon)
that the type has value semantic. It works fine for me so far. Maybe
visual studio should show value type variables in a slightly different
font or color.
[snip]
> I don't see a need for more than a naming convention
> though, and it's clear we can get along without even
> that.
>
I never had any problems with it. Were it not for people like asj and
petilon, I would never have considered it a problem. It feels very
natural to me. But that is probably because I come from a C++
background and switched to java a few years ago. And I was always
frustrated about the lack of value types in java.
[snip]
>
> I think auto-boxing might be dispensed with when genericity
> makes it into the language. There could be a compiler switch
> that makes it a warning, for instance, once it got to the point
> that you rarely needed it.
>
That would depend on the quality of the generics implementation. I
really like the fact that I use the code for e.g. Hashtable for any
kind of object. That way, only a very small piece of code has to be
present in the processor cache. If there were different hashtable
implementations for all kinds of data types, the amount of code that
has to be accessed would be greatly increased. You can see that with
c++ libraries that rely heavily on templates: they tend to have a very
large working set and thus big problems with small cache sizes and
lots of memory consumption.
> [snip]
> > The java vm does not even have the ability to remove a thread group
> > cleanly without killing the VM. .NET has the concept of AppContexts,
> > i.e. you can have many completely separated AppContexts on one VM, and
> > you can remove one of them without affecting the others. This is very
> > useful for large, failure-tolerant systems. And that is just one of
> > many examples for enterprise features lacking in the java vm.
>
> I believe you mean "AppDomain" not "AppContext";
> an "AppDomain" is an isolated environment where assemblies
> may be loaded and run, which has its own security configuration.
>
You are right. I did not look up the class name. Something like
AppDomains is extremely useful. E.g. When you have a servlet container
running servlets for different customers on one machine, a
malfunctioning servlet from one company can make the whole servlet
container useless. In .NET you would just launch the servlets in
different AppDomains and kill a domain that misbehaves.
> In .NET, you load assemblies into app domains, but you can only
> unload the whole app domain.
>
> [snip]
> > The lack of layout management in Windows.Forms is, at least for me,
> > the biggest deficiency of the .NET library.
>
> Which is odd, because Windows Forms *does have* layout
> management. Look at the Dock and Anchor properties. It's really
> very nice, and much simpler to use that Java layout objects.
>
I agree that it is simple to use, but it is not possible to create
decent size-independent layouts with it, so it is not real layout
management. Take for example a dialog box containing a few buttons
with varying text. With Dock and Anchor it is not possible to lay out
the buttons in such a way that they change their size when their text
is changed. This will be a pain in the ass, especially for
localization and for applications that run both on ultra-high
resolution tft displays and low-resolution handhelds. It is not even
possible to find out how large a Control wants to be, since there are
no MinimumSize or PreferredSize properties.
How would I write a layout consisting of three columns that
automatically have 1/3 of the width of the parent widget with Anchor
and Dock properties? I think it is impossible.
> > The Windows.Forms
> > namespace is basically just a thin wrapper around the windows widget
> > and drawing system.
>
> That isn't even vaguely true of Windows.Forms. System.Drawing is
> a thin wrapper around GDI+, but Windows.Forms is not thin at all,
> and it includes significant functionality not found in USER32.DLL:
> like layout management.
>
I do not find the Anchor and Dock properties very useful. For real
layout management, take a look at the layout management approach in
the widget toolkit of Mac OS X. I think it is called cocoa or
something. A friend of mine bought an eBook and showed me the included
dialog builder tools, and I was really impressed.
> > There are plenty of methods that actually need a
> > handle,
>
> No, there are not. Not in Windows Forms.
>
I agree that most methods requiring a Handle are in System.Drawing,
but there are some in Windows.Forms, for example:
Windows.Forms.CommonDialog:
[C#]
protected virtual IntPtr HookProc(
IntPtr hWnd,
int msg,
IntPtr wparam,
IntPtr lparam
);
Windows.Forms.Control:
[C#]
public static Control FromHandle(
IntPtr handle
);
I am aware that most of these methods exist to make interaction with
native programs easier. But it is still messy and not portable. Most
.NET client applications will not be portable anyway, since they will
use some non-standardized windows dll.
regards,
tuttle
Jason Kratz
> > > > I have no Java blinders (the majority of my daytime work has nothing
> to
> > do
> > > > with Java).
> > >
> > > You defend currentTimeMillis as consistent. You defend patchwork Java
> > > IDEs as consistent. You have Java blinders.
> > >
> >
> > You refute that currentTimeMillis existed before the JavaBeans API (and
> the
> > standard of get/set). You can't come up with any reasons as to how IDEs
> are
> > patchwork and inconsistent. You have VS.NET blinders.
>
> It's sad to watch you keep beating your head against a door.
>
Funny...I was thinking the same thing about you.
> Simply because I state that currentTimeMillis is completely inconsistent
> with the rest of the J2API does not mean I have VS.NET anything.
>
Yes but you do have VS.NET blinders.
> It is inconsistent, why can't you simply admit that fact?
>
Why should I? It isn't inconsistent with what was around at the time that
method was written. What can't you simply admit that fact?
> Sure, it was around before. But why is it still there? Sun has
> deprecated many methods for many reasons, why not this one?
>
Ask Sun. I have no idea.
> There's no good reason you might answer. Ok, fair enough, but my
> statement that it's inconsistent still remains. Sun has had the
> opportunity to make it more consistent, yet they have not.
>
The answer is totally obvious actually.
> Back to the original argument which you conveniently ignore,
> the .NET FCL is not as inconsistent as the J2API. I didn't
> say it was better or worse or whatever, just that it's
> not as inconsistent. Anders (I believe his name was) argued
> that the FCL was inconsistent and that the J2API was not.
>
Yep. That is true and i'm not ignoring it. I was never arguing about
anything in .NET being inconsistent.
> >
> > > > I can also see simple concepts quite easily however that
> > > > requires that they make sense.
> > >
> > > Well, you completely missed the whole argument. That was a pretty
> > > simple concept...
> > >
> >
> > Funny coming from the guy who makes up facts, presents opinion as fact,
or
> > gets lost in his own arguments. Youre a funny guy.
>
> Makes up facts? Cite please. Presents opinion as fact? Cite please?
>
See below.
> All I see from you is bs and more bs and amusing defenses for Java's
> quirks and inconsistencies and blind statements about how evil
> Microsoft is without every one piece of evidence to back it up.
>
Really? I gave plenty of evidence of how MS is 'evil' but you shouted read
Ayn Rand!!! Read Ayn Rand!!! Like Ayn Rand is the answer to anything.
Mind showing where I am defending any Java quirks and inconsistencies? This
thread is getting so long that my memory is failing me. Oh....you mean
System.currentTimeMillis()? Not inconsistent.
> I have presented pieces of evidence and you don't even refute them,
> you make excuses and apologize for Sun and Java. You are a Sun/Java
> apologist and you have blinders. Just admit it. Admitting you have
> a problem is the first step to being cured.
>
Really? What excuses and apologies? You mean about the court cases?
System.currentTimeMillis()? No apologies were necessary or given for those.
Yes....admitting you have a problem is the first step to being cured. I'd
suggest you have to admit you have a problem following Objectivism. After
all...admitting you have a problem is the first step.
> >
> > > > You aren't making any sense. Apparently
> > > > your VS.NET blinders are making you have issues with typing or
> > something.
> > >
> > > There are better IDEs for VS.NET, just not any Java IDE's I've seen.
> > >
> >
> > Oh are there? Care to point them out and why?
>
> Let me rephrase, I'm sure that VS.NET is not the best IDE that
> ever existed and there are certainly IDEs that will be better in
> the future. There probably are today, but I don't know of any off
> the top of my head.
>
Ah. So now you have to rephrase. In other words you were spewing again
right? And then you say there might be better IDE's but you really don't
know. Want your cite for both making up facts and passing off opinion as
fact? You got one good example right there.
> I, unlike others *cough*you*cough* am not so arrogant to think
> that my IDE is the best ever and none could ever be better.
>
Where did I say my IDE is the best ever and none could ever be better?
JEdit is not and IDE and I know of other editors that are far better. None
of those are free though.
> I do happen to know for a fact, that no Java IDE matches the
> level of functionality, consistency, productivity and integration
> that VS.NET offers.
There is your second cite Chet.
>Yes, VS.NET does not have refactoring currently,
> but it still outnumbers all Java IDEs (that I've seen so far)
> with features.
>
Such as?
> >
> > > > Can you point us to the plugins youre referring to? I'd be curious
to
> > see
> > > > just what quirks and inconsistencies youre referring to. For
> example
> > I
> > > > use JEdit (http://www.jedit.org) for all my coding needs. It relies
> > > > extensively on plugins and has a nice plugin API yet somehow I'm not
> > > seeing
> > > > the quirks and inconsistencies you're talking about.
> > >
> > > I use jEdit frequently as well, and it is the prime example of what
> > > I'm talking about. If you don't know what I'm talking about, then
> > > either a.) You haven't actually used jEdit, b.) You've never used
> > > a jEdit plugin, or c.) You're bullshitting.
> > >
> >
> > Ah. So your evidence is that solid huh?
>
> See below. It is obvious as water is wet that jEdit has many quirks,
> bugs, and inconsistencies. Your attempts to dispute this are
> simply amusing.
>
I'm sure they are to a person with VS.NET blinders. Wait a second
though....what quirks, bugs, and inconsistencies does JEdit have? We were
talking about plugins before? Are you changing the subject on me?
> > I have no clue what you're talking about.
>
> Case in point.
>
Point in what case?
> > I use JEdit every single day for Cold Fusion programming, Perl, and
> > PL/SQL.
>
> Cold Fusion "programming" huh? That's a laugh.
>
Is it? Care to explain why? Have you done extensive work in Cold Fusion to
make any judgements?
> > Would you like the list of JEdit plugins I use too? I'm kind of
> > curious...why would someone who is raving about VS.NET, .NET in general
> and
> > who apparently doesn't do any Java programming anymore using JEdit? Did
> you
> > just download it for the sake of arguing?
>
> No. I used it daily for a little over 2 years. I still use it, though
> not quite daily. It is too slow and cumbersome compared to VS.NET.
>
Oh....I'm suuuure it is.
> >
> > > Ok, let's fire up jEdit shall we? Version 4.1pre2. 5 minutes later
after
> > > it's loaded, go to Utilities->Global Options.
> > >
> >
> > Apparently you have something less than a P3-500 notebook with 256mb of
> RAM.
> > Only took 20 seconds for JEdit to fire up here (v 4.0).
>
> 5 minutes was an exaggeration,
Of course it was.
> but on my P3-533 with 256, it certainly
> takes much longer than 20 seconds.
Sucks to be you then.
> From dbl-click to typing, my
> experience was around 40 seconds (41 to be exact). And that was
> after I had already loaded it earlier today.
As I said...it sucks to be you.
> When I'm off a reboot,
> it takes longer on first startup. Probably something like 50 seconds,
> but I haven't clocked it. At any rate, that's not what I was arguing,
> whether it takes 1 second or 100, it still has inconsistencies.
>
Actually you said the plugins have inconsistencies.
> >
> > > Expand Plugins and click around. You'll see a hodgepodge of various
> > > plugin configuration UIs all with various quirks.
> > >
> >
> > Funny. I see various UIs that all use the same set of UI widgets in
> pretty
> > much the same way (checkboxes, dropdowns, etc). Also funny that once
> I've
> > gone thru them and set up the options I like I don't have to do it
again.
> > Where is the drop in productivity?
>
> So, using checkboxes and buttons in various configurations, layouts,
> alignments, etc is consistent to you?
>
If the various configurations are the same of course.
> Therefore, by your definition, the Mac UI and the Windows UI are
> consistent because they use buttons and checkboxes? Absurd. Now you're
> being ridiculous and your apologies are nothing less than completely
> amusing.
>
If the Mac UI and Windows UI use them in a consistent manner sure. Using the
built-in UI widgets gets you consistency. Making up your own doesn't. That
is how one comes up with UI standards Chet.
> >
> > > Note that the memento, Spell Check, and SQL plugins have a "NO LABEL
> > > PROPERTY" prefix. Great consistency there. Some displays are
> > > vertical-aligned top, some middle, some bottom.
> > >
> >
> > Don't use any of those but I just downloaded the SQL plugin and
SpellCheck
> > and I still have no idea wtf you're talking about. Are you seriously
> > telling me that alignment problems cause a drop in productivity?
>
> Slightly, yes. However, the point is, the plugins are inconsistent due
> to lack of programmer discipline. This type of inconsistency throughs
> off motor memory and encourages errors and user mistakes.
Hahahahahaha! God damn I don't know where you store that stuff but you sure
have a nice pile of bullshit to pull things from. Motor memory only comes
about from doing something over and over again. Option panes for a plugin
are not something that would benefit from motor memory (hint: you don't use
them often enough). Stuff like Cut/Copy/Paste shortcuts are (hint: you use
them all the time).
> I suggest
> you read a book on UI design. However, such books will probably burn
> the hands of a Java developer.
>
I've read plenty of books on UI design. Maybe you should actually read one
instead of making shit up.
> > > Go to the LookAndFeel plugin, select Oyoha as the L&F. Notice
> > > the two textboxes that appear. Notice the text running off the right
> > > hand side of the dialog, requiring a resize to see it.
> > >
> >
> > Yep. Don't see that as a productivity sink.
>
> Look, if you're unwilling to face hard facts and keep your hands over
> your eyes, I can't help you.
What hard facts are you presenting? That crap you brought up about the text
is not a productivity sink. Is it annoying? Sure. Is it going to keep me
from doing work or working quickly? Hardly. Maybe you consider going into
look-and-feel options dialogs all the time as something that is productive?
> No amount of common sense and facts
> will illustrate to you that Java IDEs just don't compare with
> VS.NET.
>
What facts? You still haven't presented any....especially about VS.NET.
Youve shared a lot of opinion though.
> <SNIP More demonstrations which were ignored and blinded by
> the Jason's blinders>
>
Whatever.
> > > Now, please demonstrate several examples of this kind of
> > > inconsistency and poor programming in VS.NET.
> > >
> >
> > Can't and never said I could. Haven't used VS.NET ever and am not
> planning
> > on it anytime soon.
>
> And there we have it. Argument from ignorance. You have argued this
> whole time that Java IDEs are better than VS.NET, yet you HAVEN'T EVEN
> USED IT?
>
What argument? I haven't been arguing about VS.NET at all.
> > > Another? When was the first? Given the very specific and
> > > poignant examples above, I think it's safe so say that you're
> > > the one with no clue and who makes things up or conveniently
> > > ignores arguments to keep the blinders going full bore.
> > >
> >
> > Dude...you've been spewing garbage in every thread you're involved in.
>
> Ah, as opposed to the insightful, fact filled embarassment you just
> committed the past 3-4 posts in this thread?
>
Its all been very insightful. You bring up bullshit excuses for argument
and I refute them.
> If you call that fact, I'm happy that you call what I say Garbage.
>
No. I call your opinion garbage because you attempt to pass it off as fact.
> In Kratese, that means fact, I guess.
>
Heh. whatever.
> > The best part was when you said I should read Ayn Rand.
>
> Or anything, really. Your distored world view, or lack thereof
> is disturbing.
>
Which distortion are you referring to? Oh...I know...the one you dont agree
with! If everyone doesn't agree with Chad they must certainly be distorted!
I understand now.
> To think that there are so horribly undereducated unintelligent
> people voting for the people that charge me taxes and make the
> laws that I must follow is horrifying to me.
>
Imagine that. They should just lock up all the stupid people who don't
agree with you and that would make your world so much easier. I can see how
that would be horrifying to you.
> To think that you would rather than the government run everything
> for us and tuck us in at night, despite all the lessons we
> have learned for thousands of years of government abuse and
> human corruption makes me doubt humanity as a whole.
>
Wow Chad. Now you're even speaking for me. Damn you're good!
Hell....why don't you just speak for everyone in these newsgroups? You seem
to be trying awfully hard.
> The fact that you dismiss intellectual discourse out of hand
> is equally as shocking.
>
Oh? What "intellectual discourse" are you referring to?
> > That was the absolute best. Of course you assumed that I hadn't read
> > Ayn Rand but that is just a nit.
>
> I doubt that you've read anything.
>
I'm sure you do. That would make you secure in your own little world.
> > I'm not ignoring anything but the opinion you're trying to pass off as
> > fact.
>
> Ah, and which is that? Opinion? You mean the several explicit examples
> of evidence I gave supporting the other facts I talked about, as
> opposed to your simple and ignorant dismissals in the face of common
> sense?
>
Whos common sense? You certainly haven't been showing any.
> Again, if evidence is opinion in your world, then I'll be happy to
> be called an opinionated person by you.
>
Which evidence? You never showed evidence.
> > Your 'very specific and poignant examples' still didn't show any
> > inconsistency that causes interruption to work flow or slows down
> > productivity.
>
> If you can't see it, I don't know what will prove it to you. In fact,
> I suspect that you are incapable of seeing any fact.
Oh I can see fact. You just haven't presented any yet to see? Is this
part sinking in yet?
> Your constant
> recitations of "Java is King. Must hate Microsoft" only drone on
> and lend you no credibility.
>
Care to cite where I recited "Java is King. Must hate Microsoft"?
> > You also ignore that the various plugin UIs all have their
> > options entered in a consistent manner via a standard plugin UI/API (as
a
> > regular JEdit user I'm sure you know what I'm referring to) but
hey...who
> > cares right? Long as you can advocate VS.NET....
>
> I didn't say that consistent plugins didn't exist, I just said that
> they are most inconsistent and indeed, most of the plugins were
> inconsistent with themselves, and most certainly with the rest of the
> UI.
>
My statement went totally over your head. Not to mention that paragraph
made absolutely no sense.
> In some places there are graphical buttons, in some places there
> aren't. In some places widgets behave differently than in other
> places, etc.
>
Really? I've seen consistent use of graphical buttons in the plugins (for
instance..opening a file dialog like in the L&F options). Those are the
only graphical buttons I've seen in any of the options UIs. I also
haven't seen widgets that behave differently than in other places. Buttons
are buttons, checkboxes are checkboxes, etc.
> Deny if you wish, but it doesn't change the facts that are so
> obvious to everyone else.
>
Apparently only obvious to you. But then again you talk for everyone else
right?
Anders Dahlberg
<snipped chad having trouble with a jdk1.0 method not following > jdk1.1
beans naming conventions>
Here you go:
// where getInstance() also can take either a Locale or a TimeZone
Calendar.getInstance().getTimeInMillis();
Same thing, but *consistent*
> -c
(hd on my regular news-server went dead today - thus posting this via
msnews.microsoft.com)
--
When replying - ".tabort" is not needed
/Anders
Chad Myers
"Anders Dahlberg" <anders71...@student.tabort.liu.se> wrote in message
news:eNAFHzlQCHA.1672@tkmsftngp12...
> Chad Myers wrote:
> <snipped chad having trouble with a jdk1.0 method not following > jdk1.1
> beans naming conventions>
LOL, nice try. Making yourself sound smarter doesn't actually make you
smarter. You're just making excuses. Your excuses don't change the
fact that it's still there, despite Sun having ample opportunity to
change it.
> Here you go:
> // where getInstance() also can take either a Locale or a TimeZone
> Calendar.getInstance().getTimeInMillis();
> Same thing, but *consistent*
Ok, but currentTimeMillis still exists. That's the problem you so
conveniently ignore.
Backwards compatibility? Hasn't stopped them from deprecating other
methods.
Instead they choose to leave it in there which confuses the API
and makes it (once again I point out) INCONSISTENT.
Your excuses do not change the fact. They have not removed it,
it's still there, and it's still inconsistent.
Your assertion that the J2API is not inconsistent is false.
You have to do prove otherwise.
-c
Anders Dahlberg
> "Anders Dahlberg" <anders71...@student.tabort.liu.se> wrote in message
> news:eNAFHzlQCHA.1672@tkmsftngp12...
>
>>Chad Myers wrote:
>><snipped chad having trouble with a jdk1.0 method not following > jdk1.1
>>beans naming conventions>
>
>
> LOL, nice try. Making yourself sound smarter doesn't actually make you
> smarter.
> You're just making excuses.
Nope, no excuses...
> Your excuses don't change the
> fact that it's still there, despite Sun having ample opportunity to
> change it.
repeat after me: "Backwards compability"
You're *still* having trouble with that?
>
>>Here you go:
>>// where getInstance() also can take either a Locale or a TimeZone
>>Calendar.getInstance().getTimeInMillis();
>>Same thing, but *consistent*
>
>
> Ok, but currentTimeMillis still exists.
repeat after me: "Backwards compability"
You're *still* having trouble with that?
> That's the problem you so
> conveniently ignore.
Nope, I see no problem there through my nice $200k Oracle J2ME enhanced
sun-glasses with J2EE services through proxy ... :)
> Backwards compatibility? Hasn't stopped them from deprecating other
> methods.
Probably because that getCurrentTimeMillis() isn't that different from
currentTimeMillis() + the Calendar option now exists?
> Instead they choose to leave it in there which confuses the API
> and makes it (once again I point out) INCONSISTENT.
^^^^^^^^^^^^^^^^^^^^^^^^
LOL
Excuse me, but to me it seams you're the only one having trouble with
your conceived "inconsistency problems"
>
> Your excuses do not change the fact. They have not removed it,
> it's still there, and it's still inconsistent.
>
> Your assertion that the J2API is not inconsistent is false.
Your assertion that my assertion is false is totally bogus as I've never
made that assertion in the first place which leads to the fact that you
have totally lost it :)
>
> You have to do prove otherwise.
Why should I "prove" that .NET api is less consistent than j2se api when
your then one having trouble with it, I don't care either way*? Because
otherwise you'll scream and moun ".NET api is not
less consistent than j2se api" for the next couple of months or what?
> -c
* As you should remember this thread started by tuttle by asking what
changes/additions to .NET people in comp.lang.java.advocacy (among
other) would require for considering using it.
One of my points was that I would like .NET api to "better
designed"/"more clean"
This have *nothing* to do with java.
Chad Myers
> Chad Myers wrote:
> > "Anders Dahlberg" <anders71...@student.tabort.liu.se> wrote in
message
> > news:eNAFHzlQCHA.1672@tkmsftngp12...
> >
> >>Chad Myers wrote:
> >><snipped chad having trouble with a jdk1.0 method not following > jdk1.1
> >>beans naming conventions>
> >
> >
> > LOL, nice try. Making yourself sound smarter doesn't actually make you
> > smarter.
> ? I was just stating the obvious
What, that you fail to grasp the concept?
Do you really think I don't know that currentTimeMillis came before
jdk1.1? Of course I do.
It is YOU who has the problem grasping the obvious. You still don't
seem to get that it is STILL THERE making the API inconsistent.
>
> > You're just making excuses.
> Nope, no excuses...
Yes, you are making excuses for why it is there. Did you not give
me a big diatribe on how important backwards compatibility was?
Nevermind that other methods have been deprecated, but I digress...
> > Your excuses don't change the
> > fact that it's still there, despite Sun having ample opportunity to
> > change it.
> repeat after me: "Backwards compability"
Excuses. Sun has deprecated other methods. Backwards compatibility has
never been a problem before.
At any rate, if they chose that, then fine, so be it. But, back
to the original argument which you keep doding, it makes the API
INCONSISTENT. Your reasons are merely excuses.
YOU CLAIMED that the J2API wasn't inconsistent, but indeed it is
and you fail to refute this.
-c
Anders Dahlberg
<snip>
What's the point of answering when you don't read what I post? Here let
me make it easy for you:
1a, I gave some examples (answer to tuttle) of changes/additions to .NET
I would require for considering using it. One of my points was that I
would like .NET api to be "better designed"/"more clean"
b, You began raving about some conceived "inconsistensies" in j2se api
(?) even though I was talking about enhancement to .NET
c, I didn't agree with you
2a, You brought up System.currentTimeMillis() as "proof"
b, I told you that it was from pre jdk1.1 (which is also pre j2se)
thus no naming conventions in place and that backward compability is
important
c, You're still having trouble with a method from jdk1.0 not following
naming conventions of >= jdk1.1 (?)
d, You argue that this method should be deleted/deprecated (?)
e, I argue that it shouldn't as backward compatibility is important,
Calendar.getInstance().getTimeMillis() is available anyway and
System.currentTimeMillis() only problem being a lacking get-prefix
f, You still think it should be deleted/deprecated (??)
g, I don't
h, You still still etc etc etc
3a, I don't give a shit if you says "j2se api is inconsistent"
b, You think I do (?)
c, IMO .NET api is not well-designed/clean enough for me to consider
using it (e.g. no java involved in this point)
d, You're still saying "j2se api is inconsistent"
NOW, do you understand what I'm talking about here?
> -c
ROFL
Cameron Purdy
> Smalltalk or FORTH. Java is many things, but it is only simple
> compared to C++.
I don't know FORTH, but Java is (IMHO) simpler by at least an order of
magnitude than C++, and by a large (though less impressive) margin compared
to Smalltalk. (Functions? We don't need no stinking functions.)
Peace,
Cameron Purdy
Tangosol, Inc.
.NET to J2EE porting service available
"Dan Johnson" <daniel...@vzavenue.net> wrote in message
news:ulg884l...@news.supernews.com...
>
Cameron Purdy
> Backwards compatibility? Hasn't stopped them from deprecating other
> methods.
> Instead they choose to leave it in there which confuses the API
> and makes it (once again I point out) INCONSISTENT.
I don't mean to make you sound ignorant (again) but "deprecating" means
leaving it in there. Purposefully.
I think you can do something similar in .NET with some square brackets and
crap after the method declaration.
(If you're interested in debates on the "inconsistent" part of the
libraries, check out the recent threads on JavaLobby.com and
TheServerSide.com about "Java 3.0".)
Peace,
Cameron Purdy
Tangosol, Inc.
.NET to J2EE porting service available
"Chad Myers" <cmy...@N0.SP.4M.austin.rr.com> wrote in message
news:zcY59.81764$Yd.36...@twister.austin.rr.com...
>
Courageous
>I don't mean to make you sound ignorant (again) but "deprecating" means
>leaving it in there. Purposefully.
It also means marking it @deprecated and coming up with a preferred
interface. @deprecated means it's no longer to be used and, IIRC, that
it could be removed in future versions of Java.
C//
tuttle
> tuttle wrote:
>
> <snip>
>
> > How would you write a complex number class in a language without value
> > types such as java?
>
> It is trivial to do so.
>
efficient complex number class in java because of the absense of value
types. Take for example an array of 1000000 complex numbers. In c# it
is a memory block of 16 megabytes size filled with zeros. In java, it
is a pointer array of 4 megabytes size (on 32bit systems) and 1000000
objects on the heap. Allocating 1000000 objects on the heap is not
exactly fast, you know. And accessing objects that are spread all over
the heap completely destroys cache consistency. Garbage collecting
1000000 objects on the heap is a real PITA.
And besides, a complex number class feels much more natural if it has
value type semantic.
> > I am not asking for something complicated. Even a
> > talented 8th grader can write a well-performing and easy to use
> > complex number class in C++ or C#. But can you do it in java?
>
> Of course you can. Java is Turing complete.
>
So is a turing machine. That does not mean that a turing machine is
the best way to write programs.
> > Well I guess complex numbers and vectors are not that important
> > then...
>
> I didn't have any trouble porting Eric Gunnerson's 'collide' code (which
> uses several value types) to Java.
>
But the performance was probably a factor of 10 worse. If you want to
convince me, just write a mandelbrot set viewer in java that does use
a Complex class. If the performance is within a factor of 2 to the C#
version I will be really impressed. But I suspect that it will be
much, much worse.
regards,
tuttle
Dan Johnson
news:1006f17d.02081...@posting.google.com...
> > for certain kinds of code; in theory, of course, you only need
> > a compiler that can perform the same optimization without
> > hints, but those turn out to be very hard to implement.
> >
> Such compilers are not available and will not be available for some
> time. There has been some talk at sun about automatically creating
> short-lived objects on the stack. But only talk so far, and this is
> only a tiny part of the problem.
It is a difficult problem.
> [snipped lots of stuff where we agreed]
> > The reverse error, using a class for a struct, is actually much more
> > difficult to find. When you do this, you get aliasing, where two
> > variables that may be widely separated can affect each other;
> > if you do this in error you presumably don't realize it, and it can be
> > a lot of fun trying to figure out why thus-and-such a private variable
> > changed, if you do not realize you've aliased it.
> >
> People will rarely have the need to define their own complex
> value-types. And if they do they probably know exactly the difference
> between struct and class.
I wrote that passage in teh context of developing
a *framework*; if you were writing one for numerical
computations, writing a value type for complex numbers
would not seem strange, I think.
> Most people who develop scientific and
> graphics software are very competent and have no problems at all with
> this issue. After all most of them understand c++, and that has a lot
> more complex issues. Most people who do more mundane stuff will always
> use class, just like in java.
Struct isn't *that* hard, though.. I do not think it will
be a problem for ordinary developers to use it from
time to time.
> [snip]
> > Though IMHO it would be better to have used a common
> > naming convention for all structs, and to make it different
> > from classes. It's better to be on the safe side, if it's cheap
> > to do so- and anyway C# could use a more consistant
> > approach to this.
> >
> > C# uses "all lower case" for primitives (and string
> > and object!), and "word initial caps" for both non-primitive
> I never really understood why string and object are lower-case.
As far as I can tell, it is because they are keywords.
> Making
> only value-types such as int lower case would make a lot more sense.
> Adding an S just like adding I for Interfaces also could not help. But
> the language designers probably thought that structs will be used only
> in cases where it is obvious for everyone (except asj and petilon)
> that the type has value semantic. It works fine for me so far. Maybe
> visual studio should show value type variables in a slightly different
> font or color.
It does have tooltips that show you what they are, but
not coloration.
However, you are basically right: only Petlion gets
confused about this in practice. :D
I therefore would do nothing that makes structs more
difficult to use to solve this nonproblem.
[snip]
> > I don't see a need for more than a naming convention
> > though, and it's clear we can get along without even
> > that.
> >
> I never had any problems with it.
That's why it's clear. :D
> Were it not for people like asj and
> petilon, I would never have considered it a problem. It feels very
> natural to me. But that is probably because I come from a C++
> background and switched to java a few years ago. And I was always
> frustrated about the lack of value types in java.
That may be so on. If you are sufficiently wrapped up in
OO, it can be very hard to think of non-OO constructs
in their own terms. Structs do seem very strange if you
can think only as funny classes.
[snip]
> > I think auto-boxing might be dispensed with when genericity
> > makes it into the language. There could be a compiler switch
> > that makes it a warning, for instance, once it got to the point
> > that you rarely needed it.
> >
> That would depend on the quality of the generics implementation.
It would have to be able to accept values, but that seems
unproblematic, as it can already do that without generics.
> I
> really like the fact that I use the code for e.g. Hashtable for any
> kind of object. That way, only a very small piece of code has to be
> present in the processor cache. If there were different hashtable
> implementations for all kinds of data types, the amount of code that
> has to be accessed would be greatly increased. You can see that with
> c++ libraries that rely heavily on templates: they tend to have a very
> large working set and thus big problems with small cache sizes and
> lots of memory consumption.
Microsoft has put some whitepapers out about this. Their idea is to
generate an different implementation for each phyiscal representation
needed. All reference types get one implementation, and value types
get others. But Size and Point would share an implementation, because
they have the same fields in the same order.
This seems a good compromise. It greatly reduces the number of
implementations, and still lets them inline value types in most
cases.
[snip]
> > Which is odd, because Windows Forms *does have* layout
> > management. Look at the Dock and Anchor properties. It's really
> > very nice, and much simpler to use that Java layout objects.
> >
> I agree that it is simple to use, but it is not possible to create
> decent size-independent layouts with it, so it is not real layout
> management.
I have no difficulty doing so.
> Take for example a dialog box containing a few buttons
> with varying text. With Dock and Anchor it is not possible to lay out
> the buttons in such a way that they change their size when their text
> is changed.
That is because Button does not change its size to match
its text, not anything to do with layouts. If you create a Button
that *does* change its own size to fits its text, then you can
use Docking to change other parts of the dialog- within
some limits.
That doesn't really change the fact that there's no
provision in Windows Forms to do what you want
directly.
The thing to bear in mind is that Windows Forms is
intended to implement Microsoft's UI only, and what
you are describing is a violation of their UI guidelines,
if I recall them correctly. Buttons aren't supposed to
change size dynamically.
> this will be a pain in the ass, especially for
> localization and for applications that run both on ultra-high
> resolution tft displays and low-resolution handhelds.
Well, resolution changes are handled through a scaling
mechanism, same as in Win32, not through layouts.
You are going to have to get your hands dirty when you
localize an app, though.
> It is not even
> possible to find out how large a Control wants to be, since there are
> no MinimumSize or PreferredSize properties.
>
> How would I write a layout consisting of three columns that
> automatically have 1/3 of the width of the parent widget with Anchor
> and Dock properties? I think it is impossible.
It is impossible. But it is still an error to say that Windows Forms
have *no layout functionality* because it cannot do everything
you can think of. They are not indended to implement an arbitrary
UI, but a Microsoft one.
And in Microsoft's world, you'd have three colums that you
resize using splitter bars, and one of them (only) would
change size when you resize the window. Explorer is like
that.
Windows Forms *can* do that; docking is a very nice way
to handle splitter bars. It's possible you do not like Explorer-like
interfaces, but you should not dismiss the the functionality that
Windows Forms provides to implement them.
[snip]
> > That isn't even vaguely true of Windows.Forms. System.Drawing is
> > a thin wrapper around GDI+, but Windows.Forms is not thin at all,
> > and it includes significant functionality not found in USER32.DLL:
> > like layout management.
> >
> I do not find the Anchor and Dock properties very useful.
They are nevertheless not present in Win32. And there's
other stuff. Windows Forms has controls that don't exist in
Win32, like System.Windows.Forms.DataGrid. It has
features like per-control double buffering that you have
to do by hand in Win32.
Many things that both APIs do, Forms does better or more
completely, like Tab controls. In Win32 a tab control is just
the tabs, and you must position and hide/show the tab *pages*
yourself. In Forms, the TabControl has TabPages as children
and it places them and displays them for you.
If you want to see what a thin layer on Win32 looks like,
check out MFC sometime.
> For real
> layout management, take a look at the layout management approach in
> the widget toolkit of Mac OS X. I think it is called cocoa or
> something.
I've read about it. It's identitical to anchoring, unless
I've missed something. I might have, Apple's docs (on their
website) are not all that great
> A friend of mine bought an eBook and showed me the included
> dialog builder tools, and I was really impressed.
What impressed you?
[snip]
> > No, there are not. Not in Windows Forms.
> >
> I agree that most methods requiring a Handle are in System.Drawing,
.. and there aren't all that many even there. But that is, of course,
irrelevant to the question of whether System.Drawing is a thin or
a think layer. There's a pretty good 1-to-1 correspondance between
System.Drawing's methods and classes and GDI+'s when accessed
with native code. So it is thin layer, and would be even if no handles
were ever visible.
In fact, System.Drawing never gives you direct access to
an unmanaged GDI+ object pointer. Those handles are there
so you can switch to using GDI32, which you might want to
do because it is a lot faster.
> but there are some in Windows.Forms, for example:
> Windows.Forms.CommonDialog:
> [C#]
> protected virtual IntPtr HookProc(
> IntPtr hWnd,
> int msg,
> IntPtr wparam,
> IntPtr lparam
> );
>
> Windows.Forms.Control:
> [C#]
> public static Control FromHandle(
> IntPtr handle
> );
There are a very few methods like these present to support
using Windows Forms and Win32 together. If you don't
want to use Win32 also, you won't use these methods.
They form a very small minority of the methods in
Windows Forms. You do not need to resort to handles
to use any of Windows Forms functionality.
> I am aware that most of these methods exist to make interaction with
> native programs easier. But it is still messy and not portable. Most
> .NET client applications will not be portable anyway, since they will
> use some non-standardized windows dll.
Microsoft was clearly not even trying to be portable, but I
disagree that these methods are "messy"; they are the simplest
way I can see to handle interaction between Win32 and
Windows Forms code for the same Window when desired;
they are completely nonintrusive if you don't want to do that.
I'd like to know how you'd do this, if you were to redesign
Windows Forms?
Dan Johnson
"Cameron Purdy" <cpu...@tangosol.com> wrote in message
news:uYyRL8nQCHA.212@tkmsftngp11...
> > Come on. If you really favored simplicilty, you'd be hawking
> > Smalltalk or FORTH. Java is many things, but it is only simple
> > compared to C++.
>
> I don't know FORTH,
That's probably just as well. FORTH is very strange
and while it is brutally simple, it is very difficult to write
high level code in such a low level language. It's not
a plausible alternative to Java, simplicity or no. Smalltalk
is a better example.
> but Java is (IMHO) simpler by at least an order of
> magnitude than C++, and by a large (though less impressive) margin
compared
> to Smalltalk. (Functions? We don't need no stinking functions.)
Everything is simpler than C++. :D
Java is not simpler than Smalltalk by any stretch of the
imagination. Java has lots and lots of extra cruft, like
static methods, final method, primitives and interfaces, and
so on. Smalltalk doesn't need that stuff. Smalltalk does have
closures, but while that's certainly cruft, it's still a lot simpler
than anonymous inner classes. Smalltalk has doesNotUnderstand,
but that's still a lot simpler than java.lang.reflect.Proxy.
Smalltalk takes it to an extreme. It doesn't even have
*operator precedence*; even that is too complex for
Smalltalk. Operators behave just like binary functions
(er, "messages".) The syntax is strange but it is
relentlessly consistant.
Mind, I personally tend to like formalisms like interfaces
and value types; they express what I mean better than
informal protocols and flyweight objects would. But if
simplicity is your thing, then Java is a very strange choice:
there are *much* simpler languages with similar capabilities.
Cameron Purdy
> imagination. Java has lots and lots of extra cruft, like
> static methods, final method, primitives and interfaces, and
> so on. Smalltalk doesn't need that stuff. Smalltalk does have
> closures, but while that's certainly cruft, it's still a lot simpler
> than anonymous inner classes. Smalltalk has doesNotUnderstand,
> but that's still a lot simpler than java.lang.reflect.Proxy.
I came to Smalltalk from C++, so I didn't find it "natural", as I did Java
(and by relation, C#).
Peace,
Cameron Purdy
Tangosol, Inc.
.NET to J2EE porting service available
"Dan Johnson" <daniel...@vzavenue.net> wrote in message
news:ulhpipq...@news.supernews.com...
>
Cameron Purdy
> In c# it is a memory block of 16 megabytes size filled with
> zeros.
Are these mutable or immutable objects? If immutable, 1000000 objects of
value zero do little good.
If you want most objects to be zero (a huge vector) you'd still be better
off with a sparse array or sparse vector implementation.
> In java, it is a pointer array of 4 megabytes size (on 32bit
> systems) and 1000000 objects on the heap. Allocating
> 1000000 objects on the heap is not exactly fast, you know.
On Hotspot (not the fastest JVM by any stretch) on my notebook it is 511ms
to allocate the array and the 1000000 objects. That includes all garbage
collection costs amortized over 100 iterations.
> And accessing objects that are spread all over
> the heap completely destroys cache consistency.
Very true. Even worse is if you run out of physical RAM and go into swap,
because a heap of objects with some part of the object graph on disk is a
nightmare performance problem.
> Garbage collecting 1000000 objects on the heap is a real PITA.
See above. "Only" 1000000 objects is basically a no-op for modern JVMs.
> And besides, a complex number class feels much more natural
> if it has value type semantic.
Agreed. There are trade-offs for value semantics, but this is one case
(about the only one ;-) where it makes real sense.
Peace,
Cameron Purdy
Tangosol, Inc.
.NET to J2EE porting service available
"tuttle" <mrwro...@yahoo.com> wrote in message
news:1006f17d.0208...@posting.google.com...
>
tuttle
> tuttle wrote:
>
> <snip>
>
> >
> > You *definitely* need some kind of value types to do efficient complex
> > or vector calculations, at least with current processors. Just think
> > about the cache consistency issues: An array of complex numbers in C#
> > is a single, non-fragmented block of memory. An array of complex
> > numbers in java would be an array of pointers and a huge number of
> > totally fragmented, tiny objects on the heap. The performance would be
> > horrible, that is why nobody is using java for this kind of stuff.
>
> Java typically uses a generational garbage collector. A generational GC
> allocates new objects in a nursery, and these allocations are typically
> contiguous, and extremly fast, much like stack allocated objects.
> Objects that live past the nursery stage are transferred elsewhere on
> the heap. The HotSpot VM is fully accurate which means that *all*
> objects can be relocated, which allows the GC to control heap
> fragmentation. See:
>
the stack pointer by the size of the value type object is still much,
much faster than even the best generational gc.
[snip]
> >
> > double xr,xi,cr,ci;
> > ...
> > xr=xr*xr-xi*xi+cr;
> > xi=2*xr*xi+ci;
>
> Why would you write it this way? It can certainly be much improved
> without the use of user defined value types.
>
Using a complex class, the above line would look like this:
x=Complex.sum(Complex.product(x,x),c);
Since a Complex class would have to be immutable just like Integer,
Double etc. to avoid aliasing bugs, the above line would involve
creating two temporary objects. That is simply unacceptable.
> Would you be willing to post your code to the above Complex struct and
> Mandelbrot viewer? I would be happy to port it to Java for the purpose
> of determining if your claims about the necessity of value types for
> this type of work are true. I will post the resulting Java code which
> anyone can compile and use to form their own opinion. Publishing
> results would violate the .NET SDK EULA, but there is nothing
> prohibiting the creation of such comparable code.
>
Sure. I have to find it on my windows machine. I will post it when I
found it.
> <snip>
>
> >
> > You can have ADA for the .NET platform. No problem. But for normal
> > applications I want a language that is easy to write in. Having to
> > write ten times as many characters does not make complex algorithms
> > easier to understand.
>
> I doubt that ten times the characters are required. A well designed
> class based implementation can be fairly easy to read and write.
>
Without operator overloading, many complex formulas will be extremely
long and extremely difficult to read.
Just compare
//mandelbrot iteration:
c#: x=x*x+c;
java: x=Complex.add(Complex.multiply(x,x),c);
//looking up an int in a hashtable using an int as a key:
c# (int)ht[i];
java: ((Integer)ht.get(new Integer(i))).intValue();
Are you seriously claiming that the java code is easier to read and
understand?
[snip]
> > The result is clearer than I thought it would be:
> C# xxxxxxxxxxxxxxxxx
> Java: 526315.7894736842
>
> Considering I get > 580K/sec for Java on my 400MHz Pentium II with JDK
> 1.4.0 beta 3, I'd say your results are less than conclusive. The IBM
> 1.3 VM yields 1,250,000 per second on the same machine.
>
Do you want to imply that I am lying? I am using a normal java1.4 VM
straight from sun and a normal .net framework straight from MS. I am
not willing to try 20 different VMs and different runtime parameters
to get decent performance for a trivial code sample.
[snip]
> > The java vm does not even have the ability to remove a thread group
> > cleanly without killing the VM.
>
> Evidence of this please...
>
Thread.kill() and ThreadGroup.kill() are deprecated. Thus there is no
way to get rid of a malicious, non-cooperating thread. The only way to
get rid of it is to kill the VM.
> > .NET has the concept of AppContexts,
> > i.e. you can have many completely separated AppContexts on one VM, and
> > you can remove one of them without affecting the others. This is very
> > useful for large, failure-tolerant systems. And that is just one of
> > many examples for enterprise features lacking in the java vm.
>
> There is no such thing as 'the Java VM'. For example:
>
> =================================
> The Janos Virtual Machine (JanosVM) is an Open Source virtual machine
> for executing Java bytecodes. Unlike any available virtual machine,
> the JanosVM supports multiple, separate process-like entities (called
> "teams" in the JanosVM) within a single VM, without reliance on any
> underlying OS or hardware support for such separation. The JanosVM
> supports separate per-team heaps, per-team garbage collection threads,
> inter-team thread migration, safe cross-team reference objects, and a
> spiffy tutorial. Designed to support asynchronous termination of
> buggy, uncooperative, or malicious Java bytecode applications, the
> JanosVM provides robust and scalable multi-process support within a
> single virtual machine.
> ===================================
>
This is nice and all, but as long as this is not standardized it is
useless for me and my customers. Is this janos VM ready for production
environments?
[snip]
> How so? The scoping rules in Java are quite well defined and easily
> understood. Any temporary objects are eligible for GC as soon as they
> are out of scope and unreachable.
>
But creating objects on the heap is still much slower than on the
stack, even if they are destroyed immediately after they get out of
scope. Creating a Complex struct on the stack basically involves
pushing two double zeros on the stack. No heap will ever be that fast.
> > Another big advantage of structs: they
> > live on the stack and do not need garbage collection!
>
> A generational collector can allocate contiguously with stack-like
> speed. Why is immediate deallocation of structs significant?
>
Speed is significant. And even after many years of optimization, a
loop in java that creates temporary objects will have a performance
that is almost an order of magnitude worse than allocation on the
stack. This is a fact, even if it is not legal to publish the
benchmark results because of microsofts stupid EULA.
> <snip Hotspot description>
>
> >
> > All this is really nice, but unfortunately it has a lot of overhead,
> > and it takes some time to have an effect.
>
> Evidence of this? As a counterexample, you can set the threshold at
> which compilation begins in the IBM VM. In the Sun VM you can tell it
> to compiler everything up frotn with the -Xcomp switch. Surprise,
> surprise, doing so hurts startup time.
>
Of course it does. But only because there is no support for
precompiled binaries in the big java VMs (sun, ibm).
> <snip>
>
> >
> > The .NET VM on the other hand is very simple. When a method is called,
> > it is immediately compiled to machine code and then executed.
>
> And how long does this compilation take versus interpreting the code?
>
Longer. But that does not matter at all because most code is
precompiled and cached. Even you can not deny that the startup times
for .NET programs are much shorter than for java programs.
> > Since
> > the .NET VM does not know as much about the code as the java VM does,
> > it can not do many of the more sophisticated optimizations like
> > virtual method inlining. But the advantage is that you can precompile
> > MSIL code to machine code and cache the result on disk.
>
> To my knowledge, there is nothing preventing the existence of a caching
> JIT for Java.
>
But it *does* *not* *exist*, neither in the Sun VM nor in the IBM vm.
This is no big deal for server programs that run for months, but it is
simply unacceptable for client programs.
> > Therefore the
> > very large .NET class library (mscorlib.dll) and other often-used
> > libraries are already compiled to machine code when you start your
> > program, so only the code of your program itself has to be JITed. In
> > java on the other hand, every class in the class library that you use
> > has to be JITed each and every time you start your program. When you
> > start JBuilder (which probably uses almost every class in the java
> > class library), the poor java hotspot VM has to JIT-compile the
> > *whole* *class* *library*.
>
> No it doesn't. Your own description of HotSpot above says as much.
>
Of course only the most often used parts of javax.swing are JITed. But
both instances of the Java VM have to analyze the whole code to find
out where the hot spots are. You can not deny that both instances do
basically the same work. This should be cached somehow, but it is not.
Just start up a simple client program such as the eDonkey2000 java GUI
and then tell me with a straight face that this is fast...
>
> > And you know how large that is. This is
> > really braindead: when you start two java programs using swing, you
> > have two java VMs running on your system that do almost exactly the
> > same work (jiting the javax.swing.* classes). Sun promised to do
> > something about this, but they did not deliver.
>
> Where did they make such a promise? Incidentally, I believe that the
> MacOS VM has such a feature.
>
It was somewhere in the feature list of java 1.4 before it was
released. I was really hopeful that it would be included in java 1.4.
But the fact that java 1.4 did not solve the problem of long startup
times convinced me that java is dead as a platform for client
programs.
And the fact that a shared memory VM is available for Mac OS X does
not do me any good since I have x86 machines.
Chad Myers
"Courageous" <jkr...@san.rr.com> wrote in message
news:r13hlu4tik4rqdce9...@4ax.com...
(shh, let Cameron have his moment of glory. We all know he is lost,
and doesn't understand, but it makes him feel better and it's better
for his self esteem)
-c
Jason Kratz
> > Java is not simpler than Smalltalk by any stretch of the
> > imagination. Java has lots and lots of extra cruft, like
> > static methods, final method, primitives and interfaces, and
> > so on. Smalltalk doesn't need that stuff. Smalltalk does have
> > closures, but while that's certainly cruft, it's still a lot simpler
> > than anonymous inner classes. Smalltalk has doesNotUnderstand,
> > but that's still a lot simpler than java.lang.reflect.Proxy.
>
> I came to Smalltalk from C++, so I didn't find it "natural", as I did Java
> (and by relation, C#).
>
Same here (Smalltalk from C++). Was pretty difficult at first but you get
used to it ;)
Cameron Purdy
> Sure. .NET also uses a generational garbage collector.
> But decreasing the stack pointer by the size of the value
> type object is still much, much faster than even the best
> generational gc.
Your technical simplifications aside, that is how most new multi-threaded
generational garbage collectors work today. The first generation is
allocated by advancing the "next" pointer, just as is shown in the classic
K&R. Those objects don't move to a "heap" data structure until the
generation passes.
Peace,
Cameron Purdy
Tangosol, Inc.
.NET to J2EE porting service available
"tuttle" <mrwro...@yahoo.com> wrote in message
news:1006f17d.02081...@posting.google.com...
>
Cameron Purdy
> > >I don't mean to make you sound ignorant (again) but "deprecating" means
> > >leaving it in there. Purposefully.
> > It also means marking it @deprecated and coming up with a preferred
> > interface. @deprecated means it's no longer to be used and, IIRC, that
> > it could be removed in future versions of Java.
> (shh, let Cameron have his moment of glory. We all know he is lost,
> and doesn't understand, but it makes him feel better and it's better
> for his self esteem)
Yes or no question: When you deprecate a method, does that in any way remove
the method or make it less accessible or available or otherwise?
I suggest that you avoid allowing your insecurity to expand on the proof of
your lack of knowledge.
Peace,
Cameron Purdy
Tangosol, Inc.
.NET to J2EE porting service available
"Chad Myers" <cmy...@N0.S.P4.M.austin.rr.com> wrote in message
news:ui6iMXtQCHA.2560@tkmsftngp09...
>
tuttle
[snip]
> Struct isn't *that* hard, though.. I do not think it will
> be a problem for ordinary developers to use it from
> time to time.
>
Yes, you are right. Even ordinary developers should have no problems
grasping structs. But even if there were somebody who just does not
get it, he would have no problems as long as he does not try to
develop a framework for numerical computing :-)
[snip]
> As far as I can tell, it is because they are keywords.
>
Why is string a keyword? It is just a class that handles strings. C#
would work just fine without it.
> > Were it not for people like asj and
> > petilon, I would never have considered it a problem. It feels very
> > natural to me. But that is probably because I come from a C++
> > background and switched to java a few years ago. And I was always
> > frustrated about the lack of value types in java.
>
> That may be so on. If you are sufficiently wrapped up in
> OO, it can be very hard to think of non-OO constructs
> in their own terms. Structs do seem very strange if you
> can think only as funny classes.
>
I know quite a bit about OO, but when I write programs I have a very
pragmatic approach: I use what works, and using classes for complex
numbers and vectors most definitely does not work.
[snip]
> > I
> > really like the fact that I use the code for e.g. Hashtable for any
> > kind of object. That way, only a very small piece of code has to be
> > present in the processor cache. If there were different hashtable
> > implementations for all kinds of data types, the amount of code that
> > has to be accessed would be greatly increased. You can see that with
> > c++ libraries that rely heavily on templates: they tend to have a very
> > large working set and thus big problems with small cache sizes and
> > lots of memory consumption.
>
> Microsoft has put some whitepapers out about this. Their idea is to
> generate an different implementation for each phyiscal representation
> needed. All reference types get one implementation, and value types
> get others. But Size and Point would share an implementation, because
> they have the same fields in the same order.
>
> This seems a good compromise. It greatly reduces the number of
> implementations, and still lets them inline value types in most
> cases.
>
I read about it. It seems to be an excellent way to introduce generics
into an intermediate-code based framework. My only problem is that
microsoft will have plenty of patents on these things that enable them
to lock out third party developers such as the mono project.
[snip]
> > this will be a pain in the ass, especially for
> > localization and for applications that run both on ultra-high
> > resolution tft displays and low-resolution handhelds.
>
> Well, resolution changes are handled through a scaling
> mechanism, same as in Win32, not through layouts.
>
How does this work? I did not find it. I suppose it has something to
do with the ominous property "AutoScaleBaseSize".
> You are going to have to get your hands dirty when you
> localize an app, though.
>
That is why Windows.Forms is not well suited to applications that will
be translated to many different languages. In KDE/Qt for example, if
you want to localize an application, you just provide translations for
each string that is used by the application. This can be done by
somebody who knows nothing at all about software development. You do
not even need the source code of the application.
[snip]
> If you want to see what a thin layer on Win32 looks like,
> check out MFC sometime.
>
YUCC! I tried that once, and I decided that I will *never* write MFC
programs unless somebody gives me a real large heap of money. I never
saw such an ugly toolkit. Qt is so much better.
> > For real
> > layout management, take a look at the layout management approach in
> > the widget toolkit of Mac OS X. I think it is called cocoa or
> > something.
>
> I've read about it. It's identitical to anchoring, unless
> I've missed something. I might have, Apple's docs (on their
> website) are not all that great
>
> > A friend of mine bought an eBook and showed me the included
> > dialog builder tools, and I was really impressed.
>
> What impressed you?
>
They have struts and springs that enable you to build really beautiful
size-independent layouts. It is a bit like a GridBagLayout in java,
only that it is a lot more intuitive.
Unfortunately I do not own an iBook, so all I can tell you is that he
produced a nice scalable layout in no time at all. He works as a GUI
designer, and he likes it a lot.
> [snip]
> > > No, there are not. Not in Windows Forms.
> > >
> > I agree that most methods requiring a Handle are in System.Drawing,
>
> .. and there aren't all that many even there. But that is, of course,
> irrelevant to the question of whether System.Drawing is a thin or
> a think layer. There's a pretty good 1-to-1 correspondance between
> System.Drawing's methods and classes and GDI+'s when accessed
> with native code. So it is thin layer, and would be even if no handles
> were ever visible.
>
> In fact, System.Drawing never gives you direct access to
> an unmanaged GDI+ object pointer. Those handles are there
> so you can switch to using GDI32, which you might want to
> do because it is a lot faster.
>
The constructor for System.Drawing.Imaging.Metafile has 39 overloads.
37 of them have an IntPtr as a parameter. In fact I did not find out
how to use a Metafile without a) reading a file or b) using an IntPtr.
[snip]
> Microsoft was clearly not even trying to be portable, but I
> disagree that these methods are "messy"; they are the simplest
> way I can see to handle interaction between Win32 and
> Windows Forms code for the same Window when desired;
> they are completely nonintrusive if you don't want to do that.
>
> I'd like to know how you'd do this, if you were to redesign
> Windows Forms?
I would like a much more abstract approach to GUI design. Let the
developer write a Document class that presents some data and/or some
functionality and make the GUI completely separate from the Document
class.
A standard View could be made from the Document class without any
developer interaction (a bit like a PropertyGrid on Steroids). This
standard view could then be modified using a GUI editor and stored in
an XML config file.
That would solve the problem of separation of Content and
Presentation. You always have some people who are good at coding, but
could never desing a decent GUI as well as some people who can design
brilliant GUIs but can not understand a single line of code.
There would have to be some way to define custom view classes for
certain datatypes. Some kind of dictionary that defines viewer classes
for different Types would work just fine. The GUI designer would
enable you to choose from these different Viewer classes.
regards,
tuttle
Chad Myers
> Hi Chad,
>
> > > >I don't mean to make you sound ignorant (again) but "deprecating"
means
> > > >leaving it in there. Purposefully.
>
> > > It also means marking it @deprecated and coming up with a preferred
> > > interface. @deprecated means it's no longer to be used and, IIRC, that
> > > it could be removed in future versions of Java.
>
> > (shh, let Cameron have his moment of glory. We all know he is lost,
> > and doesn't understand, but it makes him feel better and it's better
> > for his self esteem)
>
> Yes or no question: When you deprecate a method, does that in any way
remove
> the method or make it less accessible or available or otherwise?
You get a compiler warning. It is a standard procedure to discontinue
the use of the deprecated method because it could be removed in any
future version. It is a way to migrate away from it.
At least they would be on the road to getting rid of the inconsistent
methods, but it seems that that isn't a priority to make their API
more easily workable.
> I suggest that you avoid allowing your insecurity to expand on the proof
of
> your lack of knowledge.
Lack of knowledge? You seem to misunderstand the problem and so your
attempts to make yourself sound smarter only really embarass you.
Did you really think that I didn't understand what deprecated means?
How sad.
-c
Cameron Purdy
> the use of the deprecated method because it could be removed in any
> future version. It is a way to migrate away from it.
> At least they would be on the road to getting rid of the inconsistent
> methods, but it seems that that isn't a priority to make their API
> more easily workable.
I'm sorry, but was that a Yes or a No?
Peace,
Cameron Purdy
Tangosol, Inc.
.NET to J2EE porting service available
"Chad Myers" <cmy...@N0.S.P4.M.austin.rr.com> wrote in message
news:Of#08PvQCHA.2792@tkmsftngp09...
>
tuttle
> Would you be willing to post your code to the above Complex struct and
> Mandelbrot viewer? I would be happy to port it to Java for the purpose
> of determining if your claims about the necessity of value types for
> this type of work are true. I will post the resulting Java code which
> anyone can compile and use to form their own opinion.
>
---
using System;
using System.Diagnostics;
using System.Drawing;
using System.Collections;
using System.ComponentModel;
using System.Windows.Forms;
using System.Data;
using Scalar=System.Double;
namespace MandelbrotViewer
{
struct Complex : IFormattable
{
public Complex(Scalar re,Scalar im)
{
this.re=re;
this.im=im;
}
public Scalar Re
{
get { return re; }
set { re=value; }
}
public Scalar Im
{
get { return im; }
set { im=value; }
}
public Scalar R
{
get { return Complex.Absolute(this); }
}
public Scalar Theta
{
get { return Math.Atan2(im,re); }
}
public static implicit operator Complex(Scalar re)
{
return new Complex(re,0);
}
public static Complex Conjugate(Complex a)
{
return new Complex(a.re,-a.im);
}
public static Scalar AbsoluteSquared(Complex a)
{
return a.re*a.re+a.im*a.im;
}
public static Scalar Absolute(Complex a)
{
return Math.Sqrt(Complex.AbsoluteSquared(a));
}
public static Complex Inverse(Complex a)
{
return 1/a;
}
public static Complex Exp(Complex a)
{
return new Complex(Math.Cos(a.im),Math.Sin(a.im))*Math.Exp(a.re);
}
public static Complex Log(Complex a)
{
return new Complex(Math.Log(a.R),a.Theta);
}
public static Complex Pow(Complex a,Complex b)
{
return Complex.Exp(b*Log(a));
}
public string ToString(string format,IFormatProvider formatProvider)
{
return "Complex["+re.ToString(format,formatProvider)+"+"+im.ToString(format,formatProvider)+"i]";
}
public static Complex operator + (Complex a,Complex b)
{
return new Complex(a.re+b.re,a.im+b.im);
}
public static Complex operator - (Complex a,Complex b)
{
return new Complex(a.re-b.re,a.im-b.im);
}
public static Complex operator - (Complex a)
{
return new Complex(-a.re,-a.im);
}
public static Complex operator * (Scalar a,Complex b)
{
return new Complex(a*b.re,a*b.im);
}
public static Complex operator * (Complex a,Scalar b)
{
return new Complex(a.re*b,a.im*b);
}
public static Complex operator * (Complex a,Complex b)
{
return new Complex(a.re*b.re-a.im*b.im,a.re*b.im+a.im*b.re);
}
public static Complex operator / (Complex a,Complex b)
{
return new Complex(a.re*b.re+a.im*b.im,a.im*b.re-a.re*b.im)/(b.re*b.re+b.im*b.im);
}
public static Complex operator / (Scalar a,Complex b)
{
return new Complex(a*b.re,a*b.im)/(b.re*b.re+b.im*b.im);
}
public static Complex operator / (Complex a,Scalar b)
{
return new Complex(a.re/b,a.im/b);
} public static Complex Sum(Complex a,Complex b)
{
return a+b;
}
public static Complex Difference(Complex a,Complex b)
{
return a-b;
}
public static Complex Product(Complex a,Scalar b)
{
return a*b;
}
public static Complex Product(Scalar a,Complex b)
{
return a*b;
}
public static Complex Product(Complex a,Complex b)
{
return a*b;
}
public static Complex Negative(Complex a)
{
return -a;
}
public static Complex Division(Scalar a,Complex b)
{
return a/b;
}
public static Complex Division(Complex a,Scalar b)
{
return a/b;
}
public static Complex Division(Complex a,Complex b)
{
return a/b;
}
private Scalar re;
private Scalar im;
public static readonly Complex I=new Complex(0,1);
}
public class MandelbrotForm : System.Windows.Forms.Form
{
const int SetWidth=512;
const int SetHeight=512;
const int MaxIterations=256;
static int totalIterations;
private System.ComponentModel.Container components = null;
private int[,] iterations;
private Bitmap bitmap;
public MandelbrotForm()
{
InitializeComponent();
totalIterations=0;
DateTime time0=DateTime.Now;
CreateMandelbrotSet(new Complex(-2,-1),new
Complex(0.5,1),SetWidth,SetHeight,MaxIterations,out iterations);
TimeSpan deltat=DateTime.Now-time0;
Trace.WriteLine("SetWidth="+SetWidth);
Trace.WriteLine("SetHeight="+SetHeight);
Trace.WriteLine("MaxIterations="+MaxIterations);
Trace.WriteLine("TotalIterations"+totalIterations);
Trace.WriteLine("Time="+deltat);
Trace.WriteLine("Iterations per
Second="+totalIterations/deltat.TotalSeconds);
CreateBitmap(iterations,out bitmap);
}
protected override void OnPaint(PaintEventArgs args)
{
args.Graphics.DrawImage(bitmap,ClientRectangle);
}
protected override void OnResize(EventArgs args)
{
Invalidate();
}
private int MandelbrotIteration(Complex c,int maxIterations)
{
Complex x=new Complex(0,0);
int iterations=0;
while((iterations<maxIterations)&&(Complex.AbsoluteSquared(x)<=4))
{
x=x*x+c;
iterations++;
}
totalIterations+=iterations;
return iterations;
}
private void CreateBitmap(int[,] iterations,out Bitmap bitmap)
{
int width=iterations.GetLength(0);
int height=iterations.GetLength(1);
bitmap=new Bitmap(width,height);
for(int x=0;x<width;x++)
for(int y=0;y<height;y++)
{
int c=(int)(iterations[x,y]*255.0/MaxIterations);
bitmap.SetPixel(x,y,Color.FromArgb(c,255-c,0));
}
}
private void CreateMandelbrotSet(Complex c0,Complex c1,int width,int
height,int maxIterations,out int[,] iterations)
{
iterations=new int[width,height];
Complex delta=c1-c0;
delta.Re/=width;
delta.Im/=height;
for(int x=0;x<width;x++)
for(int y=0;y<height;y++)
iterations[x,y]=MandelbrotIteration(c0+new
Complex(delta.Re*x,delta.Im*y),maxIterations);
}
protected override void Dispose( bool disposing )
{
if( disposing )
{
if (components != null)
{
components.Dispose();
}
}
base.Dispose( disposing );
}
#region Windows Form Designer generated code
/// <summary>
/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.
/// </summary>
private void InitializeComponent()
{
//
// Form1
//
this.AutoScaleBaseSize = new System.Drawing.Size(5, 13);
this.ClientSize = new System.Drawing.Size(292, 273);
this.Name = "Form1";
this.Text = "Form1";
}
#endregion
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
Application.Run(new MandelbrotForm());
}
}
}
Dan Johnson
> I came to Smalltalk from C++, so I didn't find it "natural", as I did Java
> (and by relation, C#).
I'd never call Smalltalk *natural*. It is a most
unconventional language, but very simple.
Jason Kratz
I would. lots of smalltalk statements read very close to English. like
atList: at:0 put: whatever. OK...natural if youre an English speaker :)
Chad Myers
> > You get a compiler warning. It is a standard procedure to discontinue
> > the use of the deprecated method because it could be removed in any
> > future version. It is a way to migrate away from it.
>
> > At least they would be on the road to getting rid of the inconsistent
> > methods, but it seems that that isn't a priority to make their API
> > more easily workable.
>
> I'm sorry, but was that a Yes or a No?
Your question was invalid. Please put in another quarter and
try again.
-c
Dan Johnson
> grasping structs. But even if there were somebody who just does not
> get it, he would have no problems as long as he does not try to
> develop a framework for numerical computing :-)
So even Petilon will be all right, if he follows
his own advice. Is C# a great language, or what? :D
> [snip]
> > As far as I can tell, it is because they are keywords.
> >
> Why is string a keyword? It is just a class that handles strings. C#
> would work just fine without it.
The class is System.String; "string" is a keyword that
denotes it even if you do not have "using System;" at
the top of your file.
No, it's not really all that useful. It *is* legal to have
classes and structs at the top level of the naming heirarchy;
they didn't have to put String in System, and had they not,
there would be no need for an alias as far as I can see.
[snip]
> > That may be so on. If you are sufficiently wrapped up in
> > OO, it can be very hard to think of non-OO constructs
> > in their own terms. Structs do seem very strange if you
> > can think only as funny classes.
> >
> I know quite a bit about OO, but when I write programs I have a very
> pragmatic approach: I use what works, and using classes for complex
> numbers and vectors most definitely does not work.
Then I would argue that you are, nevertheless, insufficiently
wrapper up in OO. Petilon does not seem to understand
what values *are*, whereas you clearly do.
[snip]
> > This seems a good compromise. It greatly reduces the number of
> > implementations, and still lets them inline value types in most
> > cases.
> >
> I read about it. It seems to be an excellent way to introduce generics
> into an intermediate-code based framework. My only problem is that
> microsoft will have plenty of patents on these things that enable them
> to lock out third party developers such as the mono project.
That may be so; but if they did not have those patents,
others would apply for them, and then sue. The state of
the patent system today leaves Microsoft little choice but
to patent everything that isn't nailed down, and indeed
most thing that are. And the nails too.
The question is whether they will put their patents
to malicous use. I think they are capable of it, but
it's not certain they'll take that tack. They might also
submit the changes to the CLR and C# to ECMA
for inclusion in the standard, the better to stick a
thumb in Sun's eye.
[snip]
> > Well, resolution changes are handled through a scaling
> > mechanism, same as in Win32, not through layouts.
> >
> How does this work? I did not find it. I suppose it has something to
> do with the ominous property "AutoScaleBaseSize".
It is not quite the same as the approach used in Win32
(Windows Forms does not use the Win32 dialog layout
engine). But the principal is the same. You lay out your
form in a co-ordinate system, then when them form is
generated for display, it is scaled by mapping that co-ordinate
system to the physical one based on the metrics of the font
chosen for the dialog.
In Win32, dialogs are laid out in dialog units, which are
1/8th of the maximum character height tall, and 1/4th of
the average character width wide. They are not quite square,
but almost, and they are just about 1 pixel in size if you are
using the MS Sans Serif font on 96 dpi screen. This works
quite automatically- the dialogs just grow when used
on higher resolution screens. But you can't place controls
with per-pixel precision on high resolution screens, beacuse
on those screens a dialog unit is larger than a pixel.
.NET places controls in pixel co-ordinates, but also saves
with the form an indicator of how big the pixels were relative
to the font used. This is the "AutoScaleBaseSize" property;
it isn't clearly stated in the docs what it is, but it appears to
have the width of an average character, and the height of
the tallest character.
It is possible, using this information and the current
font metric, to work out how much larger or smaller the
display should be, and then resize every control by
that amount.
> > You are going to have to get your hands dirty when you
> > localize an app, though.
> >
> That is why Windows.Forms is not well suited to applications that will
> be translated to many different languages. In KDE/Qt for example, if
> you want to localize an application, you just provide translations for
> each string that is used by the application. This can be done by
> somebody who knows nothing at all about software development. You do
> not even need the source code of the application.
As long as you are not going to need substantial layout
changes, yes, that's so. If it is acceptable to resize controls
to fit enlarged (and translated) text, Qt may be a better
choice. I have dabbled in Qt and I think it is a nice
comrpomise. It doesn't quite let you lay things out
just as you want, but it's as close as ever I've seen
anyone get with the "layout manager" model.
I find Java's layout system so obtuse and so difficult
to manage, I am not sure this argument could redeem it,
however. But that does not mean the layout manager
approach is hopeless; it really needs a good forms
designer tool, basically.
[snip]
> > If you want to see what a thin layer on Win32 looks like,
> > check out MFC sometime.
> >
> YUCC! I tried that once, and I decided that I will *never* write MFC
> programs unless somebody gives me a real large heap of money. I never
> saw such an ugly toolkit. Qt is so much better.
MFC is barely a "toolkit" at all. It is a very thin wrapper on
Win32; indeed it's little more than Win32 spelled differently.
I don't recommend it, it's pretty much obsolete now.
But my point was that Windows Forms was not like MFC.
[snip]
> > > A friend of mine bought an eBook and showed me the included
> > > dialog builder tools, and I was really impressed.
> >
> > What impressed you?
> >
> They have struts and springs that enable you to build really beautiful
> size-independent layouts. It is a bit like a GridBagLayout in java,
> only that it is a lot more intuitive.
I don't recall seeing anything like that in the Apple
docs. They seemed to have a flag word on each
control that determined how it would move when
the form resized. The UI screenshots of Interface
Builder show springs, but they are not like
the ones in Qt: they are just a way to specify what
the flags are. VS.NET uses little gray blocks instead
of springs, but the idea is the same.
> Unfortunately I do not own an iBook, so all I can tell you is that he
> produced a nice scalable layout in no time at all. He works as a GUI
> designer, and he likes it a lot.
I can believe it. But that is true also of Windows Forms.
There are, I suggest, two basic schools of thought on
UI layout. The Macintosh has always belonged to the
same school as Windows (it's chief pupil): you lay out
your UI in terms of where the controls are- their locations
and sizes. Then you somehow define rules to explain how
they change when their contain resizes.
Windows Forms and Cocoa belong to this school. As
you've noticed, it tends to be a bit tough to internationalize
such systems, as the layout may need to change based
on factors other than the container resizing. But it is
very easy to use.
Resolution independance was a problem on the
original Macintosh Toolbox. The solution was
to stipulate 72 dpi screens always and everywhere. :D
Windows solved the problem in the manner I
described above; but that only handles resolution
or font changes, not stuff like translation.
The other school is the one most Unix toolkits
use, and which Java follows. This school would have
you define the UI in terms of abstract relationships, and
then whenever the windows is displayed or resized,
these relationships can be used to derive the correct
layout.
This approach can easily incorporate data other than
form size changes. New fonts and resolutions are
easy, and other things (like translated texts for controls)
are doable.
But it's much harder to actually use. People have been
working of Forms designers for some time that would
make it easy. Forte's is a nightmare. Qt's is much
nicer. But I don't think they've managed to draw equal
with Interface Builder or Visual Studio .NET in this
area.
Nevertheless, I reiterate my actual point: Windows Forms
does layout management. It does it in a way quite different
from the Java approach, because it comes from the Macintosh
school rather than the Motif school. But it does it.
[snip]
> > In fact, System.Drawing never gives you direct access to
> > an unmanaged GDI+ object pointer. Those handles are there
> > so you can switch to using GDI32, which you might want to
> > do because it is a lot faster.
> >
> The constructor for System.Drawing.Imaging.Metafile has 39 overloads.
> 37 of them have an IntPtr as a parameter. In fact I did not find out
> how to use a Metafile without a) reading a file or b) using an IntPtr.
Windows Metafile is a file format that contains written
out GDI commands; the enhanced metafile format includes
GDI32 commands. If there a file format that handles GDI+
commands, many of which do not exist in GDI32,
I've not heard of it. I think Microsoft expects you to use
JPEG, BMP, or the like, which are not sensitive to
such things.
The Metafile class lets you read in a metafile from
any stream, a file by name, or a Win32 metafile handle;
you can then draw this metafile into your windows
or a bitmap. But you cannot draw *into* a metafile.
It's not supported. You can call Graphics.FromImage()
in an effort to get a Graphics object for one, but it
just throws an exception, I believe.
In other words, this class isn't given you access to
the underlying GDI+ structures; it is letting you
use Win32 handles again.
[snip]
> > I'd like to know how you'd do this, if you were to redesign
> > Windows Forms?
>
> I would like a much more abstract approach to GUI design. Let the
> developer write a Document class that presents some data and/or some
> functionality and make the GUI completely separate from the Document
> class.
That is no doubt a good idea for some apps, but
do you think the GUI toolkit should *enforce* such
a structure? MFC did so, and I found it an immense
pain on occasion. Their notion of what a document
was like was not appropriate for me then; it wanted to
do serialization to files, and I wanted to do database
access.
I prefer Windows Forms partly because it concerns itself
with the GUI, rather than deeper structural issues. If I need
a document class, I can write one myself with little difficulty.
I think most GUI toolkits, including Swing, Cocoa, Windows
Forms, and Qt, concur on this one point: GUI toolkits should
not dictate the 'deep' structure of an application. It greatly
limits their usefulness.
> A standard View could be made from the Document class without any
> developer interaction (a bit like a PropertyGrid on Steroids). This
> standard view could then be modified using a GUI editor and stored in
> an XML config file.
I do not see how this would work. How do you express the
behavior of the GUI in an XML config file?
It's fairly transparent how to do this with the forms
designer; the form is almost entirely represented
as a C# class, and you can add your own methods and
code. It's quite nice that way.
> That would solve the problem of separation of Content and
> Presentation.
I think you are solving the wrong problem. It's not
separation of content and presentation that is at issue. It's
how you allow interaction between Win32 and your new
kit without either *forcing* such interaction, or making things
terribly awkward.
One of the reasons MFC was so widely loathed is that
it made exactly this mistake. It bought you almost
nothing in terms of GUI implementation, and instead
saddled you with a ton of structural gunk you probably
could have done better yourself.
> You always have some people who are good at coding, but
> could never desing a decent GUI as well as some people who can design
> brilliant GUIs but can not understand a single line of code.
Of course.
OTOH, you do need both involved. The GUI you get will be
constrained by the capabilities of the tools; if your designers
really cannot understand a single line of code, they are not
likely to understand the limits in which they must work,
and ask for things that cannot be done in a reasonable time,
or on a reasonable budget. In that case they will certainly need
help with the tools, at least.
> There would have to be some way to define custom view classes for
> certain datatypes. Some kind of dictionary that defines viewer classes
> for different Types would work just fine. The GUI designer would
> enable you to choose from these different Viewer classes.
This is a useful technique, though you can't always
use it. But it the tricky bit is how you are going to
do the user interface itself- in this case, that is the question
of how to define these viewer classes.
If you are using XML as you described above, you are
presumably not defining your own classes. Or maybe you
are have something like Cocoa's .nib files in mind, which
are to be used *with* user defined classes?
Dan Johnson
"Jason Kratz" <e...@joes.com> wrote in message
news:ajbr6c$35a$1...@flood.xnet.com...
> > I'd never call Smalltalk *natural*. It is a most
> > unconventional language, but very simple.
>
> I would. lots of smalltalk statements read very close to English. like
> atList: at:0 put: whatever. OK...natural if youre an English speaker :)
I would think that for English speakers, it
would be best to have:
list put: x at: 0
Read as:
Mr. List, put x at (index) 0.
But it's not the pseudo-mathematical notation we're
all used to, is what it comes down to.
Chris Dunaway
> I don't mean to make you sound ignorant (again) but "deprecating"
> means leaving it in there. Purposefully.
>
>
But "deprecating" also implies that the item in question will eventually be
removed and that you should upgrade code that uses decprecated methods to
use the newer, better ones.
Chris
--
If you don't like lunchmeat, please remove it from my e-mail address to
send me an e-mail
Chad Myers
Well, you could just use COBOL.NET and have a statement that's
something like:
LIST FOO, PLEASE PUT THE VALUE OF X INTO YOUR INTERNAL LIST AT
POSITION OR INDEX (whichever you prefer) 0.
-c
Chad Myers
"Chris Dunaway" <dunawayc@_lunchmeat_sbcglobal.net> wrote in message
news:Xns9269AC...@207.46.239.39...
> "Cameron Purdy" <cpu...@tangosol.com> wrote in
> news:euGUh#nQCHA.2600@tkmsftngp11:
>
> > I don't mean to make you sound ignorant (again) but "deprecating"
> > means leaving it in there. Purposefully.
> >
> >
> But "deprecating" also implies that the item in question will eventually
be
> removed and that you should upgrade code that uses decprecated methods to
> use the newer, better ones.
Sorry Chris, explaining water is wet to Cameron is a lost cause.
It's been tried and fails repeatedly. Apparently explaining the
obvious to Cameron makes you "stupid", or so he has told me, but
I just smile and nod. Smile and nod...
-c
tuttle
> > Take for example an array of 1000000 complex numbers.
> > In c# it is a memory block of 16 megabytes size filled with
> > zeros.
>
> Are these mutable or immutable objects? If immutable, 1000000 objects of
> value zero do little good.
>
as Integer, BigInteger etc. in java need to be immutable.
[snip]
> > In java, it is a pointer array of 4 megabytes size (on 32bit
> > systems) and 1000000 objects on the heap. Allocating
> > 1000000 objects on the heap is not exactly fast, you know.
>
> On Hotspot (not the fastest JVM by any stretch) on my notebook it is 511ms
> to allocate the array and the 1000000 objects. That includes all garbage
> collection costs amortized over 100 iterations.
>
511 milliseconds on a decent processor are an eternity. A decent
processor with a good graphics card will render 30 frames of Quake 3
Area in that time. And all java can do in that time is to allocate and
deallocate a mere 1000000 complex numbers.
> > And accessing objects that are spread all over
> > the heap completely destroys cache consistency.
>
> Very true. Even worse is if you run out of physical RAM and go into swap,
> because a heap of objects with some part of the object graph on disk is a
> nightmare performance problem.
>
So you agree with me that one should not stress the heap when it is
not nessecary?
> > Garbage collecting 1000000 objects on the heap is a real PITA.
>
> See above. "Only" 1000000 objects is basically a no-op for modern JVMs.
>
511ms is a very long time for modern processors. I would consider
nothing that takes more than 1e-6s a no-op. Allocating and
deallocating a takes less than 10ms under C#.
> > And besides, a complex number class feels much more natural
> > if it has value type semantic.
>
> Agreed. There are trade-offs for value semantics, but this is one case
> (about the only one ;-) where it makes real sense.
>
2D, 3D and 4D vectors are another example. I think you will see a lot
of useful examples for structs in the .NET API for DirectX 9. That is
an example where structs are a must.
regards,
tuttle
Courageous
>> You get a compiler warning. It is a standard procedure to discontinue
>> the use of the deprecated method because it could be removed in any
>> future version. It is a way to migrate away from it.
>I'm sorry, but was that a Yes or a No?
You are attempting the fallacy of false dichotomy. His answer was what
it was, and correct for what it was. While attempting to steer a
conversation into a dichotomous world may serve your argumentative
purposes, the fact remains...
C//
Cameron Purdy
> try again.
You are sooooo cute ;-)
Peace,
Cameron Purdy
Tangosol, Inc.
.NET to J2EE porting service available
"Chad Myers" <cmy...@N0.S.P4.M.austin.rr.com> wrote in message
news:u1bHz5wQCHA.1648@tkmsftngp08...
>
Cameron Purdy
> 1/8th of the maximum character height tall, and 1/4th of
> the average character width wide. They are not quite square,
> but almost, and they are just about 1 pixel in size if you are
> using the MS Sans Serif font on 96 dpi screen.
They used to just be hardcoded to "2".
> I find Java's layout system so obtuse and so difficult
> to manage, I am not sure this argument could redeem it,
> however. But that does not mean the layout manager
> approach is hopeless; it really needs a good forms
> designer tool, basically.
Depends which layout. You could easily replicate Windows functionality (to
the pixel) with a LayoutManager. It's an interface, and most of the
implementations are designed for coders, not visual tools that do layout.
IMHO that's the biggest shortcoming of Java, is the late start of the "real"
visual tools. Maybe now that VS.POUND is around, they'll have more of a
reason to make the hard stuff more simple.
Peace,
Cameron Purdy
Tangosol, Inc.
.NET to J2EE porting service available
"Dan Johnson" <daniel...@vzavenue.net> wrote in message
news:ulivdit...@news.supernews.com...
>
Cameron Purdy
Revisionist history. Frankly, I still think you don't know what you're
talking about.
As for "oh no, it will be removed next release", I'm still waiting for the
prophetic "other shoe" in this case.
So while I have backwards compatibility, including binary serialization of
objects, all the way to 1997 or 1996, you've gotten to go through 2 or 3
whole "technology generations" in the mean time just to catch up with
technology that I can barely remember. How quaint.
Peace,
Cameron Purdy
Tangosol, Inc.
.NET to J2EE porting service available
"Chad Myers" <cmy...@N0.S.P4.M.austin.rr.com> wrote in message
news:#W#kFZxQCHA.2456@tkmsftngp10...
>
Cameron Purdy
> as Integer, BigInteger etc. in java need to be immutable.
They don't "need to be", but there are very positive aspects of
immutability. Really. I'm serious. Absolutely. My #17 pet peeve in Java is
that some of the "value types" like "date" are mutable.
> 511 milliseconds on a decent processor are an eternity. A decent
> processor with a good graphics card will render 30 frames of Quake 3
> Area in that time. And all java can do in that time is to allocate and
> deallocate a mere 1000000 complex numbers.
Touche. With the accent thingy. For some apps, that is as good as not being
bought.
On the other hand, how long does it take to allocate and fill an array of
1000000 objects (not structs) in C# on my notebook? Care to wager? I'm a
betting man. ;-)
> So you agree with me that one should not stress the heap when it is
> not nessecary?
ASM, C, and C++ exist for good reasons. Use when applicable. If that means
C# too, good for it. Yes, for some apps, I absolutely agree. Few and far
between as they may be.
> 2D, 3D and 4D vectors are another example. I think you will see a lot
> of useful examples for structs in the .NET API for DirectX 9. That is
> an example where structs are a must.
Unfortunately, that's still a "wait and see". In the meantime, you get
better performance on Windows from Java graphics APIs because they already
map directly to DirectX. Ironic, isn't it? (I'm not sure if it is funny or
not. Kind of like JDBC being a pass-through to ODBC initially.)
Peace,
Cameron Purdy
Tangosol, Inc.
.NET to J2EE porting service available
"tuttle" <mrwro...@yahoo.com> wrote in message
news:1006f17d.02081...@posting.google.com...
>
tuttle
[snip]
> On the other hand, how long does it take to allocate and fill an array of
> 1000000 objects (not structs) in C# on my notebook? Care to wager? I'm a
> betting man. ;-)
>
longer than in java. The java vm is quite impressive. But the point is
that I do not need to allocate 1000000 objects in C#.
> > So you agree with me that one should not stress the heap when it is
> > not nessecary?
>
> ASM, C, and C++ exist for good reasons. Use when applicable. If that means
> C# too, good for it. Yes, for some apps, I absolutely agree. Few and far
> between as they may be.
>
If you do not need fast value-types, fine, stay with java. I myself
would love to stay with java myself. But it just does not work for the
kind of programs I write. And I do not want to go back to an unmanaged
language, so C# is the only rational choice.
> > 2D, 3D and 4D vectors are another example. I think you will see a lot
> > of useful examples for structs in the .NET API for DirectX 9. That is
> > an example where structs are a must.
>
> Unfortunately, that's still a "wait and see". In the meantime, you get
> better performance on Windows from Java graphics APIs because they already
> map directly to DirectX. Ironic, isn't it? (I'm not sure if it is funny or
> not. Kind of like JDBC being a pass-through to ODBC initially.)
>
You can use DirectX with COM Interop. It is quite easy to use, and
also very fast. But DirectX 9 will come with an API for .NET, and it
will be a good example on how to use structs to avoid temporary object
creation.
regards,
tuttle
tuttle
[snip]
> > > This seems a good compromise. It greatly reduces the number of
> > > implementations, and still lets them inline value types in most
> > > cases.
> > >
> > I read about it. It seems to be an excellent way to introduce generics
> > into an intermediate-code based framework. My only problem is that
> > microsoft will have plenty of patents on these things that enable them
> > to lock out third party developers such as the mono project.
>
> That may be so; but if they did not have those patents,
> others would apply for them, and then sue. The state of
> the patent system today leaves Microsoft little choice but
> to patent everything that isn't nailed down, and indeed
> most thing that are. And the nails too.
>
That is ok as long as they do not enforce them to kill third party
implementations. If the patents do not have overly broad claims, it
should be possible to write a decent generics system without violating
them. There is a lot of prior art in this area, so Microsoft can
hardly claim that they invented generics.
> The question is whether they will put their patents
> to malicous use. I think they are capable of it, but
> it's not certain they'll take that tack. They might also
> submit the changes to the CLR and C# to ECMA
> for inclusion in the standard, the better to stick a
> thumb in Sun's eye.
>
I really hope so. After generics, C# will have everything I need. So
future extensions are no longer important for me. But generics is a
feature I really miss, even though you can usually work around it by
using aliases.
> [snip]
> > > Well, resolution changes are handled through a scaling
> > > mechanism, same as in Win32, not through layouts.
> > >
> > How does this work? I did not find it. I suppose it has something to
> > do with the ominous property "AutoScaleBaseSize".
>
[Explanation of Auto Scaling snipped]
Thanks! I never thought I would learn something useful from this
flamewar :-)
[snip]
> As long as you are not going to need substantial layout
> changes, yes, that's so. If it is acceptable to resize controls
> to fit enlarged (and translated) text, Qt may be a better
> choice. I have dabbled in Qt and I think it is a nice
> comrpomise. It doesn't quite let you lay things out
> just as you want, but it's as close as ever I've seen
> anyone get with the "layout manager" model.
>
The layout manager model is the only choice for a project such as KDE
where you do not have enough manpower to lay out dialogs for each and
every language. Take a look at <http://i18n.kde.org/teams/index.php>
to see the scope of this project. I guess microsoft has enough
manpower to properly localize their programs.
> I find Java's layout system so obtuse and so difficult
> to manage, I am not sure this argument could redeem it,
> however. But that does not mean the layout manager
> approach is hopeless; it really needs a good forms
> designer tool, basically.
>
Have you tried the automatic GridBagLayout designer that comes with
JBuilder? It is not perfect, but it is much better than using a
GridBagLayout by hand.
[snip]
> I don't recall seeing anything like that in the Apple
> docs. They seemed to have a flag word on each
> control that determined how it would move when
> the form resized. The UI screenshots of Interface
> Builder show springs, but they are not like
> the ones in Qt: they are just a way to specify what
> the flags are. VS.NET uses little gray blocks instead
> of springs, but the idea is the same.
>
Maybe I overestimated the abilities of Cocoa. I will ask my friend for
another demo when I see him.
[snip]
> But it's much harder to actually use. People have been
> working of Forms designers for some time that would
> make it easy. Forte's is a nightmare. Qt's is much
> nicer. But I don't think they've managed to draw equal
> with Interface Builder or Visual Studio .NET in this
> area.
>
I think most KDE applications look just fine. And they are
localizable, themable, and extremely flexible. So I do not see how
Visual Studio.NET is superior.
> Nevertheless, I reiterate my actual point: Windows Forms
> does layout management. It does it in a way quite different
> from the Java approach, because it comes from the Macintosh
> school rather than the Motif school. But it does it.
>
I think you are right. Saying that Visual Studio.NET does not have
*any* Layout Management is too harsh. I was just very disappointed
that it did not have Layout Managers.
[snip]
> Windows Metafile is a file format that contains written
> out GDI commands; the enhanced metafile format includes
> GDI32 commands. If there a file format that handles GDI+
> commands, many of which do not exist in GDI32,
> I've not heard of it. I think Microsoft expects you to use
> JPEG, BMP, or the like, which are not sensitive to
> such things.
>
> The Metafile class lets you read in a metafile from
> any stream, a file by name, or a Win32 metafile handle;
> you can then draw this metafile into your windows
> or a bitmap. But you cannot draw *into* a metafile.
> It's not supported. You can call Graphics.FromImage()
> in an effort to get a Graphics object for one, but it
> just throws an exception, I believe.
>
> In other words, this class isn't given you access to
> the underlying GDI+ structures; it is letting you
> use Win32 handles again.
>
I guess that explains it. In Qt (and also in BeOS R.I.P.), you can
record drawing commands in a QPicture and then play them back by
drawing the QPicture. That is very useful if you want to draw the same
shape on different locations. I thought that metafile was the same.
Is there no way to record and replay drawing commands in
System.Drawing? Then it is just another point where Qt is superior.
> [snip]
> > > I'd like to know how you'd do this, if you were to redesign
> > > Windows Forms?
> >
> > I would like a much more abstract approach to GUI design. Let the
> > developer write a Document class that presents some data and/or some
> > functionality and make the GUI completely separate from the Document
> > class.
>
> That is no doubt a good idea for some apps, but
> do you think the GUI toolkit should *enforce* such
> a structure? MFC did so, and I found it an immense
> pain on occasion. Their notion of what a document
> was like was not appropriate for me then; it wanted to
> do serialization to files, and I wanted to do database
> access.
>
If you wanted complete control, you could always define a viewer for
the top level document and do everything yourself.
> I prefer Windows Forms partly because it concerns itself
> with the GUI, rather than deeper structural issues. If I need
> a document class, I can write one myself with little difficulty.
>
> I think most GUI toolkits, including Swing, Cocoa, Windows
> Forms, and Qt, concur on this one point: GUI toolkits should
> not dictate the 'deep' structure of an application. It greatly
> limits their usefulness.
>
There would of course be a lower level API that you would use when
creating your own Viewers.
> > A standard View could be made from the Document class without any
> > developer interaction (a bit like a PropertyGrid on Steroids). This
> > standard view could then be modified using a GUI editor and stored in
> > an XML config file.
>
> I do not see how this would work. How do you express the
> behavior of the GUI in an XML config file?
>
The XML config file would store only information like layouts, colors,
fonts and which viewer to use for which type. The behavior of the GUI
would be programatically defined in the viewers for each type.
[snip]
> > There would have to be some way to define custom view classes for
> > certain datatypes. Some kind of dictionary that defines viewer classes
> > for different Types would work just fine. The GUI designer would
> > enable you to choose from these different Viewer classes.
>
> This is a useful technique, though you can't always
> use it. But it the tricky bit is how you are going to
> do the user interface itself- in this case, that is the question
> of how to define these viewer classes.
>
You just write a class that implements some interface that marks it as
a viewer for certain types. Doing so would be quite similar to
creating an UserControl or whatever it is called.
> If you are using XML as you described above, you are
> presumably not defining your own classes. Or maybe you
> are have something like Cocoa's .nib files in mind, which
> are to be used *with* user defined classes?
>
XML would be used for the simpler parts such as Fonts, Colors, Layout
and setting Properties of the viewer classes. If you want to do
something more complicated, you just define in the XML document that
you want a custom viewer and give its strong name or something as a
parameter.
regards,
tuttle