3 ms·

It’s not required to use a basic editor from the early 90s, no… but it can help on a big codebase. Why handicap yourself? I make patches once in a while with

It’s not required to use a basic editor from the early 90s, no… but it can help on a big codebase. Why handicap yourself? I make patches once in a while with nano/micro without issue. Maybe your functions are just too long, dunno. A lot of folks can’t survive today without a giant ide awhile you advocate not to use something downright tiny in comparison. Do you hate working with jpeg or blender files because they require software? Rather move bits with a magnetic needle and steady hand? Admit I was put off by it for an hour or so as well. One spring day in 2001? That afternoon I realized it as a masterstroke and didn’t write another line of c, perl, or java by choice for almost two decades. Two ways to delimit blocks is redundant. Either one indents already or the project is a disaster.

JohnFen 4y ago
Again, just to make sure I'm being very clear, note what I said in my original comment. I wish that I enjoyed Python. I did not say, and don't assert, that Python is bad or that nobody else should enjoy it. I just wish that I did. > A lot of folks can’t survive today without a giant ide while you advocate not to use something tiny in comparison I'm not advocating anything. I'm stating my personal preferences. But I also make sure that I don't rely on a giant IDE for any language. I use a couple of different ones at work, but I don't use one at home (even though my hobby projects are no less complex), because I've found that using IDEs encourages me to engage in poor programming practices. I am not saying that nobody should use IDEs or that they make people worse programmers. I'm speaking for myself. I want to deeply understand the languages I use. > Do you hate working with jpeg or blender files because they require software? Rather move bits with a magnetic needle and steady hand? Of course not. Those are not human-readable data collections are need a tool to make them understandable by a human. A programming language is supposed to be directly understandable by a human, though, and if you need a tool to make it so, that strikes me as a failure of the design of the language. > Two ways to delimit blocks is redundant. Either one indents already or the project is a disaster. Eh, each to his own. Yes, there is a redundancy there, but I think it's a redundancy that brings value and reduces error.
- mixmastamyk 4y ago
  Belt and suspenders, eh? Not sure how well-known but many 3D scene formats are text, especially early ones. Similar to svg conceptually, which many are familiar with. At a certain complexity, writing it by hand is no longer practical and software support approaches necessity.
  - JohnFen 4y ago
    This is very true. I do 3D printing, and am also very familiar with the fact that STL files are text files. I even edit them by hand from time to time -- but I still use software to manipulate them, for obvious reasons. It boils down to "the right tool for the job", of course, and like every developer, I choose my tools with an eye toward the goals I want to accomplish. That my goals and yours aren't 100% aligned is to be expected. We're different people. And that also means that at times, a tool that is appropriate for your use case may not be appropriate for mine. And vice versa.
sqlserver2008 4y ago
>Two ways to delimit blocks is redundant. 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: def example(): x = 5 print("Hello world") 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, function example() { let x = 5 console.log("Hello world") } 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.
- mixmastamyk 4y ago
  The first example is a syntax error, which must be fixed, and takes a second. Not a PITA, just a part of normal day to day refactoring. I see how a formatter could help you out in this specific situation. However you are trading typing of redundant characters every few seconds and readability per minute, to avoid an issue that happens once or twice a day, per week on a mature project. In other words we generally don’t significantly reorganize code nearly as much as reading, tweaking, adding features etc. Readability is definitely a strength of Python, not a weakness. A lot of this is because of reduction of required notation.
  - JohnFen 4y ago
    > Readability is definitely a strength of Python, not a weakness. I find Python to be on the lower end of average in terms of readability.
  - sqlserver2008 4y ago
    >first example is a syntax error The code runs so it's most definitely not a syntax error. May be against PEP styling rules, but it is valid Python code. >which must be fixed, and takes a second. 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. >typing of redundant characters 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. >readability per minute 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. >we generally don’t significantly reorganize code nearly as much as reading, tweaking, adding features etc. 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. https://www.youtube.com/watch?v=ubWB_ResHwM https://www.youtube.com/watch?v=ubWB_ResHwM

JohnFen 4y ago

Again, just to make sure I'm being very clear, note what I said in my original comment. I wish that I enjoyed Python. I did not say, and don't assert, that Python is bad or that nobody else should enjoy it. I just wish that I did. > A lot of folks can’t survive today without a giant ide while you advocate not to use something tiny in comparison I'm not advocating anything. I'm stating my personal preferences. But I also make sure that I don't rely on a giant IDE for any language. I use a couple of different ones at work, but I don't use one at home (even though my hobby projects are no less complex), because I've found that using IDEs encourages me to engage in poor programming practices. I am not saying that nobody should use IDEs or that they make people worse programmers. I'm speaking for myself. I want to deeply understand the languages I use. > Do you hate working with jpeg or blender files because they require software? Rather move bits with a magnetic needle and steady hand? Of course not. Those are not human-readable data collections are need a tool to make them understandable by a human. A programming language is supposed to be directly understandable by a human, though, and if you need a tool to make it so, that strikes me as a failure of the design of the language. > Two ways to delimit blocks is redundant. Either one indents already or the project is a disaster. Eh, each to his own. Yes, there is a redundancy there, but I think it's a redundancy that brings value and reduces error.

mixmastamyk 4y ago
Belt and suspenders, eh? Not sure how well-known but many 3D scene formats are text, especially early ones. Similar to svg conceptually, which many are familiar with. At a certain complexity, writing it by hand is no longer practical and software support approaches necessity.
- JohnFen 4y ago
  This is very true. I do 3D printing, and am also very familiar with the fact that STL files are text files. I even edit them by hand from time to time -- but I still use software to manipulate them, for obvious reasons. It boils down to "the right tool for the job", of course, and like every developer, I choose my tools with an eye toward the goals I want to accomplish. That my goals and yours aren't 100% aligned is to be expected. We're different people. And that also means that at times, a tool that is appropriate for your use case may not be appropriate for mine. And vice versa.

sqlserver2008 4y ago

>Two ways to delimit blocks is redundant. 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: def example(): x = 5 print("Hello world") 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, function example() { let x = 5 console.log("Hello world") } 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.

mixmastamyk 4y ago
The first example is a syntax error, which must be fixed, and takes a second. Not a PITA, just a part of normal day to day refactoring. I see how a formatter could help you out in this specific situation. However you are trading typing of redundant characters every few seconds and readability per minute, to avoid an issue that happens once or twice a day, per week on a mature project. In other words we generally don’t significantly reorganize code nearly as much as reading, tweaking, adding features etc. Readability is definitely a strength of Python, not a weakness. A lot of this is because of reduction of required notation.
- JohnFen 4y ago
  > Readability is definitely a strength of Python, not a weakness. I find Python to be on the lower end of average in terms of readability.
- sqlserver2008 4y ago
  >first example is a syntax error The code runs so it's most definitely not a syntax error. May be against PEP styling rules, but it is valid Python code. >which must be fixed, and takes a second. 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. >typing of redundant characters 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. >readability per minute 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. >we generally don’t significantly reorganize code nearly as much as reading, tweaking, adding features etc. 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. https://www.youtube.com/watch?v=ubWB_ResHwM https://www.youtube.com/watch?v=ubWB_ResHwM