11 ms·

Ruby Is Defined by Terrible Tools

115 points by davidcelis 11y ago

kazinator 11y ago
> And yet, in the early 2000s, long before Rails drove throngs of people to learn Ruby, very smart people who knew about Lisp and Haskell and good tooling, fell in love with Ruby. People like Dave Thomas and Martin Fowler and Jim Weirich. This is probably because very smart people don't need tools, so they can let themselves fall for the appearance of raw textbook examples of the source code. Very smart people probably have written programs in low-level languages and gotten them right with only the help of print traces, and raw stack/register dumps.
- TodPunk 11y ago
  Print traces and dumps were the only tools had for a long time, and quite frankly there are a lot of areas in programming where this is still the case (lots of embedded programming, for instance, and it's not likely you'll get a print from that either). Tools are nice, this isn't an old-man shaking his fist at the wind moment. It's more important to note that not all tools are software. Some tools are mental-based. We have to force ourselves to build those tools over time.
- marssaxman 11y ago
  I have no idea whether it correlates with "very smart" in any particular way, and suspect that it probably doesn't, but I have definitely observed significant differences in preference when it comes to the use of extralinguistic tools. It's easy to see how there are some people better suited to early adoption of new languages than others, because they are comfortable with and may actually prefer a minimal-tooling environment, while others will find it so unbearably primitive that they won't be able to get anything done. I've had coworkers who believed anything that can be automated should be, and therefore one should learn and use all available tools. In this view, anyone failing to take advantage of all possible automation is wasting their time on grunt work and therefore being less productive than they could. One guy at my last job was notorious for his incredibly long and frequently misspelled identifiers; I could not understand how he was failing to notice these problems until I realized that he literally never typed out a full identifier more than once, and typically generated as many bytes of source code via intellisense as he did by typing. I am out on the opposite end of the spectrum; when I'm coding I don't want to think about tools at all, and a tool had better be absolutely spot-on perfect or its rough edges will waste more of my time by distracting and irritating me than its features will save by automating something I would otherwise have had to do with my brain. I sometimes use IDEs depending on the project, but I always disable code indexing / completion, because the little timing hiccups you get as the tool does its thing break my flow and irritate me. Instead, I put more time into making consistent names and simple APIs so there is less to remember, and do a bit of extra grepping when I can't recall what I need. For me this feels easy and natural; for other people it seems like going the hard way, and they don't understand why I won't let the machine help. These differences extend all up and down the tool chain; some people love their sophisticated debuggers and write all kinds of complex scripts that produce interesting results, while I tend to just throw in a lot of printfs and debug by reading logs. Not to say I won't use a debugger when it's available - just that I know the log approach will always work, and it can be less work to fall back on something simple that I don't have to think about rather than taking the time to remember where all the debugger's knobs and switches are. On the flip side, I will make heavy use of all available language tools for abstraction and code simplification - lambdas, namespaces, interfaces, whatever's handy, my goal is to build every interface, no matter how minor or internal, in such a way that it's difficult to use it improperly. This has irritated people I've worked with who are happy with simple boilerplate because they rely on automated refactoring tools; to them, these esoteric abstractions were aggravating because it left them struggling to see the forest for all the unfamiliar trees. Some of this may be a function of experience, particularly experience with low-level environments. I've written plenty of debugging, logging, grepping, and reporting tools over the years, so I know I can always just bang together what I need in the moment, and the prospective payback from learning some existing do-it-all tool feels correspondingly reduced. But is this a smarts thing? I am not so sure - I mean, I do think I'm pretty smart, but it could just be preference; I really like digging into the foundations of things and have therefore invested a lot of time learning how to work in those environments. Someone who actually prefers to live at a higher abstraction level might well be wasting their time by thinking about this sort of thing, and while that's not my bag I certainly wouldn't argue that high-level work is unnecessary or of lesser importance. Some of it may also be a function of age. I've seen so many tools come and go that it has come to feel like a waste of time to learn one deeply until it has become stable and ubiquitous enough that I can reasonably expect the time I invest in it to pay back over at least 5-10 more years. If it doesn't meet that threshold then why bother? There will just be something else coming along later. I'll learn it if I need to use it, but because of the above-described confidence that I can get the job done regardless of tooling, I'm less likely to hit the bar for "need to use it". The weakness of the heavy-tooling approach is that tools always have flaws and blind spots, and one can get stuck thinking through the tool's mindset and have trouble when there's a problem it doesn't solve particularly well. But the weakness of the light-tooling approach is that tools shape mental models, and mental models shape language, and software development is really more about communication between humans than it is about communication with machines; if you don't adopt the mental frameworks your coworkers are using it may be more difficult to interact with the systems they are building. (also, a moment of brag: one of my proudest debugging feats was when I wrote a bootloader for a brand new embedded architecture using no feedback but a single blinking LED. There was no stack trace, not even a serial line for a printf log, because none of the drivers had loaded yet.)
  - realharo 11y ago
    Regarding misspelled identifiers, I've experienced the exact opposite problem. Code I had to work with that was clearly written in simple editors often contained misspelled words (though it was also usually written by non-native English speakers) and even bugs arising from using a wrong variable name. Errors that with proper tooling would be near impossible to make, because the tool would immediately underline the variable as either containing a spelling error or not being defined. Not to mention it also lead people to using generic non-descriptive variable names and abbreviations. I also watched some people trying to printf-debug a problem, and it's usually a fest of "Was the problem here? Hm, not here, ok, let's put these statements over there. Hm, not over there either, what about here... (repeat several more times, depending on how deep the calls go)" Having to do something like this would really feel like stone age to me, when you could just get all the relevant information in one quick pass without having to modify any code. Another thing is documentation. When you know that you can just bring up a method's documentation with a single keystroke, you are much more motivated to document your own methods in the same way. If it's just "some generator will create a bunch of static html pages later on that most people likely won't ever read", some people will not bother. I do agree about flaws in tools being a huge issue though. Especially with refactoring tools, if you can't trust it to not accidentally mess up parts of your code, you might as well not use it at all. Similarly, if you can't trust a "find usages of this method" to find ALL of its usages, the utility diminishes severely. EDIT: oh, and perhaps the most simple, but most important feature of all, being able to Ctrl+click a function to navigate to its definition means that people are going to dive into the code a lot more often, even framework/library code, which is obviously beneficial to learning how things work under the hood. The less friction there is to doing something, the more readily people are going to do it.
    - MrBra 11y ago
      TL;DR?
    - MrBra 11y ago
      Why my request for a TL;DR got downvoted? I thought, if you had that much to say, it could be am interesting opinion, but I didn't have enough time to go through it all.
- catnaroek 11y ago
  "Very smart" probably means different things to different people, but, for me, it means proactive laziness: the ability to foresee anything that might create repetitive work in the future, and work now to prevent that from happening. So I can't regard a programmer as being "very smart" if he or she doesn't have the ability to abstract over every recurring pattern in his code, and turn it into a nice reusable library. And I also can't regard a programmer as being "very smart" if he or she designs abstractions that leak: in my experience, abstraction leaks create more work than anything else.
matthewmacleod 11y ago
Hmm, I'm not so sure about this. Ruby's tooling is obviously not as advanced as a language like Java, for many reasons. But terrible isn't the adjective I'd use. It's pretty easy to use editor integration to provide pretty decent automatic formatting, linting and code completion. Pry-debugger is pretty great, and generally I don't find working in Ruby to be markedly more taxing that other languages. I guess YMMV, though.
- braythwayt 11y ago
  > automatic formatting, linting and code completion You are describing tooling that is used to write code, but not to read or debug it. And Ruby is exceptionally easy to write without any tooling whatsoever. The hard problem with dynamic languages is reading the code and understanding what it is doing at run time. And that is where TFA suggests Ruby is terrible.
  - davorb 11y ago
    I used to think that it was fine, but then I started working with LISP and SLIME, and the difference between that and what's available in the Ruby-world is striking.
  - x0x0 11y ago
    For a short while, I thought about taking a stab at building the above. The thing that stopped me is I couldn't figure out how to get paid, and I'm not independently wealthy.
  - Gibbon1 11y ago
    One the way to reading about something else, I read an essay by a language developer complaining about type erasure. In functional languages. In short, when you get to the point in implementing a language where you can do type erasure, you're golden because it usually means you have things nailed down. Unfortunately then people actually implement type erasure and now there is no way to link data structures in memory with a piece of code at run time. Or at least very easily. As an example C/C++ does erase type information. There often being nothing that tells you what an object in memory is. But compilers take great pains to preserve that information in the generated output formats. Which allow you to write debuggers. I'm sure languages like Java and .net do the same.
braythwayt 11y ago
> People in the industry are very excited about various ideas that nominally help you deal with > large code bases, such as IDEs that can manipulate code as "algebraic structures", and search > indexes, and so on. These people tend to view code bases much the way construction workers view > dirt: they want great big machines that can move the dirt this way and that. There's > conservation of dirt at work: you can't compress dirt, not much, so their solution set consists > of various ways of shoveling the dirt around. There are even programming interview questions, > surely metaphorical, about how you might go about moving an entire mountain of dirt, one truck > at a time. > Industry programmers are excited about solutions to a big non-problem. It's just a mountain of > dirt, and you just need big tools to move it around. The tools are exciting but the dirt is not. > My minority opinion is that a mountain of code is the worst thing that can befall a person, a > team, a company. I believe that code weight wrecks projects and companies, that it forces > rewrites after a certain size, and that smart teams will do everything in their power to keep > their code base from becoming a mountain. Tools or no tools. That's what I believe. —Steve Yegge, "Code's Worst Enemy" http://steve-yegge.blogspot.ca/2007/12/codes-worst-enemy.html http://steve-yegge.blogspot.ca/2007/12/codes-worst-enemy.htm... I'm not quoting this to refute the idea that Ruby has terrible tooling, or to suggest that tooling doesn't matter. But rather, to give some context for this idea: When we first embraced Ruby, we were writing web apps in Java. Ruby allowed us to write those same apps with fewer lines of code, by fewer people, in less time. That was a triple-win, and there were all sorts of secondary positive effects. Fewer people on a team means less necessary process. It means less money required. YCombinator wouldn't exist today if you couldn't have done something meaningful with $18,000 over a few months. Less time means you can be lean and iterate, rather than spending time and tons of money trying to analyze what a market wants in advance. Those factors were massive wins for the startup culture. There are similar effects within companies, but I needn't list them out here. But one negative effect is that with small teams writing fewer lines of code, in a startup culture, there is much less emphasis on tooling. It's a "nice-to-have," because app complexity does not make the difference between shipping and not shipping. So yeah, there's some tooling, but it is not very good. Really, it's not. But it was good enough. But as time went on, our apps and teams grew. Most businesses are in a Red Queen's Race against their competition. It is very hard to stay small and focused and have a single responsibility in a market. So our code grows and grows, until it reaches a kind of equilibrium with how many lines of code a company can support. Which means we expand until we're back to having big code bases, with many engineers. And guess what? One million lines of Java is easier to understand than one million lines of Ruby. Doubly so when you have better Java tooling than Ruby tooling, and when Ruby does things that demand better tooling. So now we're in this place where successful companies have big apps, but we don't have a "big app" culture, so we don't have the tooling required to support this many lines of Java, much less this many lines of Ruby. --- p.s. Here's a very nice person saying the same thing at WebRebels: http://vimeo.com/76141334 http://vimeo.com/76141334
davexunit 11y ago
I write both Ruby and Lisp frequently, and I must agree that Lisp tools are vastly superior. Ruby, despite being a dynamic language, has a sorry excuse for a REPL which really hampers my workflow. For example, Rails watches your Ruby files for changes and reloads them in development mode, but if it was easy to re-evaluate arbitrary expressions from your editor (a la SLIME or Geiser) such a feature would never be needed. Then, of course, there's typically so much magic happening that it's often impossible to find the place in which a symbol was defined by searching for that symbol, which makes debugging overly difficult.
- cpitt 11y ago
  When you say "sorry excuse for a REPL", you are referring to the built in repl and not pry (http://pryrepl.org/ http://pryrepl.org/), right? because pry is freaking awsome!
  - davexunit 11y ago
    The same issue is there. This is a language issue. I want to edit a file and re-evaluate arbitrary expressions with a keystroke. Writing the code and then copy/pasting it into a REPL prompt is not sufficient. Lisp programmers have had excellent live coding environments for a very long time, but with Ruby I must make do with Rails auto-reloading files for me.
    - JoelMcCracken 11y ago
      Not sure if you're aware, but things like this can be done with Emacs. It really isn't that simple, though, and I've only used it for the most trivial of situations.
    - vidarh 11y ago
      > I want to edit a file and re-evaluate arbitrary expressions with a keystroke. Writing the code and then copy/pasting it into a REPL prompt is not sufficient. This suggests to me you've not spent much time with Pry. Are you aware of this: https://github.com/pry/pry/wiki/Editor-integration https://github.com/pry/pry/wiki/Editor-integration It's not perfect - doing it perfect with Ruby is a hard problem, as a method can have been defined and redefined in multiple places. But it works very well.
bascule 11y ago
This is one of the things I've always liked about JRuby. You can use the excellent tooling of the JVM ecosystem (e.g. YourKit, Coverity Dynamic Analyzer) to understand the behavior of your JRuby applications, and even attach directly to running production apps to debug them. I've found tools like this essential for debugging multithreaded JRuby applications, and there's simply nothing else like them available for MRI.
rquantz 11y ago
So what's a language that has much better tooling than ruby, but still has a web stack as good as Rails? Does one exist?
- lelandbatey 11y ago
  Some people would say "Python", since the tooling for Python is generally excellent, but I don't have enough experience with Python web stacks to say that they're better or worse than Rails. There's certainly less "magic" with Python, but I'd argue that's a good thing.
  - mtarnovan 11y ago
    I think all the criticism from that article applies to Python as well.
    - andybak 11y ago
      Not all of them. Python is often stricter in some aspects of the language and in community norms. Someone can correct me if I'm wrong but the module namespacing helps mitigate this complaint via Twitter: > Can't figure out how a simple thing works in a codebase with a zillion tiny objects and a billion levels of indirection? i.e. unless you've gone out of your way to be too clever - you usually know where things in the current namespace came from.
- PuercoPop 11y ago
  Give Pharo a try, I think you'd be pleasantly surprised.
- rickr 11y ago
  I've just started messing with elixir. It's a functional language that runs on the Erlang VM but it's syntax is ruby-ish. I'm a newbie but I've been impressed by the tooling so far. And once you change how you think about everything the learning curve isn't too bad. =) It has a rails-y framework that I haven't heard much about (and nothing particularly bad): https://github.com/phoenixframework/phoenix https://github.com/phoenixframework/phoenix
PythonicAlpha 11y ago
I don't know, if the statement is true, since I did not work with Ruby really till now. But I definitively would support this statement: > Programming languages cannot be considered separately from their ecosystems I think, one of the main reasons for the success of the C system was not the language itself, but the standard C library. Standard Pascal did not have such a thing (Borland Pascal had and was more successful as any other Pascal), Modula 2 -- a superior language at its time, did not have it (the library that was standard for Modula 2, was just to clunky for wide usage) and also other languages did not have it. C, when it started, had not only the library, but also a -- for that time -- superior development environment: Unix. From this, I would strongly agree, that the ecosystem is decisive -- and the bar has risen since the times of C. Today, you need top compilers or interpreters, top of the notch libraries -- best to have a framework (like Rails) for a good use-case to use the language and tools around that support your programming. With all those good languages around today, any new language must have an appeal and the ecosystem and if possible the community, to be successful.
- pjmlp 11y ago
  I came to view UNIX as the actual C runtime, they just decided to split it up into ANSI C and POSIX standards.
nchelluri 11y ago
EDIT: I realize I left out my main point: I definitely agree with several of the points in the article. I have long wished for some way to traverse ObjectSpace easily and to know what code is being actually executed at any point in time. Lack of use of or availablity of comprehensive static analysis tools in our programming today is a huge problem, IMO. </end edit> I don't have much experience with Ruby debuggers, as I rarely use them. I do use RubyMine, every day. It's got powerful inspections and is an incredibly valuable tool for me. But, I originally used IDEA many years ago, and I don't think that RubyMine is anywhere near as powerful, because of all the dynamism inherent in Ruby. I personally think that Ruby is far too flexible a language. I use metaprogramming, monkey patching, and `method_missing` exceedingly sparingly, if at all. I try to never make code any less traceable than possible. But, I use Rails, and while I don't dive into the Rails source very often, I'm sure there's a lot of hidden stuff in there. All sorts of methods added to classes (ActiveSupport - inflections, time zone helpers, ... - and all the core extensions that have made their ways into gems that do not even require ActiveSupport), and all of my URL helpers which use method_missing to "define methods" that never existed. In a word, Ruby's dangerous (and can be made to be very hard to reason about). I have been watching http://crystal-lang.org/ http://crystal-lang.org/ every once in a while. I think one of the core strengths of Ruby is how concise and elegant it is or at least can be, and how readable it is or at least can be. It's pretty damn nice in a lot of ways. The community support is of course incredible as well (https://github.com/bbatsov/ruby-style-guide https://github.com/bbatsov/ruby-style-guide is great, http://slim-lang.com/ http://slim-lang.com/ has made markup a non-arduous task, etc). Maybe we can do better. EDIT: Incidentally: a lot of my complaints about Ruby are things that I would say about JS as well, but I have considerably less experience there. I just know that I've half-learned sooo many JS patterns. While I don't know Python, one of the things I've really liked hearing about it is how there's supposed to be "one right way" to do stuff. I think this is good. Code serves a purpose, it's a functional tool - IMO, it's not like written language where you really need a bunch of similar-but-different ways to get the same meaning across.
- Retra 11y ago
  The Python "one right way" is a bit of a myth. It's a design goal that is unrealizable in practice. However, the documentation is very good and (in my experience) it lends itself to solving problems in very obvious ways.
graffitici 11y ago
How would people that use both Python and Ruby compare the tooling for both languages? I only am familiar with Python, and I end up using IPython most of the time. I'm curious whether I'm missing out, or maybe Python also has "terrible" tooling..
- steveklabnik 11y ago
  > LRT: Don't think Perl or Python gets off the hook for the tooling that @avdi > talks about. https://twitter.com/brianwisti/status/618815261580263425 https://twitter.com/brianwisti/status/618815261580263425
  - hogu 11y ago
    what is wrong with IDEs like pycharm/intellij?
- boardwaalk 11y ago
  This is pretty specific, but Ruby has pretty terrible support for parsing Ruby. Libraries are either unmaintained or broken or for old versions. Python is great for parsing ('import ast'), compiling ('compile(...)') and executing ('exec(...)'). So it's much easier to write code generators, write linters and autocompletion tools and such.
  - cremno 11y ago
    >but Ruby has pretty terrible support for parsing Ruby https://github.com/whitequark/parser https://github.com/whitequark/parser Neither unmaintained, broken nor just for old versions. It has some really minor incompatibilities though: https://github.com/whitequark/parser#known-issues https://github.com/whitequark/parser#known-issues The same person also wrote a Python parser because apparently the ast module doesn't provide precise location information of tokens: https://github.com/m-labs/pythonparser https://github.com/m-labs/pythonparser
  - graffitici 11y ago
    I had looked into the 'ast' module a little while back, and I do agree that it's pretty neat. The main use I've seen it type checking, or adding language level features (that would typically be done by macros in LISP). I am not aware of many tools written using 'ast', that don't try to extend the language in some way. Any thoughts there?
justinzollars 11y ago
The hipster backlash on Ruby continues.
- jballanc 11y ago
  Considering that the author's primary source of income (to the best of my knowledge) is a video series on tips and tricks for Ruby development, I wouldn't chalk this up to "backlash" so much as "call to arms".
yesdocs 11y ago
This argument rings true and has been in the back of my mind for quite a while. To take this into a different context... for example if you were building a house per se. Houses were built out of wood for years (and still is), but we slowly built tools to make it easier (Hand held saws, levels, nail guns). Now a new material has hit the market... plastic (for instance) and it is a better and more pliable medium to build a home, but we lack the tools to make it easier. It is as though we have no hand tools that will cut through it, or no nail gun that will penetrate it. Yes, it (Ruby) seems to be a better material to have a structure built with, but when you are building a lot of homes or even a mansion, it seems silly to use a material that limits what you can do to manipulate it. The argument that "Ruby is so cool, I don't need tools" seems quite silly and misguided. That may be OK if you are building treehouse in your back yard, but if you are building an entire housing district, you are going to lose money in the development costs.
- beat 11y ago
  The best quality, long term lowest cost roofing material is copper. But we use asphalt shingles, which are short-lived and expensive in the long term. Why? Because they're cheap in the short run, they require little expertise to install, and they're easy to customize. Sound familiar?
yoklov 11y ago
> "In Smalltalk, everything happens somewhere else." - Adele Goldberg Am I the only one that thinks this sounds like a maintenance nightmare? I don't understand how this could ever be a good thing.
- endlessvoid94 11y ago
  Have you tried using Smalltalk?
- akud 11y ago
  It can be beneficial for maintenance as it helps avoid overly-large methods and monolith objects.
- atmosx 11y ago
  Might be, but (regarding ruby) not if your codebase is designed[1] and not grown. Saudi Metz does an extremely good job at explain how to use 'single responsibility' to make even huge codebases maintainable. I believe the same is be true for smalltalk and any OO language. [1] http://poodr.com http://poodr.com
saosebastiao 11y ago
I tend to think that the sophistication of the tools reflect the extent that the language is broken. Valgrind doesn't need to exist for the Java user. You don't need class boilerplate getter/setter generators for Scala. Nobody needs NPE static analyzers for Rust. The need for rename refactoring tools is drastically diminished by the existence of type inference, almost to the point where `:%s/Foo/Bar/g` is entirely adequate. The non-existence of tools that you find in other languages might signal an immature ecosystem, but it might also signal a diminished need for them.
- rictic 11y ago
  It's been a while since I wrote much Ruby, but I can vividly recall wanting to find the definition of a method and being frustrated at how difficult it often was.
  - dragonwriter 11y ago
    > It's been a while since I wrote much Ruby, but I can vividly recall wanting to find the definition of a method and being frustrated at how difficult it often was. Given Ruby's open classes and per-object metaclasses (which are still open), I'm pretty sure a general solution to "find the definition of the method being called at this point in the code" is impossible (and not just, "there is a single correct answer, no general solution is available" impossible, but "there is no guarantee that there is a single correct answer, and even for the subset of cases where there is, no general solution is available" possible.)
    - pjmlp 11y ago
      Ever used Smalltalk, Dylan or Common Lisp commercial tools?
      - hire_charts 11y ago
        Personally, I haven't -- is there a way that the benefits of these tools could be translated into a ruby-based environment? Are such solutions already available? Would be interested to know more.
MrBra 11y ago
everything within our knowledge in the material world can be fixed with enough resources. maybe for Ruby you could need more resources at the beginning given how it has been designed, but once you build up a good land upon which it will be easier to make other changes, (possibly even with a Kickstarter for a new kickass ruby implementation?) then the resources required for other changes will be comparable with the same needed in other languages. In the meanwhile in Ruby we have been profiting from nice syntax and object model, which in the end, IMHO is what paired the balance and still made us use it. This article was great in the sense that highlightinged the right approach that we would need in Ruby to make it grow to a "state of the art language". I really hope this will happen but for some reason I feel a great amount of opposing force to it and I am not sure it only comes from rational thought. I'd like to see someone have their say on this aspect at a deeper level.
- deleted 11y ago
  [deleted]
- MrBra 11y ago
  Refactoring my own comment above (I apologize but I can't delete it anymore). Everything in the material world within our knowledge can be fixed with enough resources. Given the current design, maybe for Ruby we could need more resources at the start of this process, but once a good base is layed out it will be easier to make other changes. Or could it all start with a Kickstarter for a new Ruby implementation??? Anyway, at that point, the resources required for successive changes will be comparable with the same needed by other languages. So far in Ruby we have been profiting from nice syntax and object model, which in the end is what paired the balance and still made us use it. This article was great in the sense that highlightinged the right approach that we would need in Ruby to make it grow to a better implementation. I really hope this will happen but for some reason I feel a great amount of opposing force to it and I am not sure it only comes from rational mindset. I'd like to see someone have their say on this on a deeper level.
endlessvoid94 11y ago
I wrote a Smalltalk-esque System Browser for manipulating class definitions without the need for a filesystem awhile ago (here's a rather crappy screencast of it: https://www.youtube.com/watch?v=2xC5B5t5Rq8 https://www.youtube.com/watch?v=2xC5B5t5Rq8) It was a LOT of fun, and I wish I had the time to resume it. The feedback loop was so much faster, and I can say that there is serious cognitive overhead we all carry by manipulating the definitions of things in files rather than just the objects and classes themselves. It was a fun experiment.
beat 11y ago
The author touches on something important when comparing Ruby to Unix, and why we love them more than more structured systems. Rigorous language is the enemy of expressive language. That's not to say you can't be expressive within a rigorous system - it's just more difficult. And you can only express the things that the rigorous language is capable of expressing. So less rigorous, less formal environments, like Ruby and Unix, allow for a great deal of fast and intuitive expressiveness.
- falcor84 11y ago
  > Rigorous language is the enemy of expressive language. That's an interesting statement. I couldn't find it on the web, is this your own, or a paraphrasing/translation?
  - beat 11y ago
    Yeah, I just made it up.
- scott_karana 11y ago
  Do you really think Lisp is rigid, and not expressive?
  - beat 11y ago
    Immutability is rigidity. Of course, it comes with tremendous benefits as well, but as an effort latency vs bandwidth thing, there's significant latency with using Lisp intellectually. Would you use it for shell scripting or a simple glue language? I wouldn't, and I love Lisp. Lisp is the language of the future. it's always been the language of the future, for nearly 60 years now. It always will be the language of the future. We should think hard about why Lisp has both never become mainstream and never died out. But the fact that it never become mainstream, especially if you exclude conspiracy theory and "most programmers are idiots unworthy of our wisdom", is telling. Rigidity may not be the reason Lisp never broke out. But there is some human factors reason that's worth understanding.
jasim 11y ago
One of the biggest success stories in recent times where language support has made tooling awesome is JSX. The success of JSX shows that developers are happy to write HTML inside code, and there are clear benefits of doing so compared to using a dedicated templating language. But the reason why this wasn't popular till JSX showed up was that it is impossible to parse the HTML built in code through string munging. JSX makes XML-inside-Code parseable, which makes it possible for us to use IntelliJ's excellent IDEs to work seamlessly with it.
- anon4 11y ago
  For those confused: JSX is a statically-typed, object-oriented programming language designed to run on modern web browsers. Being developed at DeNA as a research project, … https://jsx.github.io/ https://jsx.github.io/
  - a-priori 11y ago
    I think the parent is actually referring to this JSX: https://facebook.github.io/react/docs/jsx-in-depth.html https://facebook.github.io/react/docs/jsx-in-depth.html
crimsonalucard 11y ago
For a second I thought that subtle background on the site was actually something physically happening on my screen.
lcfcjs1 11y ago
and out march the high and mighty ruby devs
mark_l_watson 11y ago
So wrong. The author has probably never tried RubyMine (or IntelliJ with the Ruby + Rails + etc. plugins). I was hacking with Pharo Smalltalk just yesterday, so I get what the author means by the niceties of Smalltalk, but Ruby tools from Jetbrains are very nice.
- lukeholder 11y ago
  Please read the article before posting. He mentions rubymine.
  - mark_l_watson 11y ago
    Thanks for the correction! I missed that he relies on Rubymine for his work.

115 points by davidcelis 11y ago

> And yet, in the early 2000s, long before Rails drove throngs of people to learn Ruby, very smart people who knew about Lisp and Haskell and good tooling, fell in love with Ruby. People like Dave Thomas and Martin Fowler and Jim Weirich. This is probably because very smart people don't need tools, so they can let themselves fall for the appearance of raw textbook examples of the source code. Very smart people probably have written programs in low-level languages and gotten them right with only the help of print traces, and raw stack/register dumps.

TodPunk 11y ago
Print traces and dumps were the only tools had for a long time, and quite frankly there are a lot of areas in programming where this is still the case (lots of embedded programming, for instance, and it's not likely you'll get a print from that either). Tools are nice, this isn't an old-man shaking his fist at the wind moment. It's more important to note that not all tools are software. Some tools are mental-based. We have to force ourselves to build those tools over time.
marssaxman 11y ago
I have no idea whether it correlates with "very smart" in any particular way, and suspect that it probably doesn't, but I have definitely observed significant differences in preference when it comes to the use of extralinguistic tools. It's easy to see how there are some people better suited to early adoption of new languages than others, because they are comfortable with and may actually prefer a minimal-tooling environment, while others will find it so unbearably primitive that they won't be able to get anything done. I've had coworkers who believed anything that can be automated should be, and therefore one should learn and use all available tools. In this view, anyone failing to take advantage of all possible automation is wasting their time on grunt work and therefore being less productive than they could. One guy at my last job was notorious for his incredibly long and frequently misspelled identifiers; I could not understand how he was failing to notice these problems until I realized that he literally never typed out a full identifier more than once, and typically generated as many bytes of source code via intellisense as he did by typing. I am out on the opposite end of the spectrum; when I'm coding I don't want to think about tools at all, and a tool had better be absolutely spot-on perfect or its rough edges will waste more of my time by distracting and irritating me than its features will save by automating something I would otherwise have had to do with my brain. I sometimes use IDEs depending on the project, but I always disable code indexing / completion, because the little timing hiccups you get as the tool does its thing break my flow and irritate me. Instead, I put more time into making consistent names and simple APIs so there is less to remember, and do a bit of extra grepping when I can't recall what I need. For me this feels easy and natural; for other people it seems like going the hard way, and they don't understand why I won't let the machine help. These differences extend all up and down the tool chain; some people love their sophisticated debuggers and write all kinds of complex scripts that produce interesting results, while I tend to just throw in a lot of printfs and debug by reading logs. Not to say I won't use a debugger when it's available - just that I know the log approach will always work, and it can be less work to fall back on something simple that I don't have to think about rather than taking the time to remember where all the debugger's knobs and switches are. On the flip side, I will make heavy use of all available language tools for abstraction and code simplification - lambdas, namespaces, interfaces, whatever's handy, my goal is to build every interface, no matter how minor or internal, in such a way that it's difficult to use it improperly. This has irritated people I've worked with who are happy with simple boilerplate because they rely on automated refactoring tools; to them, these esoteric abstractions were aggravating because it left them struggling to see the forest for all the unfamiliar trees. Some of this may be a function of experience, particularly experience with low-level environments. I've written plenty of debugging, logging, grepping, and reporting tools over the years, so I know I can always just bang together what I need in the moment, and the prospective payback from learning some existing do-it-all tool feels correspondingly reduced. But is this a smarts thing? I am not so sure - I mean, I do think I'm pretty smart, but it could just be preference; I really like digging into the foundations of things and have therefore invested a lot of time learning how to work in those environments. Someone who actually prefers to live at a higher abstraction level might well be wasting their time by thinking about this sort of thing, and while that's not my bag I certainly wouldn't argue that high-level work is unnecessary or of lesser importance. Some of it may also be a function of age. I've seen so many tools come and go that it has come to feel like a waste of time to learn one deeply until it has become stable and ubiquitous enough that I can reasonably expect the time I invest in it to pay back over at least 5-10 more years. If it doesn't meet that threshold then why bother? There will just be something else coming along later. I'll learn it if I need to use it, but because of the above-described confidence that I can get the job done regardless of tooling, I'm less likely to hit the bar for "need to use it". The weakness of the heavy-tooling approach is that tools always have flaws and blind spots, and one can get stuck thinking through the tool's mindset and have trouble when there's a problem it doesn't solve particularly well. But the weakness of the light-tooling approach is that tools shape mental models, and mental models shape language, and software development is really more about communication between humans than it is about communication with machines; if you don't adopt the mental frameworks your coworkers are using it may be more difficult to interact with the systems they are building. (also, a moment of brag: one of my proudest debugging feats was when I wrote a bootloader for a brand new embedded architecture using no feedback but a single blinking LED. There was no stack trace, not even a serial line for a printf log, because none of the drivers had loaded yet.)
- realharo 11y ago
  Regarding misspelled identifiers, I've experienced the exact opposite problem. Code I had to work with that was clearly written in simple editors often contained misspelled words (though it was also usually written by non-native English speakers) and even bugs arising from using a wrong variable name. Errors that with proper tooling would be near impossible to make, because the tool would immediately underline the variable as either containing a spelling error or not being defined. Not to mention it also lead people to using generic non-descriptive variable names and abbreviations. I also watched some people trying to printf-debug a problem, and it's usually a fest of "Was the problem here? Hm, not here, ok, let's put these statements over there. Hm, not over there either, what about here... (repeat several more times, depending on how deep the calls go)" Having to do something like this would really feel like stone age to me, when you could just get all the relevant information in one quick pass without having to modify any code. Another thing is documentation. When you know that you can just bring up a method's documentation with a single keystroke, you are much more motivated to document your own methods in the same way. If it's just "some generator will create a bunch of static html pages later on that most people likely won't ever read", some people will not bother. I do agree about flaws in tools being a huge issue though. Especially with refactoring tools, if you can't trust it to not accidentally mess up parts of your code, you might as well not use it at all. Similarly, if you can't trust a "find usages of this method" to find ALL of its usages, the utility diminishes severely. EDIT: oh, and perhaps the most simple, but most important feature of all, being able to Ctrl+click a function to navigate to its definition means that people are going to dive into the code a lot more often, even framework/library code, which is obviously beneficial to learning how things work under the hood. The less friction there is to doing something, the more readily people are going to do it.
  - MrBra 11y ago
    TL;DR?
  - MrBra 11y ago
    Why my request for a TL;DR got downvoted? I thought, if you had that much to say, it could be am interesting opinion, but I didn't have enough time to go through it all.
catnaroek 11y ago
"Very smart" probably means different things to different people, but, for me, it means proactive laziness: the ability to foresee anything that might create repetitive work in the future, and work now to prevent that from happening. So I can't regard a programmer as being "very smart" if he or she doesn't have the ability to abstract over every recurring pattern in his code, and turn it into a nice reusable library. And I also can't regard a programmer as being "very smart" if he or she designs abstractions that leak: in my experience, abstraction leaks create more work than anything else.

matthewmacleod 11y ago

Hmm, I'm not so sure about this. Ruby's tooling is obviously not as advanced as a language like Java, for many reasons. But terrible isn't the adjective I'd use. It's pretty easy to use editor integration to provide pretty decent automatic formatting, linting and code completion. Pry-debugger is pretty great, and generally I don't find working in Ruby to be markedly more taxing that other languages. I guess YMMV, though.

braythwayt 11y ago
> automatic formatting, linting and code completion You are describing tooling that is used to write code, but not to read or debug it. And Ruby is exceptionally easy to write without any tooling whatsoever. The hard problem with dynamic languages is reading the code and understanding what it is doing at run time. And that is where TFA suggests Ruby is terrible.
- davorb 11y ago
  I used to think that it was fine, but then I started working with LISP and SLIME, and the difference between that and what's available in the Ruby-world is striking.
- x0x0 11y ago
  For a short while, I thought about taking a stab at building the above. The thing that stopped me is I couldn't figure out how to get paid, and I'm not independently wealthy.
- Gibbon1 11y ago
  One the way to reading about something else, I read an essay by a language developer complaining about type erasure. In functional languages. In short, when you get to the point in implementing a language where you can do type erasure, you're golden because it usually means you have things nailed down. Unfortunately then people actually implement type erasure and now there is no way to link data structures in memory with a piece of code at run time. Or at least very easily. As an example C/C++ does erase type information. There often being nothing that tells you what an object in memory is. But compilers take great pains to preserve that information in the generated output formats. Which allow you to write debuggers. I'm sure languages like Java and .net do the same.

braythwayt 11y ago

> People in the industry are very excited about various ideas that nominally help you deal with > large code bases, such as IDEs that can manipulate code as "algebraic structures", and search > indexes, and so on. These people tend to view code bases much the way construction workers view > dirt: they want great big machines that can move the dirt this way and that. There's > conservation of dirt at work: you can't compress dirt, not much, so their solution set consists > of various ways of shoveling the dirt around. There are even programming interview questions, > surely metaphorical, about how you might go about moving an entire mountain of dirt, one truck > at a time. > Industry programmers are excited about solutions to a big non-problem. It's just a mountain of > dirt, and you just need big tools to move it around. The tools are exciting but the dirt is not. > My minority opinion is that a mountain of code is the worst thing that can befall a person, a > team, a company. I believe that code weight wrecks projects and companies, that it forces > rewrites after a certain size, and that smart teams will do everything in their power to keep > their code base from becoming a mountain. Tools or no tools. That's what I believe. —Steve Yegge, "Code's Worst Enemy" http://steve-yegge.blogspot.ca/2007/12/codes-worst-enemy.html http://steve-yegge.blogspot.ca/2007/12/codes-worst-enemy.htm... I'm not quoting this to refute the idea that Ruby has terrible tooling, or to suggest that tooling doesn't matter. But rather, to give some context for this idea: When we first embraced Ruby, we were writing web apps in Java. Ruby allowed us to write those same apps with fewer lines of code, by fewer people, in less time. That was a triple-win, and there were all sorts of secondary positive effects. Fewer people on a team means less necessary process. It means less money required. YCombinator wouldn't exist today if you couldn't have done something meaningful with $18,000 over a few months. Less time means you can be lean and iterate, rather than spending time and tons of money trying to analyze what a market wants in advance. Those factors were massive wins for the startup culture. There are similar effects within companies, but I needn't list them out here. But one negative effect is that with small teams writing fewer lines of code, in a startup culture, there is much less emphasis on tooling. It's a "nice-to-have," because app complexity does not make the difference between shipping and not shipping. So yeah, there's some tooling, but it is not very good. Really, it's not. But it was good enough. But as time went on, our apps and teams grew. Most businesses are in a Red Queen's Race against their competition. It is very hard to stay small and focused and have a single responsibility in a market. So our code grows and grows, until it reaches a kind of equilibrium with how many lines of code a company can support. Which means we expand until we're back to having big code bases, with many engineers. And guess what? One million lines of Java is easier to understand than one million lines of Ruby. Doubly so when you have better Java tooling than Ruby tooling, and when Ruby does things that demand better tooling. So now we're in this place where successful companies have big apps, but we don't have a "big app" culture, so we don't have the tooling required to support this many lines of Java, much less this many lines of Ruby. --- p.s. Here's a very nice person saying the same thing at WebRebels: http://vimeo.com/76141334 http://vimeo.com/76141334

davexunit 11y ago

I write both Ruby and Lisp frequently, and I must agree that Lisp tools are vastly superior. Ruby, despite being a dynamic language, has a sorry excuse for a REPL which really hampers my workflow. For example, Rails watches your Ruby files for changes and reloads them in development mode, but if it was easy to re-evaluate arbitrary expressions from your editor (a la SLIME or Geiser) such a feature would never be needed. Then, of course, there's typically so much magic happening that it's often impossible to find the place in which a symbol was defined by searching for that symbol, which makes debugging overly difficult.

cpitt 11y ago
When you say "sorry excuse for a REPL", you are referring to the built in repl and not pry (http://pryrepl.org/ http://pryrepl.org/), right? because pry is freaking awsome!
- davexunit 11y ago
  The same issue is there. This is a language issue. I want to edit a file and re-evaluate arbitrary expressions with a keystroke. Writing the code and then copy/pasting it into a REPL prompt is not sufficient. Lisp programmers have had excellent live coding environments for a very long time, but with Ruby I must make do with Rails auto-reloading files for me.
  - JoelMcCracken 11y ago
    Not sure if you're aware, but things like this can be done with Emacs. It really isn't that simple, though, and I've only used it for the most trivial of situations.
  - vidarh 11y ago
    > I want to edit a file and re-evaluate arbitrary expressions with a keystroke. Writing the code and then copy/pasting it into a REPL prompt is not sufficient. This suggests to me you've not spent much time with Pry. Are you aware of this: https://github.com/pry/pry/wiki/Editor-integration https://github.com/pry/pry/wiki/Editor-integration It's not perfect - doing it perfect with Ruby is a hard problem, as a method can have been defined and redefined in multiple places. But it works very well.

bascule 11y ago

This is one of the things I've always liked about JRuby. You can use the excellent tooling of the JVM ecosystem (e.g. YourKit, Coverity Dynamic Analyzer) to understand the behavior of your JRuby applications, and even attach directly to running production apps to debug them. I've found tools like this essential for debugging multithreaded JRuby applications, and there's simply nothing else like them available for MRI.

rquantz 11y ago

So what's a language that has much better tooling than ruby, but still has a web stack as good as Rails? Does one exist?

lelandbatey 11y ago
Some people would say "Python", since the tooling for Python is generally excellent, but I don't have enough experience with Python web stacks to say that they're better or worse than Rails. There's certainly less "magic" with Python, but I'd argue that's a good thing.
- mtarnovan 11y ago
  I think all the criticism from that article applies to Python as well.
  - andybak 11y ago
    Not all of them. Python is often stricter in some aspects of the language and in community norms. Someone can correct me if I'm wrong but the module namespacing helps mitigate this complaint via Twitter: > Can't figure out how a simple thing works in a codebase with a zillion tiny objects and a billion levels of indirection? i.e. unless you've gone out of your way to be too clever - you usually know where things in the current namespace came from.
PuercoPop 11y ago
Give Pharo a try, I think you'd be pleasantly surprised.
rickr 11y ago
I've just started messing with elixir. It's a functional language that runs on the Erlang VM but it's syntax is ruby-ish. I'm a newbie but I've been impressed by the tooling so far. And once you change how you think about everything the learning curve isn't too bad. =) It has a rails-y framework that I haven't heard much about (and nothing particularly bad): https://github.com/phoenixframework/phoenix https://github.com/phoenixframework/phoenix

PythonicAlpha 11y ago

I don't know, if the statement is true, since I did not work with Ruby really till now. But I definitively would support this statement: > Programming languages cannot be considered separately from their ecosystems I think, one of the main reasons for the success of the C system was not the language itself, but the standard C library. Standard Pascal did not have such a thing (Borland Pascal had and was more successful as any other Pascal), Modula 2 -- a superior language at its time, did not have it (the library that was standard for Modula 2, was just to clunky for wide usage) and also other languages did not have it. C, when it started, had not only the library, but also a -- for that time -- superior development environment: Unix. From this, I would strongly agree, that the ecosystem is decisive -- and the bar has risen since the times of C. Today, you need top compilers or interpreters, top of the notch libraries -- best to have a framework (like Rails) for a good use-case to use the language and tools around that support your programming. With all those good languages around today, any new language must have an appeal and the ecosystem and if possible the community, to be successful.

pjmlp 11y ago
I came to view UNIX as the actual C runtime, they just decided to split it up into ANSI C and POSIX standards.

nchelluri 11y ago

EDIT: I realize I left out my main point: I definitely agree with several of the points in the article. I have long wished for some way to traverse ObjectSpace easily and to know what code is being actually executed at any point in time. Lack of use of or availablity of comprehensive static analysis tools in our programming today is a huge problem, IMO. </end edit> I don't have much experience with Ruby debuggers, as I rarely use them. I do use RubyMine, every day. It's got powerful inspections and is an incredibly valuable tool for me. But, I originally used IDEA many years ago, and I don't think that RubyMine is anywhere near as powerful, because of all the dynamism inherent in Ruby. I personally think that Ruby is far too flexible a language. I use metaprogramming, monkey patching, and `method_missing` exceedingly sparingly, if at all. I try to never make code any less traceable than possible. But, I use Rails, and while I don't dive into the Rails source very often, I'm sure there's a lot of hidden stuff in there. All sorts of methods added to classes (ActiveSupport - inflections, time zone helpers, ... - and all the core extensions that have made their ways into gems that do not even require ActiveSupport), and all of my URL helpers which use method_missing to "define methods" that never existed. In a word, Ruby's dangerous (and can be made to be very hard to reason about). I have been watching http://crystal-lang.org/ http://crystal-lang.org/ every once in a while. I think one of the core strengths of Ruby is how concise and elegant it is or at least can be, and how readable it is or at least can be. It's pretty damn nice in a lot of ways. The community support is of course incredible as well (https://github.com/bbatsov/ruby-style-guide https://github.com/bbatsov/ruby-style-guide is great, http://slim-lang.com/ http://slim-lang.com/ has made markup a non-arduous task, etc). Maybe we can do better. EDIT: Incidentally: a lot of my complaints about Ruby are things that I would say about JS as well, but I have considerably less experience there. I just know that I've half-learned sooo many JS patterns. While I don't know Python, one of the things I've really liked hearing about it is how there's supposed to be "one right way" to do stuff. I think this is good. Code serves a purpose, it's a functional tool - IMO, it's not like written language where you really need a bunch of similar-but-different ways to get the same meaning across.

Retra 11y ago
The Python "one right way" is a bit of a myth. It's a design goal that is unrealizable in practice. However, the documentation is very good and (in my experience) it lends itself to solving problems in very obvious ways.

graffitici 11y ago

How would people that use both Python and Ruby compare the tooling for both languages? I only am familiar with Python, and I end up using IPython most of the time. I'm curious whether I'm missing out, or maybe Python also has "terrible" tooling..

steveklabnik 11y ago
> LRT: Don't think Perl or Python gets off the hook for the tooling that @avdi > talks about. https://twitter.com/brianwisti/status/618815261580263425 https://twitter.com/brianwisti/status/618815261580263425
- hogu 11y ago
  what is wrong with IDEs like pycharm/intellij?
boardwaalk 11y ago
This is pretty specific, but Ruby has pretty terrible support for parsing Ruby. Libraries are either unmaintained or broken or for old versions. Python is great for parsing ('import ast'), compiling ('compile(...)') and executing ('exec(...)'). So it's much easier to write code generators, write linters and autocompletion tools and such.
- cremno 11y ago
  >but Ruby has pretty terrible support for parsing Ruby https://github.com/whitequark/parser https://github.com/whitequark/parser Neither unmaintained, broken nor just for old versions. It has some really minor incompatibilities though: https://github.com/whitequark/parser#known-issues https://github.com/whitequark/parser#known-issues The same person also wrote a Python parser because apparently the ast module doesn't provide precise location information of tokens: https://github.com/m-labs/pythonparser https://github.com/m-labs/pythonparser
- graffitici 11y ago
  I had looked into the 'ast' module a little while back, and I do agree that it's pretty neat. The main use I've seen it type checking, or adding language level features (that would typically be done by macros in LISP). I am not aware of many tools written using 'ast', that don't try to extend the language in some way. Any thoughts there?

justinzollars 11y ago

The hipster backlash on Ruby continues.

jballanc 11y ago
Considering that the author's primary source of income (to the best of my knowledge) is a video series on tips and tricks for Ruby development, I wouldn't chalk this up to "backlash" so much as "call to arms".

yesdocs 11y ago

This argument rings true and has been in the back of my mind for quite a while. To take this into a different context... for example if you were building a house per se. Houses were built out of wood for years (and still is), but we slowly built tools to make it easier (Hand held saws, levels, nail guns). Now a new material has hit the market... plastic (for instance) and it is a better and more pliable medium to build a home, but we lack the tools to make it easier. It is as though we have no hand tools that will cut through it, or no nail gun that will penetrate it. Yes, it (Ruby) seems to be a better material to have a structure built with, but when you are building a lot of homes or even a mansion, it seems silly to use a material that limits what you can do to manipulate it. The argument that "Ruby is so cool, I don't need tools" seems quite silly and misguided. That may be OK if you are building treehouse in your back yard, but if you are building an entire housing district, you are going to lose money in the development costs.

beat 11y ago
The best quality, long term lowest cost roofing material is copper. But we use asphalt shingles, which are short-lived and expensive in the long term. Why? Because they're cheap in the short run, they require little expertise to install, and they're easy to customize. Sound familiar?

yoklov 11y ago

> "In Smalltalk, everything happens somewhere else." - Adele Goldberg Am I the only one that thinks this sounds like a maintenance nightmare? I don't understand how this could ever be a good thing.

endlessvoid94 11y ago
Have you tried using Smalltalk?
akud 11y ago
It can be beneficial for maintenance as it helps avoid overly-large methods and monolith objects.
atmosx 11y ago
Might be, but (regarding ruby) not if your codebase is designed[1] and not grown. Saudi Metz does an extremely good job at explain how to use 'single responsibility' to make even huge codebases maintainable. I believe the same is be true for smalltalk and any OO language. [1] http://poodr.com http://poodr.com

saosebastiao 11y ago

I tend to think that the sophistication of the tools reflect the extent that the language is broken. Valgrind doesn't need to exist for the Java user. You don't need class boilerplate getter/setter generators for Scala. Nobody needs NPE static analyzers for Rust. The need for rename refactoring tools is drastically diminished by the existence of type inference, almost to the point where `:%s/Foo/Bar/g` is entirely adequate. The non-existence of tools that you find in other languages might signal an immature ecosystem, but it might also signal a diminished need for them.

rictic 11y ago
It's been a while since I wrote much Ruby, but I can vividly recall wanting to find the definition of a method and being frustrated at how difficult it often was.
- dragonwriter 11y ago
  > It's been a while since I wrote much Ruby, but I can vividly recall wanting to find the definition of a method and being frustrated at how difficult it often was. Given Ruby's open classes and per-object metaclasses (which are still open), I'm pretty sure a general solution to "find the definition of the method being called at this point in the code" is impossible (and not just, "there is a single correct answer, no general solution is available" impossible, but "there is no guarantee that there is a single correct answer, and even for the subset of cases where there is, no general solution is available" possible.)
  - pjmlp 11y ago
    Ever used Smalltalk, Dylan or Common Lisp commercial tools?
    - hire_charts 11y ago
      Personally, I haven't -- is there a way that the benefits of these tools could be translated into a ruby-based environment? Are such solutions already available? Would be interested to know more.

MrBra 11y ago

everything within our knowledge in the material world can be fixed with enough resources. maybe for Ruby you could need more resources at the beginning given how it has been designed, but once you build up a good land upon which it will be easier to make other changes, (possibly even with a Kickstarter for a new kickass ruby implementation?) then the resources required for other changes will be comparable with the same needed in other languages. In the meanwhile in Ruby we have been profiting from nice syntax and object model, which in the end, IMHO is what paired the balance and still made us use it. This article was great in the sense that highlightinged the right approach that we would need in Ruby to make it grow to a "state of the art language". I really hope this will happen but for some reason I feel a great amount of opposing force to it and I am not sure it only comes from rational thought. I'd like to see someone have their say on this aspect at a deeper level.

deleted 11y ago
[deleted]
MrBra 11y ago
Refactoring my own comment above (I apologize but I can't delete it anymore). Everything in the material world within our knowledge can be fixed with enough resources. Given the current design, maybe for Ruby we could need more resources at the start of this process, but once a good base is layed out it will be easier to make other changes. Or could it all start with a Kickstarter for a new Ruby implementation??? Anyway, at that point, the resources required for successive changes will be comparable with the same needed by other languages. So far in Ruby we have been profiting from nice syntax and object model, which in the end is what paired the balance and still made us use it. This article was great in the sense that highlightinged the right approach that we would need in Ruby to make it grow to a better implementation. I really hope this will happen but for some reason I feel a great amount of opposing force to it and I am not sure it only comes from rational mindset. I'd like to see someone have their say on this on a deeper level.

endlessvoid94 11y ago

I wrote a Smalltalk-esque System Browser for manipulating class definitions without the need for a filesystem awhile ago (here's a rather crappy screencast of it: https://www.youtube.com/watch?v=2xC5B5t5Rq8 https://www.youtube.com/watch?v=2xC5B5t5Rq8) It was a LOT of fun, and I wish I had the time to resume it. The feedback loop was so much faster, and I can say that there is serious cognitive overhead we all carry by manipulating the definitions of things in files rather than just the objects and classes themselves. It was a fun experiment.

beat 11y ago

The author touches on something important when comparing Ruby to Unix, and why we love them more than more structured systems. Rigorous language is the enemy of expressive language. That's not to say you can't be expressive within a rigorous system - it's just more difficult. And you can only express the things that the rigorous language is capable of expressing. So less rigorous, less formal environments, like Ruby and Unix, allow for a great deal of fast and intuitive expressiveness.

falcor84 11y ago
> Rigorous language is the enemy of expressive language. That's an interesting statement. I couldn't find it on the web, is this your own, or a paraphrasing/translation?
- beat 11y ago
  Yeah, I just made it up.
scott_karana 11y ago
Do you really think Lisp is rigid, and not expressive?
- beat 11y ago
  Immutability is rigidity. Of course, it comes with tremendous benefits as well, but as an effort latency vs bandwidth thing, there's significant latency with using Lisp intellectually. Would you use it for shell scripting or a simple glue language? I wouldn't, and I love Lisp. Lisp is the language of the future. it's always been the language of the future, for nearly 60 years now. It always will be the language of the future. We should think hard about why Lisp has both never become mainstream and never died out. But the fact that it never become mainstream, especially if you exclude conspiracy theory and "most programmers are idiots unworthy of our wisdom", is telling. Rigidity may not be the reason Lisp never broke out. But there is some human factors reason that's worth understanding.

jasim 11y ago

One of the biggest success stories in recent times where language support has made tooling awesome is JSX. The success of JSX shows that developers are happy to write HTML inside code, and there are clear benefits of doing so compared to using a dedicated templating language. But the reason why this wasn't popular till JSX showed up was that it is impossible to parse the HTML built in code through string munging. JSX makes XML-inside-Code parseable, which makes it possible for us to use IntelliJ's excellent IDEs to work seamlessly with it.

anon4 11y ago
For those confused: JSX is a statically-typed, object-oriented programming language designed to run on modern web browsers. Being developed at DeNA as a research project, … https://jsx.github.io/ https://jsx.github.io/
- a-priori 11y ago
  I think the parent is actually referring to this JSX: https://facebook.github.io/react/docs/jsx-in-depth.html https://facebook.github.io/react/docs/jsx-in-depth.html

crimsonalucard 11y ago

For a second I thought that subtle background on the site was actually something physically happening on my screen.

lcfcjs1 11y ago

and out march the high and mighty ruby devs

mark_l_watson 11y ago

So wrong. The author has probably never tried RubyMine (or IntelliJ with the Ruby + Rails + etc. plugins). I was hacking with Pharo Smalltalk just yesterday, so I get what the author means by the niceties of Smalltalk, but Ruby tools from Jetbrains are very nice.

lukeholder 11y ago
Please read the article before posting. He mentions rubymine.
- mark_l_watson 11y ago
  Thanks for the correction! I missed that he relies on Rubymine for his work.