Orchid XP v7 wrote:
>> Me, I like the Common Lisp object system.
> Me, I dislike anything that says "Lisp" in it. :-S

You don't need to like LISP to appreciate the object system CLOS 
provides. It really isn't much lisp-specific in concept.

> I gave up when the language libraries were so obviously stupid...

Well that too. I was just doing text in/out with it.

> That's a miracle. It's a pretty rare language...

I used Icon too, which is also a pretty cool language. :-)

> Didn't try it personally, no. But that's what the language spec says. 

It has been an ongoing complaint that nobody actually implements the 
hard parts of the language.

> Note that Eiffel Studio isn't the only implementation. There's Smart 
> Eiffel (AKA Small Eiffel) that reguarly does quite well in the language 
> shootout benchmarks... But either way, the libraries are very poor.

Unless you use Eiffel.NET.  *That* is the power of the .NET stuff, in my 
view.

> [E.g., Eiffel provides strong generics support with a whole heap of 
> infrastructure to support writing really generic code. So they designed 
> one class for character I/O, and a completely unrelated one for binary 
> I/O. GAH! >_< Why?!]

Meyers was really desiging a language for designing data structures in. 
The data structure libraries are really nicely thought out. A shame the 
*useful* stuff isn't there.

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Eero Ahonen wrote:
> you'll have every one of them ripping theier (big) bits of memory.

Yah, that's called "side-by-side execution". It's a selling point, 
because you don't wind up with having to support old stuff in new 
runtimes, and you can leave the old bugs buggy, avoiding "DLL Hell".

> AFAIK frameworks like .Net should ease up programming by providing basic
> functions allready-coded and ease up resource-consuming as being
> something like shared libraries. 

They do.

 > Need of multiple versions of the same
> frameworks simultaniously just.. hmm.. breaks this illusion.

Wow, I run Java and C# next to each other, and they both take up memory! :-)

One really has two choices: Run different versions of the runtime and 
use up those resources, or have DLL hell where upgrading the runtime 
breaks working programs. The "upgrade the runtime and maintain 100% 
backward compatibility" eventually turns into a nightmare.

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

>> That's a miracle. It's a pretty rare language...
> 
> I used Icon too, which is also a pretty cool language. :-)

OK then...

>> Didn't try it personally, no. But that's what the language spec says. 
> 
> It has been an ongoing complaint that nobody actually implements the 
> hard parts of the language.

Heh. I never actually tried it, so I can't comment. I just assumed it 
would work. ;-)

>> Note that Eiffel Studio isn't the only implementation. There's Smart 
>> Eiffel (AKA Small Eiffel) that reguarly does quite well in the 
>> language shootout benchmarks... But either way, the libraries are very 
>> poor.
> 
> Unless you use Eiffel.NET.  *That* is the power of the .NET stuff, in my 
> view.

Depends. How good are the .NET libraries? [I hope to God they're better 
than the Java ones!]

>> [E.g., Eiffel provides strong generics support with a whole heap of 
>> infrastructure to support writing really generic code. So they 
>> designed one class for character I/O, and a completely unrelated one 
>> for binary I/O. GAH! >_< Why?!]
> 
> Meyers was really desiging a language for designing data structures in. 
> The data structure libraries are really nicely thought out. A shame the 
> *useful* stuff isn't there.

Yeah. Bloody type-I languages...

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

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >  Why not disallow diamond inheritance? 

> Technically, you can't, since there's a common base type for all objects 
> in those languages.

  No, there isn't: The so-called "interfaces" are not inherited from the
common base class. What would stop these interfaces from having member
variables and function implementations?

  Besides, does this common base class have member variables? If not,
there is no problem with diamond inheritance.

  And even if it had, since it's an automatic inheritance forced
by the compiler, it's perfectly possible for it to automatically do
the same thing as C++'s "virtual inheritance" does. That is, even if
you multiple-inherit, there's still only one base class part in the
resulting objects and everything referring to this base class uses
this unique instantiation.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> One really has two choices: Run different versions of the runtime and 
> use up those resources, or have DLL hell where upgrading the runtime 
> breaks working programs. The "upgrade the runtime and maintain 100% 
> backward compatibility" eventually turns into a nightmare.

  Third choice: Design the system so that you don't *have* to upgrade
ever. ;)

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> It also offered a way to 
> access Microsoft functionality from within Java.

  Isn't that precisely breaking standards?

  If Microsoft's version of Java didn't break any Java specifications,
how come Sun sued and won?

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Invisible wrote:
> > ....so they implemented Java's flawed MI-but-not-MI model? How is that 
> > fixing the flaws from other major programming languages?

> Probably fixing what they saw as flawed MI in C++. :-)

  They "fixed the problems" by removing multiple inheritance completely?

  Maybe MI in C++ has some problems. I has never stopped me from using
MI in C++ efficiently and for really useful stuff, though.

  Ok, one small problem with C++'s multiple inheritance might be that
if you want to use virtual inheritance in a diamond inheritance situation,
you would have to have editing access to both base classes you are inheriting
from if they are not virtual-inheriting already. If these classes are eg.
in a library you don't have access to, tough luck.
  Of course this is because of technical reasons. The only alternative
would be that classes are *always* virtually-inherited by default, which
would introduce overhead in the vast majority of situations where virtual
inheritance is not needed. (Once again, the possibility of precompiled
libraries and dynamically-loadable libraries makes it not possible to
perform some post-compilation optimizations. Having shared system-wide
dynamically-loadable libraries is too much of an advantage to simply drop
that feature.)

  (Btw, I have always wondered: How are you supposed to build huge systems
with languages which do not support dynamically loadable shared libraries?
The advantage of these is that it reduces memory consumption a lot,
because libraries which are common to most programs are loaded into memory
only once, and all the programs use those one unique instantiations.
  Without this possibility each program would have to be statically linked
with all the system libraries, and thus the same system libraries would be
loaded into memory multiple times. If there's eg. a huge library used by all
programs, it would be loaded to memory as many times as there are programs
running.)

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> Me, I dislike anything that says "Lisp" in it. :-S

  Says the person who is infatuated with functional languages such as
Haskell...

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Orchid XP v7 <voi### [at] devnull> wrote:
>> Me, I dislike anything that says "Lisp" in it. :-S
> 
>   Says the person who is infatuated with functional languages such as
> Haskell...

Aren't you that guy who loves C++ but hates C? ;-)

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

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Warp wrote:
> > Orchid XP v7 <voi### [at] devnull> wrote:
> >> Me, I dislike anything that says "Lisp" in it. :-S
> > 
> >   Says the person who is infatuated with functional languages such as
> > Haskell...

> Aren't you that guy who loves C++ but hates C? ;-)

  C isn't object-oriented.

-- 
                                                          - Warp

Post a reply to this message

>>>> Me, I dislike anything that says "Lisp" in it. :-S
>>>   Says the person who is infatuated with functional languages such as
>>> Haskell...
> 
>> Aren't you that guy who loves C++ but hates C? ;-)
> 
>   C isn't object-oriented.

True. But C and C++ are vastly more closely related than Haskell and Lisp.

[And if you wanted to split hairs, Haskell is a pure-functional 
language, while Lisp isn't.]

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

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> [And if you wanted to split hairs, Haskell is a pure-functional 
> language, while Lisp isn't.]

  A pure-functional language which has things like indexable arrays and
assignment? Hardly.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> [And if you wanted to split hairs, Haskell is a pure-functional 
>> language, while Lisp isn't.]
> 
>   A pure-functional language which has things like indexable arrays and
> assignment? Hardly.

Really? And indexable arrays are impure because...?

Similarly, all side-effecting operations are implemented using 
referentially-transparent monadic constructs. In Lisp, if you want a 
side-effect, you just do it. That's the difference.

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

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Warp wrote:
> > Invisible <voi### [at] devnull> wrote:
> >> [And if you wanted to split hairs, Haskell is a pure-functional 
> >> language, while Lisp isn't.]
> > 
> >   A pure-functional language which has things like indexable arrays and
> > assignment? Hardly.

> Really? And indexable arrays are impure because...?

  Because it's not a feature of the functional programming paradigm,
but the imperative programming paradigm.

  Purely functional languages are mostly impractical.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>> Really? And indexable arrays are impure because...?
> 
>   Because it's not a feature of the functional programming paradigm,
> but the imperative programming paradigm.
> 
>   Purely functional languages are mostly impractical.

Tell me Warp, do you actually understand what "functional programming" 
means?

You seem to think it means "programming with lists", which isn't correct.

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

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Tell me Warp, do you actually understand what "functional programming" 
> means?

  A purely functional programming language doesn't have side-effects.
If I'm not mistaken, for example assignment produces a side-effect.
Even I/O causes side-effects.

  Thus a purely functional language is mostly impractical. Quoting
wikipedia:

"Purely functional programs have no side effects. This makes it easier
to reason about their behavior. However, almost no programmers bother
to write purely functional programs, since, by definition, a program
with no side effects (one that accepts no input, produces no output,
and interfaces with no external devices ) is formally equivalent to a
program that does nothing; typically, purity is used to enforce a
separation of concerns where one clearly-delineated section of the
program does impure operations like I/O, and calls pure functions and
libraries as needed to compute answers."

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Thus a purely functional language is mostly impractical. Quoting
> wikipedia:
> 
> "Purely functional programs have no side effects. This makes it easier
> to reason about their behavior. However, almost no programmers bother
> to write purely functional programs, since, by definition, a program
> with no side effects (one that accepts no input, produces no output,
> and interfaces with no external devices ) is formally equivalent to a
> program that does nothing;

Quoting wikipedia is not always that useful:  that section is most 
likely vandalism by some angry COBOL programmer.

Surely separation of concerns is good as is reducing side-effects to a 
minimum.  To say a purely functional program is incapable of accepting 
input or generating output is not correct:  if anything, a purely 
functional program is able to, in shared memory, take a list as input 
and generate a list as output.  An outside program can write the input 
list in memory, call the pure program on it and read its output and 
write to file.  That's, AFAIK, is what was done in the old days of 
Haskell:  delayed list IO.

More practically, functional language compilers and runtimes carry out 
the ugly side-effect bits while the purely functional programs do their 
stuff and get written as if acting on purely side-effect free 
datastructures.  That's monadic IO today.

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> Tell me Warp, do you actually understand what "functional programming" 
>> means?
> 
>   A purely functional programming language doesn't have side-effects.

Indeed.

> If I'm not mistaken, for example assignment produces a side-effect.
> Even I/O causes side-effects.

Assignment and I/O are both side-effects. Accessing an indexed array 
does not. There is absolutely no reason why a pure functional language 
cannot have arrays.

>   Thus a purely functional language is mostly impractical.

Depends on your definition of "practical".

> Quoting wikipedia:
> 
> "Purely functional programs have no side effects. This makes it easier
> to reason about their behavior. However, almost no programmers bother
> to write purely functional programs, since, by definition, a program
> with no side effects is formally equivalent to a program that
> does nothing."

Indeed, a program with absolutely no side effects at all is rather 
pointless. (!) There are several approaches to this apparent problem.

One approach is to *allow* side-effects, but say "hey, don't use this 
unless you have to". This is the Lisp approach. (And Erlang. And a few 
others.)

The Haskell approach is different. A Haskell "program" just returns a 
list of instructions to the Haskell runtime, and the Haskell runtime 
actually "does" the instructions on the program's behalf.

Why is that different? Well, it means that the entire program remains 
referentially transparent. And *that* is the defining characteristic of 
functional programs.

In Haskell, *every* expression can be replaced by the value it returns 
without altering the result of the program. [Indeed, this is notionally 
how you execute a Haskell program.] The same statement does *not* apply 
to Lisp. Hence, Haskell is pure, and Lisp is not. QED.

Note that you *could* write referentially transparent code in just about 
any programming language, if you wanted to. It's just that in Haskell 
you can't write code that isn't. ;-)

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

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> > If I'm not mistaken, for example assignment produces a side-effect.
> > Even I/O causes side-effects.

> Assignment and I/O are both side-effects. Accessing an indexed array 
> does not. There is absolutely no reason why a pure functional language 
> cannot have arrays.

  Are you telling me in Haskell you can't modify the contents of an array
in-place? (By "indexable array" I implied that it can be assigned to,
although I should have perhaps stated it more explicitly.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>>> If I'm not mistaken, for example assignment produces a side-effect.
>>> Even I/O causes side-effects.
> 
>> Assignment and I/O are both side-effects. Accessing an indexed array 
>> does not. There is absolutely no reason why a pure functional language 
>> cannot have arrays.
> 
>   Are you telling me in Haskell you can't modify the contents of an array
> in-place? (By "indexable array" I implied that it can be assigned to,
> although I should have perhaps stated it more explicitly.)

Haskell provides a kind of array that you cannot modify in-place. (It's 
useful e.g. for pre-computed lookup tables.)

Haskell also provides another kind of array which can be modified 
in-place in the same sense that files can be written to - i.e., your 
program returns a set of instructions to the runtime that says "hey, 
create this array and modify its contents like this". Which makes sense 
really. After all, what is a "file"? It's a named array of bytes that 
can be modified [and reised] in-place! :-D

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

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Haskell also provides another kind of array which can be modified 
> in-place in the same sense that files can be written to - i.e., your 
> program returns a set of instructions to the runtime that says "hey, 
> create this array and modify its contents like this". Which makes sense 
> really. After all, what is a "file"? It's a named array of bytes that 
> can be modified [and reised] in-place! :-D

  Somehow I get the feeling that means:

  1) If you want to make a program which does some efficient calculations
using arrays, you have to jump through many useless hoops.

  2) Haskell is not pure regardless.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   Somehow I get the feeling that means:
> 
>   1) If you want to make a program which does some efficient calculations
> using arrays, you have to jump through many useless hoops.
> 
>   2) Haskell is not pure regardless.

Well, you've seen code that does it, so you can see it's really not that 
hard. And the "hoops" are precisely what *makes* Haskell pure. To my 
mind, that makes them not "useless". Still, it is only to my mind... 
obviously what is or is not useful is in the eye of the beholder.

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

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> >   Perhaps a bit surprisingly, Microsoft even has some open-source
> > projects, under OSI-compliant licenses. For example:
> > http://en.wikipedia.org/wiki/Windows_Template_Library

> I know. There's also WiX, a free toolset to make MSI-based installers 
> from XML configuration files. Released under the Common Public License.

> And probably many others.

  I just find this rather surprising, considering that they CEO considers
open source software a cancer and communism.

-- 
                                                          - Warp

Post a reply to this message

Warp escribió:
>   I just find this rather surprising, considering that they CEO considers
> open source software a cancer and communism.
> 

"We're open-source friendly!" might be good marketing. Even though they 
really aren't.

Post a reply to this message

On Fri, 15 Feb 2008 16:51:17 -0200, Nicolas Alvarez wrote:

> Warp escribió:
>>   I just find this rather surprising, considering that they CEO
>>   considers
>> open source software a cancer and communism.
>> 
>> 
> "We're open-source friendly!" might be good marketing. Even though they
> really aren't.

Well, arguably they have an interoperability lab that they run with 
Novell (again, that's who I work for, so I'm perhaps biased - though I 
really do dislike Windows and pretty much always have - I preferred 
Desqview when it was around).

They're also working with the SAMBA team now.

So it seems that some things are changing, finally.

Jim

Post a reply to this message

Jim Henderson <nos### [at] nospamcom> wrote:
> They're also working with the SAMBA team now.

yeah, they probably want some hints at how to correctly handle their spec.  Not
first time it happened.

But truth be told, M$ only said GPL was a cancer, not general opens-source
software.  It's understandable.  They certainly would feel a lot happier to
just integrate BSD-covered code into their products without much legal fuss.
hey, more people working for free for their glory...

Post a reply to this message

On Fri, 15 Feb 2008 15:59:49 -0500, nemesis wrote:

> Jim Henderson <nos### [at] nospamcom> wrote:
>> They're also working with the SAMBA team now.
> 
> yeah, they probably want some hints at how to correctly handle their
> spec.  Not first time it happened.

Possibly.  But the SAMBA team agreeing to work with them is a significant 
thing as well, because they were so outspoken over the Novell/Microsoft 
agreement.  I mean, Jeremy Allison quit Novell over that deal.

> But truth be told, M$ only said GPL was a cancer, not general
> opens-source software.  It's understandable.  They certainly would feel
> a lot happier to just integrate BSD-covered code into their products
> without much legal fuss. hey, more people working for free for their
> glory...

Well, they've used a fair bit of BSD code already; their TCP/IP stack 
reportedly comes from the BSD implementation.

Jim

Post a reply to this message

Jim Henderson escribió:
> Well, they've used a fair bit of BSD code already; their TCP/IP stack 
> reportedly comes from the BSD implementation.
> 

And also reportedly, they rewrote the whole TCP/IP stack for Vista. Lots 
of bugs reappeared (like many that had been fixed in Windows 95, ping of 
death anyone?).

Post a reply to this message

On Fri, 15 Feb 2008 19:13:55 -0200, Nicolas Alvarez wrote:

> Jim Henderson escribió:
>> Well, they've used a fair bit of BSD code already; their TCP/IP stack
>> reportedly comes from the BSD implementation.
>> 
>> 
> And also reportedly, they rewrote the whole TCP/IP stack for Vista. 

Huh, I hadn't heard that.

> Lots
> of bugs reappeared (like many that had been fixed in Windows 95, ping of
> death anyone?).

Great....

Jim

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> And also reportedly, they rewrote the whole TCP/IP stack for Vista.

good code is old code.  passed the test of time.

good for them.

Post a reply to this message

Jim Henderson escribió:
>> Lots
>> of bugs reappeared (like many that had been fixed in Windows 95, ping of
>> death anyone?).
> 
> Great....

...bugs that were of course fixed long before the final Vista release! I 
thought I'd better clarify that :)

http://www.grc.com/SecurityNow.htm#51

Post a reply to this message

On Fri, 15 Feb 2008 19:46:10 -0200, Nicolas Alvarez wrote:

> Jim Henderson escribió:
>>> Lots
>>> of bugs reappeared (like many that had been fixed in Windows 95, ping
>>> of death anyone?).
>> 
>> Great....
> 
> ...bugs that were of course fixed long before the final Vista release! I
> thought I'd better clarify that :)
> 
> http://www.grc.com/SecurityNow.htm#51

Yeah, I understood that, but it seems that some didn't. :-)

Jim

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>>  Why not disallow diamond inheritance? 
> 
>> Technically, you can't, since there's a common base type for all objects 
>> in those languages.
> 
>   No, there isn't: The so-called "interfaces" are not inherited from the
> common base class.

Interfaces aren't objects. They're types.

The rest snipped, because I agree with you. I'm not saying MI is 
especially hard to get right. I'm just saying you can't disallow diamond 
inheritance in a language where everything inherits from the same base 
class.

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> One really has two choices: Run different versions of the runtime and 
>> use up those resources, or have DLL hell where upgrading the runtime 
>> breaks working programs. The "upgrade the runtime and maintain 100% 
>> backward compatibility" eventually turns into a nightmare.
> 
>   Third choice: Design the system so that you don't *have* to upgrade
> ever. ;)

That's really bad for a commercial company. ;-)

Seriously, lots of systems do that. You upgrade by throwing away the 
entire old system and buying a new one.

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> It also offered a way to 
>> access Microsoft functionality from within Java.
> 
>   Isn't that precisely breaking standards?

No. Is providing OpenGL breaking the ANSI C standard?

>   If Microsoft's version of Java didn't break any Java specifications,
> how come Sun sued and won?

The same reason Alcoa lost their anti-trust case?

The fact that some company loses an anti-trust case says nothing about 
their behavior, in the USA. One of the first lawsuits under the Sherman 
anti-trust act was against Alcoa Aluminum company. They lost, not 
because they did anything wrong, but because the judge said "if you have 
most of the customers, you must be doing something wrong."

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Invisible wrote:
> Depends. How good are the .NET libraries? [I hope to God they're better 
> than the Java ones!]

They're actually surprisingly good for what they do. Far, far better 
than the Java stuff. Much of the Java stuff was designed to be 
oh-so-flexible, with three or four layers of abstraction between 
"socket" and "network connection", for example, so much so that it's 
almost unusable. It might have been worthwhile if people actually wrote 
code that was as flexible as the specs, but that never happened either.

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Invisible wrote:
>>> ....so they implemented Java's flawed MI-but-not-MI model? How is that 
>>> fixing the flaws from other major programming languages?
> 
>> Probably fixing what they saw as flawed MI in C++. :-)
> 
>   They "fixed the problems" by removing multiple inheritance completely?

I just want to clarify the smiley-face means I was being at least 
somewhat sarcastic.

>   Maybe MI in C++ has some problems. I has never stopped me from using
> MI in C++ efficiently and for really useful stuff, though.

Remember that C# also allows reflection, dynamic loading of precompiled 
libraries, and runtime code generation, as well as supporting a couple 
dozen other languages. All of this might have some effect on the decisions.

>   Without this possibility each program would have to be statically linked
> with all the system libraries, and thus the same system libraries would be
> loaded into memory multiple times. If there's eg. a huge library used by all
> programs, it would be loaded to memory as many times as there are programs
> running.)

It depends. Some systems had non-dynamic loadable libraries that were 
indeed shared between programs using them. They just got linked at 
specific addresses. (I think Multics did this, IIRC.) For example, on 
the first mainframe I used, the fortran library was at 0x1FF00 or 
something like that. When you started a program that needed the fortran 
runtime, it got mapped into your address space.

I.e., "linked" but not "dynamically under programmer control".

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>> Depends. How good are the .NET libraries? [I hope to God they're 
>> better than the Java ones!]
> 
> They're actually surprisingly good for what they do. Far, far better 
> than the Java stuff.

That's not hard. :-S

> Much of the Java stuff was designed to be 
> oh-so-flexible, with three or four layers of abstraction between 
> "socket" and "network connection", for example, so much so that it's 
> almost unusable. It might have been worthwhile if people actually wrote 
> code that was as flexible as the specs, but that never happened either.

Tell me, have *you* ever seen a non-empty catch{} block in Java? ;-)

BTW, I especially love the way Java, an "object oriented language", uses 
lots of procedural techniques in it's class library. Neat...

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

Post a reply to this message

Darren New wrote:
> Warp wrote:
>>   Because it's not a feature of the functional programming paradigm,
>> but the imperative programming paradigm.
> 
> Huh?  Since when?  I think you're mistaken here, but I'm happy to learn 
> otherwise.

As posted elsewhere, what Warp *really* means is "arrays with in-place 
update". Which *is* strictly speaking against functional style. (But 
that doesn't stop you using it even in a pure functional language such 
as Haskell...)

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

Post a reply to this message

Warp wrote:
>   A purely functional programming language doesn't have side-effects.

The trick is to embed the purely functional programming language into a 
larger system that does the I/O. For example, have a CGI script that 
takes its input and generates output from that functionally, and let the 
web server do the I/O part.  POV-Ray could be purely functional, except 
for a small shell that reads the input file into a buffer (ignoring 
includes and such) and another that takes the calculated pixels and 
outputs them to the destination file.

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Orchid XP v7 wrote:
> Tell me, have *you* ever seen a non-empty catch{} block in Java? ;-)

Only in my own code. ;-)

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> As posted elsewhere, what Warp *really* means is "arrays with in-place 
> update". Which *is* strictly speaking against functional style. (But 
> that doesn't stop you using it even in a pure functional language such 
> as Haskell...)

  Well, modifying an array in-place means it's a side-effect, which
means Haskell is not pure.

  OTOH, why would that be a bad thing? Just being "pure functional" for
the sake of being pure is counter-productive. There are many situations
where being able to handle arrays in-place is more or less mandatory
for efficiency. Trying to avoid it would sometimes be more awkward than
would be worth.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> >   Without this possibility each program would have to be statically linked
> > with all the system libraries, and thus the same system libraries would be
> > loaded into memory multiple times. If there's eg. a huge library used by all
> > programs, it would be loaded to memory as many times as there are programs
> > running.)

> It depends. Some systems had non-dynamic loadable libraries that were 
> indeed shared between programs using them. They just got linked at 
> specific addresses. (I think Multics did this, IIRC.) For example, on 
> the first mainframe I used, the fortran library was at 0x1FF00 or 
> something like that. When you started a program that needed the fortran 
> runtime, it got mapped into your address space.

> I.e., "linked" but not "dynamically under programmer control".

  That still doesn't solve the problem of virtual inheritance being
either always-on or always-off for a class in a precompiled library,
without any possibility of changing it on a per-program basis.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   OTOH, why would that be a bad thing? 

You lose a whole bunch of things the compiler can optimize.

If you do
   "let x = replace offset 27 in y with 'hello'"
(i.e., y[27]='hello')
and then use "x", the compiler can often figure out that y isn't used 
any more and update it in place.

Sort of like using tail recursion instead of iteration, but they're both 
equivalent.  Or avoiding loops in APL. Or avoiding cursors in SQL.

And yes, sometimes (often, for me) it gets awkward. You sometimes have 
to spend some time figuring out how to do it functionally, but it gets 
easier with practice.

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Warp wrote:
>   That still doesn't solve the problem of virtual inheritance being
> either always-on or always-off for a class in a precompiled library,
> without any possibility of changing it on a per-program basis.

I'm not sure what "virtual inheritance" means outside the very narrow 
context of C++. And inside that context, I'm not sure I understand what 
problem it's supposed to be solving.

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   That still doesn't solve the problem of virtual inheritance being
> > either always-on or always-off for a class in a precompiled library,
> > without any possibility of changing it on a per-program basis.

> I'm not sure what "virtual inheritance" means outside the very narrow 
> context of C++. And inside that context, I'm not sure I understand what 
> problem it's supposed to be solving.

  Virtual inheritance is related to diamond inheritance.

  Any OOP language which supports multiple inheritance, and consequently
diamond inheritance, must resolve the problem in one way or another.
Virtual inheritance in C++ is one solution.

  When you use virtual inheritance in diamond inheritance situations,
the base class appears in the object only once, and all the derived
objects use that one single instance of the base class object (instead
of each using their own).

  Naturally this requires that all the access to the base class members
be indirect. They cannot be accessed directly but only through a vtable.
Since having to access all member variables indirectly would be a
completely useless overhead in non-diamond-inheritance situations, this
is not done by default.

  The problem is that classes derived from a common base class need to
make the decision of whether they will use virtual inheritance or not.
Using virtual inheritance will allow diamond inheritance with a common
base class. However, if this is not needed, then virtual inheritance
would be completely useless overhead.

  When these derived classes are in a precompiled library which cannot
be changed, the decision cannot be changed either. They either use
virtual inheritance (allowing diamond inheritance with a single base
class) or they don't. If they don't, and you would need it, bad luck.

  That's the reason why precompiled libraries sometimes may introduce
problematic situations.

  Fortunately it's rare to need to use diamond inheritance in the first
place (and in many cases where diamond inheritance is needed, the common
base class isn't). Thus the problem appears quite rarely.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   When you use virtual inheritance in diamond inheritance situations,
> the base class appears in the object only once,

So lacking "virtual inheritance" means there's one copy of the 
superclass for each subclass that has it on its parent chain? OK.

> Since having to access all member variables indirectly would be a
> completely useless overhead in non-diamond-inheritance situations, this
> is not done by default.

It sort of sounds like this would be just the thing for a runtime with 
JIT to deal with, wouldn't it? I.e., it sounds like this is even easier 
to solve in .NET than in C++, because the actual code isn't generated in 
.NET until the thing is actually linked together at runtime?

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Warp wrote:
> Orchid XP v7 <voi### [at] devnull> wrote:
>> As posted elsewhere, what Warp *really* means is "arrays with in-place 
>> update". Which *is* strictly speaking against functional style. (But 
>> that doesn't stop you using it even in a pure functional language such 
>> as Haskell...)
> 
>   Well, modifying an array in-place means it's a side-effect, which
> means Haskell is not pure.

For the Nth time: All side-effects are technically outside the language 
itself, and hence Haskell is not impure.

For example, in Lisp, if you have a list, usually you update it by 
constructing a modified copy. But, if you feel like it, you can just go 
"ah well, I can't be bothered" and modify a list (or any other data 
structure) in-place. In Haskell, you cannot do this.

[Since you can call C from Haskell, you can tell the compiler "hey, this 
C function has no side effects" when actually it does. But there's not 
really anything the Haskell language spec can do about that... And if 
you try this, Bad Things happen.]

>   OTOH, why would that be a bad thing? Just being "pure functional" for
> the sake of being pure is counter-productive.

Remember how in Haskell code executes in arbitrary order?

Now mix that up with side-effects. Go on. See what kind of a mess you 
end up with. Hint: it won't be pretty. ;-)

Haskell is able to execute things in arbitrary order (and possibly not 
execute things at all, and possibly execute many things in paralle 
transparently, and...) precisely *because* it is a pure language. And 
that's to say nothing about the optimisation possibilities offered to 
the compiler.

You make it sound like purity is just some arcane concept invented by 
mathematicians that serves no practical purpose. ;-)

> Trying to avoid it would sometimes be more awkward than
> would be worth.

Sometimes, yes. And this is partly why Haskell offers you a way to 
indirectly perform various side-effecting operations such as in-place 
array updates (not to mention file I/O etc.)

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

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> > Since having to access all member variables indirectly would be a
> > completely useless overhead in non-diamond-inheritance situations, this
> > is not done by default.

> It sort of sounds like this would be just the thing for a runtime with 
> JIT to deal with, wouldn't it?

  And then you lose the advantage of shared libraries because each library
would have to be JIT-compiled for each program which uses it. Which was
the whole point.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   And then you lose the advantage of shared libraries because each library
> would have to be JIT-compiled for each program which uses it. Which was
> the whole point.

Well, I think JIT-compiled code is easier to compile than C#, for 
example. But yeah, the actual executable bytes would be different for 
each process running, or at least each program, if that's what you're 
trying to avoid.

I suppose you could also have two copies of the code in each library, 
one with and one without. Doubles the size somewhat of any routine that 
is affected by that. Select the right set of routines when you start up 
the program, or when you link the child class, or some such? I'm not 
sure when you'd pick in this case.

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message