 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/16/2012 4:13, Invisible wrote:
> Does /any/ high-level language do this?
Depends what you mean by "high level", but yes. Ada, C#, FORTH, a few others
here and there.
>> Does it handle threads running on various address spaces (i.e.,
>> distributed processing) well?
>
> The language itself does not include this feature. You would have to use
> some kind of library.
I guess being functional has some advantages here.
>> Can you write programs that notice your
>> SQL schema has changed and modifies the running program to account for
>> that?
>
> Since it's not possible to receive notifications for schema changes in the
> first place, I don't see how this is feasible.
You are allowed to poll. ;-)
>> Can you compile and distribute Haskell code, let other people use it,
>> and then release new object code that is compatible with the existing
>> code people already wrote and compiled without breaking things?
>
> No.
See, that's exactly the target market for C#. Or rather for .NET. C# is a
component-oriented language that happens to be OO. F# is a
component-oriented language that happens to be (somewhat) functional. Etc.
> Haskell is usually distributed in source form. Partly that's because the
> community is small, and nobody has the resources to compile their code for
> every target platform. Partly it's because most Haskell code is open-source
> anyway. But partly it's because the extant Haskell implementations have very
> poor object code compatibility.
And that's the sort of thing I'm talking about. :-)
>> How elegantly does it interface to dynamic languages like javascript?
>
> What do you mean by "interface"?
Can you invoke a javascript library as if it were written in Haskell? I.e.,
is it as easy to invoke something like javascript as it is to invoke
something like C?
> The Leksah IDE compiles as you type, and highlights compilation errors in
> near-realtime. (Like, there's a delay of a couple of seconds.)
Not bad.
> More to the point, most of the questions above aren't about the language
> itself, they're about all the supporting infrastructure that goes with a
> language to make it useful. While these are obviously important things, they
> aren't part of the core language.
Well, if your language can't handle dynamic loading or can't handle
object-code distribution, then these are inherent in the language. I.e., if
type inference is such that you have to do whole-program compilation for it
to work, then you can't link in new code at runtime.
> In summary: If you're saying that C# has better tools and better libraries
> for doing real-world stuff, then I have no argument. If you're saying that
> the C# language design is superior, then I must disagree.
Not superior. Superior at various tasks.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/16/2012 4:13, Invisible wrote:
> Similar remarks go for most of your points. There are languages like Erlang
> where support for distributed processing is built-in. Haskell is not such a
> language. On the other hand, we already have a library for shared-memory
> synchronisation and communication between threads; it's not inconceivable
> that some day somebody will extend it to work across node boundaries.
But that's not all it takes to make it do what Erlang does. Erlang isn't
just "distributed processing." It's "reliable processing." Which means you
need to be able to (for example) start a new version of the code running
while not actually throwing away the stack of call frames that got you
there. You have to be able to have A call B call C call D, and have D say
"Oh, by the way, next time C returns, B should be calling the new version of
C, but only in those threads where C has actually returned. Oh, and don't
screw up B's local variables." That's the sort of thing that's really,
really hard to do in a library, unless you're running something like FORTH
that actually has access to the executing code.
How would you write a Haskell library that says "once each call to X
returns, replace that thread's version of X with new executable code,
without otherwise disturbing the thread that's running there"?
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/16/2012 1:27, Invisible wrote:
> You're probably write. (Depending on how you want to argue about the
> semantics.) My point was just that "oh, it's /obviously/ impossible" isn't
> actually so obvious.
It obviously *is* impossible, if your definition of "type" is "collection of
values and the operators that transform them into other values."
If you return a private stack, it's not a stack unless I can call push and
pop on it. It's some other type that's just wrapping up a stack until you
unwrap it again.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/16/2012 1:38, Invisible wrote:
> It still works if you take Show out. (Although in that case it becomes even
> more pointless.)
As it does in C#. You return Object.
> My point isn't that this is a useful thing to do. It's just that it doesn't
> necessarily /have/ to be impossible. C# /chose/ to make it impossible - a
> not unreasonable choice, but not the /only/ choice.
You're just arguing syntax at this point. If I return a value and there's
nothing you can do with that value that you can't do with every other value
of every other type, then you've returned Object. You haven't returned a
value of a private type - you've cast it to a value that has no operations
defined except assignment.
> According to the spec document, any value of a value type is not formally
> referred to as an "object"; that term is reserved for values of reference
> type. Similarly, the term "class" is reserved to refer to types declared
> with the "class" keyword.
Not you're picking nits.
> Of course, with the C# unified type system, all types /behave/ as classes in
> the usual OO sense (which is the point you're making). It's just that the C#
> language spec does not /call/ then classes.
Are they all subclasses of Object? How can you have a subclass of Object
that isn't in turn an object? :-)
>> They correspond to integers. They aren't integers. I *do* think Java did
>> that one much better.
>
> What, by not having enumerations at all?
No. Java has actual useful enums, which are basically classes with a finite
collection of named static instances created at compile-time.
>>> If you have real enumerations, why do you need a special-case for bool?
>>
>> Because you have syntax in the language that uses specific types, like
>> "if" statements.
>
> Haskell has special if syntax, and yet Bool is defined in library code.
So? bool is defined in library code too. System.Boolean in mscorlib.dll
>> Hermes, for example, does not have a string type. But if you have an
>> enum where each name is one character long, you can make an array of
>> that value by sticking it inside quotes. Which I thought was kind of cute.
>
> Nice. :-S
And then there's ACT.1, where a number like 534 is actually a big long
expression that is ((5 * 10 + 3) * 10) + 4. I.e., similarly to the way
Hermes does strings, ACT.1 does every literal including integers and floats.
"Int" is actually a source code library.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/15/2012 17:13, clipka wrote:
> You're presuming here that GUI item superclasses keep growing new functions.
> That's not a necessary prerequisite for a GUI library though.
No. It's just that *that* is one of the use cases that OO was intended to
solve. Of course if you're sure you're never going to have new superclass
methods, or that you're willing to update every subclass every time you add
one to the superclass, then you don't need inheritance. But having that
break between superclass and subclass, and between sibling subclasses (so
you can add a new subclass without changing every reference to a superclass
method to include a new case for that new subclass) is exactly the point of
dynamic dispatch.
>> I don't know of any language that implements inheritance and interfaces
>> that doesn't allow interfaces to inherit. Quite honestly, that would
>> make almost no sense.
>
> I totally agree that it's a good choice to not design a language that way.
> But still, even with such a language you /could/ write a GUI library.
I can write a GUI library in assembler. Or in C, faking OO. Or in C, not
faking OO. That doesn't mean it's easy.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/16/2012 7:33, Warp wrote:
> These have been cases where I have had an object which should act as a
> screen element (whatever the basic element may be called in a particular
> GUI library) and also as another class, neither of which could have been
> just an interface (because both base classes contained functionality of
> their own).
Yeah, OK, fair enough. I can see that. It's sort of what the MVC pattern is
designed to get around, in a way.
Just as an amusement, I've found a very funky failure of inheritance at work.
We have a system that contains what we'll call documents. The business logic
loads a bunch of documents, and then the UI has a bunch of subclasses of
document that format the documents appropriately. (And the business document
instantiates the appropriate subclass by looking at flags in the data and
using factories and such.) All well and good. You have documents, and you
have SpreadhseetDocuments, PdfDocuments, VideoDocuments, TextDocuments,
etc., all of which make calls to the superclass to get the parameters and
then display the content appropriately.
Now we're doing a mechanism to let you edit documents, so we'll have
DraftDocuments. But we want SpreadsheetDocuments, VideoDocuments, etc to use
the data in the draft documents (which is stored in other tables, in funky
formats appropriate for editing, etc) for previews. But I can't instantiate
a VideoDocument with either a (final) Document or DraftDocument as the
superclass as appropriate, because it's Java. So I have to figure out a way
around that somehow.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/16/2012 3:14, Invisible wrote:
> According to Wikipedia, Mono /also/ does JIT compilation to native code.
> (Although I agree it would be better if there were published benchmark
> results for .NET itself.)
You almost have to. But the GC and the JIT for Mono both suck compared to
the ones optimized by MS.
> Because you have to make sure it actually happens, and uses up-to-date
> information. It looks remarkably easy for this step to get missed under
> sufficiently unusual conditions.
At worst, every time you load new code, you throw away all the compiled code.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/16/2012 7:34, Warp wrote:
> Darren New<dne### [at] san rrcom> wrote:
>>> Even if it does, then the language could implicitly do with it what C++'s
>>> virtual inheritance does. You can still forbid all other types of diamond
>>> inheritance if you so wish.
>
>> You could, but then it's getting weird.
>
> What would be weird about it?
What about diamond inheritance from Number or Enum or something like that?
There would be a bunch of cases where you could reasonably expect diamond
inheritance to work, or where there's one class under Object which is
nothing but some extra routines you want all *your* classes to inherit.
I.e., it's a very ad hoc rule that tells the programmer that the language
designer didn't know how to solve the problem but recognized it needed
solving. :-)
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 18/08/2012 05:34 AM, Darren New wrote:
> On 8/16/2012 3:14, Invisible wrote:
>> According to Wikipedia, Mono /also/ does JIT compilation to native code.
>> (Although I agree it would be better if there were published benchmark
>> results for .NET itself.)
>
> You almost have to. But the GC and the JIT for Mono both suck compared
> to the ones optimized by MS.
You have an actual citation for that?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 18/08/2012 05:10 AM, Darren New wrote:
> On 8/16/2012 4:13, Invisible wrote:
>> Does /any/ high-level language do this?
>
> Depends what you mean by "high level", but yes. Ada, C#, FORTH, a few
> others here and there.
I very much doubt that C# lets you trivially call arbitrary machine code.
>>> Can you write programs that notice your
>>> SQL schema has changed and modifies the running program to account for
>>> that?
>>
>> Since it's not possible to receive notifications for schema changes in
>> the first place, I don't see how this is feasible.
>
> You are allowed to poll. ;-)
In that case, yeah, it ought to be possible to build something that does
this. Nobody has, but somebody could.
>> Haskell is usually distributed in source form. Partly that's because the
>> community is small, and nobody has the resources to compile their code
>> for
>> every target platform. Partly it's because most Haskell code is
>> open-source
>> anyway. But partly it's because the extant Haskell implementations
>> have very
>> poor object code compatibility.
>
> And that's the sort of thing I'm talking about. :-)
And, as I wrote in the part you snipped, this is a property of the one
extant Haskell compiler. It's not necessarily intrinsic to the language
itself. Somebody could write a compiler that /does/ have good object
code compatibility. It's just that to date, it hasn't been a priority.
There's nothing about the /language design/ that makes this impossible.
On the other hand, if you're coding in BASIC, with line numbers and all,
then this pretty much /is/ impossible. Because BASIC is a very, very bad
language.
>>> How elegantly does it interface to dynamic languages like javascript?
>>
>> What do you mean by "interface"?
>
> Can you invoke a javascript library as if it were written in Haskell?
> I.e., is it as easy to invoke something like javascript as it is to
> invoke something like C?
Don't you need a web browser to run JavaScript code?
Regardless, invoking JS is, in principle, similar to invoking any other
foreign language. Once you work out how to call it, you'd need to write
at least some trivial wrappers to get it to work, and after that it's
pretty easy.
>> More to the point, most of the questions above aren't about the language
>> itself, they're about all the supporting infrastructure that goes with a
>> language to make it useful. While these are obviously important
>> things, they
>> aren't part of the core language.
>
> Well, if your language can't handle dynamic loading or can't handle
> object-code distribution, then these are inherent in the language. I.e.,
> if type inference is such that you have to do whole-program compilation
> for it to work, then you can't link in new code at runtime.
No.
If the /design/ of the language makes dynamic loading impossible, then
that's a language limitation. If the current /implementation/ of the
language does not support dynamic loading, then that's just an
implementation limitation.
And that's what I'm saying. Most of the stuff you can't do with Haskell
right now isn't because of poor language design. It's just that nobody
has built the tools or libraries required to do it. Some day these
things /could/ become possible, without changing the language.
> Not superior. Superior at various tasks.
From what I can see, C# is superior at migrating C++ code and letting
it integrate with old VB code...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
