Ceylon: Quick introduction
ceylon-lang.org
ceylon-lang.org
There is also this huge 2013 article comparing eight JVM languages with each other: http://zeroturnaround.com/rebellabs/the-adventurous-develope...
In the end, only actually using the languages helps...
The Haxe compiler is much, much faster than Ceylon. I wonder if certain features just can't pass a speed threshold.
However, Haxe's algebraic data types are really not the same thing. It takes a bit more code to achieve an identical effect. On the other hand, algebraic data types are much more general purpose, and allow techniques like pattern matching.
http://en.wikipedia.org/wiki/Algebraic_data_type http://haxe.org/manual/lf-pattern-matching-introduction.html
In the case of Haxe, you can construct a pattern that uses guards and/or extractors (e.g., a pattern that matches cases where you have an empty Tree, or a tree that contains a specific Node. You could also do matches on structural subtypes, etc.)
> This code is not legal, since all three statements occur in the initializer section of the class body:
class Point() {
Float x => y; //compiler error: y is not referenceable
Float y => x;
Float->Float xy = x->y;
}
class Point() {
Float x => y;
Float y => x;
}
0: http://ceylon-lang.org/documentation/1.0/spec/html_single/#r...
interface IPoint
{
// Property signatures:
int x
{
get;
set;
}
int y
{
get;
set;
}
}
In the example above, this code:
class Point() {
Float x => y;
Float y => x;
}
class Point() {
Float x => y; //compiler error: y is not referenceable
Float y => x;
Float->Float xy = x->y;
}
You can't declare mutually-recursive methods before
initialization logic in the body of a class. You have to
declare them _after_ the fields of the class are fully
initialized.
To see why it's like this, you need to consider :
- Unlike most OO languages Ceylon statically _guarantees_ that a field of an object is initialized before it is accessed. (If we didn't, then we would have to have something conceptually equivalent to a NullPointerException when you access a field before initialization.) - We've always hated the amazingly repeaty syntax of constructors in C++/C#/Java.
What I mean is, in Java I have to write stuff like:
class Point {
final float x;
final float y;
Point(float x, float y) {
this.x = x;
this.y = y;
}
}
class Point(Float x, Float y) {}
class Point {
final float x;
final float y;
Point(float x, float y) {
fun();
this.x = x;
this.y = y;
}
void fun() { System.out.println(x); }
public static final void main(String[] args) {
new Point(1.0f,2.0f);
}
}
And while working on CDI and Weld, Gaving really was the one who pushed for "plug and play" in JBoss, mediating between departments and making sure stuff got usable and in some cases even quite fast. In the end, the Seam guys more or less abandoned EJB and more or less started the POJO trend.
Additionally, I thing that Gavin was one of the first to spot where Hibernate was heading and started to work on ceylon quite early (I forgot when). And if you read what he has written you can tell that he knows his stuff!
You have to give the guy some cred!
Kind of reminds me of the quote from the Groovy creator.
Seems like most of the JVM languages these days are created because people are too lazy to research the state of the art...
I wonder if the goal of making the language 'immediately readable to people who aren't Ceylon programmers' limits them too much. This might be why the type signature for functions in `void repeat(Integer times, void iterate(Integer i))` is so macabre.
Tuples and comprehensions are always nice. The 'tree syntax' stuff seem a lot like JSON-javascript, which I guess has found it useful.
At the end of the day I'm not convinced why this is a better language than the lot of JVM languages out there.
The map comprehension is very interesting, going beyond list comprehension. Should make functional style programming easier.
I wonder how big the download of the runtime is for running as Javascript inside the browser.
{i: i+1 for i in range(10)}
list(p.first_name + " " + p.last_name for p in people)
dict((p.first_name + " " + p.last_name, p) for p in people)
set(j.organization for p in people for j in p.jobs)
print(", ".join(p.first_name + " " + p.last_name for p in people))
set(j.organization for p in people for j in p.jobs)
{j.organization for p in people for j in p.jobs}
I think that conflating clarity of keywords with the clarity of language is a huge and pointless confusion, especially when touting metaprogramming, comprehensions and variadic function arguments.
It doesn't look like a bad language; its features seem well rounded, yet there's a lot of stuff out there that's both more capable, with features that are more orthogonal. There's less feature mishmash than Scala, certainly, but it doesn't seem that far up in the power spectrum to justify learning another language, especially when compared to Kotlin, its closest competitor.
Kotlin just seems to be better in most regards: much more compact syntax, similar features set without some of the questionable overhead of Ceylon, and extension methods.
This sales pitch finds me at home!
Also there seems to be some nifty features in there e.g native unions and intersections.
I'm thinking of something modifying form text boxes or something simple like that.
At my last job we had a Node.js app talk to a Scala backend and the other end of the system ran PHP. I mean we already had like 30 servers at least, so dedicating one to Node and a few to Scala wasn't a problem.
I'm not sure if it's quite as flexible as C++'s const-correctness, but if you're creating your own class hierarchy from scratch, you can (and are encouraged to) code in a style that basically ensures that every parameter is practically passed as a const (immutable) reference. So you can easily do things like make strongly-typed functional data structures that will compiler-complain if you try to modify them after creation, without needing to remember to type "const" all the time. And that's realistically what most people need at the end of the day.
I'm excited to experiment with this - it seems definitely designed by pragmatists who want to lower the barrier to entry and make it fun for non-functional programmers to code in (I'm looking at you, Haskell), but also encouraging and enforcing best practices wherever possible.
So I was mainly hoping it is like F#, that forces you to decorate non-immutable variables with the `mutable` keyword, inside a method/function.
However, thinking about it more deeply, this is not so important. Because local variables (in a method) are never shared between threads. So immutability doesn't suffer from them being mutable. Right?
http://smallcultfollowing.com/babysteps/blog/2014/05/13/focu...
"Put another way, it’s become clear to me over time that the problems with data races and memory safety arise when you have both aliasing and mutability. The functional approach to solving this problem is to remove mutability. Rust’s approach would be to remove aliasing."
Local variables themselves are naturally non-aliased, although the objects they point to might be.
PS apologies to anyone who's seen it before for trotting that link out yet again!
The reason for that is that a local variable could be captured by an anonymous function or nested function, and escape from the local scope, so it's exactly the same situation with a local variable as for an instance variable of a class: both kinds of variable break referential transparency.
LOL, what?
Time is a real property just like IO, effects, values and types. If people stop hand-waving, we would have fewer bugs.
I agree it's not right for everything, but there are a lot of operations that can be modelled with immutable data, such as most server-side web code - reads definitely, and a lot of the write operations don't actually need to mutate objects though most ORMs and other DB APIs do require this.
This depends on your definition of "the world". If time and memory are taken into account, you could easily make the case that the world is very much immutable. For example, if your friend changes his email address, its not as if his old address no longer exists. Even if it only exists in memory, it still exists somewhere, and you're still able to reference it.
If you're interested in this topic, I highly recommend Rich Hickey's talk "The Value of Values"[1].
Ps: welcome again Ceylon, hope you'll give RedHat a brighter future in the enterprise.
From late 80's to mid 90's (I think) there was even a magazine called Computer Language that focused almost exclusively on writing about different programming languages.
It was common to see articles about writing compilers and interpreters for your own languages in various magazines. One Amiga magazine I picked up in 1990 in Germany included a listing for a full (tiny) compiler for a Pascal inspired language.
Some languages, like Go, implement a different edition directly atop many various OS's, with their own garbage collection and type inference. Whereas others, like Coffeescript, are text generators sitting atop and relying on features of other languages. And there's many shades in between, such as languages that produce JVM bytecode rather than executables for each different hardware target the JVM sits atop.
Then there's the issue of how much support atop the text files a language directly supports. Some, like Kotlin, make IDE support an official policy, whereas others, like Java, don't, instead relying on third parties to provide it. Some languages only provide the visual interface. Macros, like in Clojure, and compiler directives, like in C, could also be considered "atop the text file syntax".
If readable source code in some certain language can be generated from a VM or an AST that many different "languages" target, then in a sense they're not really languages at all, only "bytecode generators" or "transpilers".
Ceylon seems like a very nicely designed language (and I don't mean syntax). I would love to see a LLVM back end and the requisite docs for low level system hacking.
[1] http://ceylon-lang.org/documentation/1.0/reference/interoper...
Regardless, my assertion is that the problem is when most of us write web apps, we think of it as a single application. Frameworks often make this worse, as half of them treat the goal as to hide that you are writing a distributed application.
Contrast this with what is really going on, where you have -- at a minimum -- a front end and a backend operating independently of each other. And I'm not just talking multithreaded. They are literally completely disconnected from each other.
So, consider how we use all sorts of paradigms to try and make writing a multithreaded program easier. Now, consider at the end of the day many of these tasks can be done with simple locks and semaphores. Better yet, consider that most of the higher abstractions build on those.
Now, when is the last time you saw a tutorial for using a semaphore between an html front end and a backend?*
* I'm really hoping someone proves me wrong on this question. :)
Version 0.1 was released on Dec 20 2011 : http://ceylon-lang.org/download-archive/ .
We've changed the submitted title (which was "Ceylon: A new language by Red Hat for the JVM and the browser") to the article title.
The language is still relatively new, and under active development: https://github.com/ceylon
...yet we introduce the VB-keyword "shared" instead of "public", "variable" instead of C#'s "var" and use square brackets instead of curly braces for array initialization. You know, just because fuck you.
Seriously I see this all the time in new languages. Why invent or change keywords just for the sake of changing? Why does Rust use "let"? Why does Scala use "def"? If you want easy adoptation from one of the two largest languages in the world, change what matters and stick with the rest.
let is the standard keyword for introducing a new, shadowing variable binding. It is a very old tradition and is immediately recognizable to functional programmers.
> If you want easy adoptation from one of the two largest languages in the world, change what matters and stick with the rest.
In the case of "let", it would be a false consistency with C/Java. Assignment in C/Java does not have the same semantics as a let binding in Rust, although a let binding in Rust has very similar semantics to a let binding in Scheme or Haskell.
† Here is a not-remotely-exhaustive list of languages with square sequence literals: D, Objective-C, Python, Ruby, JavaScript, PHP, the whole ML family, Clojure. On the other hand, C didn't even traditionally have array literals — it just had a special curly-brace initializer syntax you could use with arrays as well as other aggregates.