Invisible wrote:
> Warp wrote:
>> Mike Raiford <mra### [at] hotmailcom> wrote:
>>> I'd venture to say C# also has an astounding amount of libraries (at 
>>> least, on the Windows platform ...) the base library for .NET is 
>>> pretty extensive, though not without limitations, but those can 
>>> easily be worked around. I don't know whether the base libraries for 
>>> Mono are as plentiful, as I only have very limited experience with Mono.
>>
>>> The drawback? It's not viewed as a high performance language.
>>
>>   And rather Windows-only.
> 
> Isn't that the whole point of the Mono project?
> 

I thought so. But the caveat is this:

Programs written to the MS .NET Framework, will not run under the Mono 
.NET Framework, and vice-versa. Though you can write software in C# 
using Mono as the framework, and have it run under Windows, and various 
Linux flavors.

Post a reply to this message

Darren New wrote:

>>    // This will call DoStuff (In C# pfunc would be called a "delegate")
> 
> No it wouldn't.
> 

Aside from multicast delegates, Doesn't a delegate act similar to a 
function pointer?

Post a reply to this message

Warp wrote:
>   Yeah. You can do that with a one-liner:
> 
> std::vector<std::vector<int> > foo(nx, std::vector<int>(ny));
> 
>   And you don't have to delete anything.
> 

Hmm, I'll consider using this in the future. If I'm lucky, I can even 
change my existing code to accommodate it. Thanks!

Sam

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> > Oh I think I know. I took a while without noticing anything wrong, but 
> > now I remember having read about it in C++ FAQ Lite. theMap(Comp()) 
> > *declares a function* instead of instantiating an object.

>   But why? Doesn't "Comp()" create an object? How can you declare a function
> with an object (instead of a type)?

>   What kind of function? What does it return? Does it take parameters?
> What is the type of those parameters?

  Nobody probably cares, but the answer is:

std::map<A, int, Comp> theMap(Comp());

declares a function called 'theMap' which returns a value of type
std::map<A, int, Comp> and takes one parameter: A pointer to a function
which takes no parameters and which returns a value of type Comp.

  The reason *why* this is so is apparently because of backwards
compatibility with old C code, and something the C++ standardization
committee really didn't want to include in the standard, but they had
little alternatives (lest they break a lot of existing code).

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:
> Warp wrote:
>> if(10 < money*money && money*12 < 100)
>>
>>   Now it becomes much harder to understand quickly what's going on.
> 
> If money squared is more than ten or money times twelve is less than a 
> hundred.  Makes sense to me. :-)  But then, I'm used to it.

To be clear, I think it's harder to understand because it's nonsensical, 
not because the comparisons are in the wrong order. Is it any harder to 
understand that than

    if(money*money > 10 && money*12 < 100)

??  I'd say the failure here is naming the "money" variable incorrectly 
and not abstracting out the meaning.
   interest_basis = money * money;
   total_interest = money * 12;
   if (10 < interest_basis && total_interest < 100) ...


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

Invisible wrote:
> Haskell supports random number generators. And I/O. And asynchronous 
> exceptions. It just cleanly seperates what *is* deterministic from what 
> is *not*, that's all. ;-)

So does Erlang, from what I can see. Every statement always works the 
same way. It's nondeterministic because it depends on the timing of 
statements between asynchronous events. But once a message is in your 
queue, you'll process it the same way every time. Again, as far as I can 
tell from my reading so far...

Now, Erlang does have stuff like the "process dictionary" that is 
imperative, but every mention of it is followed by "don't use this if 
you don't know what you're doing, because it's stateful and imperative!"

>> Who throws the exception? The machine running the calculation isn't in 
>> any shape to do so.
> 
> I would presume the exception is just thrown to whoever is waiting for 
> the answer?

Right. As an asynchronous message, unless you're not trapping it, in 
which case you too throw the same message.

(You don't wait for results. You send a message, and optionally wait for 
one to come back, perhaps with a timeout. But you can "link" processes, 
which means a failure of one of them will cause the others to fail with 
the same exit code, unless they're "trapping exits", in which case the 
failure will be translated into a notification.)

So, overall, still functional.

> To be honest, I'm not really seeing a clean way to handle this in *any* 
> language, but I haven't thought about it for that long yet.

Erlang does it by running the old version and new version at once. As 
long as your code only makes local calls, it keeps running the old code. 
If it makes a tail-recursive call to a fully-qualified method, then the 
latest version of that method gets run.

So you have code like this (not in actual erlang syntax):
   method myserver::loop(State)
     receive {request, Params} from Sender ->
        {Result, NewState} = calculate(Params, State);
        send Result to Sender;
        loop(NewState);
     receive {upgrade, TransformFunction} ->
        NewState = TransformFunction(State);
        myserver::loop(NewState);
   end.

So it runs along happily, processing requests, in the loop. If you want 
to upgrade, you recompile the code, load the new version, write an 
anonymous function that transforms the data the server is holding from 
what the old version uses to what the new version uses, and tell the 
server to restart the loop after passing the state through the transform.

And this is all managed by the release management code, too. *That* is 
the complicated part: all the infrastructure already built.

>>> If by "simple and straight forward" you mean "assumes referential 
>>> transparency but doesn't actually enforce it or make any attempt to 
>>> check that it's there", then sure. Go knock yourself out. ;-)
>>
>> Where do you think it doesn't assume referential transparency?
> 
> Please reparse my sentence. I said it *does* assume referential 
> transparency yet does nothing to *enforce* or even *check* for it.

> In other words, if you're not careful, you can easily cause the system 
> to massively malfunction with a few incautiously chosen commands.

Like what?  I mean, that's true in some sense, but it's true of any 
system depending on what you mean by "massively malfunction". Since 
processes *can* have side-effects, you don't get referential 
transparency. But I don't think you have that with monads in Haskell, 
either, yes?  Are references to the IO monad referentially transparent? 
I thought that was kind of the point of monads.

>> By "simple and straightforward" I meant in the sense that there are 
>> relatively few types and primitives and interactions between them. 
>> More like Tcl or C than Ada or C++.
> 
> I consider Haskell to be quite simple in this respect too. 

Yes, exactly.

> I'm looking at you, Oracle. Trying to figure out where to start reading 
> to actually comprehend this stuff is *far* too hard!

Just Oracle, or SQL in general?  But yah, giant lumps of code like that 
are a mess to grok.

I once was looking at a program called Scopus (functionality not unlike 
SAP), and I spent literally a full work day trying to get a record 
entered into the database.

Me: Create a contact.
It: You first have to create the company the contact works for.
Me: Create a company.
It: You have to create the city the company is in.
Me: Create a city.
It: You first have to create the salesman responsible for that city.
Me: Create a salesman
It: You first have to create the department the salesman works for.

Literally. I gave up after about 40 of these indirections, some of which 
seemed circular.

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

Mike Raiford wrote:
> Darren New wrote:
> 
>>>    // This will call DoStuff (In C# pfunc would be called a "delegate")
>>
>> No it wouldn't.
>>
> 
> Aside from multicast delegates, Doesn't a delegate act similar to a 
> function pointer?

Only if you disregard that they're multicast and object-oriented and can 
be targets of events.  I'll grant you that "delegate" is as close as C# 
has to the concept of "pointer to function". :)

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

Mike Raiford wrote:
> Programs written to the MS .NET Framework, will not run under the Mono 
> ..NET Framework, and vice-versa. 

It depends on the program.  ASP.NET stuff runs quite smoothly.  Stuff 
you write that depends on libraries that haven't been ported yet 
doesn't, no. :-)

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

Invisible wrote:
>> Where do you think it doesn't assume referential transparency?
> 
> Please reparse my sentence. I said it *does* assume referential 
> transparency yet does nothing to *enforce* or even *check* for it.

What does Haskell do to enforce referential transparency, by the way? I 
don't really understand monads any more, but it would seem to me that if 
you piped the standard output of a Haskell program into a second Haskell 
program, then the output of the second one back into the first one, you 
could see some odd "non-transparent" things happen as each program's 
output affected its input, yes?

Otherwise, I'm not sure where Erlang falls down, other than, as I said, 
the obvious places where you're actually actively writing things to 
disks and reading them back later.

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

Invisible wrote:
> Please reparse my sentence. I said it *does* assume referential 
> transparency yet does nothing to *enforce* or even *check* for it.

Actually, thinking on it more, I don't think it assumes referential 
transparency.

    X = nodes(),
    Y = nodes(),
    X = Y.

(where "nodes()" returns the list of running computers, basically)

I am not sure that's guaranteed not to fail out when it compares the two 
lists, nor would you want it to.

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