4 ms·

I think it's a pure joy to read the ruby source. Allthough ruby is not fast, it's got some of the simplest most elegant frameworks out there. Sinatra is not muc

I think it's a pure joy to read the ruby source. Allthough ruby is not fast, it's got some of the simplest most elegant frameworks out there. Sinatra is not much more than a router config file with some logic. Sequel is the simplest database orm and migration tool around. And slim makes very readable templates. All frameworks perfect for the first minimum viable product. If this site takes off, I would perhaps pay someone to rewrite some bottlenecks of it in java.

csense 13y ago
> it's a pure joy to read the ruby source If you like it so much, here's a copy-paste from the project for your edification [1]: def new_tags=(tags_string) tags_string.gsub! /[^a-zA-Z0-9, ]/, '' tags = tags_string.split ',' tags.collect! {|c| (c.match(/^\w+\s\w+/) || c.match(/^\w+/)).to_s } @new_tag_strings = tags end I don't mean to pick on this project in particular. In fact, this project as a whole is quite possibly the cleanest Ruby code I've ever seen. That being said, Ruby's syntax makes me want to gouge my eyes out. There's equal signs, unquoted regular expressions, exclamation points, absolute value bars, and at signs all over the above code. You can't even sort-of follow what this code is doing without searching through the manual every third character. Ruby syntax is worse than C++ and almost as bad as Perl. Someone tried to explain Ruby syntax to me last week [2], and I'm not sure if I understood it more, or less, as a result, because my conclusion was that Ruby's syntax is so bad, the language shouldn't even be able to exist! I.e., there are a large number of syntactical ambiguities, so writing a parser for it should be completely impossible! [1] https://github.com/kyledrake/neocities-web/blob/933c3549264ee809c0e09f0af73cdd2f2236a63d/models/site.rb#L53 https://github.com/kyledrake/neocities-web/blob/933c3549264e... [2] https://news.ycombinator.com/item?id=5872899 https://news.ycombinator.com/item?id=5872899
- dragonwriter 13y ago
  > equal signs I fail to see how using equal signs for assignment (or for defining assignment methods) is a problem with syntax, rather than an enhancement to clarity. > unquoted regular expressions What's wrong with that? Regexes are a different type than strings. Why should they look like strings? > exclamation points ...again, so, what? > absolute value bars vertical bars used to set off block argument lists aren't absolute value bars. (Neither are vertical bars used for logical-or.) > at signs Again, so? > You can't even sort-of follow what this code is doing without searching through the manual every third character. Yes, I can, and not just "sort-of follow" it. > Ruby syntax is worse than C++ and almost as bad as Perl. There's no accounting for taste, I suppose. > there are a large number of syntactical ambiguities, so writing a parser for it should be completely impossible As Ruby does exist, and is parsed, this is clearly not the case. That said, ruby's syntax is not optimized for machine parsing, its designed to be ruby-developer-friendly rather than ruby-parser-developer-friendly. If you want something optimized for the developer of the language's parser, look to Lisp.
- vinceguidry 13y ago
  What's difficult about that function? It's terse, but very understandable. Oh, the inability to parse Ruby shouldn't be held against it. It has (at the least) a context-sensitive grammar. So do lots of languages, including HTML and perl. Not being able to parse it doesn't really mean what you think it means. It just means that in order to figure out what it does programmatically, you have to evaluate it. Its unparseability makes certain things impossible, like writing a perfect syntax highlighter. Also makes building certain tools you'd normally see in an IDE difficult.
- fghfg 13y ago
  // Parse tags string. // Example: // "tag1, tag2" => {"tag1", "tag2"} // "tag1, very long tag" => {"tag1", "very long"} string[] NewTags(string tags_string) { //Allow only letters, numbers and spaces in tag. tags_string = new string(tags_string.Where(c => char.IsLetter(c) || char.IsNumber(c) || c == ' ' || c == ',').ToArray()); //Separate multiple tags with commas. string[] tags = tags_string.Split(',').Select(s => s.Trim()).ToArray(); //Two word per tag maximum (extra words in a tag will be removed). for (int i = 0; i < tags.Length; i++) { List<string> validWords = new List<string>(); string[] wordsInTag = tags[i].Split(' '); if (wordsInTag.Length > 2) { tags[i] = wordsInTag[0] + " " + wordsInTag[1]; } } return tags; }
- eksith 13y ago
  This is on the same league with arguing against Esperanto in favor of Interlingua. You'll never get anywhere with people with the "so what?" or "no it's just you" mindset as in their capacity, they're not capable of (or unwilling?) to entertain perspectives beyond their own. That said, I do really enjoy reading this code. It's indeed very, very clean!
- Jeremysr 13y ago
  I don't know if this works for everyone, (and I hate to appeal to magic), but I'm pretty sure it was http://mislav.uniqpath.com/poignant-guide/book/chapter-3.html http://mislav.uniqpath.com/poignant-guide/book/chapter-3.htm... that gave me a visceral understanding of Ruby's syntax. For example, the slashes surrounding the Regexp are like pins that you stick the Regexp onto the paper with, and it lights up if the pattern matches. The at signs stand for "ATtribute". Exclamation/question marks have meanings analogous to their natural language counterparts. And the vertical bars form a little chute that the block variables slide down into the block through. It's really fun.
- pak 13y ago
  Ruby's syntax is beautiful once you've realized two things: 1. How blocks work, and how their minimalist syntax is beautiful. You see absolute value bars but believe me, getting used to that barebones function syntax is a gift. (No other programming language that I know of has an absolute value operator with vertical bars so it is not as hard as you think.) 2. Every time you see a dot, do NOT think attribute access. Think message sending a la Smalltalk. Suddenly then, things like the tags.collect! line become pretty for encapsulating a callback on one line unlike the ugly function() {} crud of JavaScript, and things like defining a newtags= method become sensible, because everything including traditional attribute getting and setting reduces to message passing.
  - whimsy 13y ago
    > Every time you see a dot, do NOT think attribute access. Think message sending a la Smalltalk. Huh. You just rekindled my interest in learning Ruby. Learning Smalltalk was pretty mind-expanding.
- whimsy 13y ago
  > there are a large number of syntactical ambiguities, so writing a parser for it should be completely impossible Keep in mind that while your protest does sound intuitive - e.g. that Ruby can be syntactically ambiguous, ergo it is unparseable, it turns out that that doesn't stop us from writing a parser. We can parse most things even if we can't parse the "general case." When we DO encounter something unparseable, the compiler can a) guess or b) fail, hopefully with a message that will help us investigate and rectify the failure. You point out that Perl's syntax may be worse than Ruby's, and I assume that implies that it is more syntactically ambiguous, ergo, writing a parser should also be impossible for Perl. It turns out that Perl is provably unparseable in the general case - in fact, it's been done rather rigorously: http://www.jeffreykegler.com/Home/perl-and-undecidability http://www.jeffreykegler.com/Home/perl-and-undecidability Regardless of Perl's general unparseability, we have compilers for Perl and even large projects manage to compile to what appear to be functional executables. The same is true for Ruby. I wrote this comment mostly a reminder that while something may appear to be insoluble, we may be able to solve for sufficient cases that we don't care about the rest, particularly if we have an oracle to fix the number of cases that we can't solve. (In this case, the oracle is the developer.)

csense 13y ago

> it's a pure joy to read the ruby source If you like it so much, here's a copy-paste from the project for your edification [1]: def new_tags=(tags_string) tags_string.gsub! /[^a-zA-Z0-9, ]/, '' tags = tags_string.split ',' tags.collect! {|c| (c.match(/^\w+\s\w+/) || c.match(/^\w+/)).to_s } @new_tag_strings = tags end I don't mean to pick on this project in particular. In fact, this project as a whole is quite possibly the cleanest Ruby code I've ever seen. That being said, Ruby's syntax makes me want to gouge my eyes out. There's equal signs, unquoted regular expressions, exclamation points, absolute value bars, and at signs all over the above code. You can't even sort-of follow what this code is doing without searching through the manual every third character. Ruby syntax is worse than C++ and almost as bad as Perl. Someone tried to explain Ruby syntax to me last week [2], and I'm not sure if I understood it more, or less, as a result, because my conclusion was that Ruby's syntax is so bad, the language shouldn't even be able to exist! I.e., there are a large number of syntactical ambiguities, so writing a parser for it should be completely impossible! [1] https://github.com/kyledrake/neocities-web/blob/933c3549264ee809c0e09f0af73cdd2f2236a63d/models/site.rb#L53 https://github.com/kyledrake/neocities-web/blob/933c3549264e... [2] https://news.ycombinator.com/item?id=5872899 https://news.ycombinator.com/item?id=5872899

dragonwriter 13y ago
> equal signs I fail to see how using equal signs for assignment (or for defining assignment methods) is a problem with syntax, rather than an enhancement to clarity. > unquoted regular expressions What's wrong with that? Regexes are a different type than strings. Why should they look like strings? > exclamation points ...again, so, what? > absolute value bars vertical bars used to set off block argument lists aren't absolute value bars. (Neither are vertical bars used for logical-or.) > at signs Again, so? > You can't even sort-of follow what this code is doing without searching through the manual every third character. Yes, I can, and not just "sort-of follow" it. > Ruby syntax is worse than C++ and almost as bad as Perl. There's no accounting for taste, I suppose. > there are a large number of syntactical ambiguities, so writing a parser for it should be completely impossible As Ruby does exist, and is parsed, this is clearly not the case. That said, ruby's syntax is not optimized for machine parsing, its designed to be ruby-developer-friendly rather than ruby-parser-developer-friendly. If you want something optimized for the developer of the language's parser, look to Lisp.
vinceguidry 13y ago
What's difficult about that function? It's terse, but very understandable. Oh, the inability to parse Ruby shouldn't be held against it. It has (at the least) a context-sensitive grammar. So do lots of languages, including HTML and perl. Not being able to parse it doesn't really mean what you think it means. It just means that in order to figure out what it does programmatically, you have to evaluate it. Its unparseability makes certain things impossible, like writing a perfect syntax highlighter. Also makes building certain tools you'd normally see in an IDE difficult.
fghfg 13y ago
// Parse tags string. // Example: // "tag1, tag2" => {"tag1", "tag2"} // "tag1, very long tag" => {"tag1", "very long"} string[] NewTags(string tags_string) { //Allow only letters, numbers and spaces in tag. tags_string = new string(tags_string.Where(c => char.IsLetter(c) || char.IsNumber(c) || c == ' ' || c == ',').ToArray()); //Separate multiple tags with commas. string[] tags = tags_string.Split(',').Select(s => s.Trim()).ToArray(); //Two word per tag maximum (extra words in a tag will be removed). for (int i = 0; i < tags.Length; i++) { List<string> validWords = new List<string>(); string[] wordsInTag = tags[i].Split(' '); if (wordsInTag.Length > 2) { tags[i] = wordsInTag[0] + " " + wordsInTag[1]; } } return tags; }
eksith 13y ago
This is on the same league with arguing against Esperanto in favor of Interlingua. You'll never get anywhere with people with the "so what?" or "no it's just you" mindset as in their capacity, they're not capable of (or unwilling?) to entertain perspectives beyond their own. That said, I do really enjoy reading this code. It's indeed very, very clean!
Jeremysr 13y ago
I don't know if this works for everyone, (and I hate to appeal to magic), but I'm pretty sure it was http://mislav.uniqpath.com/poignant-guide/book/chapter-3.html http://mislav.uniqpath.com/poignant-guide/book/chapter-3.htm... that gave me a visceral understanding of Ruby's syntax. For example, the slashes surrounding the Regexp are like pins that you stick the Regexp onto the paper with, and it lights up if the pattern matches. The at signs stand for "ATtribute". Exclamation/question marks have meanings analogous to their natural language counterparts. And the vertical bars form a little chute that the block variables slide down into the block through. It's really fun.
pak 13y ago
Ruby's syntax is beautiful once you've realized two things: 1. How blocks work, and how their minimalist syntax is beautiful. You see absolute value bars but believe me, getting used to that barebones function syntax is a gift. (No other programming language that I know of has an absolute value operator with vertical bars so it is not as hard as you think.) 2. Every time you see a dot, do NOT think attribute access. Think message sending a la Smalltalk. Suddenly then, things like the tags.collect! line become pretty for encapsulating a callback on one line unlike the ugly function() {} crud of JavaScript, and things like defining a newtags= method become sensible, because everything including traditional attribute getting and setting reduces to message passing.
- whimsy 13y ago
  > Every time you see a dot, do NOT think attribute access. Think message sending a la Smalltalk. Huh. You just rekindled my interest in learning Ruby. Learning Smalltalk was pretty mind-expanding.
whimsy 13y ago
> there are a large number of syntactical ambiguities, so writing a parser for it should be completely impossible Keep in mind that while your protest does sound intuitive - e.g. that Ruby can be syntactically ambiguous, ergo it is unparseable, it turns out that that doesn't stop us from writing a parser. We can parse most things even if we can't parse the "general case." When we DO encounter something unparseable, the compiler can a) guess or b) fail, hopefully with a message that will help us investigate and rectify the failure. You point out that Perl's syntax may be worse than Ruby's, and I assume that implies that it is more syntactically ambiguous, ergo, writing a parser should also be impossible for Perl. It turns out that Perl is provably unparseable in the general case - in fact, it's been done rather rigorously: http://www.jeffreykegler.com/Home/perl-and-undecidability http://www.jeffreykegler.com/Home/perl-and-undecidability Regardless of Perl's general unparseability, we have compilers for Perl and even large projects manage to compile to what appear to be functional executables. The same is true for Ruby. I wrote this comment mostly a reminder that while something may appear to be insoluble, we may be able to solve for sufficient cases that we don't care about the rest, particularly if we have an oracle to fix the number of cases that we can't solve. (In this case, the oracle is the developer.)