Hacker News new | past | comments | ask | show | jobs | submit login

>other languages which apparently don't suffer from these problems have most of the same features

Well, one of the very first differences I think of between Lisp/smalltalk and Java is dynamic vs static typing. In Java, you have to write extra boilerplate code to satisfy the type system. This slows you down when you're writing code. However, when you're figuring out someone else's code, static types can be a big help. Often times, you can guess the right way to call a method based solely off the signature, and if pass the wrong thing, your IDE can highlight your mistake almost instantly.

So when you're working on your own freshly written code here and now, static typing is usually a hindrance. When you're working on 3 year old undocumented code written by someone you've never met, static typing is a key source of information on how things work. The bigger the team/project, the more likely it is you're working on code that's not familiar, so it would follow that static typing helps scalability.

I've started using type hints with python and they are amazing, not just for historic code, but improving my productivity in real time (especially in conjunction with an IDE). I think what's great is when you use hints, you get benefits in linting, but you can also get away from it when you need to. With mandatory types, you are always having to work in the type system. Best of both worlds. But not everyone is as excited about or as thoughough with them as I am.

I find type hinting to be very useful, but it has some gotchas (also present in unhinted Python), where the type you get isn't the type you expect:

- Int and float from numpy arrays are np.int/float32/64. And round(np.floatXX) returns a float, but round(float) returns an int in Python 3. - ruamel.yaml loads CommentedMap and some custom scalar types. CommentedMap is not a subclass of dict.

> Well, one of the very first differences I think of between Lisp/smalltalk and Java is dynamic vs static typing.

That's true, but that's not what the article is about. He specifically calls out PHP, Python, and Ruby as examples of languages which do scale well to larger teams.

It seems that there's something else in the space between Ruby and Smalltalk that he thinks is responsible for a language being able to scale or not. I just can't figure out what it is.

I remember that many years ago somebody told me (or did I read it?) that he expected Smalltalk to eventually succeed but he didn't expect that it would be called Ruby.

My guess: maybe a Smalltalkish language in a conventional environment? Don't underestimate the power of being close to what the average programmer used to experience in the years before a new language is released.

Python is from the end of the 80s and its classes look like OO in C (without ++, I mean the explicit self), plus functional methods (len, etc). Ruby and Java are from the middle 90s and take that for granted and hide self and go all in with method calls. They take small steps and adopt a syntax similar to other existing languages. Too much change and developers won't follow en masse.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact