<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: sqlserver2008</title><link>https://news.ycombinator.com/user?id=sqlserver2008</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Mon, 03 Aug 2026 03:48:25 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=sqlserver2008" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by sqlserver2008 in "F*: A general-purpose proof-oriented programming language"]]></title><description><![CDATA[
<p>Sure but even with no code indentation at all, an auto-formatter can easily indent everything for you because of the braces. If you have poorly indented code in a language like Python, you're on the hook for indenting everything yourself. And as a bonus, the code won't even run until you do.</p>
]]></description><pubDate>Sun, 02 Aug 2026 23:36:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=49149498</link><dc:creator>sqlserver2008</dc:creator><comments>https://news.ycombinator.com/item?id=49149498</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49149498</guid></item><item><title><![CDATA[New comment by sqlserver2008 in "Why Python keeps growing, explained"]]></title><description><![CDATA[
<p>>first example is a syntax error<p>The code runs so it's most definitely not a syntax error. May be against PEP styling rules, but it is valid Python code.<p>>which must be fixed, and takes a second.<p>And that was my earlier point. The responsibility to get the code in a state where it is formatted AND runnable falls entirely on you, as this work cannot be entirely delegated to software when the syntax uses significant indentation. And the fixing of the code would require you to reanalyze the code's semantics before you would even know what the appropriate fix is. Of course it would only take a second for a trivial example like the one I used, but real Python codebases aren't going to be trivial.<p>>typing of redundant characters<p>It actually doesn't require any additional typing as compared to Python. In modern editors the closing brace is automatically added when you type the opening brace. So you simply type the opening brace and hit enter, just as you would type the colon and hit enter in Python. Even the space between the closing parenthesis and opening brace in the function header is added automatically by formatters.<p>>readability per minute<p>Seems pretty subjective but I don't think there's a significant difference in readability between Python and braced languages, or even between Python and languages that use block delimiters other than braces, like Ruby. A lot of readability comes down to personal familiarity with a language.<p>>we generally don’t significantly reorganize code nearly as much as reading, tweaking, adding features etc.<p>Totally agree, and I think this is one of the big problems of software development. People generally don't want to make big reorganizational changes to code and instead prefer to change the code only through additions. As a result, legacy projects tend to accrete layers of cruft over time whether it is necessary or not. I'm not a Jonathan Blow fanboy by any means, but I recently saw this clip which I think makes a good point. 
<a href="https://www.youtube.com/watch?v=ubWB_ResHwM">https://www.youtube.com/watch?v=ubWB_ResHwM</a></p>
]]></description><pubDate>Sun, 05 Mar 2023 10:19:14 +0000</pubDate><link>https://news.ycombinator.com/item?id=35028331</link><dc:creator>sqlserver2008</dc:creator><comments>https://news.ycombinator.com/item?id=35028331</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=35028331</guid></item><item><title><![CDATA[New comment by sqlserver2008 in "Why Python keeps growing, explained"]]></title><description><![CDATA[
<p>>Two ways to delimit blocks is redundant.<p>It isn't redundant though because without delimiting symbols for a code block you lose the ability to have your code autoformatted in certain situations. Here's a trivial example to illustrate the point:<p><pre><code>    def example():
        x = 5
    print("Hello world")
</code></pre>
What's the mistake here? Depending on whether the print is part of the function, it should either be indented or have a newline before it. The point is you (and any formatting tool) can't know what the horizontal alignment of this code should be just by examining the vertical line order. You can only determine this by knowing (or reanalyzing) the semantics of the code. During a refactor where you're moving around lots of code, this can be a significant PITA. However, in the JS example,<p><pre><code>    function example() {
        let x = 5
    console.log("Hello world")
    }
</code></pre>
it's unambiguous what the mistake is because you can determine the correct formatting entirely from the line order, without having to know anything about the code's semantics.</p>
]]></description><pubDate>Sat, 04 Mar 2023 00:44:54 +0000</pubDate><link>https://news.ycombinator.com/item?id=35016961</link><dc:creator>sqlserver2008</dc:creator><comments>https://news.ycombinator.com/item?id=35016961</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=35016961</guid></item><item><title><![CDATA[New comment by sqlserver2008 in "Ask HN: What's your secret diet tip you can share?"]]></title><description><![CDATA[
<p>Was it this review? <a href="https://slatestarcodex.com/2017/04/25/book-review-the-hungry-brain/" rel="nofollow">https://slatestarcodex.com/2017/04/25/book-review-the-hungry...</a><p>This also lines up with my anecdotal experience, and the best boring food I've ever found were potatoes. I used to avoid them because of the carb content, but they always seem to give me good energy while also being 'filling'. If you look up various satiety indices, potatoes always seem to be at the top, even higher than most meats.<p>With regular consumption, I've found simple, unprocessed potatoes to become very boring even while being very satiating. It's strange, like I have this strong psychological urge to consume something with more exciting flavor to it (i.e. processed food) while being completely satisfied physically. Regardless, I think  it's a food that can really help people who struggle to lose weight.</p>
]]></description><pubDate>Mon, 26 Dec 2022 07:08:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=34135458</link><dc:creator>sqlserver2008</dc:creator><comments>https://news.ycombinator.com/item?id=34135458</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=34135458</guid></item><item><title><![CDATA[New comment by sqlserver2008 in "OCaml 5.0 Multicore is out"]]></title><description><![CDATA[
<p>> OCaml isn't indentation sensitive, so doesn't suffer from this<p>True, I was just making the point that the lightweight syntax of indentation-sensitive languages like Python can be problematic. I don't know how OCaml is able to achieve this style of syntax without the use of significant indentation, but it is impressive.</p>
]]></description><pubDate>Sat, 17 Dec 2022 09:23:14 +0000</pubDate><link>https://news.ycombinator.com/item?id=34026242</link><dc:creator>sqlserver2008</dc:creator><comments>https://news.ycombinator.com/item?id=34026242</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=34026242</guid></item><item><title><![CDATA[New comment by sqlserver2008 in "OCaml 5.0 Multicore is out"]]></title><description><![CDATA[
<p>Indentation-sensitive syntax is totally obsolete in a world with autoformatters. In addition, with this kind of syntax you also lose the ability to have your code autoformatted in certain situations. Here's a trivial example to illustrate the point:<p><pre><code>    def example():
        x = 5
    print("Hello world")
</code></pre>
What's the mistake here? Depending on whether the print is part of the function, it should either be indented or have a newline before it. The point is you (and any formatting tool) can't know what the horizontal alignment of this code should be just by examining the vertical line order. You can only determine this by knowing (or reanalyzing) the semantics of the code. During a refactor where you're moving around lots of code, this can be a significant PITA. However, in the JS example,<p><pre><code>    function example() {
        let x = 5
    console.log("Hello world")
    }
</code></pre>
it's unambiguous what the mistake is because you can determine the correct formatting entirely from the line order, without having to know anything about the code's semantics.</p>
]]></description><pubDate>Sat, 17 Dec 2022 05:47:58 +0000</pubDate><link>https://news.ycombinator.com/item?id=34025180</link><dc:creator>sqlserver2008</dc:creator><comments>https://news.ycombinator.com/item?id=34025180</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=34025180</guid></item></channel></rss>