It's also called baduk and weiqi, both should give good results

On the PC you still get 30-day trials for professional software or apply-for-private-use-licence-leave-an-email models.

It's not quite the same as the eternal winzip install on millions of PCs, but some people still make money that way.

Actually Sublime Text is a prime example for the WinZip model: you can use it with no limitations, but only for evaluation. You're meant to pay if you keep using it but other than a nagging popup and a note in the window title there are no restrictions.

The Reaper DAW (digital audio workstation) is another example. There's actually a lot of such 'nagware' in the audio world.

Elegant to program with. Not write a parser for.

An ambiguous syntax is not elegant to program with. Is this a variable reference? Is it a method call? I dunno!

Boring arm chair language criticism. I have programmed professionally in Ruby for 5 years and it has never been a problem. You may as well complain that the ability to import an identifier leads to confusion about which identifier from which namespace you are calling when you reference one. I have 99 gripes about Ruby, but this ain't one.

I just started working with Ruby on Rails a few weeks ago and I think the so-called "elegant" syntax is the reason why I went with it. That and the fact that Rails is a joy to work with.

Among people who like Ruby, this is seen as a feature, not a bug. It makes refactorings easier when you change something from a local variable to a method call and don't have to search for all the places you would have to add parentheses in a language like Java. Granted, you could argue that your IDE should take care of that for you with automatic refactorings, but to a Rubyist this is a crutch and also something that forces her to use a particular IDE instead of her favorite editor.

> Is this a variable reference? Is it a method call? I dunno!

Neither. It's a message sent to an object. The object decides how to respond to that message.

Caring about the implementation of the message receiver breaks information hiding. If you have to distinguish between .message and .message(), you already know more than you need to know to interact with that object.

Every language is confusing until you understand the mental model (even if you disagree with the utility of that model). If you come to Ruby thinking in Java/C++/C terms, you'll be unhappy, because the mental model is very different.

For Ruby, the book to read is The Well-Grounded Rubyist, which makes the language quite obvious.

I've been programming in Ruby for years, and the inherent ambiguity proven by the complexity of the parser isn't made better by telling me I'm not thinking right.

Variables and methods are treated differently. I can't pass arguments to a variable, I can't even write foo(), but if it were a method I could. I can't treat variables like any other object because they have different rules applied.

Actually, you're wrong. The syntactic ambiguity between local variable references and implicit self method calls us not accurately resolved by thinking of it as message sends because it's only a message sends if it is a self method call, not it is a local variable reference. This is a real syntactic ambiguity in Ruby.

The book I pointed to also discusses the concept of self. It's not really that ambiguous.

Wait - are we talking C/C++ here? where a function call, a variable declaration, an expression cast all look identical?

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.

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.

No, C/C++ have bad syntax too, imo.

Have you written Ruby often and still felt like this? I'm asking because I'm newer to Ruby and this does come up a fair bit, but I was assuming that with time the ambiguity would disappear.

I have written Ruby for many years now. The ambiguity never disappears, and the delight at how "expressive" the syntax is quickly turns to loathing. YMMV, of course.

Capitalised identifiers? Global variables? Inconsistent indentation? PM of Singapore needs a better style guide.

People with agendas making aggressive comments on barely related subjects to incite arguments which accomplish nothing are precisely what is wrong with todays online discussion.

i got it to say some pretty mean things. i dunno if you wanna fix that in case some people get offended: https://imgur.com/a/03Bgv

I would guess that would be a response to a question you asked. Nobody that's going to be offended would be asking those questions in the first place.

Ugh go back to reddit

You've got to get your earn the right to downvote by being a productive member of the community. I think it's 500 karma before you can downvote

You can't downvote stories. You can only flag them when they're inappropriate.

oh ok, i only assumed cause I can't downvote yet haha

How do you figure? Reading source code is incredible helpful for understanding how to program properly. Watching somebody step through their code and solve each problem in real time would be absolutely fantastic for understanding problems and organising solutions. Also what's wrong with code as a verb for programming?

Reading "refined" source code for projects will likely teach you significantly more about programming if that's what you wanted to learn. These videos are mostly to see someone else's process rather than the code itself.

For example, I watched the linked video. Using it as an example for Python programming would be terrible - it does not follow PEP8 (extremely long lines, no spaces around operators, excessive descriptive names ("Java style")), has many unnecessary assignments and copies, very few comments, no sphinx docstrings, etc...

Coding sounds like a monotonous task of slapping together stuff until it works without any thought about architecture, testing, or anything 'big picture'.