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

I'm skeptical for the simple reason that this post never calls out any specific feature of Lisp or Smalltalk which could cause this problem, and other languages which apparently don't suffer from these problems have most of the same features. It's almost as if unpopularity is the root cause.

Guy Steele famously said that with Java they "managed to drag a lot of [C++ programmers] about halfway to Lisp". I don't hear many complaints about Java being too 'organic' or difficult to document or that it only works on 2-pizza teams.

If you think that sufficiently powerful languages only work on small teams of dedicated people, why draw the line at Lisp/Smalltalk? Why aren't the Ada people going crazy about how loose and dynamic Java is, much less Python and Ruby -- all of which apparently "breeze through the 100, 200, 500 developer marks without much trouble"?

I remember reading about how Codd's relational databases struggled with acceptance because it was believed at the time that 'tables' were too complex for the average programmer, yet today that idea is laughable. People tend to rise to the level of expectation.




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


> It's almost as if unpopularity is the root cause.

It kind of is. What determines which things people are excited to learn? What determines which things people will feel safe doing? What determines which things get you in, and which get you sidelined?

Creating knowledge that can be used in practice in a non-enclave environment, and creating common knowledge, overlap a lot. “Make this maintainable” = “Make this something people can adequately be assumed to know how to maintain” = “Don't do anything weird”—thus the focus on keeping code idiomatic. So it's not really about absolute power; it's about relative power. If you can establish a cultural boundary, and then set up a pipeline of enough people dealing with a higher-power language, it seems possible to make that work, but that's a social undertaking that easily falls apart to things like “people will call you elitist for separating yourself and doing anything that might imply the others are inferior” (this visibly happens to Lispers) and “your code gains more from talking to other code easily than it does from being powerful in itself, so you need a lot of knowledge surface area, where people who use your environment are widely distributed in what else they know”. Notably, though, enclaves of Lisp and OCaml do exist in industry where there's some amount of big projects that have a limited surface area and they can make use of the higher power. I've heard similarly for Haskell. And academia seems to practically be a supercluster for higher-power language use.

I get the impression that one of the big ways Java and C#¹ are gradually steering the big ships into higher-power water is by having backing organizations who can introduce a new “fancy” feature, document it extensively, watch how the great masses of programmers in that language actually use it, push for them to learn it, and then wait before adding the next feature, so that the delta between highest and lowest power feels more socially safe; no one is ever far enough from the crowd to become a problem, but the rallying banner can still move it gradually. The slowness is widely detested among programmers who want to jump to the higher power level now and know that there isn't necessarily a technical reason not to, but it's a feature for social cohesion. It also provides a convenient binding for transmitting this information for teamwork purposes: “we're using Java 8” implies a whole set of things about expectations in a way that “we're using Common Lisp” by itself doesn't.

¹ Apparently I can't write the sharp sign here.


While NoSQL databases don't owe all their popularity to a common developer aversion towards thinking in tables/relations, there's some portion of enthusiasm that was generated pretty much on that basis.


> I'm skeptical for the simple reason that this post never calls out any specific feature of Lisp or Smalltalk which could cause this problem

How about the fact that Smalltalk at scale involves custom version control systems? I'm haven't used Smalltalk seriously, but that feature gap alone could keep Smalltalk projects and teams small.

https://news.ycombinator.com/item?id=2031536


Hmm, it's true that one common feature of both of these languages is that they traditionally use process images. That's not required, though, and every Lisp program over 100 lines I've seen written in the past 25 years has used a normal text-based version control system.

Also, while bypassing version control and doing everything in-process can be a great productivity boon for a single programmer, even a team of 2 has outgrown that. This wouldn't explain why (he thinks) these languages work for small teams but not larger teams.


Pharo uses Git




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

Search: