Re: Crystal
On Wed, 20 Mar 2013 13:32:50 -0400, Russel Winder rus...@winder.org.uk wrote: PS http://www.digitalmars.com/d/archives/digitalmars/D/announce/ appears to stop in 2012-12 http://forum.dlang.org/group/digitalmars.D.announce Don't use that other thing any more. -Steve
Re: Crystal
On 2013-02-17, 10:52, Russel Winder wrote: Why is this thread on the announce mailing list instead of the discussion list? Because it's more an announcement, and less a discussion about D? -- Simen
Re: Crystal
On Wed, 2013-03-20 at 17:31 +0100, Simen Kjaeraas wrote: On 2013-02-17, 10:52, Russel Winder wrote: Why is this thread on the announce mailing list instead of the discussion list? Because it's more an announcement, and less a discussion about D? The original posting was clearly an announcement. No problem. However as the thread lengthened, it got more and more into discussion of content rather than being announcement, i.e. the thread should have shifted to a non-announcement list almost immediately. This undermines the separation of the list from the DMD one. No big deal though. PS http://www.digitalmars.com/d/archives/digitalmars/D/announce/ appears to stop in 2012-12 -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Crystal
On Sunday, 17 February 2013 at 06:28:09 UTC, Ary Borenszweig wrote: Hello everyone :-) I follow this newsgroup from time to time. I like D templates. I like the auto keyword. I like auto in templates. I love efficiency and expressiveness. I believe in smart compilers. (you might remember me: I'm the author of Descent) I *really* like D, because it cares about one thing I care about: *performance*. Let's save this world's energy. Let's make a better world. Let's make users' life more enjoyable. Let's be happy :-) But... do we really have to specify const pure safe nothrow and whatnot? Can't the compiler be smarter? I'm sure there must be a better way. Most new programming languages look like older ones. Newness comes slowly... One time I asked in this newsgroup if it was possible to have an auto keyword for function/method arguments. And... why not make all functions/methods be templates on the type of its arguments? I think nobody liked this idea. I said Ruby is like this: you never specify types in method definitions. But Ruby is not efficient. Ruby is a dynamic language. D is compiled, so it's faster. Don't make the mistake of comparing a dynamic language with a static/systems programming language. This were some of the answers I got. I started thinking about this idea: a compiled language that looked like a dynamic language. Is it possible? Today, I'd like you to take a look at what me and my friend Juan have been working on for the last half month or so. It's a new programming language which aims to be efficient, have similar syntax to Ruby, and where you never have to specify types of variables and arguments. https://github.com/manastech/crystal/wiki/Introduction I'd also like to ask you: 1. Do you know whether a similar language exists? It's not Ruby-like, but Julia has some similarities: http://julialang.org/ Best, Graham
Re: Crystal
On Sunday, 17 February 2013 at 06:28:09 UTC, Ary Borenszweig wrote: One time I asked in this newsgroup if it was possible to have an auto keyword for function/method arguments. And... why not make all functions/methods be templates on the type of its arguments? I think nobody liked this idea. I said Ruby is like this: you never specify types in method definitions. I started thinking about this idea: a compiled language that looked like a dynamic language. Is it possible? I think everyone who wants to create languages should first familiarize himself with ML family of languages and especially OCaml. It's got global type inference done right, you can write big programs never specifying types of arguments of functions, they all got inferred, and not just to first occurrence but to most general (polymorphic) form. The compiler is incredibly fast and generated code is pretty fast too (approximately as fast as Java). Things to learn: Damas-Hindley-Milner, structural typing, row polymorphism. So your questions are already answered ages ago: yes, it is possible to have static typing with conciseness of dynamic languages, speed of static languages and a fast compiler which inferences types. Also, knowing OCaml will make your life much easier as a compiler developer. Writing compilers is much much easier and more convenient in ML than in Ruby, I know it from first-hand experience, I did both in the past.
Re: Crystal
On Thursday, 28 February 2013 at 08:22:45 UTC, thedeemon wrote: On Sunday, 17 February 2013 at 06:28:09 UTC, Ary Borenszweig wrote: One time I asked in this newsgroup if it was possible to have an auto keyword for function/method arguments. And... why not make all functions/methods be templates on the type of its arguments? I think nobody liked this idea. I said Ruby is like this: you never specify types in method definitions. I started thinking about this idea: a compiled language that looked like a dynamic language. Is it possible? I think everyone who wants to create languages should first familiarize himself with ML family of languages and especially OCaml. It's got global type inference done right, you can write big programs never specifying types of arguments of functions, they all got inferred, and not just to first occurrence but to most general (polymorphic) form. The compiler is incredibly fast and generated code is pretty fast too (approximately as fast as Java). Things to learn: Damas-Hindley-Milner, structural typing, row polymorphism. So your questions are already answered ages ago: yes, it is possible to have static typing with conciseness of dynamic languages, speed of static languages and a fast compiler which inferences types. Also, knowing OCaml will make your life much easier as a compiler developer. Writing compilers is much much easier and more convenient in ML than in Ruby, I know it from first-hand experience, I did both in the past. My university degree had a strong focus in programming languages. We were not allowed to use ML, Lisp or Prolog for compiler design classes because it would make the project too easy. :) -- Paulo
Re: Crystal
On Wednesday, 27 February 2013 at 03:48:53 UTC, Jordan Miner wrote: It does make me wish that LLVM supported exceptions on Windows... It does support DW2-style exceptions on 32 bit MinGW now and there are preliminary patches for 64 bit SEH, even if 32 bit SEH is still unsupported. Actually, the biggest problem I encountered when I recently focussed on the LDC/MinGW port was TLS support in LLVM/MinGW. The mingw-w64 CRT from trunk already has my fix, and the LLVM patches are only waiting for somebody to actually commit them. Reminds me to note that all that would be left to make Windows/MinGW a first-class target for LDC is another week or two of work on the remaining few test suite/unit test failures and a Windows CI slave… David
Re: Crystal
On Sunday, 17 February 2013 at 06:28:09 UTC, Ary Borenszweig
wrote:
Hello everyone :-)
I follow this newsgroup from time to time. I like D templates.
I like the auto keyword. I like auto in templates. I love
efficiency and expressiveness.
I believe in smart compilers.
(you might remember me: I'm the author of Descent)
I *really* like D, because it cares about one thing I care
about: *performance*. Let's save this world's energy. Let's
make a better world. Let's make users' life more enjoyable.
Let's be happy :-)
But... do we really have to specify const pure safe nothrow and
whatnot? Can't the compiler be smarter? I'm sure there must be
a better way. Most new programming languages look like older
ones. Newness comes slowly...
One time I asked in this newsgroup if it was possible to have
an auto keyword for function/method arguments. And... why not
make all functions/methods be templates on the type of its
arguments?
I think nobody liked this idea. I said Ruby is like this: you
never specify types in method definitions.
But Ruby is not efficient. Ruby is a dynamic language. D
is compiled, so it's faster. Don't make the mistake of
comparing a dynamic language with a static/systems programming
language. This were some of the answers I got.
I started thinking about this idea: a compiled language that
looked like a dynamic language. Is it possible?
Today, I'd like you to take a look at what me and my friend
Juan have been working on for the last half month or so. It's a
new programming language which aims to be efficient, have
similar syntax to Ruby, and where you never have to specify
types of variables and arguments.
https://github.com/manastech/crystal/wiki/Introduction
I'd also like to ask you:
1. Do you know whether a similar language exists?
2. Do you think it's feasible? Right now we are getting rather
high compilation times (say, a minute) if we use lots of
generic classes on medium-large programs. We are still trying
to think of the best way to improve compilation times while at
the same time taking off programmer's burden.
(The compiler is written in Ruby, which is a bit slow, so that
might be one reason it is a bit slow on medium-large
programs... imagine Ruby might be 10 to 100 times slower than
C, so that minute might be reduced to less than a second... we
are currently working on bootstrapping the compiler... but if
compilation is on an exponential order, well, you know... ...
and the compiler is written in Ruby because it'll later (now?)
be easier to port to Crystal, which has a very similar syntax)
I ask about feasibility, but right now you can use this
language for small to medium programs (except the standard
library is still incomplete).
The goal of this programming language it so be as efficient as
possible, but probably it won't be as efficient as C in the
general case. But... who knows?
We are also thinking about incorporating concurrency features,
like the ones present in Erlang and Go.
In short: utopy =o)
I hope at least someone likes this project...
(I hope at least you, Jacob Carlborg, Ruby lover, find it
interesting... or maybe you, bearophile?)
Thanks for your comments,
Ary
P.S.: bin/crystal -e 'a = 0; 10.times { |i| a += i }; puts a'
-O3 -ll
I think this project is really interesting. I really like Ruby,
but I don't use it much because it is very slow. Another problem
I have with Ruby is that if you, say, rename a method but miss a
place it is called, you won't get an error until you try
executing that code at runtime (although I suppose tests should
catch that). Crystal fixes both of these. Also, I like how you
can call C functions. And it has macros.
It does make me wish that LLVM supported exceptions on Windows...
Re: Crystal
On 2/25/2013 6:50 AM, Ary Borenszweig wrote: On 2/19/13 6:08 PM, Walter Bright wrote: On 2/16/2013 10:28 PM, Ary Borenszweig wrote: https://github.com/manastech/crystal/wiki/Introduction Just a thought - the Introduction needs an introductory (!) paragraph at the beginning explaining what Crystal is, what its point is, and where it fits into the universe of programming languages. Maybe what's said in the homepage in enough? https://github.com/manastech/crystal Probably. But it should be in the Introduction page!
Re: Crystal
On 2/19/13 6:08 PM, Walter Bright wrote: On 2/16/2013 10:28 PM, Ary Borenszweig wrote: https://github.com/manastech/crystal/wiki/Introduction Just a thought - the Introduction needs an introductory (!) paragraph at the beginning explaining what Crystal is, what its point is, and where it fits into the universe of programming languages. Maybe what's said in the homepage in enough? https://github.com/manastech/crystal
Re: Crystal
On Sunday, 17 February 2013 at 06:28:09 UTC, Ary Borenszweig wrote: I'd also like to ask you: 1. Do you know whether a similar language exists? Not sure how similar all the goals are (dynamic with static benefits) but there is Magpie: http://magpie.stuffwithstuff.com/
Re: Crystal
On 2013-02-21 21:37, Jesse Phillips wrote: Not sure how similar all the goals are (dynamic with static benefits) but there is Magpie: http://magpie.stuffwithstuff.com/ Doesn't that run on the JVM? -- /Jacob Carlborg
Re: Crystal
On Thursday, 21 February 2013 at 21:59:06 UTC, Jesse Phillips wrote: Doesn't that run on the JVM? I couldn't find what it generates to. It has an interpreter in Java and C++ though. Ok, that sounds really stupid. I thought it had a compiled component, but I don't see that, just looks to be interpreted.
Re: Crystal
Jesse Phillips: Ok, that sounds really stupid. I thought it had a compiled component, but I don't see that, just looks to be interpreted. Magpie designer (Bob Nystrom) is a quite smart person :-) Here he explains two main kinds of iterations: http://journal.stuffwithstuff.com/2013/01/13/iteration-inside-and-out/ I think Magpie is not meant to become a widespread language, but it contains interesting ideas. I think the core of Magpie is interpreted, but you can run the type system statically, if you want. Bye, bearophile
Re: Crystal
On 2013-02-17 07:28, Ary Borenszweig wrote: The goal of this programming language it so be as efficient as possible, but probably it won't be as efficient as C in the general case. But... who knows? Do you know abou julia ? http://julialang.org/
Re: Crystal
On 2/20/13 6:28 AM, Knud Soerensen wrote:
On 2013-02-17 07:28, Ary Borenszweig wrote:
The goal of this programming language it so be as efficient as possible,
but probably it won't be as efficient as C in the general case. But...
who knows?
Do you know abou julia ?
http://julialang.org/
Yes :-)
Before we started developing Crystal we searched for similar languages,
found Julia and it really amazed us.
It's similar in some aspects, like the use of LLVM, multiple-dispatch
and the idea that implementing everything in the same language leads for
more optimizable and inlineable code (compared to Matlab, R, Python or
Ruby, where when you want to have optimized code you write it in C).
On the other hand, you must specify the structure (and optionally the
types) of a type:
type Foo
bar
baz::Int
qux::Float64
end
In Crystal a class's fields and types are inferred by its usage. And
anywhere in the code you can reopen a class to add more fields/methods
to it, which is something we like when you want to change/extend a
library's code without modifying its code (aka monkey patching :-P)
The following is an error in Julia:
julia a = [1, hello]
no promotion exists for Int64 and ASCIIString
But in Crystal it works just fine (I think you can still have arrays of
mixed types in Julia, but you either must specify it as Array{Any} or
use another constructor, not sure). We want that to work transparently
(with a minimal impact on performance, of course).
And Julia is oriented to technical computing, but we want Crystal to be
a general purpose programming language (not sure it can be a systems
programming language... probably yes since we already have pointers and
pointer arithmetic, but we'll probably need to add a lot more to the
language).
Finally, Julia has a macro system similar to Crystal... and in fact we
took the idea from there (though the original idea seems to come from Lisp).
Re: Crystal
On 2/16/2013 10:28 PM, Ary Borenszweig wrote: https://github.com/manastech/crystal/wiki/Introduction Just a thought - the Introduction needs an introductory (!) paragraph at the beginning explaining what Crystal is, what its point is, and where it fits into the universe of programming languages.
Re: Crystal
On 2/17/13 5:46 PM, Jacob Carlborg wrote: On 2013-02-17 21:22, Ary Borenszweig wrote: Since it's not yet implemented, it could be like that, or it can be that it is evaluated when you execute the program (but not at compile time). But if I just but code that the top level of a file, when at runtime is that executed? In the order it was analyzed. Same as in Ruby.
Re: Crystal
On 2013-02-18 13:46, Ary Borenszweig wrote: In the order it was analyzed. Same as in Ruby. I see. -- /Jacob Carlborg
Re: Crystal
17.02.2013 10:28, Ary Borenszweig пишет:
Hello everyone :-)
...
(you might remember me: I'm the author of Descent)
A Hero is here! Let me kowtow to you, a Descent Creator!
... Let's save this world's energy.
It's pleasantly to see this point of view at efficiency.
But... do we really have to specify const pure safe nothrow and whatnot?
Can't the compiler be smarter? I'm sure there must be a better way. Most
new programming languages look like older ones. Newness comes slowly...
One time I asked in this newsgroup if it was possible to have an auto
keyword for function/method arguments. And... why not make all
functions/methods be templates on the type of its arguments?
I think nobody liked this idea. I said Ruby is like this: you never
specify types in method definitions.
But Ruby is not efficient. Ruby is a dynamic language. D is
compiled, so it's faster. Don't make the mistake of comparing a
dynamic language with a static/systems programming language. This were
some of the answers I got.
I started thinking about this idea: a compiled language that looked like
a dynamic language. Is it possible?
Looks like it is, by what is the reason?
I'd like to specify function attributes explicitly because I do want to
get a compilation error when I e.g. use non-safe stuff in safe function
instead of a just compiler silently changing the function (and all
functions which use it) to unsafe. I also don't use type inference
everywhere because sometimes I do want to see exact types (yes, IDE
problem) and sometimes I just don't want a type to be accidentally
changed because of some function signature change as in the worst case
the code will still compile but will work incorrect.
Now about argument types. I do not understand the purpose of dynamic
typing at all and consider such languages too dangerous to use in real
projects. You proposal is a bit better as it will give CT errors
(instead of RT in dynamic typing case) but still bad as the code can
accidentally compile and work incorrect. Also this looks as a step back
as your proposal is like making from a function something like C's
preprocessor macro. And I remember how somebody defended C's macros and
told you can do it with macro, then he gave his code where he made a
fatal mistake by passing two parameters to a macro in a wrong order. And
that code accidentally compiled. Same thing can happen with every high
templated code where it is hard to predict every possible argument
combination.
I also have seen a lot of mistakes of any types in D templated code so I
consider such code almost as dangerous as pointer arithmetic and you
proposal to make everything a template looks as insane.
...
Thanks for your comments,
Ary
P.S.: bin/crystal -e 'a = 0; 10.times { |i| a += i }; puts a' -O3 -ll
Sorry for such cruel comment, I it is just my opinion.
--
Денис В. Шеломовский
Denis V. Shelomovskij
Re: Crystal
Ary Borenszweig: I started thinking about this idea: a compiled language that looked like a dynamic language. Is it possible? Of course it's possible, I given my help in the development of ShedSkin: http://code.google.com/p/shedskin/ Its compilation times are significant and they keep growing quickly as the amount of compiled code grows. Bye, bearophile
Re: Crystal
Why is this thread on the announce mailing list instead of the discussion list? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Crystal
On 2013-02-17 08:46, Paulo Pinto wrote: Have you looked into Ruby Motion or Mirah as well? Or MacRuby. It's free (as in free beer) and open source, not something that Ruby Motion is. -- /Jacob Carlborg
Re: Crystal
Am 17.02.2013 12:57, schrieb Jacob Carlborg: On 2013-02-17 08:46, Paulo Pinto wrote: Have you looked into Ruby Motion or Mirah as well? Or MacRuby. It's free (as in free beer) and open source, not something that Ruby Motion is. My problem with MacRuby and Ruby Motion is they are tied to Mac OS X. Crystal's usage of LLVM is actually quite positive in that regard. -- Paulo
Re: Crystal
On 2013-02-17 14:21, Paulo Pinto wrote: My problem with MacRuby and Ruby Motion is they are tied to Mac OS X. Yeah, I agree. But developing for iOS is pretty tied to Mac OS X anyway. -- /Jacob Carlborg
Re: Crystal
On 2/17/13 6:29 AM, Denis Shelomovskij wrote: I'd like to specify function attributes explicitly because I do want to get a compilation error when I e.g. use non-safe stuff in safe function instead of a just compiler silently changing the function (and all functions which use it) to unsafe.= It's something I didn't have time to write in that wiki page, but you can restrict the types of a function. def foo(x : Int) 1 end foo Hello # Gives a compile-time error This is similar to what you can do with D templates. You can also restrict an overload an use another one unrestricted and it will choose the correct one: def foo(x : Int) 1 end def foo(x) 2 end foo Hello # Chooses the second one So theoretically you can type everything you want. We might also support typing a variable in order to disallow it to change to another type (I think this is what is done in the Julia language). Now about argument types. I do not understand the purpose of dynamic typing at all and consider such languages too dangerous to use in real projects. In the place I work we've written several web applications and programs in Ruby and they work just fine. We writes lots of test units to make sure everything works (you don't have another option, really, with dynamic languages). Sorry for such cruel comment, I it is just my opinion. It's not cruel at all. I really appreciate your comments.
Re: Crystal
On 2/17/13 9:14 AM, Jacob Carlborg wrote: I find it very interesting. But actually I'm going to agree with Denis, mostly. If I was going to use Crystal I would probably use a lot more static typing than it's probably made for. I quite often miss static typing in Ruby. Often there are functions that are supposed to only work with a given type, I don't see why I shouldn't explicitly write that type out then. As I replied to Denis, you can specify type restrictions in functions and methods. def foo(x : Int) 1 end foo Hello # Gives a compile error It works similar to overloaded templates: you don't specify the type of the function, but which types you can give to it. In the case of Int, of course it will always just accept an Int. But you can specify for example def foo(x : Enumerable) end And there's a special restriction, self, that will only match for the owner of the method. This is used for example in the Comparable module: https://github.com/manastech/crystal/blob/master/std/comparable.cr A couple of questions: * Executable code at class level, is that supported? If that's the case, when is it run? Example: class Foo puts asd end I thought it was supported but it's not. It would be very easy to support it, but it would execute at run time, as if you had put it before the class declaration. However, there's another thing I didn't mention in that wiki page and that is macros. You can write; --- macro define_something def something; 1; end end define_something() # This defines the something method something() # And this invokes it --- Again, this is different from Ruby. Macros are executed at compile time. You can pass arguments to them, and their type will be the AST node of the expression you give them. They must return a String (for now), and it will be mixed in the program (later we'll support returning AST nodes directly). We use macros for attr_accessor and the like: https://github.com/manastech/crystal/blob/master/std/object.cr Just note that this is an experimental feature, and for now only variables, strings and symbols are allowed for macros. Macros can execute arbitrary code and have access to what you defined in your program. That means they can open a file, read/write a database and so on. I believe this can be very powerful for metaprogramming. (this is inspired mainly from Lisp) * With a statically typed languages you quite soon get the need for interfaces, abstract classes and similar. How is this handled? If you don't need them in Ruby I don't see why would you need them in Crystal. The only use of interfaces is to satisfy the compiler. But since Crystal is mostly duck-typed interfaces have no use. Another use is probably performance, and we are still considering how to fit everything together. We are writing code in Crystal and see where it's slow, and think of the most little change that's not a burden for the programmer that can help speed up compilation times. * Is Ruby code supposed to be able to run of out the box in Crystal? That is can I take arbitrary Ruby code and compile it with Crystal and expect it to work. If that's the case, what's currently supported and what's not supported? You probably won't have eval, define_method and so on. You will be able to do some of those things with macros, but it's not the same. Most Ruby code should run out of the box, unless something is missing from the standard library. For example I tried running this code: https://gist.github.com/havenwood/4724778 (removing the Time.now lines, because we don't have that yet) and it just worked. And it was much faster than all of the other languages. Our idea was to make a language as similar as Ruby, not with the intention of compiling Ruby. But accidentally (or not :-P) it is happening, slowly. Thanks for your comments and questions!
Re: Crystal
Have you looked into Ruby Motion or Mirah as well? Ruby Motion is not open source, so we couldn't (or didn't want) to take a look at that. Mirah compiles for the JVM, and we want to compile to native code. We try to escape from virtual machines...
Re: Crystal
Am 17.02.2013 17:41, schrieb Ary Borenszweig: Have you looked into Ruby Motion or Mirah as well? Ruby Motion is not open source, so we couldn't (or didn't want) to take a look at that. I know, the question was more in the value proposal kind of way. Mirah compiles for the JVM, and we want to compile to native code. We try to escape from virtual machines... Currently yes, but there have been discussions to get it to compile to native code via LLVM.
Re: Crystal
On 2013-02-17 17:34, Ary Borenszweig wrote: As I replied to Denis, you can specify type restrictions in functions and methods. def foo(x : Int) 1 end foo Hello # Gives a compile error It works similar to overloaded templates: you don't specify the type of the function, but which types you can give to it. In the case of Int, of course it will always just accept an Int. But you can specify for example def foo(x : Enumerable) end Yeah, I saw there's explicit static typing. And there's a special restriction, self, that will only match for the owner of the method. This is used for example in the Comparable module: https://github.com/manastech/crystal/blob/master/std/comparable.cr So in that case self would evaluate, at compile time, to whatever Comparable is mixed in to? I thought it was supported but it's not. It would be very easy to support it, but it would execute at run time, as if you had put it before the class declaration. That code will be executed as soon as the file has been loaded using require? However, there's another thing I didn't mention in that wiki page and that is macros. You can write; --- macro define_something def something; 1; end end define_something() # This defines the something method something() # And this invokes it --- Yeah, I saw that. Again, this is different from Ruby. Macros are executed at compile time. You can pass arguments to them, and their type will be the AST node of the expression you give them. They must return a String (for now), and it will be mixed in the program (later we'll support returning AST nodes directly). We use macros for attr_accessor and the like: https://github.com/manastech/crystal/blob/master/std/object.cr Just note that this is an experimental feature, and for now only variables, strings and symbols are allowed for macros. Macros can execute arbitrary code and have access to what you defined in your program. That means they can open a file, read/write a database and so on. I believe this can be very powerful for metaprogramming. (this is inspired mainly from Lisp) This looks cool. If you don't need them in Ruby I don't see why would you need them in Crystal. You don't need them in Ruby because it's dynamically typed. The only use of interfaces is to satisfy the compiler. But since Crystal is mostly duck-typed interfaces have no use. But it does support explicit static typing. It doesn't look easy to restrict a method for a given type for something like an interface. So what will happen is one use duck typing and it will basically be the same as templates without constrains. Another use is probably performance, and we are still considering how to fit everything together. We are writing code in Crystal and see where it's slow, and think of the most little change that's not a burden for the programmer that can help speed up compilation times. * Is Ruby code supposed to be able to run of out the box in Crystal? That is can I take arbitrary Ruby code and compile it with Crystal and expect it to work. If that's the case, what's currently supported and what's not supported? You probably won't have eval, define_method and so on. You will be able to do some of those things with macros, but it's not the same. Most Ruby code should run out of the box, unless something is missing from the standard library. For example I tried running this code: https://gist.github.com/havenwood/4724778 (removing the Time.now lines, because we don't have that yet) and it just worked. And it was much faster than all of the other languages. Our idea was to make a language as similar as Ruby, not with the intention of compiling Ruby. But accidentally (or not :-P) it is happening, slowly. I see. -- /Jacob Carlborg
Re: Crystal
On Sunday, 17 February 2013 at 12:14:40 UTC, Jacob Carlborg wrote: Except from what others already have mentioned someone created a language with a Python like syntax written in D. But I think that had explicit types. http://delight.sourceforge.net/
Re: Crystal
On 2/17/13 4:09 PM, Jacob Carlborg wrote: On 2013-02-17 17:34, Ary Borenszweig wrote: As I replied to Denis, you can specify type restrictions in functions and methods. def foo(x : Int) 1 end foo Hello # Gives a compile error It works similar to overloaded templates: you don't specify the type of the function, but which types you can give to it. In the case of Int, of course it will always just accept an Int. But you can specify for example def foo(x : Enumerable) end Yeah, I saw there's explicit static typing. And there's a special restriction, self, that will only match for the owner of the method. This is used for example in the Comparable module: https://github.com/manastech/crystal/blob/master/std/comparable.cr So in that case self would evaluate, at compile time, to whatever Comparable is mixed in to? Yes. I thought it was supported but it's not. It would be very easy to support it, but it would execute at run time, as if you had put it before the class declaration. That code will be executed as soon as the file has been loaded using require? Since it's not yet implemented, it could be like that, or it can be that it is evaluated when you execute the program (but not at compile time).
Re: Crystal
On 2013-02-17 21:22, Ary Borenszweig wrote: Since it's not yet implemented, it could be like that, or it can be that it is evaluated when you execute the program (but not at compile time). But if I just but code that the top level of a file, when at runtime is that executed? -- /Jacob Carlborg
Re: Crystal
On 2013-02-17 20:50, JN wrote: http://delight.sourceforge.net/ There we go, thanks. -- /Jacob Carlborg
Re: Crystal
Am 17.02.2013 07:28, schrieb Ary Borenszweig:
Hello everyone :-)
I follow this newsgroup from time to time. I like D templates. I like
the auto keyword. I like auto in templates. I love efficiency and
expressiveness.
I believe in smart compilers.
(you might remember me: I'm the author of Descent)
I *really* like D, because it cares about one thing I care about:
*performance*. Let's save this world's energy. Let's make a better
world. Let's make users' life more enjoyable. Let's be happy :-)
But... do we really have to specify const pure safe nothrow and whatnot?
Can't the compiler be smarter? I'm sure there must be a better way. Most
new programming languages look like older ones. Newness comes slowly...
One time I asked in this newsgroup if it was possible to have an auto
keyword for function/method arguments. And... why not make all
functions/methods be templates on the type of its arguments?
I think nobody liked this idea. I said Ruby is like this: you never
specify types in method definitions.
But Ruby is not efficient. Ruby is a dynamic language. D is
compiled, so it's faster. Don't make the mistake of comparing a
dynamic language with a static/systems programming language. This were
some of the answers I got.
I started thinking about this idea: a compiled language that looked like
a dynamic language. Is it possible?
Today, I'd like you to take a look at what me and my friend Juan have
been working on for the last half month or so. It's a new programming
language which aims to be efficient, have similar syntax to Ruby, and
where you never have to specify types of variables and arguments.
https://github.com/manastech/crystal/wiki/Introduction
I'd also like to ask you:
1. Do you know whether a similar language exists?
2. Do you think it's feasible? Right now we are getting rather high
compilation times (say, a minute) if we use lots of generic classes on
medium-large programs. We are still trying to think of the best way to
improve compilation times while at the same time taking off programmer's
burden.
(The compiler is written in Ruby, which is a bit slow, so that might be
one reason it is a bit slow on medium-large programs... imagine Ruby
might be 10 to 100 times slower than C, so that minute might be reduced
to less than a second... we are currently working on bootstrapping the
compiler... but if compilation is on an exponential order, well, you
know... ... and the compiler is written in Ruby because it'll later
(now?) be easier to port to Crystal, which has a very similar syntax)
I ask about feasibility, but right now you can use this language for
small to medium programs (except the standard library is still incomplete).
The goal of this programming language it so be as efficient as possible,
but probably it won't be as efficient as C in the general case. But...
who knows?
We are also thinking about incorporating concurrency features, like the
ones present in Erlang and Go.
In short: utopy =o)
I hope at least someone likes this project...
(I hope at least you, Jacob Carlborg, Ruby lover, find it interesting...
or maybe you, bearophile?)
Thanks for your comments,
Ary
P.S.: bin/crystal -e 'a = 0; 10.times { |i| a += i }; puts a' -O3 -ll
Nice work.
Have you looked into Ruby Motion or Mirah as well?
--
Paulo
