Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clean – A functional programming language

clean.cs.ru.nl

Post reply on HN
Print view View original

51–60 of 68 posts

Re: Clean – A functional programming language

#51

Post by vesak »

sitkack wrote: post #32
stewbrew wrote: post #22

Earlier quoted context omitted.

It took ages for Haskell to become "popular". My personal impression is that OCaml was more popular in the past and lost ground in recent years. OCaml's story demonstrates though how difficult it is to turn an academic research language into a widely accepted tool that is (financially) supported by the industry. Clean had a performant compiler when Haskell was mostly interpreted and slow. Why didn't it take off? Mayb…

Languages don't win. Package management and distribution wins. Access and energy required for a viable solution.

Excellent point. Haskell got Cabal in 2005, and even if it to this day continues to be rather awkward to use, it is something. Clean never developed anything for this.

I believe a large part of Rust's popularity is due to its superb library infrastructure via Cargo and crates.io. Furthermore, I believe a large part of its contemporary competition (say, go, swift and crystal) tripping on its own feet is the lack (or weaknesses) of such a thing.

Re: Clean – A functional programming language

#52

Post by vesak »

xyproto wrote: post #46
sitkack wrote: post #32

Earlier quoted context omitted.

Languages don't win. Package management and distribution wins. Access and energy required for a viable solution.

C won befoee package managers and Linux distributions existed.

If any of its competitors had had package managers as good as some of the modern ones, C would have lost.

Re: Clean – A functional programming language

#53

Post by agumonkey »

joe_the_user wrote: post #3

The thing about syntax like this fac :: Int -> Int fac 0 = 1 fac n = n * fac (n-1) to me, is that all the statements of this function declaration seem "disconnected". I'm guessing the "fac" connects them but it seems less clear than open-closed brackets in a c-like language (and also more cluttered). Especially, I'm not sure what tells me I've reached the end of the function declaration. This may seem trivial but it'…

as other said it's math tradition, your point about "open" fear is valuable though, you'd have to trust people not to scatter bits of defintion but well it's never a real problem.

About style, after a while spent reading about FP, I just can't solve problems without it.

Most of my code quickly ends up in lines of

  // f     => desired structure //// type
  // f   => desired structure //// type
which then gets translated on whatever language I end up writing (javascript, java, emacs lisp ..)

Re: Clean – A functional programming language

#54

Post by zem »

emmelaich wrote: post #2

You wonder why Clean isn't as popular as Haskell and Ocaml. I've read it's the lack of community. The name doesn't help either.

it was being developed on windows, and the gui library didn't work on linux. at least that's what kept me from picking it up, and i suspect a lot of the language enthusiasts who might have adopted it were similarly linux users, especially in the early 2000s

Re: Clean – A functional programming language

#56

Post by johnbender »

It's kind of a bummer to me that the one of the top comments here is about the syntax.

I get that people have syntax preferences and that there's a certain level of "sniff" test that goes along with these things, but as a fan of programming languages I am always interested in the semantics. That is, I'm interested in what's different about this language and its combination of features and goals:

http://clean.cs.ru.nl/Language_features

> The uniqueness typing system of Clean makes it possible to develop efficient applications. In particular, it allows a refined control over the single-threaded use of objects which can influence the time and space behavior of programs. Uniqueness typing can also be used to incorporate destructive updates of objects within a pure functional framework. It allows destructive transformation of state information and enables efficient interfacing to the nonfunctional world (to C but also to I/O systems like X-Windows) offering direct access to file systems and operating systems.

When I read that I think, "Wow! That seems really neat and reminds me of linear types, and I should check this out". Maybe that's just me though.

It's also worth noting that the features page does not mention the word syntax. That's not a deep insight or strong evidence for anything really but it suggests that the designer was interested in the semantics too and that the syntax was a secondary concern.

Re: Clean – A functional programming language

#57

Post by brett40324 »

pasquinelli wrote: post #49
xyproto wrote: post #46

Earlier quoted context omitted.

C won befoee package managers and Linux distributions existed.

well, unix was written in it, making it a natural choice if you're writing unix programs, or if you are writing programs on a unix.

And symbiotically, C was written to write unix.

edit: to note that by 'written' i mean designed and initially implemented.

Re: Clean – A functional programming language

#58

Post by joe_the_user »

always_good wrote: post #24
ggm wrote: post #9

Earlier quoted context omitted.

I have struggled with FP for many years. What I try and do, is approach these concepts with an open mind and I look for ways of 'saying' what I see which I then rehearse with my FP friends and stick to the one which does not make them wince when I say it. So this says three true things we know about this 'fac' Firstly it says it takes an int and it returns an int. Secondly that if the int it takes is specifically zer…

Might be cool to just overload in the function body instead of at the top level: fac :: Int -> Int (0) => 1 (n) => n * fac (n-1)

Just adding parenthesis to the original would make it clearer and closer to the mathematics expresses the structure. Especially given that parenthesis are clearly used sometimes to designate arguments in here.

    fac :: Int -> Int 
      fac(0) => 1
      fac(n) => n * fac(n-1)

Re: Clean – A functional programming language

#59

Post by e12e »

TheAceOfHearts wrote: post #21
joe_the_user wrote: post #3

The thing about syntax like this fac :: Int -> Int fac 0 = 1 fac n = n * fac (n-1) to me, is that all the statements of this function declaration seem "disconnected". I'm guessing the "fac" connects them but it seems less clear than open-closed brackets in a c-like language (and also more cluttered). Especially, I'm not sure what tells me I've reached the end of the function declaration. This may seem trivial but it'…

Also, aren't the types incorrect? Glancing over their docs, Int represents a signed integer. A negative input shouldn't be allowed, nor can you guarantee that your output fits in an int. Now I'm slightly curious as to how they handle overflows. Maybe they do runtime checks? Conflating of data types with storage types is a surprisingly common occurrence, although I can appreciate it's largely due to pragmatism.

Reminds me of this (old) issue I recently came across wrt factorial in Julia (just googling to figure out promotion to handle 52! - the trick is using a bigint).

Point being, you're spot on about mixing types and even "simple" functions need not be trivial (for various reasons, eg: factorial of a negative number - might be defined as negative infinity):

https://github.com/JuliaLang/julia/issues/6579

Re: Clean – A functional programming language

#60

Post by joe_the_user »

johnbender wrote: post #56

It's kind of a bummer to me that the one of the top comments here is about the syntax. I get that people have syntax preferences and that there's a certain level of "sniff" test that goes along with these things, but as a fan of programming languages I am always interested in the semantics. That is, I'm interested in what's different about this language and its combination of features and goals: http://clean.cs.ru.nl…

"It's kind of a bummer to me that the one of the top comments here is about the syntax.

"I get that people have syntax preferences and that there's a certain level of "sniff" test that goes along with these things, but as a fan of programming languages I am always interested in the semantics."

Well, as the syntax commenter, perhaps I'm a bit defensive but I feel like syntax is inherently an important part of what makes a language appealing - features aren't enough. To take it further, I'm pretty sure if you only absolutely only wanted features for manipulating things, you could find those features in some C++ or Java library. Just the Boost library is vast beyond my ability to encompass it but I'd prefer not to be manipulating hundred-line spews of angle-brackets and stuff.

And I, too, like programming language and I feel what makes a language as such cool/useful/etc is that you express a computer's action in a compact, elegant and clear fashion for one's fellow human beings. I remember Steve McConnell said something like "the compiler only has to read source code once but your fellow programmers will need to read it thousands of times".

...it suggests that the designer was interested in the semantics too and that the syntax was a secondary concern

Well, the problem is semantics is part of the user experience regardless of the developers intent. If anything, whenever X is important but X is not a concern of the developers, the chances of X biting you go up, not down.

Post reply on HN