I was just thinking there hasn't been a new programming language announced in the last week or so. With so few existing languages to choose from that have extensive supporting toolsets and APIs, this will surely stand out.
I feel this is a very insightful comment that adds meaningfully to this discussion. Through the use of cutting and witty satire OP has demonstrated that there is in fact an overabundance of programming languages to choose from with support and tooling, not only stating the obvious, but also serving as a blistering put-down to an individual who worked very hard to provide something useful and did it for absolutely no compensation. Good show sir. I would like to humbly request a subscription to your newsletter.
is it supposed to be obvious how 'clay' is useful? no problem with everyone forking everything and starting yet another language, and it doesn't have to be useful, it can be done for the experience. but if it's advertised, it would be good to explain why?
I'm not sure what you're talking about. The main page language is nice but explains it as much as a job candidates resume header explain what kind of a job candidate he is in a few sentences. There is no comparison to other languages or code examples, there are no success stories that I can see. Maybe they exist, but no, the OP doesn't explain this at all.
I'm not sure why people feel the need to be an asshole here. People develop new languages, they are not all meant to be production ready from day one. If the language is not interesting to you, move along.
yes I agree, one should respect the manhours put into it and evaluate it objectively before pouring in things that give others no better overview over it.
And in every language thread someone starts mentioning how good go is,.
I don't see anything here that would make me consider this over Go, though. Languages are rarely chosen based on their designs alone. Go is about as bleeding edge as I can get away with in my job.
A big problem is lack of good, built in UTF-8 support. But the no garbage collection thing is interesting as I didn't spot any explicit allocs or frees anywhere when I skimmed.
It's funny that Go keeps getting mentioned when people talk about new C-like languages because as you point out, it's not actually very C-like. In fact, the only thing that I'd say was truly C-like is the ability to create standalone executables. One of the dead giveaways is that most interest in Go seems to be coming from the Python community.
A better comparison would be Rust and Clay. Rust seems to emphasize correctness in the type system, Clay on making existing C++ style generics less cumbersome to use (a frankly laudable intention). On the other hand, I think it would be easier to give Rust the good things in Clay than the other way around.
because you probably don't know what to look at after all. Look at the predicated type declarations for example. It's a language with concepts built in.
Actually, please do more than just "Hello world", which is not going to show how awesome your language is. Show a few snippets adding up to twenty or so lines of code that illustrate what's different about your language.
good add! show Hello World. plus, show snippets which illustrate what makes your language so special. Why it's worth existing in a world that already has several pre-existing languages and ecosystems to choose from.
No, it isn't. I mean, it's possible to call what the majority of dynamic languages do "passing by reference", but it isn't the same thing as Clay does.
In C#, if I do
int foo(int x) { x += 1; return x; }
...
int x = 3;
foo(x);
then afterwards the value of x is still 3. In Clay, if I do
foo(x : Int) { x += 1; return x; }
var x = 3;
foo(x);
then the value of x is now 4. I agree with the grandparent: this seems like a really terrible idea. (In fact, I was going to post a comment saying so until I saw that someone else had got there before me.)
[EDITED to add: By the way, usually "dynamic languages" means "languages with dynamic typing", and Java and C# would be excellent examples of widely used languages that are not dynamic in that sense. The question of whether values are passed "by object reference" (my preferred way of describing what they do) is pretty much entirely separate from whether the language is dynamic. For instance: C++ (not dynamic, not p.b.o.r.), Java (not dynamic, p.b.o.r.), MATLAB (dynamic, not p.b.o.r), Python (dynamic, p.b.o.r). C# has the unusual feature that some kinds of mutable objects are passed that way while others -- structs -- are passed by value, with the object (in principle) being copied when the call happens.]
Then Car.x = 4 which has confused a lot of new programmers. More importantly it's a more consice standard for cube(x) to cube(x) than to say x=cube(x).
Object fields are always passed implicitly by reference (if that makes sense). The value that holds the reference to the object itself is passed by value, unless you specify the "ref" argument modifier (in C#).
As the author of Myrddin, I'm kind of surprised that it's even been mentioned -- I'm not aware of it being used anywhere significant yet. (And the insignificant uses are just half-baked toy programs that I've written for myself).
It's pretty incomplete, and definitely not ready for prime time yet.
Thank you, that's cool! I have been looking for Deca for hours in my Bookmarks and the Web, didn't remember the name. (I have collected some languages to study too)
http://code.google.com/p/june-language/ (java+python)
http://code.google.com/p/j-rest/ (meta: api creator)
https://code.google.com/p/szl/ (google data project)
http://luvit.io/ (nodejs for lua)
http://sourceforge.net/projects/sisal/
http://zenlang.sourceforge.net/index.html (in dev)
http://ufo.wikispaces.com/ (in dev)
Ok, the last one is a joke, but worth sharing, haha really funnny how people spent their time
http://code.google.com/p/penor-programming-language/ (a joke?)
We indeed have a similar list. Habit had slipped from my memory. I really wish Cyclone gets resurrected. There was quite a bit of discussion on HN when its closure(no pun intended) was announced. You may like digging into Felix.
Apart from this family the other I have been window-shopping on is the high performance/productivity family, consisting of the likes X10, Chapel and Fortress. Thanks to Oracle, Fortress is now abandonware.
Off late I have been quite disappointed by this trend in HN to be very hostile to things that I would consider to be the very distinguishing traits of a Hacker. Now it seems some people here compete to jump over the other to complain against things that encourage/facilitate or are meant for tweaking, learning, exploring and breaking: all things that I consider the very essence of hacking. Case in point, recent discussion on Gentoo.
The behavior reminds me of a bunch of desperate and wannabe Pink Floyd fans we had in college, who would jump to rally the crowd to disco to the opening strains of Another Brick in the Wall, much to our bewilderment but apparently to look cool.
There is always Java, if you are happy with it, stay happy with it.
I've actually never programmed in Java (just a little Clojure). I'm hoping to take a class in it this fall.
Felix is on my big list of interesting languages, but I didn't really think of it in the same category as these. I'm sort of aiming for something better than C when I get around to writing an OS kernel, you know, "someday".
I think for your use case decac, clay, bitC and Cyclone would indeed be ideal. There is this Haskell like language with effects based typesystem that might be worth looking at, the name continues to escape me.
One can go very low level with Felix, after all you can write inline C, C++ and define C and C++ functions, but those are not type checked. ABI could also be an issue given that it compiles to C++.
Hmm, the last I remember hearing about it was a notice about how the creators were sort of giving up on it, and the website I had stored apparently hasn't been updated since 2010.
Yes, they plan to go a different direction, but it doesn't mean they give up with BitC (as of now), it's probably going to be refactored. The author discusses it in the 2013 post.
I don't understand why modern languages still use the "mutli-value context" in place of tuples. When I first saw it in Matlab, I thought it was a mistake, and seeing it in Go and Julia reinforced this belief. IMO, tuples are superior in almost every way, as they are first-class, i.e. they act like any other values. They also avoid such sad patterns:
record MyInt (value:Int);
// delegate any function called with a MyInt to be called on its Int value
[F] overload F(x:MyInt) = ..F(x.value);
where `..` must be used to extract multiple values in a single-value context. This could easily avoided using tuples.
The only advantage of Matlab-style multiple values is that they allow a kind of return-value type overloading, i.e. some Matlab functions perform less work if you don't only consume 1 return value. But I believe that this could be easily solved with a first-class code pattern.
Maybe modern languages don't have tuples because modern programming language designers don't have any|much|enough experience with tuples? If I wanted to play with tuples, what language(s) would I have to use?
Python, or any of the functional programming languages: OCaml, Haskell, probably Scala. Tuples are really just syntactic shortcut for immutable lists, so Clojure would be appropriate as well, even though it makes no distinction between a tuple and a list (e.g. "rest" parameters to a variadic function are a list).
What exactly do you mean by "multi-value context" and indeed "tuple" in this case? A tuple is traditionally an ordered list where the positions may or may not be assigned a name. When we assign names to the positions, we tend to call them "records". In other words the tuple [30, "Bob"] and the record {age: 30, name: "Bob"} are equivalent.
One language that prominently relies on tuples with unnamed fields, in the absence of a built-in record syntax, is Erlang. The downside to not having names is that to find a value you must know its position, which hides information in the implementation (refactoring the code in a way that changes the position, for example, might not result in a compile-time error), which is one reason that Haskell provides syntactic sugar for expressing tuple types using a record syntax.
One thing that Go does right is to sometimes allow you to address a record as a tuple:
var x SomeRecord = {1, "Bob"}
However, when reading, I believe (I haven't actually checked) you can't access a record variable as a tuple.
By "tuple", I mean a first-class object that has multiple elements; an immutable list of sorts (and by "first-class" I mean an object that can be stored into a variable). E.g. in python:
key, value = {'a': 1}.iteritems().next()
I could also do:
item = {'a': 1}.iteritems.next()
key, value = item
which shows that tuples are first-class.
By "multi-value context" I mean treating expressions differently depending on their context; some contexts are then "multi-value". E.g. in go:
v, ok = a[x]
Here, if `x` is present in `a`, `v` is assigned the value at `x`, and `ok` is `true`; otherwise, `ok` is `false`, and `v` is assigned the zero value of its type.
Note that I cannot do this:
pair = a[x]
v, ok = pair
as `pair = a[x]` has a different meaning in this context: it only returns the value at `x` (or the zero value), and gives no indication of whether `x` is present or not. So, the meaning of the expression `a[x]` changes depending on the context, which can be either "single-value" or "multi-value".
55 comments
[ 4.8 ms ] story [ 127 ms ] threadhttp://news.ycombinator.com/item?id=6094668
And in every language thread someone starts mentioning how good go is,.
- https://github.com/jckarter/Vinyl
- https://github.com/Blei/claytracks
I don't see anything here that would make me consider this over Go, though. Languages are rarely chosen based on their designs alone. Go is about as bleeding edge as I can get away with in my job.
A big problem is lack of good, built in UTF-8 support. But the no garbage collection thing is interesting as I didn't spot any explicit allocs or frees anywhere when I skimmed.
Go is about concurrency. Clay is about generics.
Go is garbage collected; Clay is not. This allows Clay to be more suitable in environments where GC non-determinism/performance is unacceptable.
A better comparison would be Rust and Clay. Rust seems to emphasize correctness in the type system, Clay on making existing C++ style generics less cumbersome to use (a frankly laudable intention). On the other hand, I think it would be easier to give Rust the good things in Clay than the other way around.
In C#, if I do
then afterwards the value of x is still 3. In Clay, if I do then the value of x is now 4. I agree with the grandparent: this seems like a really terrible idea. (In fact, I was going to post a comment saying so until I saw that someone else had got there before me.)[EDITED to add: By the way, usually "dynamic languages" means "languages with dynamic typing", and Java and C# would be excellent examples of widely used languages that are not dynamic in that sense. The question of whether values are passed "by object reference" (my preferred way of describing what they do) is pretty much entirely separate from whether the language is dynamic. For instance: C++ (not dynamic, not p.b.o.r.), Java (not dynamic, p.b.o.r.), MATLAB (dynamic, not p.b.o.r), Python (dynamic, p.b.o.r). C# has the unusual feature that some kinds of mutable objects are passed that way while others -- structs -- are passed by value, with the object (in principle) being copied when the call happens.]
https://github.com/jckarter/clay/wiki
Myrrdin: http://eigenstate.org/myrddin.html
Pascal: http://www.freepascal.org/
Cyclone is pretty dead.
It's pretty incomplete, and definitely not ready for prime time yet.
Apart from this family the other I have been window-shopping on is the high performance/productivity family, consisting of the likes X10, Chapel and Fortress. Thanks to Oracle, Fortress is now abandonware.
Off late I have been quite disappointed by this trend in HN to be very hostile to things that I would consider to be the very distinguishing traits of a Hacker. Now it seems some people here compete to jump over the other to complain against things that encourage/facilitate or are meant for tweaking, learning, exploring and breaking: all things that I consider the very essence of hacking. Case in point, recent discussion on Gentoo.
The behavior reminds me of a bunch of desperate and wannabe Pink Floyd fans we had in college, who would jump to rally the crowd to disco to the opening strains of Another Brick in the Wall, much to our bewilderment but apparently to look cool.
There is always Java, if you are happy with it, stay happy with it.
Felix is on my big list of interesting languages, but I didn't really think of it in the same category as these. I'm sort of aiming for something better than C when I get around to writing an OS kernel, you know, "someday".
http://www.codeblog.ch/2011/06/statically-linked-linux-execu...
I think for your use case decac, clay, bitC and Cyclone would indeed be ideal. There is this Haskell like language with effects based typesystem that might be worth looking at, the name continues to escape me.
One can go very low level with Felix, after all you can write inline C, C++ and define C and C++ functions, but those are not type checked. ABI could also be an issue given that it compiles to C++.
All the best for fun with kernel writing :)
Disciple ? (DDC) http://disciple.ouroborus.net/
The only advantage of Matlab-style multiple values is that they allow a kind of return-value type overloading, i.e. some Matlab functions perform less work if you don't only consume 1 return value. But I believe that this could be easily solved with a first-class code pattern.
One language that prominently relies on tuples with unnamed fields, in the absence of a built-in record syntax, is Erlang. The downside to not having names is that to find a value you must know its position, which hides information in the implementation (refactoring the code in a way that changes the position, for example, might not result in a compile-time error), which is one reason that Haskell provides syntactic sugar for expressing tuple types using a record syntax.
One thing that Go does right is to sometimes allow you to address a record as a tuple:
However, when reading, I believe (I haven't actually checked) you can't access a record variable as a tuple.By "multi-value context" I mean treating expressions differently depending on their context; some contexts are then "multi-value". E.g. in go:
Here, if `x` is present in `a`, `v` is assigned the value at `x`, and `ok` is `true`; otherwise, `ok` is `false`, and `v` is assigned the zero value of its type.Note that I cannot do this:
as `pair = a[x]` has a different meaning in this context: it only returns the value at `x` (or the zero value), and gives no indication of whether `x` is present or not. So, the meaning of the expression `a[x]` changes depending on the context, which can be either "single-value" or "multi-value".It's over 3 years old so a lot of it is probably out of date, but still interesting to see the thought process behind the language design.