> If there ever comes a day when Haskell ships out of the door with
> top-quality libraries for doing most or all of the things that a typical
> developer would want to get done, then maybe Haskell will start to
> become popular.

The problem is that F# exists already, and I guess you wouldn't call it 
"popular" in the way that you would like Haskell to become.  So Haskell 
would need to become, in some way, superior to F# in order to become 
popular.

Post a reply to this message

On 17/04/2012 04:49 PM, scott wrote:
>> If there ever comes a day when Haskell ships out of the door with
>> top-quality libraries for doing most or all of the things that a typical
>> developer would want to get done, then maybe Haskell will start to
>> become popular.
>
> The problem is that F# exists already, and I guess you wouldn't call it
> "popular" in the way that you would like Haskell to become. So Haskell
> would need to become, in some way, superior to F# in order to become
> popular.

Haskell is /already/ superior to F#. ;-)

For a start, F# is functional in the same way that C++ is 
object-oriented. I.e., not very. F# is a normal OO language with a few 
slightly functional ideas bolted on the side as an afterthought.

But in all seriousness: Haskell will never be popular. Writing clean, 
maintainable code just isn't a high priority. Bashing out code as fast 
as possible is a high priority. Producing six point-releases per 
calendar month is a high priority. Being paid per LoC is a high 
priority. Nobody will ever want to use Haskell.

Still, at least if Haskell shipped with decent libraries, *I* could 
still enjoy using it. :-P

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> For a start, F# is functional in the same way that C++ is 
> object-oriented. I.e., not very. F# is a normal OO language with a few 
> slightly functional ideas bolted on the side as an afterthought.

  When will we see the Haskell# language?

-- 
                                                          - Warp

Post a reply to this message

Invisible escreveu:
> ...and then I feel depressed because I'm the only person in the UK who 
> programs in Haskell

you and at least Simon Peyton Jones.

Post a reply to this message

scott escreveu:
> If Haskell had a decent IDE and easy documented access to the rest of 
> the system I might consider using it.  But then F# exists already and I 
> haven't paid much attention to that so far...

IDEs are only really useful for OO languages.  You know, you have a 
variable holding an instance of a class, then you type "." and get a 
list of methods available... no such thing in functional programming 
where the order is reversed:  you have a function and want to apply 
arguments to it.  You may list arguments that match that function 
definition and you may even know their types (assuming "intellisense" 
got type inference), but most likely you're not directly applying those 
arguments to the function, but applying some other function to it first. 
  It sounds too much of hassle to use "intellisense" in those situations...

I fear IDEs are really only useful at getting away with lesser 
languages' weaknesses, AKA boilerplate cruft to make the compiler happy. 
  In Java, most of the IDE is used not just for that but also to handle 
all the xml needed, since it's the only DSL known to java-heads...

so, all that would seem to rest of usefulness for an IDE is project 
management.  Here too it proves pretty useless as it's only really 
needed to manage huge bloated projects full of boilerplate and xml.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I'm still a bit baffled that this is a valid thing to do, however...

  There's some baggage from C that would have better been dropped, but
as you may know, backwards compatibility can be a real b***h sometimes...

  It can be argued using the same logic as with uninitialized variables,
though: There are situations where execution never reaches the end of the
function, and hence having a 'return' statement there would be useless.
In most situations putting such a useless 'return' there is only a minor
inconvenience, but in theory it could be more complicated. Also, it makes
the function larger, so the 80's C hackers didn't like that (in the same
way as they didn't like the idea of spending a clock cycle to initialize
a variable with a value that would immediately be overwritten anyways).

  This would be an example of such a function:

std::string foo(int parameter)
{
    assert(parameter >= 0 && parameter < 4);
    switch(parameter)
    {
     case 0: return "Hello";
     case 1: return "there";
     case 2: return "world";
     case 3: return "!";
    }

    // Execution will *never* reach here
    // It's valid to omit a 'return'
}

-- 
                                                          - Warp

Post a reply to this message

Le 17/04/2012 21:51, Warp nous fit lire :
> the 80's C hackers didn't like that (in the same
> way as they didn't like the idea of spending a clock cycle to initialize
> a variable with a value that would immediately be overwritten anyways).

It was a time where memory access was done by putting the address on the
address bus, and the data was read/write on the data bus (and a wire was
dedicated to indicate if it was a read or write).
A time in which the memory respond time was faster than the CPU clock.
A time you could know the number of cycles to perform an addition, a
multiplication or a division (on integer). And gains a few cycles by
reordering expression.

A time I remember!

And it cost one cycle (may be a bit more, I do not remember the timing
for a move.l) to write a zero to a data bus-wide variable, but as many
cycles for an array. You do not want to waste 40 cycles to erase an
array of 40 int.

You already wasted a cycle to increase the stack usage, and by entering
a function you wasted a few more cycle saving a few registers on it too.

Post a reply to this message

Le 17/04/2012 14:13, Invisible a écrit :
> Obviously this /isn't/ what's so special about classes. The /actual/
> benefits don't appear to be mentioned.

The benefit of class over a simple struct/collection is in the
private/protected parts, and the mandatory centralisation of the
prototypes of all related functions (until you start playing with
friend, but that's another story).

The point in class is to separate the interface (how the outside world
see me and use me) from the implementation (how I do it internally).

Once exposed, the public interface must remain (it can be expanded, but
not changed drastically).
The implementation can be changed at any time.

And then we are going to enter some holy wars about automatic getter &
setter, and static member in class.


-- 
A good Manager will take you
through the forest, no mater what.
A Leader will take time to climb on a
Tree and say 'This is the wrong forest'.

Post a reply to this message

On 17/04/2012 08:09 PM, nemesis wrote:
> Invisible escreveu:
>> ...and then I feel depressed because I'm the only person in the UK who
>> programs in Haskell
>
> you and at least Simon Peyton Jones.

Yeah - I should go visit that guy sometime...

Post a reply to this message

On 17/04/2012 05:07 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> For a start, F# is functional in the same way that C++ is
>> object-oriented. I.e., not very. F# is a normal OO language with a few
>> slightly functional ideas bolted on the side as an afterthought.
>
>    When will we see the Haskell# language?

Well, a while back somebody did do a Haskell to .NET bridge for their 
PhD thesis.

(A /bridge/ is of course not the same thing as compiling to CIL. The 
Haskell stuff runs as normal, it's just that it can "talk to" stuff 
running on the .NET platform.)

Naturally, being a PhD thesis, it's proof-of-concept, not 
production-grade. And, I would imagine, no longer maintained. (Not that 
I suppose the /code/ was ever publicly released. The /thesis/ was, but I 
don't know about the runnable code.)

In a similar vein, one of the experimental Haskell compilers has a 
JavaScript back-end. As in, you write your Haskell program, compile it, 
and you get (several KB of) normal JavaScript which will run in any web 
browser. Again, not exactly production-grade, but interesting.

I think somebody somewhere once had a Haskell to Java compiler. (Or, 
more likely, a "small subset of Haskell to Java compiler".) Highly 
unfinished, of course.

Perhaps it would make an interesting research project... Maybe I should 
look up how either Java bytecodes or the CIL works, and write some code 
to target it.

Naturally, being able to run on either the JVM or the CLR wouldn't be 
interesting unless it's also simple and easy to access the existing 
class libraries. And that's another interesting project.

Post a reply to this message