The Crystal Programming Language • Hacker News Board

Re: The Crystal Programming Language

#161

Post by jwecker » Sun, Jun 07, 2015, 7:47 AM UTC

aikah wrote: post #124

I'm a go user right now, but I really want to ditch it because I'm in total disarray with the way the go language is managed and the deafness of the go team. Been looking at D,Nim and Crystal. - D is neat but I'm not interested at all in unsafe stuffs and don't want to have to debug programs or 3rd party libs that relies on that, I want a safe language. - Nim looks really good, although some features like (foo_bar =…

Quick fix, in nim:

  foo_bar = fooBar
  Foo_bar = FooBar
  foo_bar != FooBar

That is, it's case sensitive with the first character of the identity.

I've mentioned elsewhere that this one bugged me at first, but in practice it simply means that you get to use the language as if your preferred convention (whether snake or camel) is the "official" one- even when calling other libraries. Nothing more and nothing less. Cases where you need both styles but need them to be different things tend to be non-existent / code-smell.

Re: The Crystal Programming Language

#162

Post by giovannibajo1 » Sun, Jun 07, 2015, 9:04 AM UTC

MrBra wrote: post #159

davexunit wrote: post #152

Earlier quoted context omitted.

I've built many a class in Ruby.

> I've built many a class in Ruby. I see..... Anyway, this is elegant to me: sum ||= (1..100000).to_a.inject(:+) Maybe you have a different aesthetical sense than the rest of us. That's perfectly fine, we don't have to like the same things. But since you questioned, now I'm curious and I would like to ask you: what language in your opinion has the most elegant syntax? Also if you have 2 extra minutes free, would you…

In Python it's x = sum(range(100000)). You might say that's cheating because there is a specific sum function, but having smart builtins covering common programming cases is exactly what an elegant language offers.

Re: The Crystal Programming Language

#163

Post by therealdtscode » Sun, Jun 07, 2015, 9:16 AM UTC

JoeAltmaier wrote: post #155

mbel wrote: post #134

Earlier quoted context omitted.

You are probably talking about C++, not C, unless those look identical to you: foo(); int foo; (int)foo;

the cast can equally be int(foo); or (int)(foo); The parenthesis are allowed and optional. The method can be declared (int) foo(int(x), int(y)); which can also be an invocation. etc.

I wouldn't really say they are optional. The two do different things. (int) foo (or (int)(foo)) is a c-style cast. int(foo) isn't a cast. Instead it invokes the int constructor with the argument foo.

Re: The Crystal Programming Language

#164

Post by mbel » Sun, Jun 07, 2015, 9:31 AM UTC

JoeAltmaier wrote: post #155

mbel wrote: post #134

Earlier quoted context omitted.

You are probably talking about C++, not C, unless those look identical to you: foo(); int foo; (int)foo;

the cast can equally be int(foo); or (int)(foo); The parenthesis are allowed and optional. The method can be declared (int) foo(int(x), int(y)); which can also be an invocation. etc.

int(foo) and (int) foo(int(x), int(y)) are not legal syntax in C. However, they are in C++ [0], which is my whole point.

[0] your method declaration has a small problem, it apparently cannot have parenthesis around returned type.

Re: The Crystal Programming Language

#165

Post by waj » Sun, Jun 07, 2015, 3:31 PM UTC

kibwen wrote: post #145

atmosx wrote: post #120

Earlier quoted context omitted.

I don't understand what parsing has to do with elegance in this context. There are some 'best practices' but I don't see the different syntax support as a bug. I feel that it's a trademark of a modern language. Let's take rust as a counter example. IMHO this is ugly: fn foo() {...} To make it elegant I should be able to remove the parenthesis because there's no argument inside: fn foo {...} But this will come up with…

It's not just about making parsing easy (which is usually motivated by the promise of better tooling), it's about making costs explicit. `foo.bar` with no trailing parentheses is always a field access in Rust, and a field access is basically the fastest thing one can do: take a known offset from a memory location. In comparison, `foo.bar()` has a relatively tremendous cost, depending on various factors. It's for this…

`foo.bar` is always a call in Crystal. If `bar` is just an accessor, then the method will be inlined and there is no extra cost compared to make an explicit field access.

Re: The Crystal Programming Language

#166

Post by MrBra » Sun, Jun 07, 2015, 4:57 PM UTC

giovannibajo1 wrote: post #162

MrBra wrote: post #159

Earlier quoted context omitted.

> I've built many a class in Ruby. I see..... Anyway, this is elegant to me: sum ||= (1..100000).to_a.inject(:+) Maybe you have a different aesthetical sense than the rest of us. That's perfectly fine, we don't have to like the same things. But since you questioned, now I'm curious and I would like to ask you: what language in your opinion has the most elegant syntax? Also if you have 2 extra minutes free, would you…

In Python it's x = sum(range(100000)). You might say that's cheating because there is a specific sum function, but having smart builtins covering common programming cases is exactly what an elegant language offers.

I wouldn't say it's cheating but without using that function maybe we could see more of the language syntax itself. That way we are just seeing method calling.

Re: The Crystal Programming Language

#167

Post by sandbags » Sun, Jun 07, 2015, 5:35 PM UTC

MrBra wrote: post #159

davexunit wrote: post #152

Earlier quoted context omitted.

I've built many a class in Ruby.

> I've built many a class in Ruby. I see..... Anyway, this is elegant to me: sum ||= (1..100000).to_a.inject(:+) Maybe you have a different aesthetical sense than the rest of us. That's perfectly fine, we don't have to like the same things. But since you questioned, now I'm curious and I would like to ask you: what language in your opinion has the most elegant syntax? Also if you have 2 extra minutes free, would you…

Having migrated to Clojure I prefer:

(reduce + (range 1 100001))

but you can make yours a little nicer by relying on a Range being enumerable, hence:

(1..100000).inject(:+)

Re: The Crystal Programming Language

#168

Post by asterite » Sun, Jun 07, 2015, 5:39 PM UTC

giovannibajo1 wrote: post #162

MrBra wrote: post #159

Earlier quoted context omitted.

> I've built many a class in Ruby. I see..... Anyway, this is elegant to me: sum ||= (1..100000).to_a.inject(:+) Maybe you have a different aesthetical sense than the rest of us. That's perfectly fine, we don't have to like the same things. But since you questioned, now I'm curious and I would like to ask you: what language in your opinion has the most elegant syntax? Also if you have 2 extra minutes free, would you…

In Python it's x = sum(range(100000)). You might say that's cheating because there is a specific sum function, but having smart builtins covering common programming cases is exactly what an elegant language offers.

In Crystal we also have sum: http://crystal-lang.org/api/

Re: The Crystal Programming Language

#169

Post by kayamon » Mon, Jun 08, 2015, 5:46 AM UTC

seanmcdirmid wrote: post #74

MCRed wrote: post #15

I love that we're getting new languages lately, but almost all of them seem to be ignore the significant new requirement of our age: parallelism & concurrency. Specifically, you need lightweight processes and no-shared-memroy architecture. While the number of cores on a machine is remaining relatively low, the number of machines in a system are going up. Erlang got this right and build a lot of infrastructure around…

> Specifically, you need lightweight processes and no-shared-memory architecture. No you don't. I mean, that's one way to do it, but its not the only way and is often not an option if you want real performance. CUDA (a language specifically designed for SIMT parallelism) supports shared memory for good reasons; the threads are also not lightweight in that way (though they rely on memory and branch coherence).

It can be argued that shared memory should be explicit-when-needed rather than everywhere-by-default though.

Re: The Crystal Programming Language

#170

Post by seanmcdirmid » Mon, Jun 08, 2015, 7:51 AM UTC

kayamon wrote: post #169

seanmcdirmid wrote: post #74

Earlier quoted context omitted.

> Specifically, you need lightweight processes and no-shared-memory architecture. No you don't. I mean, that's one way to do it, but its not the only way and is often not an option if you want real performance. CUDA (a language specifically designed for SIMT parallelism) supports shared memory for good reasons; the threads are also not lightweight in that way (though they rely on memory and branch coherence).

It can be argued that shared memory should be explicit-when-needed rather than everywhere-by-default though.

It can also be argued the other way, of course. Do you like eating vegetables or ice cream? It's like garbage collection, some people love it because it frees them from worrying about allocating and freeing memory. Others hate it for the same reason.