4 ms·

Yeah, why did we even had that assembly stuff? We should have had rust from the start! Seriously, python was born in 1991, 4 years BEFORE Java existed. And it

Yeah, why did we even had that assembly stuff? We should have had rust from the start! Seriously, python was born in 1991, 4 years BEFORE Java existed. And it barely had any funding until 2010. Insight is 20/20 but this is not how tech works. You are limited by knowledge, resources, politics, legacy, compatibility commitment and so on. Not to mention you can simply get it wrong. Would have been funny if the whole world moved out of unicode and we got stuck with it forever. Usually, you know something is a standard only when people complain you adopted it too late because everyone else did. Like Java that used XML for all serialization and got suck with it for 15 years while we all moved to JSON. Or utf-7 that is still used by IMAP because they did the wrong call. Yes, utf-7. What, you though utf8 was the only unicode standard? No, no, no. There are utf-7, utf-8, utf-16 (JS uses that) and utf-32 (C# uses that) in use. And more exist that abandoned. People seems to be under the illusion that this stuff is easy, or obvious. Sure. In 2022. Everything about text has been a fight for death to this day, for all programming languages. This includes formatting. We have "%s" because... of printf() in C. Let that sinks in.

haberman 4y ago
> People seems to be under the illusion that this stuff is easy, or obvious. Sure. In 2022. I mentioned that Ruby had this for "upwards of 20 years." I was vague on the timeline because I didn't know for sure how long it had been. After reading your message I looked into it and it looks like Ruby supported "#{expr}" since at least Ruby 0.95, in 1995: https://github.com/nobu/ruby-1.0/blob/master/sample/tkdialog.rb#L58 https://github.com/nobu/ruby-1.0/blob/master/sample/tkdialog... This is not to mention Perl, awk, shell, and Tcl, which had syntax like $FOO for even longer. Ruby's solution existed before all of the following PEPs, which added different varieties of string formatting to Python: - PEP 215 – String Interpolation (2000) (superseded by PEP 292) - PEP 292 – Simpler String Substitutions (2002), added string.Template() - PEP 3101 – Advanced String Formatting (2006), added str.format() - PEP 498 – Literal String Interpolation (2015), added f'' I get that language design is hard, and it's difficult to have the final answer right away. But it's not as if this idea was unknown or untested when Python introduced other home-grown solutions. When Python proposed f strings in 2015, it imitated a design that had been in Ruby for almost 20 years at that point.
hnfong 4y ago
> There are utf-7, utf-8, utf-16 (JS uses that) and utf-32 (C# uses that) in use. And more exist that abandoned. Javascript is just UCS-2 that exposes UTF-16 internals (eg. surrogates) for your application logic to process if you want to do anything correct with the string (other than pass it around unmodified). Maybe it's "abandoned" in the sense that UTF-16 nominally supersedes it, but yea, it's actually just UCS-2. Lots of the stuff in early 1990s used UCS-2 (eg NTFS). This also goes to your point about living with "wrong" decisions from the past due to compatibility and inertia. Nobody knew we needed more than 2^16 code points (bet most of you don't know about the Kangxi Dictionary...)

haberman 4y ago

> People seems to be under the illusion that this stuff is easy, or obvious. Sure. In 2022. I mentioned that Ruby had this for "upwards of 20 years." I was vague on the timeline because I didn't know for sure how long it had been. After reading your message I looked into it and it looks like Ruby supported "#{expr}" since at least Ruby 0.95, in 1995: https://github.com/nobu/ruby-1.0/blob/master/sample/tkdialog.rb#L58 https://github.com/nobu/ruby-1.0/blob/master/sample/tkdialog... This is not to mention Perl, awk, shell, and Tcl, which had syntax like $FOO for even longer. Ruby's solution existed before all of the following PEPs, which added different varieties of string formatting to Python: - PEP 215 – String Interpolation (2000) (superseded by PEP 292) - PEP 292 – Simpler String Substitutions (2002), added string.Template() - PEP 3101 – Advanced String Formatting (2006), added str.format() - PEP 498 – Literal String Interpolation (2015), added f'' I get that language design is hard, and it's difficult to have the final answer right away. But it's not as if this idea was unknown or untested when Python introduced other home-grown solutions. When Python proposed f strings in 2015, it imitated a design that had been in Ruby for almost 20 years at that point.

hnfong 4y ago

> There are utf-7, utf-8, utf-16 (JS uses that) and utf-32 (C# uses that) in use. And more exist that abandoned. Javascript is just UCS-2 that exposes UTF-16 internals (eg. surrogates) for your application logic to process if you want to do anything correct with the string (other than pass it around unmodified). Maybe it's "abandoned" in the sense that UTF-16 nominally supersedes it, but yea, it's actually just UCS-2. Lots of the stuff in early 1990s used UCS-2 (eg NTFS). This also goes to your point about living with "wrong" decisions from the past due to compatibility and inertia. Nobody knew we needed more than 2^16 code points (bet most of you don't know about the Kangxi Dictionary...)