Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is because Ruby inherits it's approach to flow control from Smalltalk, while Python comes from a C/Algol-like heritage.

In fact, Smalltalk takes this much further, such that basically all flow control (including if-then-else) is handled as message sends (e.g. if-then is just a message sent to the Boolean object taking a block as it's argument).

The downside is the syntax can feel a tad clunky. The upside is incredibly simple and consistent language grammar, while making it trivial to create new flow control mechanisms since the language has all the tools baked in (primarily first class blocks).



Just a sidenote that for performance reasons, control flow messages are actually optimized in most implementations, even though they also look like regular messages.


Also, Perl's history adds an additional layer of flavor. Ruby started as somewhat "Perl 2.0" where beauty and flexibility > all things and Python started as "anti-Perl" one way to rule them all(tm) where fast and standard > perfection of beauty.


[flagged]


Ah, a brilliant idea, design all languages so people who only know C can make small changes to existing Ruby code without getting confused. Definitely don't want to enable different abstractions or models of computation. Are these core principles in codebases you mentioned mostly "how to write stuff using C paradigms"? After all, "the Real Programmer can write FORTRAN in any language"


Why are so many people interacting with this at all instead of downvoting to oblivion? What kind of post comes from an anal_reactor?


It is flagged, and it's impossible to downvote it. I wonder if its position is determined by its (frozen?) rating, or by its children rating?


I think you’re mistaking C-style syntax for what modern C languages have adopted and become.

How many C style context even really exist today? The block separation by single characters is ok. Using (), [] and {} to separate things makes things easier on the compiler, but it’s probably down to personal preference whether you like that syntax or not. I certainly vastly prefer the more simplistic approach where you don’t have to wrap everything in brackets. Like a loop… why does it really have to be inside a () denotion? Similarly I prefer Pythons indent to {}’s. Which can technically make your code harder to read, but if your Python code is hard to read it’s likely bad. Not always, but most of the time. I guess {} is better than BEGIN END, but maybe not in terms of readability.

The end of line character, ; is also sort of unnecessary for the most parts. Again it’s mostly a relic which helps the compiler, and some people like it while others don’t.

Modern loops look nothing like they did in C. Neither does variables or properties.

The use of English for a lot of things, or the use of western character sets, is also sort of bad in the modern world. Which is part of the reason behind the huge popularity of Go in Asia. Not that it’s so bad as it’s just how it is and everyone has adopted.

Anyway. Modern C style syntax like you’ll finds in C# or Java is rather cumbersome in my opinion. Rust sort of falls into this category but at least with Rust it’s very easy to define ownership of your stored data as you pass it around in your code. But almost all of it is exactly that… modern. Almost none of it is from C and a lot of it would not have existed without languages like Ruby.

You also have to keep in mind that Ruby predates the modern C syntax. As others have mentioned it’s been influential on the modern C syntax, but it was also made in a world where they modern syntax simply didn’t exist.


> Similarly I prefer Pythons indent to {}’s. Which can technically make your code harder to read

I started out having a similar opinion to you, and have completely flipped.

1. There's very little advantage to the whitespace option apart from aesthetics. Depending on your coding style, you gain 0-2 vertical lines.

2. Meaningful whitespace makes it more difficult to write code that writes code. Is it possible to manage the indents properly? Yes. Is it more difficult? Yes.

3. IMO, meaningful whitespace is what gimped lambda in Python (as compared to Ruby, where it's extremely powerful and used frequently). I'd rather have lambda + map/filter/reduce than comprehensions. Comprehensions are nicer when the code is simple and worse when it's complex.

I'm curious why you prefer Python's meaningful whitespace over explicit delimiters?


I don’t mind the {}s too much, maybe the primary reason I dislike them is actually more to do with the fact that I’m Danish and I’ll need to press option+shift+7 to make a { on my Mac… or similarly annoying combinations depending on the machine/OS. I think I once had a windows laptop where I needed to press FN + something.

Anyway, when your language adds extra letters to the keyboard ÆØÅ in my case then they have to take the space from other things and since {}’s are rarely used they were one of the “obvious” choices.

On the flip side I don’t think the curley brackets add much to the readability.


I'm European, I lived in Denmark for pretty long, and I found it a great quality-of-life improvement to switch to ANSI keyboards, or at least to an ANSI layout.

By defining a compose key, you can type á, é, å, ø, ß, §, plus many other symbols, with relative ease, while still having all keys in the right place to program.

For instance, using Emacs with any ISO layout is much harder.


> I guess {} is better than BEGIN END, but maybe not in terms of readability.

AFAIK, {} lacks initialization and finalization blocks, like a sql statement without transaction wrapper. Example is awk:

https://www.gnu.org/software/gawk/manual/html_node/Using-BEG...


I don’t think it’s a fundamental property of single-char open/close delimiters. Like, try-with-resources, or scala/kotlin/groovy/etc-like blocks do let you specify specific initializers xor finalizers, but one might as well create a language with ` { } with (FINALIZE)` syntax.


> Which is part of the reason behind the huge popularity of Go in Asia

I don’t get your point - what does Go do uniquely here?


Smalltalk and C both came out in 1972 and it really isn't clear to me that C's crazy for-loop design -- one that actually isn't used by many programming languages -- is somehow better than the one used by Algol, so I am struggling to find even a single thing you said which is making any sense to me :(.


I have programmed C since the 1980's, and I still avoid C for loops when writing C because they're hideous.


It really isn't, as I have lost count of how many get clever uses out of that loop.


What exactly do you think the purpose of having different programming languages is?

The popularity and usefulness of Ruby’s block-based control flow, which you seem to take issue with, is almost certainly largely responsible for the adoption of lambdas in… basically every modern language, not to mention being backported to existing languages like C# and Java.

Frankly your hot take is terrible. C was an amazing language, but there are an infinite number of practical and effective ways to improve upon it. Particularly having just admitted that you’ve never actually used the syntax in question it’s honestly astonishing that your first instinct is to jump straight to posting about how much better the C approach is.

Hell, you’d be hard-pressed these days to find a modern language that uses C-style `for` loops. They might say `for` on the tin, but they’re much closer to Ruby-style enumerators than they are to C-style setup-condition-increment control flow. With, of course, the caveat that that’s all they ever can be since they’re keyword syntax rather than just a method.

What a sad world this would be if everything interesting in programming was discovered by K&R in the 1970s.


And mind you, C's for loop was an innovation: languages before it (and even after) used "FOR var := start_expr [DOWN]TO end_expr [BY constant] DO ... OD" or variations thereof, with constant increment which allowed for much better codegen in a single-pass compiler: it's trivial to remember the increment constant and then issue it later, at the loop's end while remembering a whole expression... not so much.


> I feel like each new language absolutely needs to reinvent existing standards that have proven effective, just so that it feels unique. I don't have any experience with Ruby in particular, but every time a tool does some basic thing like a for loop "in a new, innovative way"

You're talking about a 25 year old decision.


You don't seem to have any knowledge about the history of programming languages. There have been several lines of PL syntaxes since the 50s.

You are crazy if you think that a C style for loop is good designed. It's way to powerful but terse and obtuse to do correctly beyond the simplest application.

C style syntax as a whole is also nothing special if you mean semicolons and braces.

If you include stupid design decisions like braceless blocks in "C style syntax" I wouldn't even know what to think of that opinion.


> You are crazy if you think that a C style for loop is good designed. It's way to powerful but terse and obtuse to do correctly beyond the simplest application.

I wouldn't go as far as calling someone crazy for thinking C-style for loops are good.

The expressions in a C-style for loop is a 1:1 mapping to sigma notation, so is intuitively understood by anyone who has done high school mathematics, even if they didn't realise there's a 1:1 mapping.

Maybe you'd like something different, but it's been a staple of mathematicians for centuries now, so it's kinda hard to complain that it isn't readable.

Easy to make mistakes? Sure!

Hard to read and/or write? Only if you have never seen sigma notation before.


> so it's kinda hard to complain that it isn't readable

Hum, no, it's very easy.

Almost all of mathematics was created without any care for readability. Mathematicians working with structures that take more than a couple of lines is a very new phenomenon, and the culture of the area didn't even fully adapt yet.


Sure, but .. we aren't really talking advanced mathematics, here, right? We're looking at an ascii representation of high school maths.


But it's not a 1-by-1 mapping. The FOR-loops of FORTRAN, ALGOL, and Pascal have 1-to-1 mapping to the sigma notation because the increment part is either a) omitted entirely and forced to be +1; b) allowed to be some other integer constant, but definitely not an integer expression.

    FOR i := 1 TO 10 DO ...

    FOR i := 20 STEP -2 UNTIL 0 DO ...

    for (i=0, j=10; s[i]; t[j--] = s[i++]);  // huh?


> for (i=0, j=10; s[i]; t[j--] = s[i++]); // huh?

If you need to mischaracterise and mislead with your examples, you probably don't have a a good argument.

The equivalent C code to your other examples are:

     for (i = 1; i <= 10; i++) { ... }
     for (i = 20; i >= 0; i -= 2) { ... }
Your argument makes less sense when you write the counter-example out correctly, see?


My argument is that there is no 1:1 mapping: for instance, "for (i=0, j=10; s[i]; t[j--] = s[i++])" has no direct correspondence with sigma notation. Does it? I don't believe so. This code also has no direct correspondence to Pascal's FOR or FORTRAN's DO, or ALGOL's FOR-STEP loops. Hence, C's for loop has no 1:1 mapping to sigma notation.

Of course, I can be mistaken and either there actually is a 1:1 mapping, or you meant by "1:1 mapping" something quite different from what I mean.


> My argument is that there is no 1:1 mapping: for instance, "for (i=0, j=10; s[i]; t[j--] = s[i++])" has no direct correspondence with sigma notation.

And? I didn't claim that all the multi-expression, body-in-the-conditional possibilities are a 1:1 mapping with sigma notation, did I?

Why do you think this is more representative of for loops in C than simpler examples I gave?

> or you meant by "1:1 mapping" something quite different from what I mean.

Well, yes. I meant that the 1:1 mapping is from sigma notation to C, not the other way around, because sigma notation was not invented after the C language.

Maybe I shouldn't have said 1:1 mapping; it's much clearer to say "The `for` loop in C is just a way to write sigma notation in programming languages".


I read the term “crazy” this way:

“We are having the same ridiculous heated arguments about syntax that programmers have over and over and over so wink I’ll use hyperbolic rhetoric to insult people and wink you shouldn’t take my words to mean very much.”

I find it tiresome. It’s excusable by youth and something that people should grow out of but some never do.


C syntax for say list iteration would be much more cumbersome than "for a in mylist", so there's benefit in diverging from C sometimes.

Funnily, regardless of deeply different implementations, for loops look almost the same in Python and Ruby.


> The upside is incredibly simple and consistent language grammar

I hope you don't mean Ruby (I haven't investigated Smalltalk grammar). Ruby grammar is atrocious due to string interpolation stuff. Nothing to do with handling loops or conditionals, but still... Ruby is not at all an example of a language with good grammar.

Unfortunately, it's surprisingly rare for popular languages to have good grammar. If you look at it from up close, there are lots and lots of really bad decisions in virtually any language in common use today. I think, this is just not a high-priority concern for most users, but still...


Could you perhaps write a blog post on what you consider bad decisions in a PL grammar? That'd be interesting to read, esp. for all the aspiring PL developers/makers here.


Well... I don't even have a blog.

But, I believe, size is a very good heuristic (i.e. the number of rules, the number of variables in rules, the number of branches in rules).

Another valuable metric to optimize is entropy. I.e. rules that look very similar aren't very good rules.

Expressiveness: how long does the program have to be to capture a useful concept.

Things like these obviously need a lot of counting and coming up with some kinds of constants, hopefully justified by experiments... That's a lot of work that will also require a lot of resources to do. But this is not to say that it is unknowable or that a programmer cannot develop an intuition which allows for rough assessment of language grammar.

So, I'm sorry, I don't have a good answer... I only offer one based on my intuition and limited experience of dealing with various language grammars.





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: