Nice post as usual! I'm secretly waiting every day for your posts, because they are really fun and interesting :-) (well, I guess it's not a secret anymore)
Regarding the lack of Pathname, Crystal has something similar, it's called Path: crystal-lang.org/api/1.3.2/Path.html . We thought Path was a better, shorter name.
Then Crystal doesn't have __dir__, but it has __DIR__ that works exactly like the one in Ruby. We though it was a bit strange that Ruby had __FILE__ and then __dir__ so we made them both look the same. And they are both resolved at compile-time.
Regarding symbols vs. strings, I totally get you. We added symbols to Crystal in the very beginning just because Ruby has them. Eventually we introduced enums, and symbols had less reason to exist. Now I really wish to remove symbols from the language, and I hope we do that for 2.0. So my advice is to never use symbols.
Regarding asserting that something doesn't compile, there's no current way to do it. Well, you could write a test that runs the compiler binary with an output and expect it to give an error. I don't think there's any language that gives you the ability to check that something doesn't compile (I might be wrong!), but we do have a discussion around that (it started being related to responds_to?): github.com/crystal-lang/crystal/is... . I personally think having something like compiles? or compile_error would be great to have, especially because in Crystal you can produce hand-crafted compile errors.
Pathname can be used as OO interface for filesystem objects, like Pathname("something").mkdir_p or Pathname("something").readlines. Path doesn't seem to have any of that.
expect{ ... }.to_not compile might be a bit much, but is there at least some way to do expect(intVar).to_not respond_to(:+, boolVar)? That's the only case I care about here, but these are fairly important checks as they prevent segfaults.
So Crystal's philosophy, unlike Ruby, is to avoid having too many ways to do the same thing. Crystal has Dir.mkdir_p that takes a String or Path, and that's the only way to do it. Having that in Path would be redundant, with all the downsides that brings (subjective!): discussions between developers around which way is better, or which one should be used here or there; then a larger binary because it's just redundant generated code; it might be slightly inefficient if one calls the other and the optimizer decides not to inline it, etc. That said, in this particular case it might not be that bad, so feel free to open a discussion around that in our forums :-)
And right now there's no way to do responds_to?(:method, args), you can only check if something responds to a method. But this might come later, even in a 1.x version!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice post as usual! I'm secretly waiting every day for your posts, because they are really fun and interesting :-) (well, I guess it's not a secret anymore)
Regarding the lack of Pathname, Crystal has something similar, it's called Path: crystal-lang.org/api/1.3.2/Path.html . We thought
Pathwas a better, shorter name.Then Crystal doesn't have
__dir__, but it has__DIR__that works exactly like the one in Ruby. We though it was a bit strange that Ruby had__FILE__and then__dir__so we made them both look the same. And they are both resolved at compile-time.Regarding symbols vs. strings, I totally get you. We added symbols to Crystal in the very beginning just because Ruby has them. Eventually we introduced enums, and symbols had less reason to exist. Now I really wish to remove symbols from the language, and I hope we do that for 2.0. So my advice is to never use symbols.
Regarding asserting that something doesn't compile, there's no current way to do it. Well, you could write a test that runs the compiler binary with an output and expect it to give an error. I don't think there's any language that gives you the ability to check that something doesn't compile (I might be wrong!), but we do have a discussion around that (it started being related to
responds_to?): github.com/crystal-lang/crystal/is... . I personally think having something likecompiles?orcompile_errorwould be great to have, especially because in Crystal you can produce hand-crafted compile errors.Oh,
__DIR__makes perfect sense.Pathnamecan be used as OO interface for filesystem objects, likePathname("something").mkdir_porPathname("something").readlines.Pathdoesn't seem to have any of that.expect{ ... }.to_not compilemight be a bit much, but is there at least some way to doexpect(intVar).to_not respond_to(:+, boolVar)? That's the only case I care about here, but these are fairly important checks as they prevent segfaults.So Crystal's philosophy, unlike Ruby, is to avoid having too many ways to do the same thing. Crystal has
Dir.mkdir_pthat takes aStringorPath, and that's the only way to do it. Having that inPathwould be redundant, with all the downsides that brings (subjective!): discussions between developers around which way is better, or which one should be used here or there; then a larger binary because it's just redundant generated code; it might be slightly inefficient if one calls the other and the optimizer decides not to inline it, etc. That said, in this particular case it might not be that bad, so feel free to open a discussion around that in our forums :-)And right now there's no way to do
responds_to?(:method, args), you can only check if something responds to a method. But this might come later, even in a 1.x version!