There's a whole generation of programming language creators born in the early to mid 1950s. In no particular order: Guido van Rossum (Python), Bjarne Stroustrup (C++), James Gosling (Java), Rob Pike (Go), Larry Wall (Perl), Walter Bright (D). Makes me wonder what kind of secret club they have going on.. Enjoy the retirement, Guido!
I can only dream of a panel or a TED talk with those computing sages! (I guess they are all alive right)
Thank You, Guido
271–280 of 388 posts
Re: Thank You, Guido
#272Earlier quoted context omitted.
I'm starting to long for a stack that doesn't constantly change. Just set the features and that's it. Security updates only after that. It feels like a constant grind keeping up with everything. Containers, clouds, programming languages, operating systems, frontend frameworks, transfer protocols, it seems like it takes so much effort to just build something and keep it going. That Python 2 is still around doesn't rea…
As I get older and crankier I find simplicity and stability become a lot more interesting than reinventing the same wheels over and over again. This is probably why I’ve come to appreciate Rich Hickey’s talks more and more as years go by. I think Clojure is a good fit when it comes to stability as per their own development guidelines [1]: The Clojure development team values a measured and thoughtful approach to langu…
To anyone who's interested in this topic, I strongly recommend this talk from Rich Hickey about "giving something to somebody that they can use and making a commitment": Spec-ulation (https://www.youtube.com/watch?v=oyLBGkS5ICk)
Re: Thank You, Guido
#273Earlier quoted context omitted.
> Lisp is a bad language to write an OS in Beg to differ. Lisp machines were huge, back in the day, and there are still hobbyist projects like https://github.com/froggey/Mezzano
"It was done at least once" != "it was a good choice", though. There's a reason why most OSes are not written in Lisp, and it's not because the OS writers aren't smart enough to learn Lisp. It's not because they don't know it exists. It's because there are better languages to write an OS in.
I think it's pretty obviously wrong to say that a language is unpopular (for a task) because it isn't good (at that task). Otherwise no one would be using java, javascript, or c++; and lisp and haskell would be a lot better used.
OSes aren't written in lisp because lisp isn't terribly popular, and subset of lisp programmers who are interested in OSes is pretty small--this is a much more interesting factor to look at than subset of OS programmers who are interested in lisp.
Re: Thank You, Guido
#274Earlier quoted context omitted.
What surprises me most is his insistence on a non-incremental update. To this day, I have no idea what the logic behind "no intermediate steps" is. Codebases are written in Python that would dwarf Margaret Hamilton's famous stack. Why should everyone have to adapt the string functions to unicode and get rid of different-type comparisons and change syntax in one go, without a good way to sound out bugs inbetween?
Regarding string , the breaking change was necessary because it was a double-duty type, sometimes acting as a byte-array and other times acting as a string. Meaning some of its functions, like string.length() , gave a value that only made sense for string-as-byte-array, but not as string-as-simple-list-of-characters. More detail on Stackoverflow if you want ( https://stackoverflow.com/questions/5471158/typeerror-str-…
string.length() still doesn't make sense in Python 3
There's nothing "simple" about "list of characters" in Unicode. Discussed at length at: https://news.ycombinator.com/item?id=18154667
Here's how a Unicode export with 20 years of experience in Unicode explained it: https://blog.golang.org/strings
> Some people think Go strings are always UTF-8, but they are not: only string literals are UTF-8. As we showed in the previous section, string values can contain arbitrary bytes; as we showed in this one, string literals always contain UTF-8 text as long as they have no byte-level escapes.
> In fact, the definition of "character" is ambiguous and it would be a mistake to try to resolve the ambiguity by defining that strings are made of characters.
> [Exercise: Put an invalid UTF-8 byte sequence into the string. (How?) What happens to the iterations of the loop?]
If you aren't in Unicode, then "character" is the same as "byte" so splitting the types gets you nothing of vlaue.
Assuming you are not implementing a low-level Unicode library, what's your use case for "list of Unicode characters" ?
Re: Thank You, Guido
#275Earlier quoted context omitted.
What is 'even' about this, given that Dropbox was founded well before the first version of Python 3 was released? Feels like less of a 'did you notice' and more of a 'let's have an interminable python2 v python3 thread no matter the topic at hand'.
Guido has been working there for 6 years yet only now is starting the conversion?
The article doesn't say "only now".
It says "He has already put into motion the conversion of the Dropbox server code from Python 2 to Python 3. "
"already" refers to "sometime in the past 6 years".
Re: Thank You, Guido
#276Earlier quoted context omitted.
Delphi still lets you build programs that used to run on Windows 3 with minimal changes, and definitely anything 32-bit. It's part of the value proposition: the language and libraries are planned for forward compatibility and stability for use ten years in the future, as well as now.
To save others the same DDG search I did -> Delphi is a Pascal language IDE that compiles to native Windows binaries. Apparently there is this thing called Lazarus that is a free version of it?
FreePascal is language/compiler and Lazarus is an IDE. Lazarus IDE runs on all major platforms and produces native code. Suitable for anything starting from system code and up to complex GUI apps.
Re: Thank You, Guido
#277Earlier quoted context omitted.
Don't they have source to source compilers that do the migration for you? I don't understand why the friction is so strong with python.
Yes but the source-to-source compilers do a fraction of the work needed to get a code base migrated. I've tried both the builtin 2to3 utility and many proprietary converters, including fancy ones that run type inference on Python 2 code and produce type annotations. None of them, as expected, can deal with the str/bytes split without manual intervention. Fundamentally the issue is that the Python language is too dyna…
Funny that you mentioned it, because there's such tool and one of it orginates from Dropbox - PyAnnotate[1]
There's also MonekyType[2] from instagram, but it only works on Python 3. I will also drop PyType[3] from Google, although this one tries to statically determine the types and when I used it felt a bit buggy.
[1] https://github.com/dropbox/pyannotate [2] https://github.com/instagram/MonkeyType [3] https://github.com/google/pytype
Re: Thank You, Guido
#278One of the things some of us learn with experience is that “clever code only the author can understand” is often a lie, too. I may be able to figure it out on the fly but code I haven’t touched in six months is less familiar than other people’s code that I touched a month ago.
When I leave hints in the code it’s enlightened self interest. It’s often as much for my own benefit as for others.
Re: Thank You, Guido
#279Earlier quoted context omitted.
What surprises me most is his insistence on a non-incremental update. To this day, I have no idea what the logic behind "no intermediate steps" is. Codebases are written in Python that would dwarf Margaret Hamilton's famous stack. Why should everyone have to adapt the string functions to unicode and get rid of different-type comparisons and change syntax in one go, without a good way to sound out bugs inbetween?
I mean, it seems like you are suggesting 3 incremental non-backwards compatible changes. I'm not sure how that's better. Nobody is going to sign on to the first two, so you end up with the exact same situation we have now, but took a more complex approach to get there.
Yes, that's what I'm suggesting. I know a big python2 codebase (SageMath) that has been "close" to python3 adaption for several times within the last 5 years but had to call it off every time because something came in the way. By the time the next serious attempt was started, lots of the changes had rotten. Anything that could be done incrementally (python 2.7.5, from-future imports, prints with parentheses) has been done long ago.
Re: Thank You, Guido
#280Earlier quoted context omitted.
personally i loath blackbox systems, regardless of how well the docs are written. i want to know how it does things...even if only to satisfy my curiosity.
It's not blackbox in that you can't look inside... it's blackbox in that you can choose to ignore it and be just fine. Springboot takes an opinionated approach to a lot of things, but always lets you override it and do whatever you want wherever you want. I suppose that's more of a greybox...
ah, yes! point taken.