Orchid XP v7 <voi### [at] devnull> wrote:
> About the only thing Java has going for it is that it's widely 
> supported.

  I like many Java applications (cgoban being a good example), but I don't
like the language itself. :)

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:
>> As I got into C# and .Net I found it to be very well thought out, rich 
>> and powerful.
> 
> It's still statically typed and compiled, so you still have the troubles 
> interfacing with Other Stuff sometimes. Like SQL - you still wind up 
> changing things in several places when you change the type of 
> arrangement of a SQL table.  I found that annoying for doing prototyping.
> 
The Program <=> SQL divide is what LINQ targets and seems to 
dramatically advance.  Suddenly the result of SQL like processes within 
the program are typed objects.  The IDE provides Intellisense on the 
objects.  They are compile time type checked.

>> about all of the neat new things and how well it all fits together.
> 
> It really is amazingly well thought out as a language. Plus they've 
> added generics, partial classes, inline SQL, etc.
> 
>> Then there is the framework which to me seems more comprehensive and 
>> consistent than anything for Java.
> 
> Yep. Again, of course, they had the hindsight of what Java had to 
> explore and then maintain.  Java was kind of "the first one you throw 
> out once you learn what you actually want," IMO.

I agree.  It is a luxury that they have certainly enjoyed and taken full 
advantage of.

> 
>> Call me a C# / .Net fanboy but don't call me one for Microsoft.  I 
>> reckon they should put the C# guys starting with Anders Hejlsberg in 
>> charge of the next OS they do.
> 
> I thought that was the idea behind Vista? Most of it rewritten to .NET?
> 

I'm not sure how much if any of Vista is actually written in .Net. 
Possibly some of the UI but I suspect not much of the core.  In any case 
it is the elegant design that I would like to see applied.  The fact 
that some of technology X may have been used in a bloated disaster isn't 
the same as saying that the design behind technology X shouldn't be used 
to avoid bloat in what comes afterwards.


The false logic is:
- Vista is a disaster
- Vista has some of .Net
- Therefore .Net is a disaster

Used by people who know little or nothing about .Net.

Post a reply to this message

Warp wrote:
> Orchid XP v7 <voi### [at] devnull> wrote:
>> About the only thing Java has going for it is that it's widely 
>> supported.
> 
>   I like many Java applications (cgoban being a good example), but I don't
> like the language itself. :)

I feel the same way about C... ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New wrote:
> There's a lot of cool stuff in C#, especially in libraries they don't 
> cover in tutorial-level books. I found the O'Reilly book very helpful too.

Incidentally, the O'Reilly book is the one that I'm liking :)

(Although it's an older version of the book, but still informative).

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Orchid XP v7 wrote:
> Darren New wrote:
> 
>> Looking at Java's GC and concluding that GC sucks is like looking at 
>> notepad and concluding that text processors suck.
> 
> OK, *surely* this ought to be quoted somewhere prominent? ;-)
> 

Now quoted at the top of my web site :)

(If you don't see it there, either refresh or click on the "View all 
quotes" link - it's at the bottom of the list, as it's the newest)

Warp wrote:
 > Darren New <dne### [at] sanrrcom> wrote:
 >> Looking at Java's GC and concluding that GC sucks is like looking at
 >> notepad and concluding that text processors suck.
 >
 >   I can't help it. I love to hate Java.
 >

This, also, is now quoted :)

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Orchid XP v7 a écrit :
> Warp wrote:
>> Orchid XP v7 <voi### [at] devnull> wrote:
>>> About the only thing Java has going for it is that it's widely 
>>> supported.
>>
>>   I like many Java applications (cgoban being a good example), but I 
>> don't
>> like the language itself. :)
> 
> I feel the same way about C... ;-)
> 
And what is your favorite Haskell application?

-- 
Vincent

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Looking at Java's GC and concluding that GC sucks is like looking at 
>> notepad and concluding that text processors suck.
> 
>   I can't help it. I love to hate Java.

It definitely provides many reasons to hate it, indeed!

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Warp wrote:
>   The OS may help the GC system when we are talking about OS resources.
> However, it can't help when we are talking about resources within the
> program itself. (For the sake of example, let's assume that the program
> uses its own "file handles" instead of the ones provided by the system.
> It doesn't need to be something related to physical files per se.)

Most systems I've seen deal with this pretty easily, too.

>   The problem is not leaving file handles open when the program exits.
> The problem is opening more and more file handles without closing the
> old ones: In most systems at some point the OS will put a limit to this
> and refuse to give any more file handles. At this point the program will
> malfunction, and finding and solving the cause can be quite difficult.

And this is where I say that the OS support helps a bunch. If the OS 
garbage-collects the file handles like it GCs memory, it's fine.

That is, saying "at some point you run out of file handles and crash" is 
no more a problem with "proper" GC than saying "at some point you run 
out of memory and crash".  Either you're actively using too many file 
handles, or they get cleaned up and collected.

Not in most desktop OSes today, mind.

>   Usually this is a sign of a bug: Some code somewhere is "leaking".
> Not all unused file handles are being closed.
>   However, with GC, where there's delayed object destruction, it might
> not be a bug per se, but a consequence of GC.

At which point the GC runs, the files get closed, and you're golden. No 
more problematic than the fact that memory cleanup is delayed until you 
run out of memory.

>> No, the OS closes the files for you.
> 
>   It can't close them if it sees that they are in use: Some live objects
> are holding the file handles (because these objects have not been
> properly destroyed).

Then it's not safe to close the files. Either they're accessible, in 
which case it's no different than using up memory, or they're not 
accessible, in which case the OS could (in theory) GC the handles for 
you just as easily.

>   Of course one thing the OS might try is to tell the GC to make a sweep
> to see if that frees any file handles (does any OS actually do this?).

That's what I was describing. And yes, there are any number of 
environments that will do this sort of thing. It is, for example, how 
Smalltalk originally worked back when it was its own OS.

> However, as I said, this will work only with system resources.

If you have a resource that's limited in your code, you write a simple 
bit of code that says "if I try to allocate an X, and there are no X's 
left, trigger a garbage collection, then try it again, once."

Just like if you run out of memory.

>   This assumes that the main loop is advanced before the amount of leaked
> resources grows too large. It can alleviate the problem, but it's not a
> guarantee.

True.

>   (And if the main loop is executed very often, eg. thousands of times
> per second, wouldn't it cause overhead to call the GC each time?)

Or call it once a second, or once every N times thru the main loop, or 
whatever.

>> And of course anything that allocated stuff on the heap has this sort of 
>> problem anyway, unless you wind up essentially writing your own GC anyway.
> 
>   There are alternatives to GC which call destructors immediately when
> the objects go out of scope. For example, if I'm not completely mistaken,
> objective C uses reference counting.

The problem with reference counting is twofold: it doesn't work reliably 
if the bits your counting can point to themselves (directly or 
indirectly), and the reference count has to be at least as big as the 
number of possible pointers.

The former is a problem if you want it to be general. Reference-counting 
strings or file handles isn't much of a problem. Reference-counting 
arbitrary user data structures (like doubly-linked lists) doesn't work. 
The firefox people are starting to realize this.

The latter is a problem if you want to deal with (as you are fond of 
using as an example) pixels. Do you really want a 32-bit reference count 
on every 32-bit pixel?

>   Someone mentioned that in C# it's possible to tell for an object that
> it should be destroyed immediately when it goes out of scope (but otherwise
> regular GC is performed). That sounds like a good solution to me. You get
> the best of both worlds.

In C#, you have a "using" statement, which creates a new scope within 
which the object is allocated, and which calls the "Dispose" method when 
you leave the scope. Basically, prettiness for try/catch/finally.

I've seen Java research that does this for *all* objects the compiler 
can prove doesn't escape the scope.  Of course, if you pass a reference 
to the object to some other method, you lose that ability.

>> Only naive GC.  Of course, sophisticated GC needs support throughout the 
>> system. Some systems have this.
> 
>   There's no way the OS can know about the program's internal resources
> even if it cooperates with the GC engine to handle system resources.

What sort of "internal resource" are you talking about? Can you give an 
example?

>> Other systems don't have this sort of problem at all, in that files are 
>> memory resources just like "in-memory" structures, so going out of scope 
>> deletes the file just like you'd expect.
> 
>   Don't stick to the file handles in particular. It was just an easy to
> understand example.

Certainly. It's just an example, but one easy to generalize. What are 
some other examples you've encountered?

AFAICT, there are three bits:
1) Internal pre-allocated things, like a threadpool or buffers in a 
certain kind of memory or something, that the OS can't help with.
2) External things that can get cleaned up reliably, like open file handles.
3) External things that can't get cleaned up reliably, like file data.

#1 is easy to take care of - invoke the GC if it runs out and have the 
"Dispose" free the resource.

#2 can be dealt with like #1 if you have an OS or other virtual layer in 
between (like a VM) cooperating.

#3 is difficult to deal with without extensively labeling what you create.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> I saw a LOL line on another conversation.
>>     > > Having used Ada and C++ extensively,
>>     > > I'll take Ada over C++ any day.
>>     > Never having used Ada at all, I'll take Ada over C++.
> 
>   Ada may be a wonderful language, but its lack of recent popularity
> means that the amount of available libraries is probably quite small.

This is true. Even simple things like base64 are not really easily 
available. I was just amused at the quote.

> No matter how wonderful a language is, having to reinvent wheels with
> it is a major letdown.

That's why I'm looking at Erlang. Nice industrial libraries to go along 
with the "bizarre" language.

>   If I had to choose a language other than C++, I'll probably choose Java
> because of the amount of libraries and portability, or C# because it
> sounds a bit better than Java. (Or if efficiency is not an issue, maybe
> I would just go with PHP.)

PHP is really sucky for anything other than what all the libraries are 
already written for. :-)  It's a good tool to have in the toolbox, but 
I'd not write a (say) desktop app in it, or for that matter anything 
intended to run longer than a web page hit.

>> It really is amazingly well thought out as a language. Plus they've 
>> added generics
> 
>   I thought templates are evil? ;)

I don't think C# generics are like templates. It's been a while, but I 
don't remember even that syntax.

>   It still makes be laugh out loud to remember how Java advocates
> fiercely attacked C++ templates. Then, some years later, they added
> some crippled template mechanism to Java (which still doesn't solve
> all the issues).

They didn't change the VM to support it. How good could it be? I think 
it was more pre-processor tricks than anything, IIRC.

>> I thought that was the idea behind Vista? Most of it rewritten to .NET?
>   Ah, now I understand why it's so large, heavy and slow.

Yep. And not even actually ported. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Paul Fuller wrote:
> The Program <=> SQL divide is what LINQ targets and seems to 
> dramatically advance.

Yeah. That, or OO databases, or whatever the flavor-of-the-week is. 
Erlang has its own database stuff, so you can store any value in the 
database, indexed by any value.  Not SQL, but a decent database.

> I'm not sure how much if any of Vista is actually written in .Net. 

Right. Sorry. I hadn't mean to imply it actually *happened*. Just that 
that was the idea of it.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message