8 ms·

Bruce Eckel announces he's going to write Atomic Python

75 points by h4xr 11y ago

harry8 11y ago
I find this guy pretty arrogant and a bit of a grand-stander, but maybe I get the wrong impression. He did have a good idea once, namely to release his textbooks free in the internet before that became fashionable. That is still a good idea today. The textbooks are not the best of breed by a long stretch but we shouldn't diminish the fact that he released them. If you think you can do it, do it, release it. Bask in the glory. Prediction: he can't. But good luck anyway.
- kevin_thibedeau 11y ago
  I really enjoyed his first C++ book. The only one I've seen that assumes proficiency in C and dives into the new stuff immediately. Bruce is a good writer but I think the ship has sailed on writing new Python books that can stand out from the crowd. Atomic Rust would be more commercially viable.
- speedkills 11y ago
  I thought he did a good job with atomic Scala and recommended it to a friend who wanted to see if programming might be for him. It did a really nice job of walking you through the language without assuming prior knowledge.
- Shorel 11y ago
  He only plans to write yet another book, not to fix the GIL issue, or something like that. Yes, the 'Atomic' in the title was confusing at first, having read none of this books with the 'Atomic' moniker. In fact, his C++ books are short and to the point. I don't see anything far fetched about his goals.
robmccoll 11y ago
What is simple and clear about Python? Overloading, decorators, coroutines, dynamic typing, strong reliance on exception handling for control flow, a boatload of basic types, deep class hierarchies, eval, massive standard library, schism between 2 and 3, eggs vs wheels, pip vs setup vs easy install... it's really a pretty complex language with a deep ecosystem.
- brudgers 11y ago
  The offside rule. Just like futbol's.
- jMyles 11y ago
  * Overloading: Is this a reference to default values for arguments? Or PEP 3124? If the former, then I think that this is itself a great example of simplicity and clarity in python. * Decorators: I grant that they're hard on a debugger; I wish that there were a slightly more sane way for the control flow to play out. However, syntactically they're super clear. * Coroutines: What's the problem here? I prefer Twisted's deferred model, but I have no problem with coroutines. * Dynamic typing: I mean, if this is a religious issue, then I don't want to offend, but seriously: especially for newcomers, the type system in Python is simple. And clear. * Exceptions as part of control flow: And why not? Exceptions are a part of ordinary human logic. Why do you regard them as unclear or complex? * Boatload of basic types: I can do with a few fewer exposures of "low level concepts" in types (ie, int, float, double, decimal), but it's not that bad. * Deep class hierarchies: I'm not even sure what to say to this. It seems like an objection to OOP generally. * eval: I think we all agree that eval introduces opacity and complexity, but do you prefer it be removed? * Massive standard library: Compared to other languages of a similar age, Python does an awfully good job at providing One Obvious Way to use the standard library to do what (and only what) you want. * schism between 2 and 3: Hear hear. * Eggs vs wheels: Yeah. Fuck. * pip vs setup vs easy_install: Yeah we get it. Packaging is a problem. Overall, I think Python is simple and clear. If I had to pick an objection, none of the ones you raised makes my list. I'll probably go with the syntax for the "type hints" system. And the GIL. And the varying definitions of "is" across implementations. But all in all, it's pretty darn simple and clear.
  - oburb 11y ago
    Overloading means that + does this: [1,2] + [3,4] == [1,2,3,4] and this: 1 + 2 == 3
    - progrn 11y ago
      What is the problem with that? Number + Number = number list + list = list str + str = str
mikeash 11y ago
From the title, I assumed this was going to be yet another attempt at making Python multithreaded. Apparently that's way off. What's the significance of "Atomic" in the title?
- lnanek2 11y ago
  It took me some research to figure out too. I've read Bruce's free books, but never even heard of Atomic Scala. Following the link in the article it's apparently a paid book that only has some free sample portion about the Scala language. So I guess he's going to write a book about Python now. Really obtuse blog post, honestly.
- yawaramin 11y ago
  Small chapters that cover a small amount of content each so that you feel like you're making progress through the book with a series of easy wins. The theory is you're more likely to keep going that way.
  - mikeash 11y ago
    Thanks! That makes a lot of sense.
- gaius 11y ago
  Ditto; I thought this was going to be about STM. Also someone who has not looked at C++ since 98 is doing themselves a disservice; C++14 is a radically different thing.
criddell 11y ago
The most interesting thing in this article was his mention of Elm: elm-lang.org I'd never heard of it before but it looks pretty cool.
stretchwithme 11y ago
Always found his writing pretty accessible.
fineline 11y ago
I've admired Bruce's work since Thinking in Java. I've also enjoyed a merry-go-round of languages in my own career. I too was interested in Scala and read Odersky's book - and improved a lot as a programmer because of it, despite not using Scala for any "real" project. I can't say I've ever found Python that compelling. Rust and Go don't do much for me. The 2 languages I'm excited about right now are Elm and Nim. Nim empowers the programmer to do just about anything, use GC or switch to manual MM, target any computing platform that supports C (i.e. everything), reinvent the language with macros, while packaging it up very elegantly indeed. Elm promises almost the exact opposite. I mean it's elegant, but it's also limited - purely functional, immutable, no nulls, no unchecked list access. And that's the kind of limitation that addresses the problem that Bruce has with other languages - dealing with all the complexity of how something's working. The promise of Elm is that if your code compiles, it works, leaving you to focus on getting the important stuff right - information flow and business logic - instead of tracking down another silly invalidity that never should have made it to runtime. They're both young, but I wish Andreas Rumpf (Nim) and Evan Czaplicki (Elm) and their teams all the best in taking on the "big boys" with these plucky languages, and would encourage Bruce Eckel to consider skipping ahead of the curve and writing for these alternatives.
- _pmf_ 11y ago
  > Rust and Go don't do much for me Go is useless, but Rust and Nim have much in common (easy integration with native toolchains, stdlib-less bare-bones development for embedded systems); why did you decide that Rust is not for you?
  - fineline 11y ago
    I guess the profusion of pointer types was one thing, and the syntax, while not a showstopper, didn't really "speak" to me the way Nim did. But I cut my teeth on UCSD Pascal (after Apple BASIC), that might have something to do with it...
    - kibwen 11y ago
      I'm curious when you last looked at Rust, because in the past year the built-in ~T and @T pointers were all removed. Nowadays there are just references and raw pointers (and the latter are primarily just for FFI).
BogusIKnow 11y ago
Following Bruce the last 15 years or so. He hypes a language and makes money. He bashes that language and makes money. He hypes a language and makes money. ...
- fsloth 11y ago
  Sounds like an evolution of the general community view of a new language :) If we take the systems design view that new languages rise as solutions to existing problems, initially they are greeted as making thing X easier. But, since they work differently in places than previous language, they expose new emergent dynamics of software development, some of which will be pathological. Once the strengths of the language are understood, improving on the usage of that language is then based on understanding the systemic pathologies that language induces and how to work around them.
wpietri 11y ago
How do folks with Scala experience react to his thoughts on Scala and its cliffs? I've only built some modest stuff in it and I've certainly felt that way, but I put that down to inexperience. But if he's done 2 years of work in Scala and has written a book on it, it sounds like experience won't help me as much as I hoped.
- bjwbell 11y ago
  Going by Paul Phillips's (largest contributor to the scala compiler) YouTube rant, https://m.youtube.com/?#/watch?v=4jh94gowim0 https://m.youtube.com/?#/watch?v=4jh94gowim0, nobody ever gets over the cliffs. His rant is great, for more than just scala.
  - wpietri 11y ago
    Wow. Just starting to watch, but my first thought is: thank goodness he got to give this talk when he did; otherwise he might have exploded. The link that works for me on a desktop browser: https://www.youtube.com/watch?v=4jh94gowim0 https://www.youtube.com/watch?v=4jh94gowim0
    - wpietri 11y ago
      And here are the slides: http://www.slideshare.net/extempore/a-scala-corrections-library http://www.slideshare.net/extempore/a-scala-corrections-libr... Wow, this is a brutal talk.
  - insulanian 11y ago
    I remember I couldn't finish watching that video, not because of the content, but due to the way he was presenting it. It was just too disturbing to watch... Don't do that guys...
    - wpietri 11y ago
      Yeah, his emotions were so intense for him that it was hard to watch. I definitely get it; if you're going to spend 80-hour weeks for 5 years on something mainly because you like it, you have to be pretty intense. But it's a double-edged sword; now his grief and loss and sense of betrayal are very intense too. It was very raw. In case others are curious as to content: For me the major takeaway was that the person who has written more core Scala code than anybody thinks that the collections and probably the whole language is irredeemably fucked. He had example after example where if you do a reasonable action in 2 different ways, you get 2 different results, and that it was impossible to know why without an incredibly deep understanding of the implementation details. This makes me sad, as I really like a fair bit of what Scala does. But the video makes a persuasive case that Odersky, et al, bit off more than could be chewed, throwing in too many interesting ideas without really thinking through what happens when those ideas intersect and combine.
insulanian 11y ago
He should have take a look at F# or OCaml. After reading his post it felt like that would be the best fit for his description of the language.
alblue 11y ago
Suggest adding "book" to the end of the HN subject, to clarify what he is writing
dkarapetyan 11y ago
I don't really understand why people think Python is a simple language. It's not. It draws too many distinctions that shouldn't exist. Functions, decorators, descriptors, classes, meta-classes, generators, iterators, properties, static methods, class methods, multiple inheritance, and probably a few more things I'm forgetting. Ruby on the other hand is simple. There are objects and there are messages, that's it.
- _pmf_ 11y ago
  I agree. Python is much more complex that Java (even Java 8), and as an additional twist, everything bites you at runtime.

75 points by h4xr 11y ago

I find this guy pretty arrogant and a bit of a grand-stander, but maybe I get the wrong impression. He did have a good idea once, namely to release his textbooks free in the internet before that became fashionable. That is still a good idea today. The textbooks are not the best of breed by a long stretch but we shouldn't diminish the fact that he released them. If you think you can do it, do it, release it. Bask in the glory. Prediction: he can't. But good luck anyway.

kevin_thibedeau 11y ago
I really enjoyed his first C++ book. The only one I've seen that assumes proficiency in C and dives into the new stuff immediately. Bruce is a good writer but I think the ship has sailed on writing new Python books that can stand out from the crowd. Atomic Rust would be more commercially viable.
speedkills 11y ago
I thought he did a good job with atomic Scala and recommended it to a friend who wanted to see if programming might be for him. It did a really nice job of walking you through the language without assuming prior knowledge.
Shorel 11y ago
He only plans to write yet another book, not to fix the GIL issue, or something like that. Yes, the 'Atomic' in the title was confusing at first, having read none of this books with the 'Atomic' moniker. In fact, his C++ books are short and to the point. I don't see anything far fetched about his goals.

robmccoll 11y ago

What is simple and clear about Python? Overloading, decorators, coroutines, dynamic typing, strong reliance on exception handling for control flow, a boatload of basic types, deep class hierarchies, eval, massive standard library, schism between 2 and 3, eggs vs wheels, pip vs setup vs easy install... it's really a pretty complex language with a deep ecosystem.

brudgers 11y ago
The offside rule. Just like futbol's.
jMyles 11y ago
* Overloading: Is this a reference to default values for arguments? Or PEP 3124? If the former, then I think that this is itself a great example of simplicity and clarity in python. * Decorators: I grant that they're hard on a debugger; I wish that there were a slightly more sane way for the control flow to play out. However, syntactically they're super clear. * Coroutines: What's the problem here? I prefer Twisted's deferred model, but I have no problem with coroutines. * Dynamic typing: I mean, if this is a religious issue, then I don't want to offend, but seriously: especially for newcomers, the type system in Python is simple. And clear. * Exceptions as part of control flow: And why not? Exceptions are a part of ordinary human logic. Why do you regard them as unclear or complex? * Boatload of basic types: I can do with a few fewer exposures of "low level concepts" in types (ie, int, float, double, decimal), but it's not that bad. * Deep class hierarchies: I'm not even sure what to say to this. It seems like an objection to OOP generally. * eval: I think we all agree that eval introduces opacity and complexity, but do you prefer it be removed? * Massive standard library: Compared to other languages of a similar age, Python does an awfully good job at providing One Obvious Way to use the standard library to do what (and only what) you want. * schism between 2 and 3: Hear hear. * Eggs vs wheels: Yeah. Fuck. * pip vs setup vs easy_install: Yeah we get it. Packaging is a problem. Overall, I think Python is simple and clear. If I had to pick an objection, none of the ones you raised makes my list. I'll probably go with the syntax for the "type hints" system. And the GIL. And the varying definitions of "is" across implementations. But all in all, it's pretty darn simple and clear.
- oburb 11y ago
  Overloading means that + does this: [1,2] + [3,4] == [1,2,3,4] and this: 1 + 2 == 3
  - progrn 11y ago
    What is the problem with that? Number + Number = number list + list = list str + str = str

mikeash 11y ago

From the title, I assumed this was going to be yet another attempt at making Python multithreaded. Apparently that's way off. What's the significance of "Atomic" in the title?

lnanek2 11y ago
It took me some research to figure out too. I've read Bruce's free books, but never even heard of Atomic Scala. Following the link in the article it's apparently a paid book that only has some free sample portion about the Scala language. So I guess he's going to write a book about Python now. Really obtuse blog post, honestly.
yawaramin 11y ago
Small chapters that cover a small amount of content each so that you feel like you're making progress through the book with a series of easy wins. The theory is you're more likely to keep going that way.
- mikeash 11y ago
  Thanks! That makes a lot of sense.
gaius 11y ago
Ditto; I thought this was going to be about STM. Also someone who has not looked at C++ since 98 is doing themselves a disservice; C++14 is a radically different thing.

criddell 11y ago

The most interesting thing in this article was his mention of Elm: elm-lang.org I'd never heard of it before but it looks pretty cool.

stretchwithme 11y ago

Always found his writing pretty accessible.

fineline 11y ago

I've admired Bruce's work since Thinking in Java. I've also enjoyed a merry-go-round of languages in my own career. I too was interested in Scala and read Odersky's book - and improved a lot as a programmer because of it, despite not using Scala for any "real" project. I can't say I've ever found Python that compelling. Rust and Go don't do much for me. The 2 languages I'm excited about right now are Elm and Nim. Nim empowers the programmer to do just about anything, use GC or switch to manual MM, target any computing platform that supports C (i.e. everything), reinvent the language with macros, while packaging it up very elegantly indeed. Elm promises almost the exact opposite. I mean it's elegant, but it's also limited - purely functional, immutable, no nulls, no unchecked list access. And that's the kind of limitation that addresses the problem that Bruce has with other languages - dealing with all the complexity of how something's working. The promise of Elm is that if your code compiles, it works, leaving you to focus on getting the important stuff right - information flow and business logic - instead of tracking down another silly invalidity that never should have made it to runtime. They're both young, but I wish Andreas Rumpf (Nim) and Evan Czaplicki (Elm) and their teams all the best in taking on the "big boys" with these plucky languages, and would encourage Bruce Eckel to consider skipping ahead of the curve and writing for these alternatives.

_pmf_ 11y ago
> Rust and Go don't do much for me Go is useless, but Rust and Nim have much in common (easy integration with native toolchains, stdlib-less bare-bones development for embedded systems); why did you decide that Rust is not for you?
- fineline 11y ago
  I guess the profusion of pointer types was one thing, and the syntax, while not a showstopper, didn't really "speak" to me the way Nim did. But I cut my teeth on UCSD Pascal (after Apple BASIC), that might have something to do with it...
  - kibwen 11y ago
    I'm curious when you last looked at Rust, because in the past year the built-in ~T and @T pointers were all removed. Nowadays there are just references and raw pointers (and the latter are primarily just for FFI).

BogusIKnow 11y ago

Following Bruce the last 15 years or so. He hypes a language and makes money. He bashes that language and makes money. He hypes a language and makes money. ...

fsloth 11y ago
Sounds like an evolution of the general community view of a new language :) If we take the systems design view that new languages rise as solutions to existing problems, initially they are greeted as making thing X easier. But, since they work differently in places than previous language, they expose new emergent dynamics of software development, some of which will be pathological. Once the strengths of the language are understood, improving on the usage of that language is then based on understanding the systemic pathologies that language induces and how to work around them.

wpietri 11y ago

How do folks with Scala experience react to his thoughts on Scala and its cliffs? I've only built some modest stuff in it and I've certainly felt that way, but I put that down to inexperience. But if he's done 2 years of work in Scala and has written a book on it, it sounds like experience won't help me as much as I hoped.

bjwbell 11y ago
Going by Paul Phillips's (largest contributor to the scala compiler) YouTube rant, https://m.youtube.com/?#/watch?v=4jh94gowim0 https://m.youtube.com/?#/watch?v=4jh94gowim0, nobody ever gets over the cliffs. His rant is great, for more than just scala.
- wpietri 11y ago
  Wow. Just starting to watch, but my first thought is: thank goodness he got to give this talk when he did; otherwise he might have exploded. The link that works for me on a desktop browser: https://www.youtube.com/watch?v=4jh94gowim0 https://www.youtube.com/watch?v=4jh94gowim0
  - wpietri 11y ago
    And here are the slides: http://www.slideshare.net/extempore/a-scala-corrections-library http://www.slideshare.net/extempore/a-scala-corrections-libr... Wow, this is a brutal talk.
- insulanian 11y ago
  I remember I couldn't finish watching that video, not because of the content, but due to the way he was presenting it. It was just too disturbing to watch... Don't do that guys...
  - wpietri 11y ago
    Yeah, his emotions were so intense for him that it was hard to watch. I definitely get it; if you're going to spend 80-hour weeks for 5 years on something mainly because you like it, you have to be pretty intense. But it's a double-edged sword; now his grief and loss and sense of betrayal are very intense too. It was very raw. In case others are curious as to content: For me the major takeaway was that the person who has written more core Scala code than anybody thinks that the collections and probably the whole language is irredeemably fucked. He had example after example where if you do a reasonable action in 2 different ways, you get 2 different results, and that it was impossible to know why without an incredibly deep understanding of the implementation details. This makes me sad, as I really like a fair bit of what Scala does. But the video makes a persuasive case that Odersky, et al, bit off more than could be chewed, throwing in too many interesting ideas without really thinking through what happens when those ideas intersect and combine.

insulanian 11y ago

He should have take a look at F# or OCaml. After reading his post it felt like that would be the best fit for his description of the language.

alblue 11y ago

Suggest adding "book" to the end of the HN subject, to clarify what he is writing

dkarapetyan 11y ago

I don't really understand why people think Python is a simple language. It's not. It draws too many distinctions that shouldn't exist. Functions, decorators, descriptors, classes, meta-classes, generators, iterators, properties, static methods, class methods, multiple inheritance, and probably a few more things I'm forgetting. Ruby on the other hand is simple. There are objects and there are messages, that's it.

_pmf_ 11y ago
I agree. Python is much more complex that Java (even Java 8), and as an additional twist, everything bites you at runtime.