Off topic (sorry): Dropbox's overall typography is blatantly offensive to the eye.
It happens (no worries): We did see before; we do see forevermore.
( ~ might be putting the cart before the horse. ~ take it easy )
Thank You, Guido
341–350 of 388 posts
Re: Thank You, Guido
#342Python literally changed my life. I was in a bad situation when I started learning it, and from that point, job offers never ended, a whole new world opened for me. Not sure if another language could have done that for me.
Thank You, Guido!
Re: Thank You, Guido
#343Earlier quoted context omitted.
> For me personally it is Python, the delay between solving a problem and having it translated to python in my head is slim. You probably feel the same way about your own favourite programming language. I feel that with Ruby, which I do a lot nowadays and love WIth regards to Python, it is the things like having to write 'self' on each class method, having spaces as part of the language syntax, inconsistent Object or…
Python and Ruby although in the same category have still different mindset. It is understandable the way you think fits Ruby more. I tried to learn ruby and was put off by all the magic, last value calculated is magically returned, the useful but cryptic method calls. It is shorter and more implicit, I like the explicit approach more. to give you my perspective on the points you made: - self: more explicit, I would p…
>spaces vs. braces: I don't hate braces, but spaces makes it more readable
Really?? This is my least favorite thing about Python. D: It can't possibly be more readable when you're talking about large code blocks. It just happens that we're never supposed to be talking about large code blocks in Python. "If you want to write a lot of code, you use another language," they say -- probably one with braces, which syntax highlighters can match-highlight on. In Python, you just hope the indentation is far enough to make it obvious where something ends and another thing begins.
Re: Thank You, Guido
#344Did you notice this: "He has already put into motion the conversion of the Dropbox server code from Python 2 to Python 3." Even the company that hired Guido is still heavily dependent on Python 2, and it doesn't surprise me at all; my own employer still has a lot of it in internal tools.
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…
> I'm starting to long for a stack that doesn't constantly change. Just set the features and that's it.
I hear every day: don't change a thing in D, just add these two features.
Re: Thank You, Guido
#345Earlier quoted context omitted.
Yeah, he already did step down from being the BDFL. PSF now has an elected steering council to replace him. https://mail.python.org/pipermail/python-committers/2018-Jul...
And Guido is currently one of the five members of the steering council.
Yes, had forgotten that for some reason. Thanks for the clarification.
Re: Thank You, Guido
#346There'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!
A few others born in the 1950s that immediately come to mind: Martin Odersky (Scala), Guy Steele (Scheme), Robert Gentleman (R), John Ousterhout (Tcl), and (sort of) Simon Peyton-Jones (Haskell).
Wow, I didn't know that John Ousterhout created TCL, come to think of it, I never thought about who was behind it.
Re: Thank You, Guido
#347Earlier quoted context omitted.
Or Perl. Perl takes backwards compatibility very seriously. There was a lot of gnashing of teeth a while back on whether to make newer versions actually change the default behavior finally to some new features could be opt-out instead of opt-in. An by new features, I mean stuff like "use strict", which has been best practice for a couple decades now, but the change would cause problems for existing scripts that didn'…
Unless it uses CPAN stuff, or calls out to external tools. Those are often needed for key functionality, and they get stale much faster than perl itself.
SaaS modules too, a lot of services have their API modules and examples provided in various languages. Perl is often not one of them. In some cases where it is, it's out of date or plain old broken. As an example (which is understandable, no hard feelings) I had to edit the SendGrid modules to fix a bug when I tried, and there were issues on GitHub that have been ignored since before it became officially unsupported in 2016.
I usually use Python these days when dealing with SaaS apps since the ecosystem is much better, and I want to learn it anyway.
Re: Thank You, Guido
#348Earlier quoted context omitted.
There has to be a term for when the business builds something with one tech stack, and then later, as if it was totally by surprise, realizes it needs to replace the whole thing, for basically no added business-value, and this happens every few years. I mean, everyone has known they would have to do this eventually, but it just kept being put off, like the business is a bad procrastinator. And they all do this.
It's just delaying maintenance. We're bad at recognizing that software requires maintenance and periodic updates/replacement, same as anything physical. Businesses think once it's written it will always just work...and that's true if the underlying OS and hardware never change, and the business never changes, and requirements never change. But even if it's a completely niche application whose requirements never chang…
The software version of driving a car until it falls apart instead of doing more than the bare minimum to keep it running. It's not always the wrong choice but it's wrong to be surprised when faced with the expected outcome.
Re: Thank You, Guido
#349Earlier quoted context omitted.
Interesting. I myself come form an Software Engineering background, and started programming very young in Logo (a LISP derivate), then BASIC, C, C++, Java, Ruby and a bunch of others. I have hated programming in Python every time I have had to do it (several times through my career). It I think the only language that I have really hated ... the language itself. I've done Z80 and 8086 assembly, I've done Prolog, I've…
I think it is about the thinking process of the person, I assume you are >35, you grew up at a time that people were think about the performance more than the readability, that was the bottleneck back then. Now that you have bigger systems and more complex requirements and cheap high performance computing, the balance is tipped. And because python is (almost) on the opposite side of the spectrum for your thinking pro…
I assume you are >35, you grew up at a time that people were think about the performance more than the readability, that was the bottleneck back then.
From the old fart: conflating performance conscious code with the lack of readability is plain wrong.
Re: Thank You, Guido
#350Earlier quoted context omitted.
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…
> 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. I think you are confusing "languages that are good" with "languages that you think should be good". I will admit that there are a fair number of programmers that are fashion-following zomb…
> I will admit that there are a fair number of programmers that are fashion-following zombies, but there are a large number who are not easily led by the crowd
Perhaps not, but they are led by money. No one is hiring lisp programmers.
> The alternative - that you're one of the enlightened few, and almost everyone else is a mindless sheep - may feel satisfying, but the very degree to which it is satisfying should make you more wary of accepting it as truth.
I should hope that's not how I come off. My meaning was more that which languages are popular is more a result of inertia than anything. My impression from reading internet forums is that most people who use java and javascript are unhappy with those languages.
> OS programmers in particular are not among those easily led by fashion. If Lisp gave them a real advantage, some of them would use it.
And they do. OS programming is notoriously hard to get into, but even more so if you leave the beaten path. It's inertia again: everyone else is using c, and there's a lot of existing literature about how to write OSes in c, so that's what people do. Rust--which has recently been popular for hobbyist OSes like redox--and c++ were explicitly designed to support the same kinds of programming paradigms as c, so OSes written in them aren't indicative of a deviation from c. But those people who have enough expertise to move past toy OSes and stolen architecture can and do write OSes in other languages, like the lisp os I linked above.