Live data from Hacker News

Thank You, Guido

blog.dropbox.com

351–360 of 388 posts

Re: Thank You, Guido

#351

Earlier quoted context omitted.

Writing an OS in Lisp basically means adapting or developing, and then growing, a Lisp implementation on the bare hardware. Someone would only do this if they are simultaneously interested in OS research R&D and Lisp implementation R&D. This is different from someone working on an OS in, say, C. They just pick some C compiler and use it, without becoming a C researcher and implementor. (They might bemoan some things…

I'm not sure I agree with this. How much assembly would you actually have to write to bootstrap a Lisp? If I understand correctly, not much. And you could cross-compile from some other platform for as long as needed as you use the Lisp to write the OS.

Cross-compiling from another platform (say, SBCL) only brings to your target whatever you have written yourself, not any attributes of that platform (say, SBCL).

You don't magically get SBCL's reader, garbage collector, hash table implementation, object system ... or anything else you might want in the OS.

(You could fork that system though to borrow those things instead of doing it from scratch.)

Re: Thank You, Guido

#352

Earlier 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. 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…

> I should hope that's not how I come off.

Well... you didn't really. You seemed to be somewhat in the neighborhood, which is why I mentioned it, but not really there, so I tried to be gentle. (I hope I came across that way...)

> My meaning was more that which languages are popular is more a result of inertia than anything.

To perhaps strain a metaphor, I think it might be more like a gas cloud gravitationally collapsing. You get denser regions, which have more gravity, so they are able to attract more gas and get even denser. In the same way, a language ecosystem that has more... something... attracts more developers, which makes it a better market for third-party libraries and how-to books and consultants and tools, all of which gives it even more "something". ("Mass" is the word in the analogy; I'm not sure what the word is for language ecosystems.)

But for a project I'm going to start right now, it's perfectly rational for me to take that "mass" (or whatever) into account when choosing a language, because it means I can find programmers, and tools, and how-to guides, even if the language as a language is no better than the alternatives.

I guess that means that I'm agreeing with you about "inertia". I don't think it's just mindshare, though. It's the ability of the ecosystem to help you get your project done.

And the languages that attain that kind of "mass" are languages that were able to attract it when they didn't already have it (when they were just starting out), which is either some indication of merit, or an indication of organizational support. For organizational support, see Java (Sun publicized Java heavily, but also wrote massive libraries). For merit, consider C. (When it started out, it didn't have tons of publicity or great libraries. But it was good enough, and it was free. That was enough to start gaining a following.)

Re: Thank You, Guido

#353

Earlier quoted context omitted.

I'm not sure I agree with this. How much assembly would you actually have to write to bootstrap a Lisp? If I understand correctly, not much. And you could cross-compile from some other platform for as long as needed as you use the Lisp to write the OS.

Cross-compiling from another platform (say, SBCL) only brings to your target whatever you have written yourself, not any attributes of that platform (say, SBCL). You don't magically get SBCL's reader, garbage collector, hash table implementation, object system ... or anything else you might want in the OS. (You could fork that system though to borrow those things instead of doing it from scratch.)

Why not, if I can get the basics of Lisp running, and those other things are written in Lisp? Isn't the hash table implementation written in Lisp?

Or are you saying that I wouldn't automatically have the source for those things? If so, then... yeah, I was kind of assuming that I would have it. If the licenses don't work that way, or if the source simply wasn't available, then my devious plan would not work.

Re: Thank You, Guido

#354
post #2

"“When asked, I would give people my opinion that maintainable code is more important than clever code,” he said. “If I encountered clever code that was particularly cryptic, and I had to do some maintenance on it, I would probably rewrite it. So I led by example, and also by talking to other people.”" This is very sage advice.

That coincides with the following: > Code is read many more times than it is written. Writing code costs something , but over time the cost of reading is often higher. Anyone who ever looks at a piece of code has to invest brain-power into figuring out what it does.[1] This is also noted in PEP8: > One of Guido's key insights is that code is read much more often than it is written. The guidelines provided here are in…

> Code is read many more times than it is written

I'm really curious how true this is. Partly because, if it really was read more than it is written, people would optimize to /write less/ of it - if you have to pick up everything you put on the floor ten times over, it will incentivize you to put fewer things on the floor in future. And people would say things about code which people say about writing, such as "you have to write for your audience", instead of the more common "it's either boolean readable or unreadable".

And partly because I suspect code is /skimmed over/ more than it is read; that is, people assume what it does, glance at its shape, then if there's no surprise triggered, move on.

I would be interested to know if anyone has studied what it means for code to be read, but my suspicions are that most code which works is almost never read, and most code which is read, is read because it doesn't work and therefore it will be self-selected to be poor code in some regard.

But then, I'm not a programmer working on a large codebase. Those of you who are, how much of it have you read in enough detail that you verified how it works - and no assuming that a method does what its name implies, or assuming that if it passes tests it must work, but actually verifying by studying it that it does what it should and that you understand it?

Re: Thank You, Guido

#355

Earlier quoted context omitted.

Honestly, if you're smart, it's just really fun to make things dense and logically concise. Think of it like a minor form of code golf. My first CL at my first job out of college was writing a state machine at Google. I remember collapsing it into this dense, elegant representation by hinging on a couple of bits of state. It took me an extra half day, but I was really proud of the end result, and I remember being mil…

My best friend in college was a writer, pursuing a BA in Literature. I’ve been thinking again lately about little bits I picked up via osmosis and my own early creative writing experiences. In fact I was just noting a couple weeks ago how refactoring resembles an exploratory writing exercise. I think we need to embrace the creative writing similarities. Would we ever celebrate an author who published efficient, dense…

Readability isn't just the inverse of code golf, but that's how it's often talked about. We want a clear picture in a few well chosen words, but writing padded with low effort filler is not clear, it's a drag. Whatever the answer is, it's not "shortest code possible" but it's also not "longest code possible". Given that, it seems quite plausible that the answer is "whatever you have learned to read is readable, and what you haven't, isn't".

We have ideas of a "grade 6 reading level", do we have such a scale for code? If not, why not?

Re: Thank You, Guido

#356
post #22

I hated C++ and Matlab as an undergraduate. Hell, I hated programming as a whole - and effectively swear never to write a line of code once I was done with my BSc in Physics. Then, at work, I was introduced to Python. It was so...obvious, for lack of a better world. It was like a language I always knew that never spoke before. I'm now a software engineer, write Python almost all day, and looking back to the 18-year o…

Have you tried Ruby? It's the most "what you describe" language I've used. I don't use it because Python's more popular and I'm a slave to fashion and critical mass, but it's so much more easy and expressive than even Python's syntax. for i in 0..5 I can't believe Python didn't adopt that syntax, which comes from Bash ... I surmise it didn't because Python is actually something of the philosophical opposite of Ruby.…

There's plenty of ways to do most things in Python. That's one of its strengths as much as anything, despite what the Zen says.

Also, I hate how discussions like this seem to always turn towards small syntactic differences rather than actual differences in functionality.

Re: Thank You, Guido

#357
post #16

Did 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.

Python 2 to Python 3 breakage is the worst thing that ever happened to Python. Even simple things like retaining the print statement (which could certainly coexist peacefully with the print() function) would have made things easier. It's not too late though. We could add better backward compatibility into Python 3.

The print function replacement can be done in a few seconds using at least 3 different tools with no risk (futurize, modernize, pyupgrade). The amount of time spent talking about why it’s hard to change greatly exceeds the time required to do so.

Re: Thank You, Guido

#358
post #152
post #16

Did 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.

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'.

Then why did Dropbox shove a Python2 v Python3 commend in the middle of a "happy retirement" blog post?

No really, what was the relevance of that comment? A task from a decade ago, with maintenance reaching end of life in two months, and they're off-topic boasting about "already starting" it. What, they think it's early and applause-worthy? They're trying to show that even Guido had to deal with it? Or that even with Guido they couldn't complete it quickly? "Here are some words about Python to make the PR representative look hip and with it"?

Nothing about that interjection reflects particularly well on Dropbox - it's far off the tone of the rest of the post, they would have been better off not mentioning it at all.

Re: Thank You, Guido

#359

Earlier quoted context omitted.

One day tech historians are gonna look back at this era and shake their heads at all the time, energy, and talent being wasted by people just trying to keep up with tech trends for the sheer purpose of remaining employable.

My general rule is that I don't even think about learning a new technology until at least two years after I first heard about it. I assume that I hear about new stuff fairly early in their adoption, since I try to keep up with these things, so if it's still a thing two years later, it might have enough staying power to be worth learning. After that it still takes a while for me to get around actually learning the thi…

Do you think React can be going away any time soon?

Re: Thank You, Guido

#360
post #330

Earlier 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…

This is really interesting to me because Ruby and Python are really close to each other, yet have completely different paradigms.

The syntax, dynamic nature (lack of privates, etc) are so similar yet one is a lot more flexible (Ruby) and another is a lot more explicit (Python).

Ruby is incredibly expressive, the language puts the full power into the authors hands and let them go wild.

There always good arguments on both side of the camp, both have mature web frameworks backed by massive communities. I don't think one is inherently better than the other, it's more a matter of style/mindsets.

I personally love coding in both, in fact today I wrote some ruby code that would run some python code and do stuff with it!

Post reply on HN