Am 16.08.2012 18:16, schrieb Orchid Win7 v1:

>> You mean, you only use languages invented after Unicode had more than
>> 65536 code points defined.
>
> And when was that? About 10 years ago? :-P

Sounds like a good estimate. Even a bit more, I'd guess.

Now that we have this sorted out, when was the last time someone 
invented a language that's well-known today?

Post a reply to this message

On 16/08/2012 05:27 PM, clipka wrote:
> Am 16.08.2012 18:16, schrieb Orchid Win7 v1:
>
>>> You mean, you only use languages invented after Unicode had more than
>>> 65536 code points defined.
>>
>> And when was that? About 10 years ago? :-P
>
> Sounds like a good estimate. Even a bit more, I'd guess.
>
> Now that we have this sorted out, when was the last time someone
> invented a language that's well-known today?

Well, the entire .NET platform is somewhat newer than 10 years, so 
presumably C# is about the same age.

Post a reply to this message

Am 16.08.2012 18:38, schrieb Orchid Win7 v1:
> On 16/08/2012 05:27 PM, clipka wrote:
>> Am 16.08.2012 18:16, schrieb Orchid Win7 v1:
>>
>>>> You mean, you only use languages invented after Unicode had more than
>>>> 65536 code points defined.
>>>
>>> And when was that? About 10 years ago? :-P
>>
>> Sounds like a good estimate. Even a bit more, I'd guess.
>>
>> Now that we have this sorted out, when was the last time someone
>> invented a language that's well-known today?
>
> Well, the entire .NET platform is somewhat newer than 10 years, so
> presumably C# is about the same age.

While the .NET platform was indeed initially released in 2002, the 
project had been officially announced as early as July 2000, so it is 
safe to assume that work on it had started somewhat before 2000.

As for C#, according to Wikipedia it "Appeared in 2001", and development 
had started as early as January 1999.

Post a reply to this message

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