

Bruce Eckel announces he's going to write Atomic Python - h4xr
http://bruceeckel.github.io/2015/08/29/what-i-do/

======
fineline
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.

~~~
dom96
> 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.

This is a very brilliant way to describe exactly what makes Nim excellent. I
hope you don't mind if I quote you on this :)

~~~
fineline
You're very welcome.

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

~~~
jMyles
* 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
Overloading means that + does this: [1,2] + [3,4] == [1,2,3,4] and this: 1 + 2
== 3

~~~
progrn
What is the problem with that? Number + Number = number list + list = list str
+ str = str

~~~
vessenes
It's a bit of cognitive load. It's not clear whether or not [1,2] + [3,4]
should equal [1,2,3,4] or [4,6].

Keeping track of that, (oh wait, this is a numpy array, not a python list...)
and things like that expand the amount of the language that a programmer must
keep in her head at any one time, and are the definition of complexity.

There's no known silver bullet for the complexity / power tradeoff, which is
why we get so many cool languages!

~~~
wpietri
Is there some language where [4,6] is the output? That strikes me as serving
some use case that I've never come across. Whereas having two lists and
wanting to end up with one list with all the elements is a very common need.

~~~
gknoy
I believe it would be in Matlab, as [1, 2] + [3, 4] would be considered matrix
addition, in which one adds elements in corresponding places. Numpy (as
mentioned in the GP) probably does similar.

~~~
wpietri
Ah, ok, thanks. Right, matrix math is is the use case I was looking for.

------
mikeash
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?

~~~
yawaramin
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
Thanks! That makes a lot of sense.

------
dkarapetyan
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_
I agree. Python is much more complex that Java (even Java 8), and as an
additional twist, everything bites you at runtime.

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

------
wpietri
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
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
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
And here are the slides: [http://www.slideshare.net/extempore/a-scala-
corrections-libr...](http://www.slideshare.net/extempore/a-scala-corrections-
library)

Wow, this is a brutal talk.

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

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

------
stretchwithme
Always found his writing pretty accessible.

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

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

