A new year resolution to have Crystal reach the 1.0 milestone in 2017(crystal-lang.org) |
A new year resolution to have Crystal reach the 1.0 milestone in 2017(crystal-lang.org) |
Second of which is `yield`, ruby's extremely powerful way of passing code to functions. In crystal, functions which take blocks are actually inlined, meaning that abstractions such as `3.times {}` or `5.upto(20, step: 5) { |i| ... }` have zero cost. For example, take a look at how simple the HTTP server example is on the crystal homepage. Very useful for building DSLs.
Macros are another powerful (but hopefully not overused) tool for building clean programs. Crystal macros receive AST nodes but return source code as text. This text is then compiled and placed inside the program. This may sound like it would have the disadvantages of C macros, but as they're more integrated into the language, the compiler can insert the generated AST of the compiled macro into the original AST in a clean way. Using "dumb" text templating has several advantages: it's really easy to use because you're essentially just writing crystal code, and it's powerful as you get access to the AST. It also has the advantage that it's actually quite hard to make large scale modifications to a method body, preventing a lot of the silly macro uses.
> you're essentially just writing crystal code
even more so in a quasiquote, since you don't have to worry about adding extraneous parenthesis "just in case" etc.
Having structured input is already way better than full token-level solutions like C, but why not go all the way ?
A fast and typed Ruby, isn't it enough? ;)
For psychological reasons, things that build on what's familiar get increased adoption. Trend started with C syntax that I can tell.
Go is a good enough replacement for C, for user space applications.
With some improvements, even for more lower level tasks.
As for the flaws, anyone that had the pleasure to work with the Algol and Wirth family of languages is well aware of them.
Are you sure you are not describing Rust?
I just don't want to have to deal with a bunch of second guessing judgmental jerks anymore. Nobody in the Crystal community is going to go after me for something "not idiomatic" I published.
It will still be CRuby, but the "C" is Crystal.
edit: Windows 7
You can read more here: https://crystal-lang.org/docs/guides/concurrency.html
We're already well past the point where we could become "native ruby" and I'm glad of that. Ruby has quite a few warts, and I'm glad most of them haven't been copied by crystal.
Compilation times are already well under a minute for the whole of the crystal compiler itself. It was actually improved quite a bit on Linux in the latest crystal release.
"reach a point where breaking changes to the core of the language are down to a minimum"
I'm very afraid of the word minimum in this context. This is why "no one was ever fired for picking Java".
Aside from tooling I need a guarantee that my code, if following all of the best practices, should be compilable from now till the foreseeable future.
There's QT, which is huge and unwieldily and not so good looking on OS X, GTK+ which is a mess on both Windows and OS X, wxWidgets (based on other libs), and a few fringe, and incomplete libs.
For one-platform apps, though, or a single backend for multiple platform UI frontends, it will do just fine, provided we get bindings for Cocoa, Windows UI libs, GTK etc.
Crystal at the very least has good support for binding C so maybe this will be the language which finally produces a modern gui toolkit, but with the move towards web apps its becoming increasingly unlikely.
Crystal vs Ruby don't really compete in the same way Crystal and Go do, it's very much a dynamic vs static typing split. Crystal is in general a bit more cleaned up but Ruby's community is much larger.
What I meant with that remark was that those languages already had fast toolchains and were more expressive.
So in this regard I also appreciate Crystal, specially since RubyMotion decided to focus on mobile.
The neat thing about the OS was that it and its compiler were simple enough for students to understand that they regularly ported or improved it a few months at a time. It's also one of the most, well-documented OS's in existence.
That Go is basically a modified Oberon means Go, currently or with some modification, could be used for low-level, systems code up to operating systems. Even with a GC since the Oberon OS's are written in GC language. Most recent, graphical one is A2 Bluebottle if you want to look it up.
You missed that Robert Griesemer is also part of the Go team.
Edit* Just saw where you said "play"
a = Object.new
list_of_modules.each { |mod| a.extend(mod) }
irb(main):001:0> "".methods.size
=> 170
irb(main):002:0> 0.methods.size
=> 133
Well, the whole Cocoa/QT/WinForms scope might be huge, but we don't even have good minimal UI libs -- e.g. with just the few basic widgets: buttons, text fields, labels, radio buttons, checkboxes, kind of what HTML forms can do -- and only very limited functionality (e.g. no fancy text formatting in the labels or whatever).
Tons of programs could be GUI-fied with just the above (sort of what Tk does, but decent looking).
In any case, my view is a bit different, I see Go as a mix of an AOT version of Limbo mixed with bits of Oberon-2.
...there's probably some other stuff I could say, and probably more coherently, but it's early (for me) and I kind of just wanted to get that thought out there. I hope it's at least a bit thought-provoking, or something. If not, well, my apologies for rambling at you ;)
The Wirth languages were categorized by a focus on absolute simplicity and safety with just enough complexity to make building large programs easier. They constantly added or removed features in various language revisions in a search of balance. His main metric was compile time: anything that took too long was kicked out. The result was these languages were easy to learn, compiled fast (100kloc a sec on good machine), rarely crashed, and ran reasonable speed. They had GC's but also allowed manual management. They were objectively better than C language because people could produce correct programs more quickly with same effort put in due to design.
Modula-3, designed at DEC, was probably the best of that line given it's like a safer, simpler C++ with a subset closer to C. Here it is:
https://en.wikipedia.org/wiki/Modula-3
Used in SPIN operating system that let you live-load code into the kernel for acceleration safely due to type-safe linking on top of memory-safe interfaces. Quite a few commercial deployments. Didn't take off since C was too popular & programmers only went with C-like alternatives. Lots of vulnerabilities and crashes happened.
Another alternative was Delphi, which succeeded for a while. Way more productive and crash-resilient than using VC++. It fell away due to C/C++ popularity but Free Pascal community still maintains a variant of it. Their compiler targets a ton of platforms which was common for Pascal.
Did Dennis Ritchie have a hand in creating Go? I must have missed that.
While Ken Thompson's earlier B language no doubt had an influence on C, Dennis Ritchie is widely regarded as the creator of C, which is really rather different from B, borrowing more heavily from BCPL and Algol-68. As an early (and heavy) user of C (perhaps the earliest, besides Ritchie himself), I'm willing to concede that he had enough input on C's design to be called a co-designer or co-creator. But which other "inventor of C" played a role in the creation of Go?
I also find it hard to label Rob Pike as an expert in any kind of language design. An expert in windowing systems and concurrency, perhaps, but language design? Hell, no. Even his earlier design, Newsqueak, was more of an experiment in concurrency than in language design—and it notably was a collaboration with Luca Cardelli, an expert in ML and OOP who also worked on Modula-3, and whose influence can be seen in Modula-3's several very ML-like constructs. Articles like this one[1] by Pike only serve to reinforce my thoughts that he, though a rather smart guy otherwise, is really rather ignorant about language design and about the role of types in programming in general.
> The Wirth languages ... had GC's but also allowed manual management.
None of Wirth's languages had GC until Oberon, as far as I'm aware. And spiritual successors by other groups, like Object Pascal and Ada, never really picked up on GC, either (Ada had GC as an optional part of the standard, but was removed in the latest standard because it was so rarely provided by implementations). As far as I can tell, Modula-3 is the only other "Wirth-style" language to provide GC.
Modula-3 was indeed a great language, and I think it's a real shame that it didn't get picked up more widely. At a time, it had several really solid implementations, and the language's definition is very short while still providing a plethora of useful features for programmers. The silver lining is that it was, at least, a very influential language, despite its limited adoption.
Oberon, on the other hand, was a very spartan language that offered little in terms of features, and it exhibited that Wirth really didn't grok OOP at the time he designed it (which, if I recall correctly, is something he later admitted, though I'm having trouble finding a citation at the moment). Some of Oberon's issues were fixed in later versions of the language, but some of its issues were also "doubled down" in later versions, as well.
> Another alternative was Delphi, which succeeded for a while. Way more productive and crash-resilient than using VC++.
Delphi was indeed a real alternative for a while, and while you're right that it was more productive than VC++, that's not saying much. Later versions of Delphi grew to C++ levels of size, complexity, and hairiness, and that's reflected in Free Pascal's implementation, as well. It's something that I've lamented on more than one occasion because I remember how great it was and feel as though it could still be great with a bit of streamlining.
[1]: https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
You can go even further back into history of computing and check the Mesa/Cedar workstation at Xerox Parc.
It is replacement of C as in low memory usage, decent level of control over memory layout, no overengineered abstractions, no classes, no generics, no exceptions, fewer concepts to grasp etc. It does not need VMs and generates executables to directly run on machines.
Besides Oberon, there was Oberon-2, Active Oberon, Component Pascal, Zonnon, Modula-2+, Modula-3.
All of them with roots actually on the Xerox PARC workstation that used Mesa/Cedar.
Unlike Cardelli, his weren't ultra-practical but they did try with a commercialized one called Component Pascal. It got significant adoption for a Wirth language along with IDE. As usual, the BNF grammar is pretty small despite its expressive power. It kind of came and went far as adoption but people are still apparently posting to the forum in 2016.
Oops. You got me on my bad memory there. I misremembered Griesemer. The C language was originally just B modified with structs to try to port UNIX from assembly. Also, the limited keywords & "programmer is in control" philosophy came straight out of B. The details are in this nice Vimeo that traces its development going through papers they presented:
"An expert in windowing systems and concurrency"
Even if we drop "language" expert, my comment had him bringing in concurrency mainly. I didn't know Cardelli started with Newsqueak, though. Makes sense given stuff as good as Modula-3 rarely comes from a vacuum.
"Articles like this one[1] by Pike only serve to reinforce my thoughts that he, though a rather smart guy otherwise, is really rather ignorant about language design and about the role of types in programming in general."
Well, see, it's been given a test. The Concurrent Pascal, Ravenscar, and Eiffel SCOOP approaches to concurrency were all very effective for what they're designed for. I've been sitting on the bench on Go watching it from afar to see what Pike's method does. So far, I see a lot of people griping about concurrency errors that didn't happen in SCOOP. Meanwhile, Rust has improved on things in a new way. Your characterization of him as an experimenter more than an expert may be right.
"None of Wirth's languages had GC until Oberon, as far as I'm aware. "
All of his languages except the first two that he started with. They made a lot of languages. It's kind of a strength and weakness of theirs as doubling down on a great one might have accomplished more. Might given Cardelli did without much direct impact.
"Oberon, on the other hand, was a very spartan language that offered little in terms of features"
So was early C. It's why I bring up Modula-2 or Oberon in comparisons as nobody is writing or deploying Modula-3 or Ada on a PDP-11. I'm not a fan of Oberon except for bootstrapping better languages or for minimalist hardware. Even then I'm more PreScheme.
"Later versions of Delphi grew to C++ levels of size, complexity, and hairiness"
Snowballs rolling into avalanches. Common ill in tech although I think it's human nature or economics more than anything. It takes a cathedral model that prioritizes just right amount of complexity to avoid. I just subseted languages like embedded people do to avoid the shit. Until I had to debug a 3rd party library. (shakes head)