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:
> 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.
"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.
I agree with most of what you say, and I'm sorry I should have been clear that I don't think your comment is without merit. In truth, I am reacting more to the general direction I see in PL discussion on HN (which is what I should have said but was too lazy to find other examples).
> To take it further, I'm pretty sure if you only absolutely only wanted features for manipulating things
I feel like lisp fits this bill to some degree. Being the AST itself it is "without syntax" to some degree. I wonder if you dislike Lisps? I can't really tell you what this means with regards to our discussion I'm just curious.
> 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.
Definitely! I would never suggest that we should entirely ignore how the syntax affects our ability to read the code but, to borrow the lisp example again, I don't care about typing lots of parenthesis if I'm otherwise effective.
Again, your earlier comment is not unfounded and I appreciate where you are coming from.
I'll admit my professional work has been limited to C++, python, Ruby, PL/SQL, Matlab and small DSLs. I've played lisp and the-fp-languages in college. Lisp and the-fp-language both seemed to at least have clean, simple syntax rules.
I started using Ruby both it was hip and because it's free form syntax was really fun. If there were languages I definitely to learn, I would be less critical about syntax and style.
My original comment on Clean's syntax wasn't intended as a full judgment on the language but simply a reaction, a reaction I shared because it seems like subjective impressions of syntax matter for the reasons I mention above.
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's always put my off this variety of functional language.
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 zero then the int it returns is specifically one.
Thirdly and lastly, for all other ints it returns that int, times (in the arithmetic sense) a recursive call to itself of the int one less.
I worry about why it doesn't have to say abs(n) but then I remember two negatives multiplied together are positive.
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)
No, the comment replied to has the first four words "Might be cool to". The differences are so minuscule that the argument could be made for it to be 2 differing standards for the same language.
Yes and no. For what I replied to is essentially garden shedding the language. The overall problem is grasping the concepts, weather or not you want es6 style lambdas, or proper haskell function definitions is irrelevant if you don't understand the concepts.
The style is lifted straight from mathematics tradition. It is a closed definition and so it would be syntax error to insert anything between the lines.
In Haskell you could always avoid that style and use the case syntax (or for this example guard syntax) instead. All varieties eventually desugar to a case analysis anyway.
Haskell even added curly braces as an alternate to indentation!
Is it a closed definition? The equivalent in Mathematica would allow one to add things whenever one wants, for example to add definitions for fac for negative integers, or to hard-code the value of fac 100.
If clean has a REPL (which I couldn’t easily find out from its web page) I expect it to have that, too.
In Haskell it certainly is a closed definition, you would get a "multiple declarations" syntax error if you tried to split the definition up. I would assume the same for Clean also.
In the Haskell REPL, you would need to enter the definitions together.
I think this is exactly the same as Haskell. As a matter of fact, I had to actually search their Wiki for the first example that was different from Haskell
I think it’s just a matter of familiarity. Once you learn how it works, it’s actually extremely elegant and in no way “disconnected.”
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):
Just implemented a List in OOP, just to proof a (different) point.
Everything is way more "disconnected" in OOP. For example I have to implement length in both the classes EmptyElement (0) and Element (1+next->length()). Both belong together, but they are scattered across the source code. With clean like syntax i would have written them right next to each other.
Anyone who hasn't tried a whitespace-significant language in anger is missing out.
I had started with F# and was put off by it like you described. I moved to Haskell and had difficulty understanding it yet again, but when I moved back to F# one more time it was a delight.
I LOVE python, it is the weapon I first take to any battle and the language I recommend to beginners. But, I have to admit that the fact that it is so easy to lose track of which "if" a nested "else" belongs to when modifying code, and, I've seen this being the source of so many bugs, that it has changed my opinion about whitespace-significant languages.
Also, I've come to appreciate when I write in say Rust, the fact that I can let go of the syntax, just write and focus on my ideas and let my editor sort the mess at the end.
> it is so easy to lose track of which "if" a nested "else" belongs to when modifying code, and, I've seen this being the source of so many bugs, that it has changed my opinion about whitespace-significant languages.
Having types and removing statements from the language make this much less of an issue
> I can let go of the syntax, just write and focus on my ideas and let my editor sort the mess at the end.
Elm has a whitespace significant syntax, but it too has an excellent code formatter tool.
Also, with editors like vim, you can press % to go to the matching brace (curly bracket). In fact that works in vi too, right from the early vi days; also, in vim, if you position the cursor on an opening or closing brace, it momentarily highlights the other one (at least if that brace is visible on the screen, can't remember offhand if this works even if not visible).
When you refactor, yes. In python, say you add a new condition inside a condition, it's really easy to get lost and indent the wrong one to the wrong level.
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 <param-1 subset> <param-2 subset> => desired structure //// type
// f <param-1 subset'> <param-2 subset'> => desired structure //// type
which then gets translated on whatever language I end up writing (javascript, java, emacs lisp ..)
This is what makes it clear. Instead of burying the value somewhere in an if expression, pattern matching makes it immediately clear what the evaluated value is for a given argument.
I think about it like you're listing various definitions for what something is, given various patterns to match against. For me, this makes it more palatable because each pattern has a different operation associated with it. It's almost like binding multiple functions to one name that are called based on what you pass in, instead of creating one function to do the operation -- even though that's exactly what you're actually doing. It's declarative programming, in a way.
the definition of fact ends when the lines starting with fac end. they aren't doing something nuts like mixing up lines of a function definition if that's what you're getting at.
also, this is syntactic sugar for a case statement.. and you couldn't just use those.
The only reason why clean has always been confidential is this:
"Developers wishing to distribute commercial applications (either publicly or privately) can purchase a commercial license."
Although there seams to be a dual license now? Can anybody with more understanding of legal verbiage confirm that if I choose to use the bsd+lgpl then the above restriction don't hold anymore?
> Clean is available under a dual license. Users can choose which of these two licenses they wish to operate under:
> 1 The Simplified BSD License (see below) applies to the libraries, runtime system and examples, the LGPL the standard GNU Lesser General Open Source license (see below) to the rest. The libraries, runtime system and examples consist of the files in the following directories (including subdirectories of these directories):
> - Libraries and Examples (versions for Windows)
> - StdEnv, data and examples (versions for Linux and Mac OS X)
> - libraries, RuntimeSystem and CleanExamples (source code).
> 2 A commercial license (see below) that can be purchased. Information on that license can be obtained from [check the original document for name and email]
So, it should be ok as using any LGPL library on any proprietary program. I wonder if they are making any money from the commercial license or this confusion is only harming the language.
No, I don't. I actually wonder why it gets mentioned. It is some professor's research project not an actual programming ecosystem. The documentation on the site is more than a decade old, it covers version 2.2 released in 2006. Want documentation on what has been happening since then? Pick up a research paper. By comparison Haskell has a dozen books on Amazon and plenty of newbie level documentation since multiple universities use it as a teaching language.
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? Maybe it wasn't the main goal of its developers once the publications were done.
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.
afaict there was a moment when most of the "pure" "lazy by default" functional language projects coalesced into Haskell to build working mass -- except the developers of Clean continued to see value in strictness analysis and uniqueness typing but that limited the numbers developing libraries and tools.
I don't know if it's changed much, but I remember that several years ago I thought about trying to learn Clean but I gave up because it looked like Linux was a second-class platform and the Clean project mostly focused on a Windows IDE.
Their documentation states: "The latest version 2.0 of the IDE is currently only available on the Wintel and MacOS/PowerPC platform. On the other platforms a much more restricted and older version of the IDE is available. "
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
For anyone in the Netherlands: There is a functional programming day being hosted by the Dutch Tax Authority on Jan 5th, and today is the last day to sign up! Check out the original link to see more details
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.