The future of the Crystal language
crystal-lang.org
crystal-lang.org
BTW : I looked at crystal syntax (I am talking about only syntax). Syntax designed extremely clear. I would say (my opinion, in short time I had to investigate crystal) maybe clear'er that python.
I wish more people took this aspect of their projects seriously. You don't need a short domain name, but your project does at least need to be Googlable.
After some time Google learns and shows you relevant results, but if you use Startpage or DuckDuckGo, you have to add "lang" or "framework" to search query
Side Note: In DDG Lua doesn't need 'lang', you can type in a function name and it'll give you documentation in the 'instant answers' thing.
> type by traversing the program, instantiating methods, and checking what gets assigned to them. So we can’t really reuse the cache because we can’t know the final
> types until we type the whole program! It’s a chicken and egg problem."
Maybe I'm oversimplifying it, but suppose you compiled a statement like...
a++
...into something like...
if a is an integer (which would presumably be something fast like "CMP [RAX],123; JNZ NotAnInteger") do "INC [RAX+8]", otherwise do more expensive stuff to look up the actual type and a function to use as a ++ operator?
As long as the programmer sticks to the same type, the compiled expression runs fast, and if they switch types midstream, it still runs, albeit with a performance hit.
http://chrisseaton.com/rubytruffle/deoptimizing/
This would have the effect that you describe (actually even faster than what you're proposing, by essentially trapping on all changes to the target to know ahead of time that deoptimisation has to occur), but it's not the world's most trivial feature to implement.
We love Ruby's efficiency for writing code.
We love C's efficiency for running code.
We want the best of both worlds.
We want the compiler to understand what we mean without having to specify types everywhere.
We want full OOP.
If they are looking for complainers about having to specify type on Array and Hash declaration I'll complain... It's seriously one of the problems with Crystal that kept me away. I'd guess some other rubyists are turned off by specifying types.
Specifying types everywhere basically takes Ruby-like syntax and makes it look like Scala or Rust. Why bother with a fully typed Crystal then when similar alternatives have greater support and other advantages?
Now imagine if we forbid ourselves to modify our guesses, you'll see how understanding natural language a forbidding task ...
Compilation is essentially a guess of meaning with no room for modifications -- neither self-modifications nor post-hoc modifications. So it is doomed for inefficiency or un-trackable difficulties.
I believe the right way for the future of programming is multi-stage compilation -- with first meta-compilation followed with static compilation. Currently our compilation only refers to the latter. The meta compilation produces human readable intermediate result -- not much different from our current code in C or Java and it will be as easy to feedback from as we do today in C or Java. However the meta-compilations takes many guesses and quite often adventurous guesses but the coder can easily tell whether it is on-track or guessed wrong. When the coder detect the meta-compilation guessed wrong, he will simply modify his source code -- slight change styles or simply write the code in a different way (which is not much different from human communication when we say "what I meant was ..."); or, in a few specific or difficult cases, the coder may opt to directly modify the intermediate code (C or Java or any of current popular languages) -- not much different from natural language when we reduce to more specific way as we write laws and contracts.
I have been exploring such idea with MyDef -- a meta programming system -- and have been more convinced it is the more sensible way (than trying to make break-throughs in the mature field of programming languages).
Ruby's syntax is one of the worst parts of Ruby. [0]
>We love C's efficiency for running code.
Many other languages have efficient native code compilers, too. I don't know why people assume this is only a C thing.
>We want the best of both worlds.
>We want the compiler to understand what we mean without having to specify types everywhere.
This is good. I much prefer dynamic languages to static ones. Though I don't know if Crystal supports the best parts of dynamic languages like runtime program modification AKA live coding.
>We want full OOP.
Single paradigm languages feel very restrictive to me. I like languages that support many paradigms because different parts of programs call for different programming techniques. OOP in particular is a paradigm that I feel forced to use more often than I feel it's the right technique for the task at hand.
[0] http://programmingisterrible.com/post/42432568185/how-to-par...
I think it's just become very common to show C as the reference to show how fast are other programming languages, and everyone keeps it this way.
> Ruby's syntax is one of the worst parts of Ruby. [0]
For people who write the language, yes, it's incredibly hard to parse (and that blog post doesn't mention the new ambiguous things like keywords vs. hashes)
Yet, for people who use Ruby, it's very convenient and easy to read.
After learning a variety of programming languages, I think homoiconic syntax is the only type I actually like.
> Similarly, distinguishing puts ([1]).map {|x| x+1} from puts([1]).map {|x| x+1} is handled by setting flags after skipping whitespace, and later checking these flags to emit an LPAREN or an LPAREN_ARG token. As well as semantic whitespace, flags are used for blocks, class definitions and method names too.
What the actual fuck.
That's not particularly unusual, is it?
>Ruby's syntax is one of the worst parts of Ruby. [0]
Your reference is about parsing the syntax, I am certain the authors mean they want Ruby syntax from the coders perspective not from the parsers perspective.
Nice work to date...