There are many people who believe that Haskell is a weird and baffling 
language. Personally, I think this is untrue. Obviously, I am in the 
minority here. But today, I found this:

http://www.e-pig.org/downloads/epigram-notes.pdf

WTF-O-Meter: 11.0

(Calibrated with 2001: A Space Oddessy as the 10.0 reference point.)

If you thought Haskell was far-out, this stuff is just mental. Even I 
have only the vaguest comprehension of what the hell they're talking 
about. This must surely be the only paper ever to refer to Haskell and 
ML as "traditional languages". (Not, say, Java and C...) Truly there are 
more things in Heaven and Hell than Man can know! o_O

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

Post a reply to this message

On Thu, 23 Jul 2009 20:44:40 +0100, Orchid XP v8 wrote:

> There are many people who believe that Haskell is a weird and baffling
> language. Personally, I think this is untrue.

Heh, but you think C is a weird and baffling language, so it balances 
out. ;)

Jim

Post a reply to this message

>> There are many people who believe that Haskell is a weird and baffling
>> language. Personally, I think this is untrue.
> 
> Heh, but you think C is a weird and baffling language, so it balances 
> out. ;)

Baffling? Yes. Weird? Not so much. Just ill thought out.

Somebody somewhere obviously thought that treating characters and arrays 
as the same type was a good idea...

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

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> http://www.e-pig.org/downloads/epigram-notes.pdf

  I think that many people who try to understand haskell feel like trying
to understand a paper like that one (even if more practical Haskell
programs are not that complicated).

  Will Haskell ever become mainstream? Yes, as soon as highly theoretical
math papers become mainstream. ;)

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v8 wrote:
> If you thought Haskell was far-out, this stuff is just mental. 

Sounds like they've reinvented typestate, but I'd have to go dig up my other 
technical books from two decades ago to see if their formulae match.


-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

On Thu, 23 Jul 2009 20:55:51 +0100, Orchid XP v8 wrote:

>>> There are many people who believe that Haskell is a weird and baffling
>>> language. Personally, I think this is untrue.
>> 
>> Heh, but you think C is a weird and baffling language, so it balances
>> out. ;)
> 
> Baffling? Yes. Weird? Not so much. Just ill thought out.

Consider when it was created.  I'm sure Brian and Dennis (ie, K&R, 
creators of the C programming language) would probably disagree with 
you. ;-)

> Somebody somewhere obviously thought that treating characters and arrays
> as the same type was a good idea...

Personally, I think it is - data is data is data is data.  A "string" is 
an array of characters.

Jim

Post a reply to this message

Orchid XP v8 wrote:
> Baffling? Yes. Weird? Not so much. Just ill thought out.

It's tremendously well thought out, actually. It just doesn't do what you 
want it to do. But C was much better thought out than a lot of the stuff 
that came after it. After all, what did they add to it? ANSI type 
declarations. Structure assignment. That's pretty much it on the significant 
changes.

There were a number of languages in the 90's less well thought out, wherein 
(for example) a leading 0 on a number meant it was octal *even if* you read 
it from the terminal, or a \0 meant the end of the string but there weren't 
any mem___() functions. Etc.

> Somebody somewhere obviously thought that treating characters and arrays 
> as the same type was a good idea...

Characters and arrays aren't the same type. If you look at C and recognise 
that every manipulable value fits in a machine word, the type system makes 
much more sense. (Broken, of course, with structure assignment, which wasn't 
in the original C version.)

Other than "I don't understand the type system" and "they could have done 
better if they were writing a different language", what do you think is 
poorly thought out?  (I'll grant the whole idea of the need for header files 
is kind of silly, but there *are* limitations you put on a language whose 
compiler has to fit in 32K.)

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Jim Henderson wrote:
> Personally, I think it is - data is data is data is data.  A "string" is 
> an array of characters.

More to the point, a bit of text is quite literally a "string" of 
characters :)  Or where did you think the term came from?

And, since characters were represented by bytes at the time, a string 
would then be an array of bytes.

-- 
Chambers

Post a reply to this message

Warp wrote:

>   Will Haskell ever become mainstream? Yes, as soon as highly theoretical
> math papers become mainstream. ;)

I know you think you're being funny, but let us examine that claim for a 
moment...



SQL is based on some highly theoretical mathematics: the relational 
algebra. Everybody thinks they're called "relational databases" because 
tables can have "relationships". However, this is false; it's because 
"tables" are actually *relations*. You know what the definition of a 
relation is?

   "A relation is a subset of the extended Cartesian product of the 
domains of its respective attributes."

Seriously. That's the definition of a relation. It's a set of tuples. A 
Cartesian product. As soon as you start to dig into this stuff, you 
rapidly find yourself reading about set theory, predicate logic, 
functions and determinents, the relational operators of projection, 
restriction and Cartesian product, the algebra of those operations 
(i.e., how you can reorder them and still get the same result), 
existential vs universal quantification, normalisation rules... and so 
on and so forth.

   Dr Constable: "Boyce Codd Normal Form states... Andrew!"
   Andrew: "...every determinent is a candidate key."
   Dr Constable: "...thank you Andrew. What this means[...]"

I have Database Systems by C J Date on my bookshelf. It's freakin' HUGE, 
and some of the chapters contain utterly impenetrable mathematics that 
even I can't begin to comprehend. (Anybody have any clue how the 
relational calculus is different from the relational algebra??)

And yet... relational databases are the most popular kind of databases. 
SQL is almost the *only* language for controlling databases. SQL is 
basically the relational algebra with COBOL-style syntax. And yet, when 
you write some statement in relational algebra, everybody's eyes glaze 
over. But write some SQL, and people are much happier.

SQL is actually quite easy to understand. You just need to know about 
tables and joins and normalisation and you're basically done. (Obviously 
if you're going to make a professional career out of this stuff, there's 
a lot more to it than you might think. But the basics are quite easy.)

Tell somebody that it's more efficient to take the disjunction of two 
predicates rather than the union of two relations and they look at you 
all confused. But tell them to use an OR-clause in their WHERE-condition 
rather than doing a UNION query and they usually understand.

It seems to be simply a question of how you dress up the terminology. 
You talk about abstract relations and domains and set-theoretic 
operations and predicates and people look confused. Talk about SQL 
statements and most people seem to not have a problem with it; I guess 
because SQL seems far more concrete and "real-world".



All of this makes me wonder... What would happen if somebody designed a 
language which was exactly like Haskell, but had syntax like Pascal or 
something? What if it didn't use terms like "monad" and "functor" and 
"existential quantification", but used something more concrete-sounding?

Of course, the really bizare (and wonderful!) thing about Haskell isn't 
its syntax, it's the ways in which you can use it. But I wonder... If 
you dressed Haskell up in sheep's clothing, how long would it take 
normal programmers to realise that what you're getting them to do is 
actually crazy? >:-)

Post a reply to this message

Invisible wrote:

> All of this makes me wonder... What would happen if somebody designed a 
> language which was exactly like Haskell, but had syntax like Pascal or 
> something? What if it didn't use terms like "monad" and "functor" and 
> "existential quantification", but used something more concrete-sounding?
> 
> Of course, the really bizare (and wonderful!) thing about Haskell isn't 
> its syntax, it's the ways in which you can use it. But I wonder... If 
> you dressed Haskell up in sheep's clothing, how long would it take 
> normal programmers to realise that what you're getting them to do is 
> actually crazy? >:-)

Just for giggles, I'm designing this language. So far I've implemented 
half the standard libraries with it. The results are... interesting. The 
code becomes 85% more verbose, but I wonder if it makes any difference 
to the level of comprehendability.

Post a reply to this message

Darren New wrote:

> Sounds like they've reinvented typestate, but I'd have to go dig up my 
> other technical books from two decades ago to see if their formulae match.

It sounds interesting and even possibly useful, but... it's 
incomprehensible. I can't make much sense out of it. Clearly whoever 
wrote this document knows what they mean. Unfortunately they didn't do a 
very good job of explaining it! :-P

Post a reply to this message

Invisible wrote:
> (Anybody have any clue how the 
> relational calculus is different from the relational algebra??)

Yes.

> SQL is 
> basically the relational algebra with COBOL-style syntax. 

Actually, it's relational calculus with COBOL-style syntax. ;-)

> All of this makes me wonder... What would happen if somebody designed a 
> language which was exactly like Haskell, but had syntax like Pascal or 
> something? What if it didn't use terms like "monad" and "functor" and 
> "existential quantification", but used something more concrete-sounding?

Go for it. Then write a parser to translate it into Haskell.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Just for giggles, I'm designing this language. So far I've implemented
> half the standard libraries with it. The results are... interesting. The
> code becomes 85% more verbose, but I wonder if it makes any difference
> to the level of comprehendability.

It absolutely depends on the keywords you use.

If you choose them to match the strict technical terms, then you're lost.

If you manage to choose them in a way that common people can relate to them,
then you may have a fair chance - even if that means picking words that would
be technically imprecise or even outright wrong.

Post a reply to this message

>> (Anybody have any clue how the relational calculus is different from 
>> the relational algebra??)
> 
> Yes.

Care to explain?

>> SQL is basically the relational algebra with COBOL-style syntax. 
> 
> Actually, it's relational calculus with COBOL-style syntax. ;-)

You know, until I read COBOL, I had no idea SQL looked like COBOL. (OMG, 
I think we have reached a tautology here!) But having seen COBOL, SQL 
really does seem overly wordy and silly... heh. :-D

>> All of this makes me wonder... What would happen if somebody designed 
>> a language which was exactly like Haskell, but had syntax like Pascal 
>> or something? What if it didn't use terms like "monad" and "functor" 
>> and "existential quantification", but used something more 
>> concrete-sounding?
> 
> Go for it. Then write a parser to translate it into Haskell.

Heh. Assuming I don't give it a type system which exceeds Haskell's 
expressive power. >:-D

But an interpretter should definitely be possible. Especially since it's 
easier to parse... ;-) I might even build a debuggar.

Post a reply to this message

>> Just for giggles, I'm designing this language. So far I've implemented
>> half the standard libraries with it. The results are... interesting. The
>> code becomes 85% more verbose, but I wonder if it makes any difference
>> to the level of comprehendability.
> 
> It absolutely depends on the keywords you use.
> 
> If you choose them to match the strict technical terms, then you're lost.
> 
> If you manage to choose them in a way that common people can relate to them,
> then you may have a fair chance - even if that means picking words that would
> be technically imprecise or even outright wrong.

Yeah, indeed.

I've come up with a language I'm calling Hax. I haven't finished 
figuring out what it looks like or how it works yet. It's basically 
Pascal with a few tweaks. And by "tweaks" I mean that the similarity 
between Hax and Pascal is like Java vs C++. Superficially, it looks the 
same. But if you investigate for more than 5 seconds, you'll discover 
that they're actually TOTALLY UNRELATED! >_<

In particular, many of the things that are implicit in Haskell are 
explicit in Hax. (E.g., allocating memory is always explicit, no 
implicit constructor functions, no currying...) And I'm trying to make 
the syntax as non-weird as possible. (No whitespace layout, no obscure 
symbols, no little ASCII-art arrows and zigzags.)

Additionally, some of the weirder features of Haskell are missing. (No 
more curried functions, no lambda functions, no pattern matching...) It 
makes the language less expressive, but no less powerful. And it makes 
it far more similar to familiar languages. CASE expressions now look 
more like Pascal or C, but with some extra super-powers. Literally, if 
you go "hey, this is basically Pascal, but it lets you do these EXTRA 
THINGS..." it comes across is kinda neat.

...or I'm delusional, of course. I have noticed that I code certain 
examples, look at them and go "hmm, there's no way a regular programmer 
would do it THAT way..." We'll see.

Oh, and "monads" are now called "procedures". ;-) This does not 
accurately reflect what they are and what they do, but it's far more 
intuitive to explain.

Post a reply to this message

Invisible wrote:
>>> (Anybody have any clue how the relational calculus is different from 
>>> the relational algebra??)
>>
>> Yes.
> 
> Care to explain?

It's kind of like the difference between functional and procedural.

In the calculus, you say "give me a table with the name, salary, and hire 
date from table X and table Y where X.name=Y.name and salary < 500"

In the algebra, you say "join table X and Y, and from that select the ones 
where the names are the same, and from that select the ones where the salary 
is < 500, and from that project over name, salary, and hire."

Think of SQL compared to something like

(((X join Y) select {salary < 500})
     select {X.name = Y.name}) project [name,salary,hire]

Only select, project, and join are defined in the algebra. There's no 
"exists" and such.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Additionally, some of the weirder features of Haskell are missing. (No
> more curried functions, no lambda functions, no pattern matching...)

What - a functional language without lambda functions? C'mon, I always thought
that was the icing on the cake...

I'd love to see such a functional language. Maybe it would help me grok the
concept, too - it somehow feels that functional programming concepts may really
be useful, and that I just didn't manage to really grasp the concepts.

And I mean grasp, not just comprehend from a theoretical point of view.

Post a reply to this message

clipka wrote:

> What - a functional language without lambda functions? C'mon, I always thought
> that was the icing on the cake...

It's nice to have, but you can live without it. Debatably, not having it 
makes things more explicit. In the language I'm designing, you basically 
always have to give a function a name before you can call it.

FWIW, I've always thought of curried functions as a syntactic short-cut 
as well. It turns out I was wrong; without curried functions, there are 
certain programs you actually can't write.

I'm ambivilent about these design choices. I'm still playing with my 
options...

(As already stated, no curried functions prevents the definition of 
certain operations. Additionally, not having lambda functions and 
curried functions means that creating functions is more hard work, and 
this somewhat tips the balance of power. It makes you more likely to 
define functions directly rather than as special cases of high-order 
functions, because it's almost more work to call a high-order function 
than to type in the definition directly. This is possibly not a good 
idea...)

> I'd love to see such a functional language. Maybe it would help me grok the
> concept, too - it somehow feels that functional programming concepts may really
> be useful, and that I just didn't manage to really grasp the concepts.
> 
> And I mean grasp, not just comprehend from a theoretical point of view.

Well, we'll see. It may be that having everything explicitly spelled out 
makes it clearer what's actually going on.

Alternatively, maybe all the syntactic chatter will be so OTT that it 
just obscures the meaning.

Or maybe the fundamental problem is that functional programming is just 
weird, and no amount of dressing it up will solve that. We'll see... ;-)

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

Post a reply to this message

>>>> (Anybody have any clue how the relational calculus is different from 
>>>> the relational algebra??)
>>>
>>> Yes.
>>
>> Care to explain?
> 
> It's kind of like the difference between functional and procedural.
> 
> In the calculus, you say "give me a table with the name, salary, and 
> hire date from table X and table Y where X.name=Y.name and salary < 500"
> 
> In the algebra, you say "join table X and Y, and from that select the 
> ones where the names are the same, and from that select the ones where 
> the salary is < 500, and from that project over name, salary, and hire."
> 
> Think of SQL compared to something like
> 
> (((X join Y) select {salary < 500})
>     select {X.name = Y.name}) project [name,salary,hire]
> 
> Only select, project, and join are defined in the algebra. There's no 
> "exists" and such.

So are the two formalisms of equivilent expressive power?

Post a reply to this message

Invisible wrote:

> I've come up with a language I'm calling Hax.

...so does this qualify me as a haxor? :-D

Post a reply to this message

On Mon, 27 Jul 2009 11:36:24 +0100, Invisible <voi### [at] devnull> wrote:

>Invisible wrote:
>
>> I've come up with a language I'm calling Hax.
>
>...so does this qualify me as a haxor? :-D

More like a Haxet :P

Invisible's hacket ;)
-- 

Regards
     Stephen

Post a reply to this message

Invisible wrote:
> So are the two formalisms of equivilent expressive power?

As far as I understand it, yes. They're just different ways of saying the 
same thing.  It has been a number of years since I've had to deal with the 
formalisms of it.  Also, there may be differences when it comes to updating 
the relations (insert, delete, update, etc), as I don't know just how that's 
handled in the formal math of it.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Orchid XP v8 wrote:
> There are many people who believe that Haskell is a weird and baffling 
> language.

There are many people who believe that English is a weird and baffling 
language.

I kinda like that.

Regards,
John

Post a reply to this message

Invisible wrote:

> I've come up with a language I'm calling Hax. I haven't finished 
> figuring out what it looks like or how it works yet. It's basically 
> Pascal with a few tweaks. And by "tweaks" I mean that the similarity 
> between Hax and Pascal is like Java vs C++. Superficially, it looks the 
> same. But if you investigate for more than 5 seconds, you'll discover 
> that they're actually TOTALLY UNRELATED! >_<

As I've rapidly discovered, designing a language like this means that 
the syntax tree ends up being *really* complicated!

I mean, your basic Haskell syntax tree consists of a type for 
expressions, a type for patterns, and a type for type signatures. And 
for that, you get a usable language. (Of course, once you start wanting 
classes and infix operators and modules and so on, it starts to get more 
complicated. But the basic language is really very simple.)

Hax, on the other hand, requires about four pages of type declarations 
to describe its syntax tree. (And, therefore, a similar amount of code 
every time you want to process it somehow.) I'm not even sure I've got 
it right yet! o_O

Hmm, maybe this wasn't such a sensible idea after all. ;-)

Post a reply to this message

Invisible wrote:
> Invisible wrote:
TOTALLY UNRELATED! >_<
> 
> As I've rapidly discovered, designing a language like this means that 
> the syntax tree ends up being *really* complicated!

I'm swingin' by my tale in a syntax tree. ;)
Did the original forbidden fruit come from a fault tree?

Is there an icon for Totally unrelated (= out on a limb)? :-P ?

David :)

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Hmm, maybe this wasn't such a sensible idea after all. ;-)

Maybe you should rename the language "Hoax" :P

(*ducks and runs*)

Post a reply to this message

>> Hmm, maybe this wasn't such a sensible idea after all. ;-)
> 
> Maybe you should rename the language "Hoax" :P

Considering it's purpose... that might not actually be such a bad idea.

Post a reply to this message

Invisible wrote:
>>> Hmm, maybe this wasn't such a sensible idea after all. ;-)
>>
>> Maybe you should rename the language "Hoax" :P
> 
> Considering it's purpose... that might not actually be such a bad idea.

Didn't someone create a computer language based on LOLcat speak?

-- 
~Mike

Post a reply to this message

Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> Didn't someone create a computer language based on LOLcat speak?

That would be LOLCODE, yes:

http://en.wikipedia.org/wiki/LOLCODE

Post a reply to this message