02:28 - Ruby in a Polyglot Architecture (Panel Experience)

04:21 - Does Ruby do well or not in the microservices area? Is Ruby keeping up?

07:30 - What are areas where Ruby still beats other languages?

13:12 - Polyglotting Architecture if Only Using Ruby for Build Tools, Deployment Tools, etc.?

16:09 - Error Messages 

18:20 - Tradeoffs in a Polyglot Architecture (Negatives)

34:35 - Learning Programming

41:24 - Mixing Languages

 [This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco, New York, and L.A. bid on Ruby developers, providing them with salary and equity upfront. The average Ruby developer gets an average of 5 to 15 introductory offers and an average salary offer of $130,000 a year. Users can either accept an offer and go right into interviewing with the company or deny them without any continuing obligations. It’s totally free for users. And when you’re hired, they also give you a $2,000 signing bonus as a thank you for using them. But if you use the Ruby Rogues link, you’ll get a $4,000 bonus instead. Finally, if you’re not looking for a job and know someone who is, you can refer them to Hired and get a $1,337 bonus if they accept a job. Go sign up at Hired.com/RubyRogues.]

Hey and welcome to the Ruby Rogues podcast. We did a live Ruby Remote Conf episode. We talked about Ruby in a polyglot architecture. And we had a lot of fun doing it. This starts kind of in the middle because I forgot to record the first two minutes. So, go ahead and just pick up where it left off. And thank you for listening.

I guess, when I got started I was using Ruby for tooling in a shop. I was mainly doing C and C++ and Assembly and stuff like that. So, there’s that. I’ve also certainly worked in teams where it was, the Ruby part was talking to another part that was written in Java or something like that.

Gotcha. I’ve worked with a few shops where they had a backend that was, like you said, you mentioned Java. I’ve done it to .NET and backends that were PHP. And I think I’ve done one with a Python backend. And so essentially then, Ruby was kind of a frontend layer that served up views and HTML. And then that all talked back to an API layer that was internal somehow. I’ve also run into this where we were transitioning from .NET or some other technology into a system that was going to be pure Ruby. And so, we had to deal with things that way.

The other thing that I’ve seen a lot of is Ruby setup as the build tools. So, in JavaScript and things like that, in some of the Node.js projects that I’ve worked on, they’ve used Rake to do builds. I’ve also worked in companies where they’re using something like Sass or something. So, they have Ruby installed to support some engine or some asset system that they have. And so, as part of their build process they’re using Ruby.

That’s how I’ve seen it used a lot, is Ruby for scripting and the smaller tasks. Also, I’ve worked in a

microservices-y environment where some of the services were in Ruby and others in Clojure.

When you talk over HTTP in JSON, it doesn’t matter.

Yeah, I’ve also seen things that back onto Resque or something because they feel like other systems like RabbitMQ or something are a little bit too heavyweight. And so, they’ll pull in a Ruby queuing system. And even though it’s not tied into a Rails app they’ll use that to send messages between microservices. So, it’s really interesting to get an idea of some of these things. I’m curious. Overall, I’ve also seen it where it’s mostly Ruby and then you have other systems like Node.js that run specific services the other way. So, instead of it being Ruby’s part of a system that is supported mostly by .NET or Java, it’s the other way around where it’s mostly Ruby and then you have Node.js and WordPress and other things in the mix. Have you found that Ruby does really well in some areas and not others in these kinds of setups? Especially in the microservices areas.

I’m afraid in our experience it was write it in Ruby and then, “Oh, crap. We would rather do this in Clojure.” And then gradually services moved from Ruby to Clojure. I’m not really sure why.

What was the source of the, “Oh, crap”?

That’s a really good question. And you know, I don’t know other than Clojure was cooler. [Laughter]

I’m old enough to remember when Ruby was the cooler language that the lucky Java developers can switch over to Ruby. And now, it feels like Clojure is more of the cool language that people get excited about, being able to write code faster than they could before. Ruby obviously is way more fun than Java. But maybe Ruby’s not state of the art anymore. What do you think? Do you think it’s keeping up?

I don’t think languages keep up.

Ecosystems do though.

Yeah, it’s true. Sometimes…

And you don’t choose a language anymore.

Yeah, sometimes you see an ecosystem that just completely fails to develop certain tooling. And others’ ecosystems really, really…

Or it develops it too early and then the people who develop it later do it better. I think Haskell suffers from some of that, its package manager. I’ve heard a lot of complaints about. It’s just been around a lot longer than some of the newer ones.

Yeah.

Yeah, you get saddled with a whole lot of old code.

Yeah, I have to wonder though if it’s just that the old system has momentum. And we could do things in a newer or better way with the existing, you know, and just update the ecosystem like you’re talking about. So, the Haskell package manager, could they write another one that works better? Or is there something inherent in Haskell that makes it so that it just is never going to make the jump?

Yeah, that’s an interesting question. I wonder if it’s just, “Well there’s already a package manager in Haskell so why would you make a new one?” And people would have to deploy to that. Whereas if you don’t, then the package manager becomes a burden. It drags the whole language usage down.

Yeah. I see a lot of ‘too little, too late’ things that go on in languages. The Perl community has been doing a ton of work in building brand new tools that are learned from other languages. There’s the whole concept of modern Perl which [inaudible] techniques and tools that are way different from what I knew as standard Perl programming. But at this point, I think most people and whole shops moved on. And so, it’s a shrinking audience that they’re developing these things for even though they’re trying to keep up now.

What are the areas where Ruby still beats the other languages?

For me, I’ve built services in Node.js and in Ruby. I haven’t done any in Clojure so I can’t really address that. But I can say that there are a lot of options that feel a lot lower impedance to me in Ruby than in JavaScript. And so, in a lot of cases I’m happy to pick up Roda or Sinatra or something where it’s got a very simple routing interface and then run ahead and get something out there that works.

The Ruby Remote Conf site is a good example of that where basically it’s a Sinatra app. It has four endpoints on it. And then the asset compilation is really the most complicated piece. So, I’ve got a little bit of AngularJS on the frontend. But the rest of the backend is Ohm which is an ORM that backs onto Redis. And so, it’s super simple. It’s easy to get set up. I probably spent two hours doing any of the technical programming on the website. And that includes all the time I spent tweaking it since I did JS Remote Conf. So overall, I think that’s a really helpful way. But a lot of times I think it really boils down to momentum and what people are used to using. And I wonder a little bit if I were more experienced with Express or something like that, or Koa, that I might be saying the same thing about JavaScript.

Ah, you have a good point. So, what’s fastest for you to get up and running is what’s fastest for you personally to get up and running.

Yeah.

And that is a historical question.

Yeah, but the tradeoff is that I wanted something up fast. I didn’t… it wasn’t about anything other than ‘I need this out there now and it needs to work’. And so, that’s what I went to.

I think Ruby does actually have a really mature package management story. Somebody in the…

With RubyGems or Bundler or both?

Yes, yeah. Now that we have both and both are mature, I think it has a really well put together package management story, especially compared to some of the stuff that’s out there. And yes, yes. CPAN is the original and still in some ways the best. But even CPAN… now it’s been a while since I’ve used CPAN. But I don’t recall CPAN doing some of the kind of advanced dependency resolution for individual projects that Bundler is capable of. CPAN was a great way of saying, “Okay, I want to install this library on my system and I want to get all of its dependencies. And I want you to sort out what mirror to bring it in from and then verify it when it’s installed.”

But Bundler is, yeah, somebody… Arthur in the chat is commenting that they’ve run into some pain with npm. And I haven’t really used npm much myself. But I was just talking to someone who was talking about some of the stuff that goes on with npm where it writes all the dependencies in subdirectories. And so, sometimes it writes so many sub… the dependency chain is so long that the subdirectories become too long. The path names become too long for the system. And so, then it has to come up with path rewriting algorithms to make the path not too long for the system and just ridiculous stuff like that.

Wow.

Or straight up installing different versions of a library, two different versions of the library in the same project and having objects move from one version of a library to another version of a library and break for that reason. These are hard problems. But if there’s one hard problem that we’ve actually managed to solve after much pain and suffering, I think we’ve nailed that one.

Ha! Ha! I deny that anyone in our industry has solved dependency management

It has been a long time since I’ve had any cause for complaint with Bundler.

You know, in fact Ruby is the language that I’ve possibly struggled the most with, with dependency management because…

Really?

Yes! Even if you can get the Bundler and your projects are set up okay, that’s alright. But as soon as you start running on the same machine, projects that were compiled and written for different versions of Ruby… Ruby itself is polyglot. [Laughs]

We’ve had production problems like this. Oh, somehow another version of Ruby got installed on the machine. And now certain scripts break in certain weird circumstances. And it’s always 18 dependencies down. Aah.

Control your versions of Ruby better. [Laughs] I know that’s a terrible thing to say. But that’s a problem with every language, is your local machine has a different version of the interpreter installed or the compiler installed than the production server does.

Yeah.

You know, I’ll give Java that backwards compatibility that causes such pain in language design. It does have its benefits.

That’s absolutely true.

That’s fair. I was actually going to point out the flaws that it caused in language design, but you called that out.

Oh yeah, totally. It’s painful. Scala takes the opposite position of “No, we’re not going to support…” well in the early days they were not backwards compatible with previous versions. And a lot of people tried Scala and absolutely hated it and have foresworn it forever because they used it in that early stage and suffered from that lack of backwards compatibility. These days Scala is if they break backwards compatibility they provide a migration path. They make sure it works for all the major libraries that are out there. They’re somewhere in between. But yeah, with Ruby, and maybe it’s obviously we just didn’t control our Ruby versions well enough. But you know what? I don’t want to sit there and think about the Ruby versions on my production server when I download somebody else’s tool and use it.

Yeah. Yeah, I’m a little curious. Do we consider it a polyglot architecture if we’re only using Ruby for the build tools or deployment tools or something like Chef or Puppet where we’re actually doing server setup? Or is that completely different where we’re managing something else? It’s not the actual running application.

I vote for deployment is part of the code. And how you get your code to production, it’s no good to you if it’s not running in production though. If there’s code that gets it there, that is production code.

I agree. So, in other systems, I’ve built a few Node apps. And I tend to deploy them with Capistrano. Is that weird? It’s a Ruby solution. But I haven’t found a good option in Node. And no, Heroku doesn’t count.

I think it’s beautiful if we can use the parts of an ecosystem that we love from one language to work with software that’s also in another.

I’ll admit that I’ve also used Rake to trigger Grunt to do some work. Grunt is one of the Rake equivalents in JavaScript.

Rake is awesome.

Yeah, it is.

Rake is just enough but not too much. And it’s easy to dig into it and understand what’s going on, which I can’t say as much for like make.

Yeah, make is one of those inscrutable systems. You just look at it and it’s like, “What is going on here?” And there are a couple of things that I don’t love about Rake. But for the most part, it is awesome. And usually, it’s stuff like passing arguments to a Rake task and things like that. It’s just weird. But it’s nice because it’s approachable. It namespaces cleanly. And it’s pretty easy to, if you put a description on it, you can figure out what things do. And it really is a terrific system.

I do feel a little bit funny sometimes when I’m calling out to something else. So, I mentioned that I’ve had it call out to Grunt and run some Grunt tasks. And I always feel funny putting a little backtick, grunt blah, blah, blah, blah, backtick in there. But sometimes, that’s what you got to do.

So, you run a shell script…

Why are you using backtick instead of sh?

Sh?

Yes, that’s Rake for ‘run this shell command’.

Because I’m going to do that from now on?

[Laughs] Who has Rake questions?

Yeah, and yet in the end it would take me a long time to use Rake for something. It goes back to what you know. If you know a tool really well then you’re going to be able to use it faster and more effectively even if there might be some other tool more precisely suited for the task, if you already knew that one. Unfortunately, that makes it painful for other people on the team if they don’t know that tool yet.

Yeah.

Yeah.

Rake is wonderful, Avdi. I’m totally not criticizing Rake. That is not about Rake. That is about tools, period.

But there are tools that are easier to learn and there are tools that are harder to learn.

Absolutely. I could totally go into a whole talk on that and how the most important thing is the error messages.

[Chuckles] Yeah. Another thing that Perl got right.

Really?

You know, Perl has a famously inscrutable syntax. [Inaudible] inscrutable, but very deep and complex. But if you got anything wrong in your Perl script, Perl would basically give you a dissertation about it. It’d be like, “Okay, here’s where the problem is. Now let me give you three paragraphs explaining how this problem usually occurs and what you can do to fix it.”

That’s wonderful.

Yeah.

I know that Elixir and Elm also focus very strongly on the error messages, that if you get an error message that doesn’t make sense to you, it’s a bug in the language. I think that’s a wonderful philosophy.

Yeah. Well, and Perl, as somebody… I was talking about this on Twitter and somebody pointed out that probably reflects Larry Wall’s linguistics background. [Inaudible] very linguistic-oriented and human-oriented. And yeah, it’s more like Perl talking to you and less like, “Oh, I had died. I do not know why. It’s your problem now.”

Got a parenthesis when I wanted a curly brace. I’m teaching my sister to program. And we’ve started with Ruby. And I have to admit, I’m really sad to say this, but I regret starting with Ruby.

And error messages are a big part of that.

Mm.

I think more and more as we go forward and as we move into more and more polyglot architectures where, and this is what I’ve encountered several times, in order to trace how something happened, how something got into production, I wind up tracing something through eight different tools and languages. And I have to understand at least a little bit about each one of those. While I think it’s beautiful to be polyglot and use the right tool for the job, it becomes more and more important that those tools be easy enough for a novice to at least be able to read and understand what’s going on, for the error messages to make sense so that someone who doesn’t know Clojure for instance doesn’t have to learn the entire language in order to fix or understand, at least understand this bug that’s happening. And Clojure’s error messages are worse than Ruby’s, by the way.

[Chuckles] Yeah, that is something that we should talk about here for a minute, is what are the tradeoffs of a polyglot architecture? You mentioned tracing errors from one system to the next, to the next. And I think we see this mostly when you have several microservices that all interconnect, that are in different languages. You run into this even if they aren’t in different languages.

Or build tools that call each other.

Yeah. [Chuckles]

Yeah. Are there any other things that you run into? I hear a lot of things about isomorphic JavaScript and people saying, well I don’t have to change context when I move from the frontend to the backend on web. And I call [them out on that] all the time.

If you are switching…

But yeah, so do you lose something in a polyglot architecture? Or does it depend on the team size or the company size?

If you are switching between the frontend and the backend or between a build tool and your program and you’re not switching contexts, you are not abstracting. And what are you doing?

[Laughs] I agree.

There’s always a context switch. But yeah, there’s also some cost to having to know the different language. To answer your question Chuck, I think if you’re a team of one there is no negative to polyglot. As in, you only use tools that you choose to use. You use the ones that are the most useful to you. So, where’s the cost? [Inaudible] other people.

I would actually disagree with that.

Go on?

I would actually, and I have an example. So yeah, I love building systems entirely myself just because they let me try things out without hurting anybody other than me. So, I’ve… the reason that I know so much about Rake is because I’ve been through four different iterations of a book building tool chain, which is a pretty elaborate thing to pull together. It’s many, many different tools to pull together for eBook publishing. And I’ve done it in make a few times. And now I’m going it in Rake. And the third time around, I decided to just have some fun. I decided to see how far I could get with just using classic tools tied together with make. So, like picking each tool for the thing that it did best.

So, I was using awk to do some line-wise transformations. And I was using sed for other things.

And for macro expansion I was using M4 because M4 is the standard GNU toolchain macro system. So, instead of using a single language for all these different things I was using all these little sharp tools as they say, all tied together by a huge make file or set of make files. And it was a fascinating experience. And I learned a lot. But in the end it was kind of awful. Because number one, as a single programmer I am separate people. Because I’m the Avdi that has all of his awk knowledge in main memory. And another day I’m the Avdi that has all of his M4 knowledge or his Perl knowledge or something loading in main memory. And especially when I have to keep swapping back and forth between that and the Avdi that has all the make knowledge in memory.

And these things have, the larger, big architecture… the big semantic differences aren’t as big a problem when you’re switching between procedural code and functional code or something like that. That’s not as big a problem to swap in my experience. It’s the little things that hurt. It’s the way string interpolation differs a tiny bit from one language to another. That or how one tool will automatically suck in environment variables and treat them as local variables but another tool, you have to explicitly pull the environment variables out of some environment has or something. It’s the little differences that…

That’s a great point.

And it was actually that experience where I decided to do it the classic Unix way and tie all these little sharp tools together with a make file that convinced me to finally switch to using Rake and actually tying a lot of Ruby scripts together using a Ruby make file. And the ability to keep the same knowledge in memory all the time massively increased my throughput.

That’s a great point. There’s all that incidental complexity in switching languages that you save yourself some from with consistency. I can see.

Yeah. And some of those tools are really sharp. Awk is kind of neat. Awk is underappreciated. Go learn awk. It doesn’t take long. And you’ll find some things that are surprisingly useful. Ruby has a lot of those things. But they’re a little bit harder to reach for than they are in awk.

I guess there’s a balance between…

[Inaudible] it’s not worth it.

Right. If you’re doing something… like what’s an example that you would use awk for? I use it on the command line sometimes.

It’s great… I would say… I’m trying to think of a good ex-… So, here’s one task that I was doing. I was taking files that were in a source format, going through them and stripping out delimited source code listings, and running them through a highlighter and then splicing them back into the original file. Not the original file, but like a copy of the original file. And awk is great for that sort of line-wise stuff.

If you’ve ever used the bizarro switch operator in Ruby which looks like a range but actually behaves like a control structure, that comes straight from awk. And it’s the ability to say, “Between a line that looks like foo in a file and another line that looks like bar in a file as you’re going through that file, I want you to basically switch mode when you’re between these two markers.” And it’s great for delimited hunks of text inside a well-structured text file. And you can build in awk, you can build these state machines that basically consume events where the events are lines from a file. And they switch state based on what part of the file they’re in. And do different things based on what part of the file they’re in. And yeah, I know that’s not a great explanation. But it’s surprisingly powerful for stuff like that.

That’s fascinating.

Yeah.

So, there’s clearly a balance there then, between when do you use a language that is highly suited to the task at hand and when do you use a language that’s highly suited to where your brain is right now because that’s the language you’re currently reading?

It’s tough right? Because like Avdi’s kind of pointed out, you don’t want to be the specialist in all the things. And if you can get stuff done in a consistent way, a lot of times even though there are better ways of doing it, you ultimately it’s the best way because you don’t have the mental load.

Yeah. I worked on a system once for some of the really deep thought about scheduling appointments. It called out to a Prolog program. And two people in the whole company understood the Prolog program. And the thing is, there are logic programming tools written in other languages.

And there are probably also C libraries that can be called into from any language with bindings.

Mm.

I think the concepts of the logic programming wouldn’t have been that hard to teach so some as other developers. But then we also had those concepts wrapped up in the syntax and the semantic roles of Prolog and the history of Prolog as well. Because it’s an old language and older languages have funky things going on.

And…

It made it really unapproachable.

That’s interesting. Now, I’ve seen that a lot in Clojure where, okay I feel like I’ve learned except with a macro system. But then I hit some code that uses Schema or it uses core logic or it uses… I’m blanking on the one that does go loops. And it’s like there’s this whole little sublanguage. Clojure being a Lisp supports little mini-languages inside. And I have to go back and learn and understand that sublanguage. But I guess it is better than shelling out to Prolog and having to learn all the Prolog and install Prolog on my computer so that I can try it.

Maybe.

It’s maybe better. It’s hard to say when it’s one of these things.

Yeah.

Yeah. Because if you implement everything that awk does in Ruby, pretty soon the language is so complicated that one person can’t know all of Ruby. And then you have Perl.

Right. Or well, you actually have Ruby. But…

[Laughs] Well, Perl suffers from that problem that there are so many ways to do everything that unless someone’s following particular coding standards, you can’t read someone else’s Perl without understanding all of the particular features that they chose to use. Scala has the same problem in a [inaudible].

Well, in Ruby we kind of went [inaudible] with DSLs, internal DSLs as well, for a long time.

Mmhmm.

Mm.

I think we’re learning a little bit, in some [inaudible].

Is that out of fashion now?

I hope so. I like to think it’s going out of fashion a little bit.

I like to think that people are acknowledging that it’s good to start with a nice API and then see how people use it and then build some sugar on top if it seems like a good idea, rather than starting with the sugar on top with no real API behind it.

By API, you mean classes that can instantiate functions they can call?

Yeah, like a well-defined object model. There are ways in Ruby to build internal DSLs where the DSL is the only API.

RSpec.

Yeah, well actually no.

No?

Because RSpec has a well-defined object model and API. Not everybody knows it.

Okay, I’ve just never seen it [inaudible].

But it’s there. It’s well-documented. And it’s what the RSpec sugar is built on top of. But you know, the difference is you’ll see one system where when you look at a definition of the DSL, each DSL method is like one line of code. It instantiates an object from the Object [inaudible] level and uses it. And then you’ll see another project where each method in the DSL is like [inaudible], maybe just 100 lines long. It’s doing all of those things that the DSL does. It’s not just arranging for an object from the well-defined object model to be instantiated.

I think you’re totally right. I see this in Scala too. Around here, some people have a tendency to jump straight to the DSL. But the DSL is really hard to follow. If you don’t know the DSL you have to learn the DSL. Whereas if you have an object model people know how to trace that to see the method and see what it…

Yeah. I think…

To see the object structure.

I think the equivalent in a Lisp, Clojure, or whatever, is you can come up with a nice set of welldefined functions that operate on some well-defined data structures. And then on top of that, you can build some macros that you write some really weird looking S expressions. And those macros do magic. And [inaudible] set of calls to those functions and those well-defined data structures. But you can also write a bunch of macros that just have all that logic inline.

Ooh. That’s true. And there at that point, you’re kind of conflating the view with the business logic.

Right.

Yeah.

You know, I’ve been wondering, to tie this back into the discussion on polyglot [inaudible]. Could this be considered maybe a downside of not having a polyglot architecture where you start trying to invent things within the system you have to do things? Like a DSL.

Oh, good point. Where you start building Prolog in Ruby or in Clojure.

Right.

Because you don’t… you’re reluctant to just use Prolog.

Great. I feel like I’ve seen some good examples of this, of things where there is a really good expression language that’s for a very constrained problem. And I guess the obvious example is just regular expressions, you know? You don’t build up regular expressions using some Ruby DSL. Now people have written some DSLs for that. But generally, you use the classic regular Perl-ish, grep-ish regular expression syntax inside a string. Well, effectively a string. And that’s just better most of the time.

Even though regular expression syntax is hideous, at least it’s fairly consistently hideous through many tools.

Right.

Such that it’s just worth it to learn it.

Yeah. And yeah, the knowledge translates usually.

I felt that way about SQL.

Right, yeah.

Because everyone builds a DSL on top SQL. And personally I get frustrated. [I would rather write SQL. I get frustrated by all of those DSLs.

In some ways, I agree. In some ways if it’s… so, there are some things that Active record does for example in Rails that I think are just really convenient. But when it gets complicated yeah, having somebody chain a whole bunch of stuff together, that’s really difficult to figure out. Whereas just one string of SQL would be much easier to parse?

Mmhmm.

Yeah. I definitely see that.

Yeah. The downside is that often when you’re dealing with raw SQL, it becomes harder to modularize your parts and make them composable.

Yeah.

Because then your tools have to be very clever about understanding what the SQL says so that they can compose it together without explosions. But yeah…

Right. In fact Avdi, this is a great example of what you said earlier with the object model. You said build the object model, that is the straightforward programming language compatible model first.

Right.

And then if you want an English-y DSL, put that on top of that. They did that wrong when they made SQL.

They started with the English-y DSL, yeah.

Yeah.

Yeah. And so now, everybody tries to put programming models on top of that, which yeah just think about that. Somewhere there’s a program that’s getting run based on this English-y DSL. And now we’re all fighting to put programs on top of the English-y DSL so we can just [speak program] to it in the first place.

Right, like if SQL had been defined at two layers, one layer is a semantic language of relations and the next layer was an English DSL built to construct that semantic language of relations, I think it might have worked out a lot better.

Exactly.

I will say, it is sometimes a good idea to build DSL first because it’s kind of the idea of readmeoriented programming. like if you have a particular language in your mind that you really think would make it easier to work in a specific domain, you might basically write your readme that shows that really easy to use DSL. And then figure out, okay, how do I make this work on the backend? It’s still important at that point. Let’s map these DSL commands to one line of code instantiates, that creates something in that object model.

True. And also, you don’t know when you start writing those DSLs how useful they’re going to be. If you write them as the object model it’s a lot easier. And then you can see how useful it becomes and whether it stays in production or whether it gets deleted next week because that feature wasn’t wanted so badly after all. I find this in Clojure.

Yeah, I 100% agree.

Yeah, yeah. I find this in Clojure where I could do that game where I just typing the code that I want to read and then make it executable. And then if I just add a few little tweaks like a function call here and there… it’s Clojure, so add more parentheses, it’ll work.

Yeah.

Then I could make that executable as simple functions with no macros.

The farther back I go in my programming history, the more I see myself wanting to make these really small games like concision, in the smallness of what I had to type.

Wait, are you saying your fingers are less lazy now?

Yeah, yeah.

The farther I go back the more I seem to be concerned with, I’ve typed this thing three times and I shouldn’t have had to type it three times. So, [inaudible] DSL that would have kept from having to type it three times. And as I’ve gotten older I’m more like, “Eh, whatever.” I still don’t like Java. I still don’t like the…

[Laughs] Java is the extreme of that, yes.

Yeah. I still don’t like the whole unnecessary repetition of the String array which is the string eh, shall be the string array that I have named stringArray.

[Laughter].

I’m starting to think that might make it easier to learn programming, though.

[Laughs] I’m not convinced. I don’t know. Convince me.

Okay. The convincing is I had my sister make a class. And the class had an initialize method that accepted a parameter which went into an instance variable. And then an outer reader so you could access that from the class. And then later, you call the class name .new and you pass it something. So, you have to know that when you say class_name.new it goes and finds a class and calls the initializer method. Then whatever you passed in the argument if it’s not in the parameter. Okay. Then that parameter is just an identifier. But then it gets assigned to something with an @ sign in front of it. And it’s important the name of the thing with the app sign. That’s the thing with the colon in front of it at the other. Which then you can then access with a dot in front of it when you call the reader on your class instance.

Yeah.

That’s really not a problem. But it’s sugar, right? You don’t have to declare your instance variables in Ruby. And you don’t have to make the explicit ghetto method. And that’s lovely when you’re experienced. And you know about parameters and you know about accessory. And you know about variables. And that @ sign clouds you in for the scope of it really fast. But it’s not simple.

No, no. Ruby is kind of a second rate language for [inaudible] programming in my opinion. It’s highly optimized for people that…

It’s sad because there are so many awesome resources out there.

Yeah, it’s true. But it’s highly optimized for people that have been working in an object-oriented programming language for many, many years. And it sort of optimizes for the set of frustrations that most people who have been working in an OO language for many years have.

So, that’s interesting. It says Ruby is a tool that’s optimized for people with a particular history.

Oh, yeah.

I’m curious. How many people in the audience was Ruby your first language, or pretty close to it, your first language that you used the whole time. So, I’ll chime in on this because I did Java, C++, C, and Assembly in College. But once I graduated from college, Ruby as my first big… it was my first professional language and let’s put it that way. As a professional it was the first language that I really used on a regular basis as a professional.

But you already had the concepts of arguments and parameters and objects and…

Oh, yeah. Yeah, I’d been doing BASIC in junior high and high school and Assembly in high school. And then I’d come up into Java and C++. So yeah, I knew the concepts. So yeah, it wasn’t my first introduction to those concepts.

So, in the chat Arthur asks what I think is a good language for beginners. I think any language that has a laser focus on limiting the number of elements, a very small set of concepts used consistently. The first ones that spring to mind are Smalltalk, the syntax of Smalltalk very deliberately can fit on a note card. And the semantics don’t take much more to explain. Scheme as the simplest of the Lisps I think. Or any Scheme derivative. Somebody mentioned Rackit in the chat. I want to say JavaScript just because it actually does have a relatively small number of concepts and it is incredibly accessible because it’s everywhere. But I’m iffy on JavaScript because it has so many gotchas. It has so many just irrational legacy gotchas.

And the error messages, OMG.

Yeah. And yeah, there’s that as well. I think it’s still very high up in the running just because its accessibility, its availability stomps on everything else. But yeah, I learn more towards like a Smalltalk or a Scheme. Even Python is honestly a lot simpler in terms of concepts than Ruby is.

So, there’s that.

Yeah. I’ve heard a lot of recommendations for Python because there’s a mother consideration in a learning language, and that’s how quickly can you do something useful? Which Ruby has fantastic stories for that. You can get up a website that’s useful. And when you’re learning you need to have that early success. And unless you get really excited about putting something to the console, Rackit’s probably not going to give you that.

The other thing that I want to point out is a lot of these have online REPLs of some kind.

Yay.

So, you can actually go to a weibsite and find somebody who’s implemented, TryRuby.org or something where you can type stuff in and gets feedback immediately. Yeah.

All of these are like ramps. There are a lot of ramps into learning a language, being able to do something useful, JavaScript just wins hands down there. But Ruby is up there as well. Those interactive environments, there’s a lot of those for JavaScript and for Ruby. Those help people get up to speed because they let them play. They let them see the results. They let them learn interactively. Yeah, and oh I wanted to relate that back to what we talked about earlier, error messages being a big part of that ramp. And the error messages are awesome because they ally not just on your first learning to learn and to play.

But also, when you’re learning it in order to dig through someone else’s code to figure out what they were doing and what it’s supposed to do. And trouble shoot this polyglot system that you’re working on that you didn’t write the whole thing. The ramps, especially the error messages, serve multiple purposes that way. They make it a language more useful in a polyglot environment. And they make it accessible to people learning it.

Yeah, one thing that’s really interesting when you’re discussing the error messages though is that if you’re in a polyglot system, you have to be very careful to make sure that the error messages reflect the boundaries. And what I mean by that is if you get something that you didn’t expect as an input or output from another system, then it’s got to be very clear that that’s what you did or didn’t expect. Otherwise you’re going to be digging through a stacktrace in JavaScript where in fact your problem is in your Rails app.

That’s a matter or our APIs, right? As programmers, we’re all language designers. When we’re producing [some sort of] API whether it’s at the class level or the service level that other systems are going to interact with. And we need to be careful about our own messages three.

Yeah. So, we’re starting to get to the end of our time. Are there eany other things we should talk about with respect to polyglot architectures. One thing that came to mind real quick, Arthur just put in there that they played with JRuby inside of a Java project. And that’s another thing that I see a lot in polyglot that people mix, like Elixir and Erlang, because they run on the same virtual machine. Or, you have the JVM and all of the languages that run on there including JRuby and I think there’s a Python version that runs on there. And a whole bunch of other different options that you can pretty much send messages and call methods through the JVM to something else that’s written in another language.

And yeah, you’re opening yourself to debugging pain there, Doctor [inaudible]

Yes. But at the same time, there are companies out there that have a large investment in the Java ecosystem .And so, they have all of the paid support versions of JBoss and things like that, or Tomcat. Rather than switch over and use MRI, they just run JRuby and the rest of their tech stack for the most part. Just winds up.

So, they’re doing waterfall architecture there when they purchase those big, open source… they purchase the paid version of, well anything. And then make other architecture all in line with that. I see that a lot.

Yeah. Alright. Well, I just want to give a shout out and a thank you to the Rogues coming on and chatting with us for an hour. This has been really, really interesting.

This was fun.

Yeah, I agree.