3 ms·

>(But like I said I'm still skeptical that you could write Eclipse in Ruby.) Why would anyone ever want to write Eclipse in Ruby? I have no doubt that such a f

• api 14y ago
  Eclipse was just an example. There is going to be a niche for massive projects. There's also going to be a niche for projects that live for a very, very long time and thus are touched by a massive number of programmers... which presents many of the same problems as a massive project. Code reuse is also problematic without structure. C++ has this problem to some extent, which is why the C++ library ecosystem is so fragmented. I typically avoid using most C++ libraries, preferring C++ as high-level glue with C underneath. STL is used because it's standardized, and maybe boost, but that's it. Every C++ library has a different style, so if you use them your code ends up looking like crap... mixed metaphors everywhere. C++ isn't powerful in the same way as LISP, but it is pretty darn powerful in its own way. It lets you do things umpty-different ways, which is bad sometimes. Common styles and idioms are very useful when you want to connect things to each other. Ruby and NodeJS have solved this problem by having a certain amount of community standardization around idioms-- convention over configuration basically. (Or in this case convention over language restriction.) Perhaps that's one thing that could help LISP-- an attitude of "yeah, you can do it that way, but that's not standard so nobody will use your code if you do." I know it would really help the C++ ecosystem.
  • kyllo 14y ago
    Eclipse was just an example. There is going to be a niche for massive projects. That niche and Java deserve each other. There's also going to be a niche for projects that live for a very, very long time and thus are touched by a massive number of programmers There's some overlap, but more than anything, this niche is just the one that really needs a solid unit test suite and documentation. There are excellent unit test framework packages for Ruby, and high unit test coverage is very much a part of Ruby programming culture. The documentation quality for open source Ruby projects also seems very high overall. Community style/idiom standardization in Ruby and Node is probably a function of having a constellation of very active, popular, and often interdependent open source projects in each. When you're writing Rails gems that depend on other Rails gems, everyone is reading everyone's code, so agreeing on some style guidelines as a community makes everyone's life much easier. I think that if someone wrote a very popular open source project (analogous to Rails) in a Lisp dialect, we might see the same thing start to evolve. And I think we're already starting to see it happening with Clojure. There's a Clojure Style Guide that's gone up on Github very recently: https://github.com/bbatsov/clojure-style-guide https://github.com/bbatsov/clojure-style-guide