45 ms·
Python with Braces
- scld 2y ago[flagged]
- Aeium 2y ago[flagged]
- teddyh 2y ago>>> from __future__ import braces File "<stdin>", line 1 SyntaxError: not a chance >>>
- clasxx 2y ago[flagged]
- water-your-self 2y agoWhat is instagram?
- kibwen 2y agoJoke's on Python, it already supports braces: def foo(): #{ if True: #{ print("The future is now, old man") #} #}
- gedy 2y agoHa cool, you could probably make a font with ligatures to hide the # too
- kazinator 2y agoMore than that, you could write a tool which checks the consistency of your indentation against your #{ and #}. This has advantages over using a generation tool that has to strip away braces to produce valid Python.
- giancarlostoro 2y agoI was going to complain that they need to be on separate lines, and then I realized it would work that way, though PEP-8 and Pycharm might complain.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- mort96 2y agoHonestly, this looks more readable than Python. Noticing whether something is 3 or 4 levels less indented than something else is really really hard. Noticing whether there are 3 or 4 braces is easy.
- jjallen 2y agoWhy not use your editor to do this? I would never expend mental energy doing something this trivial in 2024.
- teddyh 2y agoYes. A quick search yielded: <https://github.com/DarthFennec/highlight-indent-guides https://github.com/DarthFennec/highlight-indent-guides>
- deleted 2y ago[deleted]
- mort96 2y agoUse my editor to do .. what exactly?
- rented_mule 2y agoUse what are often called "indentation guides". Here's an extreme form of them from the blockman extension for vscode: https://raw.githubusercontent.com/leodevbro/vscode-blockman/main/demo-media/video/python-demo---c2-apng.png https://raw.githubusercontent.com/leodevbro/vscode-blockman/...
- mort96 2y ago1) that looks incredibly cluttered (yes, even compared to braces), and 2) it doesn't help a whole lot when reading code in any context what so ever which is outside of my preferred editor (including in github/gitlab merge requests or 'git diff' locally)
- adolph 2y agoI had to do a quick check if python do have teeth and thus use braces. My initial thought was that they do not as the most prominent teeth on snakes are fangs and python are not venomous. They do have teeth for holding their pray as they constrict it. Pythons use their sharp, backward-curving teeth, four rows in the upper jaw, two in the lower, to grasp prey which is then killed by constriction; after an animal has been grasped to restrain it, the python quickly wraps a number of coils around it. Death occurs primarily by cardiac arrest. https://en.wikipedia.org/wiki/Pythonidae https://en.wikipedia.org/wiki/Pythonidae
- m463 2y agoDo they have colons, or semi-colons? They seem to have semi-lungs, with a right lung and a vestigial left lung https://upload.wikimedia.org/wikipedia/commons/4/4d/Snake-anatomy.svg https://upload.wikimedia.org/wikipedia/commons/4/4d/Snake-an...
- gary_0 2y agoBraces, maybe. But I've always felt that semicolons at the end of lines were just noise. I can tell it's the end of the line because it's the end of the line. The few cases of ambiguity that happen can be solved by common sense (in the programmer or in the parser).
- ilyagr 2y agoThis is what golang does. https://go.dev/doc/effective_go#semicolons https://go.dev/doc/effective_go#semicolons
- xpl 2y agoAlso, JavaScript.
- gary_0 2y agoAnd Kotlin and Swift.
- xigoi 2y agoExcept JavaScript does it wrong.
- trealira 2y agoWhat makes Go's semicolon insertion algorithm different from JavaScript's? They seem similar to me. Isn't it just that the Go compiler requires very strict formatting, which saves you from getting bitten by errors due to unexpected semicolons?
- xigoi 2y agoThe following (contrived) JavaScript code does not work: let x = 5 (function() { console.log(x) })() The equivalent Go code works: package main import "fmt" func main() { x := 5 (func() { fmt.Printf("%d", x) })() }
- a3w 2y agoFirst of april is not now. So I will seriously discuss the idea: IMHO, some level of linting should be required. I would often have to reject lengthy and excellent pull requests (PRs), just because autoformat was not pressed and three instead of four whitespaces are in kotlin code. That annoys everyone. Python does that right, code won't compile with the three version whitespace, which is easily spotted before the PR.
- giancarlostoro 2y agoIn Visual Studio I turn on the feature to see whitespaces and non visible characters, just because every now and then, for some ungodly reason, someone in the project, somewhere, in every C# project I've ever worked on, will somehow open the file differently (seriously wtf? we all use Visual Studio!) and goof up a file somewhere, or there's people who instead of hitting tab, will manually insert spaces in a way that doesn't match Visual Studio's own format.
- AstroJetson 2y agoI’ll use Visual Studio when you pry my cold dead fingers off of my Vim keyboard. Since Ogg used square rock and Eagg used triangle rock to carve messages we’ve fought over editors. I fall into the camp a of formatter should do the presentation. But I also fall into the { } would be nice for Python.
- jobigoud 2y agoMost likely copy-pasting code from somewhere else that doesn't use the same convention.
- jaredsohn 2y agoI think that would ideally be done via a separate linter set up in CI. It has bugged me when using python interactively but fortunately ipython will ignore it.
- teddyh 2y agoThe documentation notes that reserving braces for blocks makes it very ugly to deal with dict literals, but it’t also terrible for sets, set comprehensions, and dict comprehensions. You’d think they’d choose some other characters than braces in order to avoid this. I seem to recall that RPL used « and » for program blocks.
- mwkaufma 2y agoWhy are braces-for-both-blocks-and-literals/etc a deal breaker here, but not in JS?
- throwitaway1123 2y agoUsing braces in an arrow function that returns an object literal actually is ambiguous in JS, which is why you have to wrap it in parentheses, e.g.: const foo = () => ({foo: 'bar'}) If you omit the parentheses it gets interpreted as a block with a label and a string literal: const baz = () => {baz: 'bar'} https://astexplorer.net/#/gist/9a86e0b61fda312dce2ea9d10d37ff20/8e2d1443456d0a4724f24b18ae2f97b585c3bc03 https://astexplorer.net/#/gist/9a86e0b61fda312dce2ea9d10d37f...
- wfleming 2y agoProbably because that makes parsing much more complicated, and this being a half-joking hobbyist project they didn’t want to increase scope that much.
- jerf 2y agoBecause bython is basically a glorified regular expression search and replace: https://github.com/mathialo/bython/blob/master/bython/parser.py#L159 https://github.com/mathialo/bython/blob/master/bython/parser... Rather than a real parser. A real parser knows about the context it is in, and as long as the grammar is unambiguous about some character, it can be reused in as many distinct parser constructions as you like. A pure regex-based approach to a first approximation can not. Whether or not it absolutely can or can't, without "approximation" and with regard to the exact re library in Python, would be something you'd have to work out through tedious effort. Regexes with backtracking can do a lot more than mathematical regexes, as well as all the other elaborations you could use. But even if Python's re can do it, you will be better off with a real parser. The "correct" solution, since by design Python and Bython share the same AST, is to take some existing code that can parse and re-emit Python code without changing it, tweak the incoming grammar to use braces instead, then emit the AST back out as Python. Then you wouldn't have this problem, or the problem with comments referenced in the source code (line 109 of the file I linked, just up a bit), or any of the probably other many little issues that would arise on real code if you tried to put this in real use. The only slight complication I can see is there may be a slight issue with comments around the braces. I'm not sure, and I'm not going to sit here & work it out fully for an HN post. Also, this is not a criticism of Bython. The author can do as they please with it. If nothing else you can always label this a prototype. Prototyping is good, right? Anyone who was rushing to slam this into production is just gonna learn a real valuable lesson worth its weight in gold, and not Bython's fault.
- Fraterkes 2y agoIs significant whitespace good or bad? Maybe 3/7/2024 is finally the day we get to the bottom of this.
- efilife 2y agoBad. Further discussion below
- deleted 2y ago[deleted]
- AcerbicZero 2y agoWhitespace is def wrong, but I'm not sure this actually makes things much better....still pretty awesome idea!
- deleted 2y ago[deleted]
- sgt101 2y agoI don't like whitespace compulsion but I can live with it. self.onandonandon is a real pain along with copy.deepcopy
- hoosieree 2y agomascot: a python, with braces
- IshKebab 2y agoOf all the things to hate about Python, this seems like the least. The indentation definitely looks nicer. I'd say the only real disadvantages it has are a) you are definitely restricted to statement-based constructs; no inline function definitions etc., and b) pasting stuff into the REPL is a mess. They could fix the latter, but the REPL is Python tooling so it is required to be awful.
- xigoi 2y agoThe statement thing could also be fixed. CoffeeScript, for example, is indentation-based and supports multiline expressions.
- IshKebab 2y agoI had a skim of it but honestly it looks like it just gets really confusing. Like you have to spend time just mentally parsing the code. Not really what I want. Similar to OCaml which is very light on punctuation - code just ends up like a sequence of words, with an occasional comma and it's quite mentally taxing to figure out where the functions and parameters are.
- 12_throw_away 2y agoI wish there were even more of this sort of thing, even though I'm an anti-braces zealot - it's crazy to me that, here in 2024, code is still so tightly linked to specific textual representations. Maybe there's an alternate reality where IDEs and development tooling got better and better post-smalltalk/lisp, instead of ... whatever we have now. Maybe we'd have editors and viewers where you could configure the syntax however you wanted. And sure, it would be persisted to disk in some canonical representation, maybe text, maybe a DB ... but you'd never need to worry about it, because all your tooling (VCS, diffs, refactoring tools, etc) would work with the AST, and you'd never need to worry about tabs or spaces ever again.
- rthnbgrredf 2y agoThanks to LLMs, we are quite close to achieving this. I can write code in Python (sometimes even plain english), and GPT can convert it to Go or even Haskell if I like. The conversion is accurate 95% of the time on the first attempt in my use cases, and I expect this to improve further with more powerful models in the near future.
- 12_throw_away 2y ago[flagged]
- rthnbgrredf 2y agoI think it is not so much surprising that large language models are particularly good at languages, including programming languages.
- randomtoast 2y agoI can confirm that it is a suitable use case for GPTs. I do GPT-assisted programming language design and experimentation. In some cases, GPT-4 can even generate a basic interpreter that allows me to test my new language. Here is an example of GPT's output for Python with braces that was generated after just spending 10 seconds for the prompt: def preprocess_braces(code: str) -> str: lines = code.split('\n') processed_lines = [] indent_level = 0 indent_str = ' ' # 4 spaces for indentation for line in lines: stripped_line = line.strip() # Check for opening brace if stripped_line.endswith('{'): processed_lines.append(indent_str * indent_level + stripped_line[:-1].strip() + ':') indent_level += 1 # Check for closing brace elif stripped_line == '}': indent_level -= 1 else: processed_lines.append(indent_str * indent_level + stripped_line) return '\n'.join(processed_lines) # Example usage: code_with_braces = """ def example_function() { if True { print("Hello, world!") } for i in range(5) { print(i) } } """ processed_code = preprocess_braces(code_with_braces) exec(processed_code) # This will execute the transformed Python code print("Processed Code:\n", processed_code)
- gabrielsroka 2y agoI found this here years ago: Python With Kurly braces. https://github.com/umlet/pwk https://github.com/umlet/pwk
- glimmung 2y agoI'm glad this exists for those who want it, but for me the added noise / cognitive load of all those braces is painful.
- pasc1878 2y agoFor another way of removing indentation needed for structure. Make python a lisp - indentation is just the number of brackets. Hy - http://hylang.org http://hylang.org
- blharr 2y agoI feel like this is a great idea, but as with other lisps, it looks really unfamiliar and loses the simple readability that python has for me.
- perrygeo 2y ago> it looks really unfamiliar Swahili looks unfamiliar to me. Because I didn't grow up in southern Africa. Don't conflate subjective familiarity with objective simplicity - any "unfamiliar" concept only reflects on you, not your subject.
- goatlover 2y agoBut millions of people are already familiar with existing Python syntax. Changing that would make it unfamiliar to them, and that's when you get people switching to another language that looks more familiar to them. Which is why C-style syntax has been so popular.
- pasc1878 2y agoNo one is suggesting changing it. This whole thread is about an alternative syntax for python. I was pointing out that there is yet another alternative. I prefer lisp syntax over indentation aware (e.g. python) over block syntax and at the bottom ones that force semi colons on you (the end of line is sufficient) - so the OP syntax for me is a massive downgrade of the language. Somewhere in that list I would add APL near the top but can't quite categorise it.
- xigoi 2y agoLisp-style parentheses are still better than brackets because at least they don’t waste verticat space. (if x (if y (if z foo))) versus if (x) { if (y) { if (z) { foo; } } }
- darby_nine 2y agoI don't understand why we don't make the aesthetic aspects of syntax (e.g. block delimitation) to be a feature of the editor rather than the source of truth for the code. For all unix profited from text I think we have the tooling necessary to move our storage and editors beyond it, and it's been obvious the entire time it comes with non-trivial liability converting to and from more reliably structured representations.
- williamdclt 2y agoI think it boils down to “text is good _enough_” (80% of the value, 10% of the complexity if even that), and it’s a format that’s incredibly interoperable. You can use tools that aren’t just language agnostic, but are not even programming-specific: notepads, grep, git, sed…
- darby_nine 2y agoI agree completely; I just think on a gut-level a solution would be validated with use despite the small marginal gain over text in complexity of tooling. Among RAGs, TreeSitter, and the success of LSPs, I think there's room here to synthesize some improvements. While we're on the topic, if we store only syntactically valid programs, we can express diffs in terms of semantic refactoring rather than textual changes. This would enable stuff like preserving refactoring across merges, thereby bypassing conflicts that would arise under text merges. There are limits to this of course as you can still come up with conflicts, but anything to ameliorate the nightmare of manually fixing a textural merge.
- digging 2y agoHuh, your comment made me reconsider. Variable names are very important to code quality, so how would those be preserved if not using text? I suppose they could be programmatically generated to be "good" but I foresee illegible edge cases being frequent in that case.
- deleted 2y ago[deleted]
- necovek 2y agoThis is a great discussion with many a differing point of view. To some, significant indentation is better. Others — too used to braces — miss them dearly in Python. Next ones, vie for the non-text source code, something to get us past these discussions altogether (editors working on .pyc files directly?). For programs to be maintained, they need to be read, understood and improved. One—often undervalued—skill in programming is to write beautiful code, because that is more art than craft. And unfortunately, tools like Black prohibit the true artists from expressing themselves clearly with code formatting too. And to those, white-space or braces matters on a different level, and everything else is attempting to make up excuses for why one is better than other. And while conceptual operations we do on the code seem simple on the surface, devising an editing tool that would do semantic operations on the AST is fricking hard and likely to be very non-ergonomic. Look at all the attempts to make code refactoring tooling: it's crazily complex and confusing that it's simpler to just go and grep for a string and fix anything you find. As long as it's faster to use regular editing operations to shuffle code around, indent or unindent it (or wrap it with braces), tweak one thing here or there, simple text editors will mostly rule the world of programming.
- mjevans 2y agogo fmt is really nice, that there is A standard for the language which is just included. No more arguments, just do what the including tooling desires. Python... I'd love if it shipped with a formatter that converted indents to braces, and then had an option for expressing indent as spaces (with number of spaces per indent) OR tabs (same, default 1); then still kept the braces.
- sigzero 2y agoI really hate the "tab width = 8" though.
- moonlion_eth 2y agoThere are kids out there with tab width 16 you should be grateful
- lionkor 2y agoAll significant characters should be non-empty/visible, I think that sums up why I prefer braces.
- Culonavirus 2y agoOnly monsters prefer invisible characters having syntactic meaning, and most of them probably also like pineapple on pizza. Shameful. (j/k)
- dajtxx 2y agoI agree entirely with the above, not kidding.
- TheOtherHobbes 2y ago<- Whitespace isn't invisible.
- makeitdouble 2y agoIt's weird to me to as a programmer to categorize space/tabs and new lines as empty or invisible. It only makes sense if you're writing by hand on paper or designing a page, sure wherever you don't write is empty. But even then that's still visible space. Then most language we currently use still rely on spaces in critical ways. `public function a()` and `publicfunctiona()`are not equivalent and there's no replacement character for the spaces. Now, more power to you to like braces, same way some languages like dollar signs.
- cardanome 2y agoNearly every editor has a "show whitespace" option.[0] I still don't understand why some people don't use it. Even in non-whitespace sensitive languages, I need to see the whitespace so that I can tell if the formatting is off or not. Also make the code easier to read as I can literally see how far the code is intended instead of having to guess by amount of space. Sure, automatic code formatting solves most of the issues but it is still good to have actual control over your whitespace. [0] Except VIM which vexes me greatly. Might be one of the reasons whitespace sensitive languages are disliked by certain programmers?
- dmurray 2y ago> At the moment, Bython is written in Python. PR #1: Makes Bython self-hosting
- calmbonsai 2y agoWith Python, use Black or go home.
- emmelaich 2y agoNever heard of it so looked it up: https://github.com/psf/black https://github.com/psf/black > Black is the uncompromising Python code formatter. By using it, you agree to cede control over minutiae of hand-formatting. In return, Black gives you speed, determinism, and freedom from pycodestyle nagging about formatting. You will save time and mental energy for more important matters.
- vaylian 2y agoThis. There are situations where I don't agree with the Black formatting, but none of them bother me enough to drop Black. Automatic consistent code formatting is very nice, especially when you need to work with other people on the same code.
- Sohcahtoa82 2y agoYup. We use Black where I work. It runs on every PR and we don't approve PRs that aren't approved by Black. Most of us have created a pre-commit hook so we don't even make commits that Black won't like.
- Probiotic6081 2y ago[dead]
- pansa2 2y agoDoes this add support for multiple-statement lambdas? IMO lack of support for them (because of the lack of a good syntax) is the main downside of Python’s significant indentation.
- Sohcahtoa82 2y agoI've never understood the strong demand for multi-statement lambdas. At best, it's just syntactic sugar. What's wrong with: def my_map_function(x): # do stuff new_list = map(my_map_function, my_list) ?
- cynicalsecurity 2y agoThe same goes for Golang. The reverse position of a variable name and type in function arguments is absolutely infuriating. I hate the person who did it, it's absolutely stupid.
- computerfriend 2y agoSee https://go.dev/blog/declaration-syntax https://go.dev/blog/declaration-syntax for the rationale.
- cynicalsecurity 2y agoI've read it before, it doesn't make any sense.
- xigoi 2y agoThe C style is the reverse one, not the Go style.
- lofaszvanitt 2y agoPeople have these culture wars about braces in the end or new line, while the whole thing should be on the editor's side. It shows you the way you want it, then convert it to the agreed upon style upon saving. Text editors are easy, but are waaaaay in the past. There could be much much better 3D like editors out there, but everyone is lazy to make one that would make your life much easier.
- unstable 2y ago> while the whole thing should be on the editor's side. This. I'd prefer using my own preferences instead of using a dumb formatter like prettier. Who cares some other dev in your team prefers 2 chars indentation? It should be an editor preference, not applied to source code. Personally I would also prefer the IDE to do type checking as well so we can get rid of the TypeScript misery, but that's another discussion.
- autoexec 2y agoHonestly, the weird whitespace annoyance doesn't bother me half as much as needing parentheses for print.
- Sohcahtoa82 2y agoThe parentheses make sense because print is a function that has parameters, and more than just the string to be printed. https://docs.python.org/3/library/functions.html#print https://docs.python.org/3/library/functions.html#print I suppose they could have given the option to continue using print as a statement if you don't care to override the default parameters, but having those parameters really simplified some options.
- deleted 2y ago[deleted]
- jackblemming 2y agoCan we get python with sane async, parallelism, map/reduce and scoping instead?
- samatman 2y agoI was wondering if this was sincere or a troll, until I saw the semicolons. Troll. 100%. A good one at that.
- DonHopkins 2y agoPython has always fully supported C style braces out of the box: you simply have to put a # before them: if foo == 1: # { print "one foo" # } It also supports PASCAL style begin/end: if foo == 1: # begin print "one foo" # end And it's fully internationalized, even supporting mixing multiple languages: if foo == 1: # beginnen print "one foo" # 終了 In fact, you can even mix styles: if foo == 1: # begin print "one foo" # } Or optionally leave one of them out, or spell them any way you like, if you feel like it: if foo == 2: print "one foo" # fi Even verbose COBOL style: if foo == 1: # perform conditional foo value check print("one foo") # end perform conditional
- 01721143931 2y ago[flagged]
- pyuser583 2y agoPython supports extensions. Maybe a better way than translating text files?
- math_dandy 2y agoShould write a PEG grammar.
- 0x1ceb00da 2y agoCould've been a python parser patch because it adds a preprocessing step. Wouldn't have been that difficult to maintain since the syntax doesn't change that much.
- make3 2y agobut then you can't pip install it, & you have to re build your whole environments, etc
- wiml 2y agoDidn't Python used to support braces as an alternative to indentation? I remember it being a feature back in the 1.x days, but I can't find it in the old language docs, so I must be thinking of some other language.
- stingraycharles 2y agoI don't think there was. As a matter of fact, there was actually the following easter egg in earlier versions of Python: >>> from __future__ import braces File "<stdin>", line 1 SyntaxError: not a chance
- qrian 2y agoIt's still there! https://github.com/python/cpython/blob/main/Python/future.c#L41 https://github.com/python/cpython/blob/main/Python/future.c#...
- aitchnyu 2y agoMight as well allow multiline lambdas and js-style ternary statements. JS (under JSX skin) makes constructing a tree of components really ergonomic. Similar libraries in Python rely on doing side effects and context managers and dsls. Also TS has slightly more consistent syntax for return types than Python. ``` // TS function fn(a: Type, b: Type) : Type { } // Python def fn(a: Type, b:Type) -> Type { } ``` But I want python to have to close braces on as few lines as possible. Yes I'm a Black user and wonder how.
- surfingdino 2y agoSacrilege /s
- woolion 2y agoFor those interested in the "no syntax" approach (the editor being aware of the structure and able to operate natively on it), there are a number of projects [0] that go beyond simple Proof of Concepts. Naturally there are more on Lisp-y languages since there is much less work to go back and forth between syntax and structure. Then is another interesting related discussion [1] from 2015, "Programmer Tooling Beyond Plain Text". Since discusses article seems down, I've added the archive link at [2]. [0] https://github.com/yairchu/awesome-structure-editors/blob/main/README.md https://github.com/yairchu/awesome-structure-editors/blob/ma... [1] https://news.ycombinator.com/item?id=9495493 https://news.ycombinator.com/item?id=9495493 [2] https://web.archive.org/web/20151023070244/http://joelburget.com/plaintext/ https://web.archive.org/web/20151023070244/http://joelburget...
- thih9 2y ago> You should still write beautiful code, but if you mess up with tabs/spaces, or copy one piece of code to another that uses a different indentation style, it won't break. This seems contradictory. But I see the benefits. Perhaps braces and an official linter would be a more ergonomic approach.
- kaplpot 2y agoThis is the least of Python's problems, but makes for a good populist discussion that will keep Python on the front page for yet another 10 hours. This is how Python got big: Discuss cute issues endlessly, pretend to be a funny, benevolent community. But real issues like performance, correctness or security are never addressed, and people who dare to mention them are punished severely.
- GaryNumanVevo 2y agoThis is a very shallow understanding of the Python community. Of course there are a lot of "cute issue discussions" it's a language with a huge number of diverse participants. Performance and security are regularly discussed and patches are contributed via the mailing list. Python is _the_ language for ML right now because of the community.
- cmalexn 2y agoAgain, the ideal version that is removed from reality is presented. The mailing lists are non-operational for political reasons and because most competent people have left. Patches have never been contributed via the mailing lists. Python is the language for ML not because of the "community", which is an exploitative system where talkers who go on stage at a PyCon and never do anything get more money and worse, control who can earn money in the Python ecosystem. It is the language for ML because Python had a decent C-API and a lot of scientific software has been written early on.
- HexDecOctBin 2y agoThis is something I have been thinking about. Why was a lot of scientific software written in Python? Remember that Torch originally had a Lua frontend, and was only later turned into PyTorch, citing the same availability of scientific software. But considering that Lua has a far better C API than Python, why did those initial scientific/mathematical software use Python?
- 2y ago
- garibaldy 2y ago[dead]
- usrbinbash 2y agoThe problem I have with such tools, is interoperability. This transpiles into Python. Okay. So for this to work in a collaborative environment, EVERYONE working on the code has to use it. Given how popular python is, and the natural inertia of programming languages, I simply don't see that happening. The reasons for this are legion: From programmers simply being used to how python looks, over IDEs and linters that would have to be remade, all the way to automated tooling. And even if all that were not a problem: This introduces one more step and one more element into the build chain. Which is something I can't see DevOps doing, for a, at the end of the day, purely cosmetic change.
- psychoslave 2y agoOn that side, as for many others, Ruby captures my love. You can use `{…}` or `do … end` as you see best fit. And enforcing some indentation convention is always an option with some upper level tools. What makes perfect sense for integration in a large codebase is ridiculous while interacting with a REPL. Now Ruby as his own defects of course. Static type can be integrated through Sorbet, but that still something out of the core for now. On that side, PHP had during the last years shown a far more remarkable pace in integrating many advanced feature for OOP (and functional stuffs are also progressing well). That said, the foundation of Ruby still win my preference in term of elegance and feeling of coherence. I didn’t touch that much Python over the last few years. The only (significant) reason I would see it as opportune is its heavy use in ML and the like domains, and I didn’t have an opportunity to dig this domain much.
- Sohcahtoa82 2y ago> You can use `{…}` or `do … end` as you see best fit. I don't use Ruby, so I don't know what happens in the Ruby world, but... Doesn't this create a Holy War akin to C/C++'s fighting over where the opening brace goes (Current line vs next line)?
- steveklabnik 2y agoIt doesn't, because 3.times do print 'Welcome ' end this works, but 3.times do print 'Welcome ' end does not work. Same with curly braces.
- Sohcahtoa82 2y agoI don't mean where to put the opening "do", I mean, a fight between: 3.times { print 'Welcome ' } and 3.times do print 'Welcome ' end
- steveklabnik 2y agoAh! So, Ruby is a bit weird: the Ruby community itself tends to be much closer to Perl than Python, that is, the language doesn't mind embracing many ways of doing the same thing. However, the Rails community tends to curb this attitude a bit by being really strongly about conventions, and following them. In practice, this means that a significant amount of the community uses one of the two rules: > Use {} for one line blocks, use do/end for multiline blocks. or > Use {} for blocks that produce a value, use do/end for side effects. The latter is called "Weirich style," after a very prominent Rubyist using that style. Hilariously, your example would be code that could go either way, depending on which style you choose. Though I would think that people who subscribe to the first rule would write it 3.times { print 'Welcome ' } as the "one line" really kinda leans this way. Anyway that's as far as I know, my Ruby knowledge is about 10 years old at this point, so maybe things have evolved since then, but I haven't really heard of any changes here.
- ivanche 2y agoAs they say, python looks exactly like Guido indented it to look.
- Ringz 2y ago“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” Antoine de Saint-Exupéry Unfortunately, we still live in an era where humans have to adapt to technology rather than the other way around. From my perspective, this is particularly true for programming. For me, Python is a good (though not ideal) mix of simple syntax and power. The language is characterized by low redundancy, meaning it uses fewer unnecessary characters like semicolons or curly braces to mark the end of a line. If a human can recognize the end of a line without special characters, then the compiler should be able to as well. As someone with ADHD, I find it particularly difficult not to get distracted by these and other superfluous details. These small distractions add up and can become very burdensome. Interestingly, I found it easier to program in Assembler and Modula than in languages like C++ (MSVC), PHP, or JavaScript – at least as long as the projects were small. Even a brief look at Rust’s syntax causes me almost physical discomfort, no matter how great, powerful, and useful the language may be. For this reason, I almost exclusively use the terminal for emails, calendar, and programming, even though complex GUIs can simplify some tasks. Although Python is not perfect in terms of syntax, it offers a good balance. Perhaps one day, before the perfect programming language exists, we will be able to use AI and ML to explain to the computer what a program should do with simple language (better than ChatGPT right now), just like Captain Picard. In fantasy, a few letters, punctuation marks, and some grammar is all that is needed. This may lead to inaccuracies in human-to-human communication, but that does not mean the same problems must occur in communication with an intelligent compiler. Making syntax as “human-readable” as possible should always be the highest priority. We could unlock so much potential this way.
- masklinn 2y ago> For me, Python is a good (though not ideal) mix of simple syntax and power. The language is characterized by low redundancy, meaning it uses fewer unnecessary characters like semicolons or curly braces to mark the end of a line. If a human can recognize the end of a line without special characters, then the compiler should be able to as well. […] Even a brief look at Rust’s syntax That’s a shame because you’re missing that these sigils actually have meaning there, because the semantics of the language are completely different: Python is statements-based with very limited scoping (global and function), Rust is expression based with block scoping. As a result, blocks (paired braces) are a way to pack multiple statements into an expression e.g. let v = { let a = thing1(); let b = thing2(); thing3(a, b) }; And `;` is not an alias for end-of-line, it’s a separator for statements. And not aliasing end-of-line to end-of-statement is relevant to rust being expression oriented, it’s very common for expressions to span multiple lines, in that case Python requires either wrapping the entire thing in parenthesis or escaping the EOL with `\`. Could you find other ways to do this? Sure, but then you have to make other tradeoffs e.g. wrap everything in matching symbols à la lisp, or make statements into special cases à la Haskell.
- JodieBenitez 2y agoI had to check the calendar. Twice.
- p5a0u9l 2y agoGlad that auto formatting tools like black and ruff (at least in Python world) are increasingly becoming the norm. It’s really nice to not think about whitespace or humor these silly arguments.
- bloopernova 2y agoI've recently created a couple of Lambdas using nodejs rather than my normal Python. Despite node feeling more verbose, I've found that I understand node easier than Python. It's definitely strange to me, because there can't be that much difference between the 2, but parentheses seem to make it easier to follow structure?
- 65 2y agoI've written a lot of Python and Javascript and still prefer Javascript (Typescript) over Python. I like how easy it is to do functional programming with Javascript. Python can have some weird syntax for functional programming, whereas Javascript has very obvious ways to do something such as an array map. To me Python feels more like PHP than Javascript.
- demondemidi 2y agoPython async syntax is ass backwards compared to JS.
- sk6565 2y ago[dead]
- RyEgswuCsn 2y agoPeople spent considerable amount of effort developing systems that separate contents from styles (latex, html/css, etc). And with Python people think it’s a good idea to encode contents as styles…
- sambalbadjak 2y agoI did not know I had such a strong reaction to seeing curly braces in python. brr not my cup of tea. but all the power to you
- shantnutiwari 2y agoThe library is 6 years old, and I remember we all laughed when it came out. Why is it on the 1st page now?
- newaccountman2 2y agoI think Python is terrible, but whitespace is ok. lol