Garden City Ruby 2014 - Panel

HEMANT KUMAR: So I would ask our panelists
to come forward and chat.

So Chad is, Chad Fowler is the author of The
Passionate Programmer

and he has been a-

CHAD FOWLER: Yes?

H.K.: He's been like, he's one of the oldest,

one of the oldest Ruby guys around. He's embarrassing
me.

C.F.: I'm one of the oldest people here. Thank
you Colby (00:01:00).

H.K.: And next, Yogi. Yogi is principal architect
of Flipkart

and he has obviously worked in one of the
largest

deployment serve and supply chain in Ruby,
and yeah.

Next person I'm gonna ask is Baishampayan
Ghose, uh, BG.

Is he outside? Can you, can anyone? So. You
guys can sit.

C.F.: Yes, what?

H.K.: You guys can sit actually.

C.F.: He wants us to sit down. Sorry, I'll
sit.

H.K.: So, yeah, our next panelist is Baishampayan
Ghose.

He is a polyglot programmer

and he is CTO of Helpshift, a start-up running
from California.

And last I would like to call on Venkat Subramaniyan.

He is CEO of Mahaswami Software.

He has been programming in Ruby for like ten
years,

and for a real long time, so.

OK, so we'll start the panel discussion by
asking the panelists like,

what is your current language of choice primarily,
and why? Swami, Venkat.

Venkat Subramaniyan: OK, we use primarily
Ruby.

We've been using Ruby for the past, I mean,

writing bigger-sized products since six, seven
years.

But we use quite a bit of Java along with
it.

H.K.: Why? Like, why do you use it? (00:02:51)

V.S.: Well, see there is some very, like,

well-established libraries, like reporting
GINs,

and several stuff that you don't want to really,
you know,

try to match from the Ruby side.

So we just bring the best of both worlds by

cutting forward all the good libraries.

Jewels we have used quite a bit. Jasper reports.

These are all stuff for which there isn't
an equivalent exist,

and we just want to use the knowledge

and, you know, the well-established software
there,

for their purpose. So that's one of the main
reasons.

Baishampayan Ghose: So we use multiple languages,
but,

Closure is our main programming language of
choice.

We have been using it since I think late 2008.

We're one of the first companies to put Closure
into production.

We use Closure because a variety of reasons,
but,

I guess if I have to say name a few reasons,
that would be,

Closure lets me focus on the problem,

and it pretty much gets out of the way.

And there is a lot of focus on awesome things
like immutability,

data as a main construct for doing competition.

And of course it's a lisp so I get all the
power,

and it's also something that runs in the JVM,

so I can also leverage the awesome Java ecosystem.

So yeah, but, at the same time,

we do use different languages for different
needs.

We have used Erlang in the past, we use Go
as well,

and of course there is JavaScript and a bunch
of other languages.

H.K.: So do you think like, let's say,

Closure doesn't seem to be right language
for

how to write utility to you know like

do something on my OS X, for example.

If I auto-install something or manage processes
or anything.

Do you think like it's a right tool for that
sort of thing?

B.G.: So, to build your, if you want to build
a small utility,

you'd need a faster start-up time,

and that problem is inherent in JVM.

It has nothing to do with Closure, per se.

But Closure also has something called Closure
Script,

which lets you write whatever code that you
want to write in Closure,

but then the compiler compiles it down to
JavaScript,

and basically you can create a node.js application
out of Closure code.

You get all the flexibility and constructs

to build abstractions that Closure provides,

but you can target, you know, different run-times.

So you can run, you can build a shell utility
as well.

C.F.: Do you actually do that?

Do you like write command line programs?

B.G.: We've done it a few times. We've done
it a few times.

It's not something that we publicly do, but
yeah,

Nailgun is another upload that you talked
about in your talk, right.

And, so yeah, so that's what we do.

But there are other hacks, like tweaking

the boot class paths in JVM to make the start
up times faster.

That's what something learning new is in Closure.

There are ways of getting it, but yeah, you
are,

in a way, right that, by default, it's, Closure
is probably not a,

not the right run time for building shell
utilities.

H.K.: OK, so, before we move to Chad, like,
you said like,

all the power of lisp actually,

so, can you elaborate on that?

What do you mean by all the power of Lisp?

B.G.: Sure. So, how many people use Emacs
here?

Twenty percent maybe. You do?

C.F.: No, I don't personally.

Never.

B.G.: Never? But you talked about Emacs

as well as good software systems.

C.F.: Not to use, though, just as an example.

B.G.: Just to talk a lot. Anyway, so Emacs
as a software

is thirty-five years old today,

and still is in production, so to speak,

you can still use it.

So, what can we learn from Emacs?

Well, the language is always available to
use,

right, so if you compare it with, let's say,

Python or Java, there is a difference between

compile time and run time. When you are running,

the language is not available to you.

You cannot, you know, manipulate the code
itself

while it is running, or generate new code,
dynamically.

So that is one thing that lisp dialect exploits
by design,

because they have something,

a property called homoiconicity,

which basically means that the code and data

are pretty much the same. Even though they
may not be identical,

but, for all practical purposes they are the
same.

That means when a Closure code is running,

it can manipulate itself while it's running,

and it can maybe generate new code, optimize
something away.

So basically it lets you write code which
writes more code,

so, and that is something which is always
preferable.

It is better to write a code that writes more
code

than to just write code. So, and there are
many other features

that lisp has, for example, the language itself
is so simple,

like there are just few primitives to understand
and learn about.

Syntax is pretty much non-existent,

and very simple to understand and learn.

And that really reduces a lot of cognitive
overload

that some languages might introduce.

So yeah, I mean, these are probably a few
superficial advantages.

I can go deep into it, but maybe we can talk
about it after.

H.K.: Yeah, so, Chad, like, what is your poison
of choice?

C.F.: My poison of choice?

H.K.: Yeah.

C.F.: I guess, it's hard to answer that question.

I don't have an answer, right?

The one single answer I could give you is
anything except for Ruby.

H.K.: OK.

C.F.: And I mean that very seriously.

I remember in 2007, I was at MountainWest
Ruby Conference,

the first one, that Coby was talking about
earlier,

and I did a keynote, my first- no, it wasn't
my first keynote,

it was my first Ruby Conference keynote.

It was about, like, what do we do next, after
Ruby?

And I was already deep in the like toil

and stress of being worried that I identified

too heavily with Ruby, in 2007.

So I wanted to like get out of the Ruby thing

and not be the Ruby guy,

and I'm still desperately trying to do that.

But, no, I mean, like, I said,

when I was speaking earlier,

I'm using Closure, Scala, Node, Java, Objective
C, Ruby, Erlang, everything,

at work right now. I think probably what I'll
learn next

really seriously is Objective C.

But I'm going to try to use it, even on the
server,

as like a language to develop services in,

just as an experiment so I can learn it better

and do better job on the clients.

H.K.: So like not Ruby?

Is it because like you already had kind of
a Ruby like,

you obviously work with Ruby as like with
the,

along with Dave Thomas, and all of these guys,

you were one of the earlier adopters of Ruby,
so like, are-

C.F.: Yeah, because I will never learn anything
else about Ruby,

cause I know everything.

No, it's- I'm always suspicious of myself

when I identify too heavily with anything
extrinsic to me.

Like for me to say I am a Ruby programmer-

if I say that, I feel bad, and I know that
I've made a mistake.

I know that I'm creating some rigidity of
value

that is ultimately counter productive to my
success

and to the success of people around me.

So like I've been doing more Java in the past
month

than Ruby, which I used to do full time in
1999.

And it's been a really good freeing thing,

like I am not a Ruby programmer, I am a programmer,

and even that is kind of limiting,

because I'm more and less than that at the
same time.

So it's not so much that I'm worried about
Ruby itself,

it's that I'm worried about putting myself

into a bucket that I can't get out of,

even if it's a subconscious problem.

H.K.: OK, Yogi. Yeah, so what do you-

Yogi Kulkarni: Sure.

So, if you're asking about personal choice
then,

sure, you know I like coding in Ruby.

I just love it because it's compact.

I feel the translation from my thoughts to
code is shortest in Ruby,

so it just feels very natural.

But that said, I think I've moved the last
seven years

from being a kind of a language geek, of sorts,

not really, but, I used to love program language
theory

and getting into stuff like that,

but to actually not caring too much about
it.

I think programming languages are good,

and they kind of get you excited,

but when it comes to actually solving hard
problems,

it's the ecosystem that matters around that
language.

Things like the tools, the profilers, the
monitoring tools,

debuggers, you know that's the stuff which
no language

is gonna save you when you're in production,
right.

So you just need to have that,

the maturity of an ecosystem is really important
there.

Which is why we keep going back to the JVM
over and over,

and even the new languages are being built
on the JVM as,

it's for exactly that reason.

But among the newer languages on the JVM,

I'm actually surprised that I've- so, I'm
kind of

intrigued by Closure and Scala.

We actually looked at Scala very carefully

for the system I spoke about.

But I didn't think it gave the kind of jump.

I felt was kind of marginal,

the improvement over just doing good Java,

that Scala gave, that's arguable.

There's a lot of language features there,

possibly too many language features,

which is one of my concerns.

But Closure, we looked at that also,

but we didn't look, we didn't actually

take it that seriously, because of basically

the prefix notation being too alien.

We wanted something block structured

for people moving from Java to Ruby.

So I think, yeah,

those are the kind of things that are on my
mind.

H.K.: OK. So, Ghose, do you- I'm gonna call
you BG, OK?

Yeah, so, BG, do you ever like,

the programming languages do not matter all
that much,

do you think the state of it are like if you
improved like-

B.G.: I'm told Alan Pearl is here,

and he basically said that programming language

basically shapes the way you think about solving
problems.

So even if you do not use Closure or Scala

or whatever fancy language that comes out,

you should try it out because ultimately

you're trying to solve a problem, right.

You have the problem at hand,

and you'd like to look at the problem from
different perspectives.

See if you only have one way of looking at
the problem,

then you know, by repeating the same approach
a

thousand times is not going to help you.

You should look at different ways of

maybe approaching the problem,

and even understanding the problem itself.

Simple example, parallel processing can be
done using threads.

You can use quarantines.

You can use CSB, you can use Actor.

What should I use, given any situation?

So even if that- if I don't even know about
Actors or CSB,

I'll never be exposed to that line of thought,

so that code is basically to learn a language,

not to just switch wholesale to that language,

but to be able to appreciate new ways of looking
at solving problems.

Y.K.: So I think that's a great point, and
when I,

kind of, I missed mentioning this, see,

when I was a program language geek,

I think the one great important inspiration
for me was SICP,

right, structural interpretation of computer
programs.

And that's something which, again, goes back
to what is,

what are the fundamental abstractions again,

you can reach out to solve problems of different
natures, right.

And that was the crux of it, you can use data
as abstraction,

procedures are abstraction,

stream processing and actually creating languages
of your own.

So the point is that there are far more paradigms,
right,

and I think getting a grasp of those paradigms
is very critical,

but for that you don't necessarily need to
go

every new languages around for you to see
what

ideas are implemented well in which language,

what can you adopt.

Take for example, after reading SICP,

I think my Java programming became so much
better,

I have said using more anonymous functions
or classes,

yeah, that's ugly but, so yeah. So I totally
agree with that.

H.K. So we, you talked about like,

how many of you heard of like something like,

or used a after patch in full or any sort
of concurrent programming,

can we have a show of hands?

OK, so, anybody wants to explain like yeah?

B.G.: There is nothing to explain.

Just go and read on Wikipedia.

C.F.: Or DFM.

B.G.: Or DFM, yeah.

H.K.: So. Which language you think like does

the whole active pattern problem programming
properly?

B.G.: So Actors are well implemented in Erlang,

and Echo, if you are using Scala, so take
a look at it.

And again this is not a single bullet,

again go back to your own basics,

Fred Brooks told you guys many years back,

go back to your basics. (00:16:28 - ??)

So Actors will not solve all kinds of problems

for you but you should be aware that there
is

another abstraction that I could probably
leverage

to solve whatever problem that I have and
can.

CSP is another thing that I briefly alluded
to.

That's something that is embodied in Go.

So Yogi just said that you don't need to learn
a programming language,

but look at systems where all these ideas
are well-implemented,

but I would also argue that not all ideas

can be implemented as well in all languages.

So you cannot, for example, Java does not,
I mean,

Java has something called Lambdas, but Java
hasn't,

does not have any of those functions.

So if I really wanted to understand the value

and virtues of any of those functions,

I can't learn it through Java.

The closest I'll get to is dependent injection,

but that is yet another level of abstraction,

which basically removes me part of the way
from the core goal, right.

So there are languages which are design to
level certain principles.

Go for example is built on top of CSP,

and the channels are a first class thing,

Erlang, also has something similar.

So maybe learning those languages will expose
you

to those ideas much better than something
other language.

H.K.: Chad, you want to-

C.F.: Yeah, I think from a,

from the perspective of learning the paradigm,

I think Yogi is lucky that he is smart enough

to read a book and then get all these things.

My experience is not the same.

I'm honest about that.

I don't think you're not being sincere,

I think some people, including me,

have to actually use the thing,

not just the language but the paradigm.

So like I can read about Actors in five minutes.

I totally understand it from a theoretical
perspective.

But it takes awhile,

and it takes actually trying

for me to really get where it makes sense,
you know.

B.G.: To appreciate it.

and also to appreciate the edges of it.

So I actually think like,

I've been trying to get out of Ruby

as I've been saying.

I mean the truth is I have learned,

I don't know how many programming languages

since I started doing Ruby,

but I have never stuck to one.

I have, but you know,

I have rarely stuck to one long enough to
where

I really, really thought like that,

and like the best case scenario for me

in picking up these other paradigms is to
like

get so into Go programming that then I go
back to Ruby,

and I go to do something, and I don't try
to implement channels,

I just say, damn it, channels aren't here,
I'm frustrated now.

And it, I see that this language isn't perfect

because no language is.

But you can't get to that point,

and that's like where the maturity comes from,

where you're not in love with any certain
thing,

and you're, you see the entire landscape,

and this is a part of why I can't answer the
question

of what my go-to language is right now.

Like I'm doing a lot of Scala because there

are certain things that I'm working on that
work really well with Actors.

Like I can conceptualize them with Actors
and that's what I'm gonna-

I'm gonna write it in Scala because we already
have the JVM,

so therefore it's easy to do Scala versus
Erlang.

H.K.: But still there's a problem here.

Like the way you approach programming language

for example like in Ruby world for example,

like Eric Hodel or [00"19"54] ??

these guys are maintaining tools that you
have written actually,

for many years back, and those tools all have,

like for example Ruby gems didn't have proper

test suite for awhile actually, and like the
building-

C.F.: That's because tests are a design smell.

That's why.

H.K.: My point is like building a tools like
of a language,

around a language takes time actually.

Do you think like for example like Eric Hodel

and these guys are probably working with this
thing

for like nine years or so,

and they're still doing it, right,

so how do you like, if, how do you fix that?

Like you need to stay long-term in a language

to really change it, right, or like am I wrong
here?

C.F.: You mean you need to stay in it to change
the language itself?

H.K.: To change the language or build like

the infrastructure or the libraries, gems
to support it.

C.F.: Yeah, somebody does.

It doesn't have to be me, right.

B.G.: Again, so let me add something to what
Chad said.

So Chad said that I don't want to remain a
Ruby programmer.

I think what he means is the Ruby mindset,
OK,

or any mindset thereof. It's not about writing,

just coding that language.

So you can still be a Ruby programmer for
twenty years,

but that doesn't mean you keep the same mindset

all the time, right. There are things which
are not even new,

but we are not discovering those things

because we are not looking beyond Ruby.

H.K.: Can anyone else, sorry -

can anyone else carry the mic

and give it to the audience actually because-
there's no mic

B.G.: It's not just about Ruby, per se, right,

it's about any- it's applicable to any language,

like JavaScript, or Scala, or even Java for
that matter.

V.S.: So this, this is kind of intrinsic to,

something intrinsic to all we actually select

a language or set of languages to develop
these tastes,

depending on the nature of the problem,

I guess you pick what is called like a language

to which other languages can actually circle
around

and support various smaller problems,

whereas this core language that you're picking
is solving

like majority of the nature of the problem.

For example, web application,

but you got some parallelism stuff

that you need to do or you got some

functional programming stuff you need to do
like Scala,

so you probably pick one language, well like,

Ruby, as to kind of like hold everything together,

but you do have these other languages in which

you actually solve problems differently.

So it's more of- but different problems in
some contexts,

Scala may be the code language,

and you may want to wrap it around Ruby

a little bit or maybe other things a little
bit as well,

so it's more of starting from the

architecture of the nature of the problem,

but being polyglots, you have this choice
now,

not to implement and struggle with one language

like you just talked about example, but I
wish

channels were there in one particular case.

But now you could pick, if you can become
a polyglot

and learn these other languages to a good
degree,

you could pick other languages to compliment
it

and solve those specific problems. So this
seems

to be an approach that's kind of intrinsically

developing right now.

QUERANT: I have a point very close to what
you're saying.

Like based on, like especially what you said
about languages, right.

Like a general message could be use the right
tool

for the right thing kind of a thing,

but the problem could be that not everyone
can pick up,

so when you go into a code based on,

let's say, five different languages are being
used

for the right kind of problems,

so they are doing the right thing,

but for someone to go into that code base

and pick it up would become very hard right,

because not everybody's turned in that way.

So that's like, so polyglot comes with a very
heavy cost

of being able to replace yourself.

At least that's been my experience,

so that's my first question,

and like adding onto that like it's very easy

like you said you know like to pick up a book,

read through it, go through some you know

tutorials or whatever it is but like Yogi

was saying how his team had a,

they needed about three to four months

to start writing idiomatic Ruby, right,

and that is a big deal,

because in those three to four months

it's critical that you keep churning out code,
right.

You'll kill yourself or you can't

come to a halt because now you're getting
this new language on board.

You guys had the luxury of having an existing
system,

which was, and you were replacing that system,

but that's not necessarily always the case.

You have to write, so- yeah, so

H.K.: [indecipherable] (00:24:14)

QUERANT: Yeah, so like my second point was
around, like,

that was the first question for polyglot recruiting

and things like that would become very hard,

how do you know that.

Second, it's easy to pick up a language on
a theoretical sense,

but to be able to start writing idiomatic
programs

while also developing production-quality code,

do you guys have any experience about how
you got that working?

H.K.: That was the second question here that

I was about to ask actually, which was like,

at least one part of, but like,

how does an organization adopt a new you know
like language?

For example in Flipkart, like,

or the company where all of us work,

like you know like there's a,

in January a programmer decides I'm going
to build

this program in Erlang or I'm going to build
this thing

in Go and there's nobody else Go,

nobody else doing Go,

so as like you guys,

a senior person in your respective companies,

so do you listen to that guy or -

our deployment system is attuned for like
JVM deployment

or Ruby deployment and whole package management
or whatever,

and don't write this.

So there is like an aspect of like adopting
a new technology,

hiring, you know like the skill, the idea
of entry,

like in code business which are like- so how
do you tackle that problem in general?

Y.K.: So it's a hard problem, right. So at
Flipkart,

we were already fairly polyglot,

for example we all, the website is in PHP,

the search engine is in Closure,

the UGC system is written in Scala,

Java is all over the place,

Ruby came into the supply chain,

node.js is there in the seller platform and
more.

So we were already there,

but we actually ran into a few problems there.

So when, I think the question of technology
selection

is actually quite critical.

Very often a lot of it is driven by,

is mostly blog-driven decision making,

and that is, that can be quite scary.

So we've started to put in some kind of process,

it's hard, it's not worked so far.

We've been trying for one year

and the process is like,

you know OK go up to somebody else in the
team

and just ask them, just bounce off your thoughts

first before you kind of take up a new system,

a new technology.

So we tried to formalize that, we failed miserably
at it.

But right now what we have set focus on is
interfaces.

So we've become fairly diligent about

making sure that the interface and contracts
are good,

building systems, and then the systems can
call independently,

whatever tech stack they use,

as long as the team is committed to it,

that's not a completely way-out language.

So we moved from being predominantly

thrift-oriented interfaces to HTTP,

and that's added a huge amount of value.

QUERANT: Can you say what thrift is? (00:27:06
- indecipherable)

Y.K.: Sure. So Thrift is a binding protocol

which came out of Facebook I think,

so it basically gives you both RPCM point

and a data utilization mechanism,

so it's basically like Corba,

but it's, so it basically gives you a fast,
uh-

C.F.: These people are too young for that
actually.

Y.K.: Oops. What is Corba? Yeah.

C.F.: Do not ask that question.

B.G.: That'll be a big panel discussion by
itself, right.

C.F.: You have to be at least twenty-one to
hear

about Corba and not everyone in this room
is twenty-one.

Y.K.: Protocol buffers. It's more like that,
OK anyway. So-

C.F.: I think connection is open too, right-

Y.K.: Sorry?

C.F.: You can keep a long-running PCP connection
with that.

Y.K.: With Thrift you can do it, yes I think
so. Yes.

C.F.: You can keep a long-running PCP connection
open too,

which makes performance better than HTTP in
some cases.

Y.K.: Right, but if you already moved to HTTP
1.1%

connections that's kind of taken care of.

So yeah most modern libraries have that. So-

H.K.: We are digressing I think-

Y.K.: Yeah, where were we?

C.F.: Let's keep digressing, let's go.

Y.K.: We were talking about the language and
like the context-

Y.K.: Right, so we become pretty delusioned
about contacts,

so HTTP and the, and actually having sensible
rest end points

and resources has become kind of defacto,

and that's actually helped a lot.

So systems within Flipkart are extremely open,

you can actually query them pretty easily
to extract data,

not push data to it, but yeah, so I think
that works.

And then each team can independently take
decisions

with some guidelines at hand,

so we kind of brought people towards

a few languages and technology stacks that
have worked,

but not insist on it, so if somebody goes
out and says you know,

Elixir is also meant for these reasons,

we'll at least ask them that OK,

does it check a box on tooling,

on some mode of profiling or monitoring,

and basically a small check list of sorts.

We have not implemented this yet.

It's probably going to-

shit's going to hit the fan when we kind of
suggest it,

but yeah that's the idea.

C.F.: Our solution is a little more messy,

I guess, as you would probably expect from
me.

But like you said, not too way-out language,

I like the way-out languages, and I would
like everyone

to be able to do any weird language they want,

cause I hate that being a thing that people
talk about

and are frustrated about at work.

Such a stupid thing to worry about.

So as I talked about in my talk this morning,

I will tell developers, any language you want,
fine,

go ahead, but you have to write very little
code,

it has to be a very small well-defined thing.

We are also working very hard on the interface
definitions,

and that's why I was talking about that JSON
Schema validation stuff,

to add one more layer of monitoring to it.

But most importantly, I want to hire people
that I trust,

and I want to show them that I trust them.

So if someone really, really wants to do something
in Elixir,

and I have one guy who really, really wants
to do something in Elixir,

he actually proposed it for one project and
I said fine,

whatever. Then we realized we needed to do
a lot of stuff

that talked to Amazon SQS, and there was no
good Erlang library

or Elixir library we could find,

so we did it in Scala instead, because it
was easier.

But he made the choice, not me, and so,

like, we have one thing in Lua even, in engine
X.

I would love to have like Assembly and Objective
C on the server,

you know any, maybe, I don't know, Visual
Basic,

does that still exist? We could do that too.

Off-screen: It totally does.

C.F.: Yeah, it does. All right, awesome.

Server-side Visual Basic.

B.G.: So I guess it's more of a cultural problem,

it's not really a technical problem.

And I think it can be solved by setting the
right expectations

and what Chad said, totally agree. Trust your
team members.

Give them the opportunity to try out new tools,
and you know, prove them.

So what we do is that, when a new programming
language

comes out, any way as such we are using a
cool

and really hip programming. But if something
cooler comes out,

like, I don't know, something might come out
tomorrow.

But we always have encouraged people to try
out new languages

and maybe build a internal project and show
it to us

and we take a collective decision in such
cases.

But, yeah. So I think it seems more like a
cultural situation,

and as far as hiring is concerned, I think
it's better off,

better if you hire programmers, instead of
Ruby programmers

or Java programmers, or PHP programmers.

Get people who can write code and who can
learn new things,

because even in the Ruby world, you are doing
new things every day.

If you cannot learn new tools or techniques
then you are stuck.

QUERANT: (indecipherable - 00:31:57)

B.G.: A code base, you are talking about a
code base.

QUERANT: (indecipherable - 00:32:04)

B.G.: So idioms are formed over time, right,

and they are also learned over time.

So if you are working on a sufficiently complicated
code base,

any way will take you some time to grok it,

if there's and existing code base.

Now if you were trying to learn something

and to build something fresh.

It will take you some time, there will be
some iterative-

some iterations, right. That, I think is perfectly
normal.

C.F.: Yeah, I actually meant to answer the
idiomatic thing.

If it works and everyone can understand it,

I don't really care.

Like let it look like Java code written

with Ruby syntax. Doesn't matter if it performs

and the person enjoyed doing it and it,

you know, didn't take them forever,

and it's not completely confusing.

But, and my answer to that is keep it really
small.

If it does, it doesn't matter if it's idiomatic
at all.

H.K.: But there's like-

B.G.: Another thing, just one thing that I'll
add is that,

how do you really define idiomatic code, OK?

A code in which you are able to leverage the
features

of a programming language the best is idiomatic
code, right.

So if you're championing a programming language

you are trying to introduce the new programming
language to your company,

and of course you'd like to exploit all its
features, right.

Unless it is handed down to you by your boss,
right.

So if someone is championing a new programming
language,

it's his prerogative to you know to learn
what the idioms are,

maybe figure them out over time.

H.K. This not working?

B.G.: Yeah that doesn't seem to work.

V.S.: So it's gonna be a slow process, you
know,

obviously we just talked about lots of languages,

and the key thing is are we doing in house,

we have control of the deployment environment,

versus, we are gonna consult.

So for example, Flipkart, or, in several cases,

that there's a lot, you're in control of the
whole thing,

that, and you basically decide, or,

you live with the consequences of the whole
thing, right.

Then when you're dealing with the customer-based
solution,

obviously there's a lot more constraints as
to,

you know, he would look for somethings that
he can

add more people to work with as opposed to
just you,

and what if you can go away,

and in-house holds the same problem.

So probably to start with just learn one more
language.

Just learn one more language and start using
it,

and it's gonna take some time, like you said,

it's just cultural thing, you know.

Particularly in India the context is not just,

you know, just start with one more language,

try to use it in deployment,

so it doesn't look like you're grabbing this
opportunity

to as many language as possible into solution
you build,

just for the sake of learning new things.

But just do one more language, carefully.

But in order for you to do that

you probably will have to casually learn five-six
languages.

And you may want to pick that language

that you want and it's gonna be a slow process.

You're not gonna be able to finally deliver
all this,

and then you know, introduce a new language
just like that next day.

C.F.: Yeah, when I started learning Ruby,

I started using it in 2000 network,

and it was to generate Java code,

because no one would let me deploy Ruby.

So I just wrote Java generators

and I wrote everything like as a DSL in Ruby.

V.S.: Yeah absolutely.

My first experience with Ruby was not really
mainstream.

We were just doing, it was called load disk
conductors.

It was an OpenSource thing that we were just
doing.

So what we wanted is we wanted to drive these
command lines,

and Ruby was a language to do that.

So there are other opportunities for you to
use

new languages may not be in your main code
base,

all the supporting tool systems as well.

So there's a lot of opportunities,

so you may not look at it as,

can I change my main language, or how soon
can I do it?

K.H.: So-

Y.K.: So, one of the, I don't know,

this is a thought, this has been kind of crossing
my mind repeatedly,

and kind of worrying me, also.

So I used to be kind of involved in the language
choice wars a lot,

and always on the now try out something new
side.

And I've kind of discovered a completely

different way of working at Flipkart,

and some of the other people who've been there.

They kind of shook me out of,

maybe my Thoughtworks influenced it in a certain
way.

So, and there's a very key point when that
happened.

So I think the difference was this, right.

The take-away was that,

if I'm arguing about a programming language,

I probably don't understand the problem domain
well enough, right.

And I've seen cases where systems have been
built

which go fundamentally towards the problem
being solved as really about,

and modeled the code abstraction so beautifully,

that then, or it identified the co-op section
so beautifully

that it doesn't matter which language you
implement it in,

because that problem is solved.

And even before we started implementation
that is beautiful.

I think with this giant perspective,

I think somewhere that has got lost.

We try to kind of get into implementation
much sooner.

So if I could actually go back and say what's
the most,

my favorite programming language,

I think I would say domain-driven design actually.

I would actually just recommend people to...

oh and actually do that on my team also, too,

actually read that book and try and apply
it.

Because I think a huge set of wins are possible
from that,

without even going down to the programming
language level.

C.F.: Yeah, the programming language is a
tactical choice,

in most cases, right, but the domain,

it's like what you were saying about performance
earlier.

You could use Java or you could use JRuby,
doesn't really matter,

because the database is gonna be slow, right.

When it comes to application design and architecture,

it's really a hierarchy, so domain-driven
design is

at a level higher than the languages.

I would still say that the languages make
you think differently,

and some languages suit different domains
better,

and having really open-mindedly going,

gone back to Java recently for various reasons,

I can tell you that it's terrible to use,
it really is.

It wastes my time compared to Ruby

and compared to Scala and compared to more
modern languages.

And it's not a knock against Java -

Java's older and doesn't have those benefits.

So I think tactically, it's a bit of an exaggeration

to say that the language doesn't matter, but
I get your point.

Y.K.: Sure. So just as a counterpoint to that.

Actually having gone from Ruby back to Java,

there's a few very low-latency systems that
we had to

build out recently and those are built with
some of the newer Java stacks,

like say dropwizard which has got Hibernate
integrated into it,

and Netti and, so it's basically a complete
stack

and actual systems and the designs that came
out of it

were actually pretty good,

and I was surprised and actually happy

to go back and look at Java.

And I actually enjoy looking forward to Java
ahead.

More than Scala in a sense.

H.K.: That's good, because-

So the Java aid that you mentioned and then
Scala.

So there's a couple of things

like if you talked about this Java like and
Scala like,

why would you choose like, for example, today,

like Java it is not released.

But what would issues like, is there any reason
to choose

like Scala over Java now actually?

Because now for example, (00:38:57 - ??)

is a good system, but it is usable from both
the languages,

right, so is there any reason to pick- Chad?

C.F.: Yes. So the question is,

is there any reason to pick Java over Scala,

or Scala over Java. Does one win?

H.K.: No, no, no, no. Just Java, like Scala
over Java, like-

C.F.: Is Scal- or, should you actually,

because of Java aid, does Scala need-

H.K.: Or Java seven, yeah.

C.F.: Java seven, then yes. Like.

For me I see Scala as like totally over-engineered,

in the same way that Yogi almost said, but
like,

too many features. But, and I'm even writing
a book about it,

but I kind of hate it.

That said, you can program Scala like Java

with less annoying syntax. You can do that,

you can make it be like a Java program,

and if you do, I would argue very strongly,

and maybe, and this is subjective

and maybe even kind of fashion-oriented,

I would argue that the Scala code is better
to look at

and easier to write than the Java code.

There's less typing, and I mean that in two
sense.

Less typing on the keyboard

and less having to explicitly type because
of type inference.

I'm sure, and like with Java seven there are
Lambdas,

with Java 8 I'm sure it's gonna be some sort
of

anemic thing that doesn't quite work the way
we want it to.

It's perfect in Scala.

There's a lot of great stuff about Scala,

as a next evolution of Java.

But, you can also, like Ruby,

with meta-programming and eval and all the
crazy stuff you can do,

you can completely shoot yourself in the foot
with it, too.

QUERANT: So, when we compare these languages,

like Java and Ruby and all that,

the thing that we kind of focus on is the
amount of,

volume of code. Volume of code doesn't lead
to the ease of understanding.

One of the thing that Java really does well

is things are so simple that there's no,

there's implicit stuff happening behind

the scenes and all that. And very, very well-factored
Java code

is not so ugly to look at.

We have written all small methods

and composed stuff out of it.

It's not so ugly to write or ugly to look
at it. So-

C.F.: I would like to answer that

even if you're not asking me,

cause I could imagine myself saying that

if I were in the audience.

But right now I strongly disagree with you.

I think Java is simple as a language, yes,

but what it leads to is, because of its lack
of flexibility,

it's not the volume of code that I hate -

I mean sometimes it is, sometimes it's literally
because

I have to type date date equals new date.

I don't need that.

But it's also the ability to be expressive,

and to me that's where Java strongly lacks.

It's pretty good as a system language, like,

at the point where you decide you need to
make that distinction,

but maybe as things get faster you don't need
to anymore.

But I believe that the abstractions that people
end up creating for Java,

at least idiomatic Java, like in the Java
world,

idiomatic is a bad sign, I would say,

because it leads to this kind of pattern soup
thing.

And it's true that you can reason about it,

because it's statically typed, and there are

less opportunities for meta-programming,

but it's a slow process in my experience of
reasoning about it,

because you get so far away from the domain,

creating all these factories and interfaces
and crap,

just so that you can make it testable and
plugable,

that it, the actual logic and the core of
the business gets lost.

Do you have a- anyone have a point to make
on that?

B.G.: So yeah, I totally agree with Chad here.

Java the language is designed to be very simple,

but at the same time it's also very rigid.

So imagine explaining philosophy to a kid,
right.

The kid probably has a vocabulary of maybe
hundred words.

How do you do that? You cannot discuss the
existence of God,

you know, or maybe the nature of knowledge,

in front of a kid, because the kid doesn't
have the vocabulary

that you need to communicate with that child,
right.

So what you end up doing is over-simplification.

So by the time you simplify the concepts to

the primitives that the child can understand,

you're far away from Aristotle and Plato,
you know.

So that's the example that I give you.

QUERANT: I have a question.

At what point do you feel comfortable or something

like a threshold level for new languages to
be used in production,

you know, like, there are some languages which
are

coming up now but you still you know

that it's not something that you use.

As for me I would probably look at an example,

if I would say OK, there are quite a few systems,

big huge systems based on Ruby, I could recommend

it to someone people who are comfortable say
if

they say it is OK if I use Ruby yeah say because

there are people who use it. But at production
level

when that new language is- at what point do
you feel

comfortable to say that, OK, this is viable
to use

in production?

B.G.: Fantastic question. I would say that
this is a

case that you need to develop over time, and
I think

it comes with experience. The more you learn
of different

programming languages, the better you get
at evaluating them,

but having said that, community support does
matter,

based on-

(00:44:36 - dead audio - 00:44:37)

OK, you can have a language which can have
a

huge community around it.

That does not necessarily equate to the language
being awesome, OK.

Documentation is also another thing, ?? (00:44:45)

is also another thing.

But again I would say that one of the ways
is to really see,

what is the USB of the language, what kind
of problem

is the language helping you solve, OK. If
you see that,

it's like you already know Python, and there
is Ruby,

not really very different, honestly.

So, but if you see Go, again, very different,

a lot of interesting concepts, and so you
might

find problems where that language might fit
in just perfectly, right.

So it's OK to maybe wait for a production
by a larger community,

but sometimes you have to be that champion
yourself, right.

Someone started using the language first,
when Ruby came out, right.

(00:45:27) was the guy, probably.

That's why he's worshiped today.

So why not be the (name) yourself.

QUERANT: (indecipherable - 00:45:37)

Y.K.: Yup. Yeah, so I think it's,

there are quite a few kind of milestones for
a language

to go through, but I think the most critical,

so again, it depends on the kind of client

that you're kind of suggesting this to, right,

like if it's a small start up then sure,

you have a lot more flexibility.

If it's a larger system, it has to scale,

you got different constraints.

But I think by and large the existence

of a very low latency production profiler

or on-time run system is probably that milestone.

The moment that it is in place,

a profiler which can actually run in production,

for that language, I think that marks a very
critical

milestone when the language starts evolving
at a very

different pace. Because you start kind of
finding issues

which you never had been able to find before,
right.

So for example, with both tools, we've been
able to do

amazing things in production with Ruby, which
was just

not possible before we knew, even the commercial
ordinative,

like ?? (00:46:35) for that matter, right,
so either a

commercial or opensource production profiling
tool I

think is a pretty significant milestone.

QUERANT: I have a couple of questions here.

B.G.: Right, Yogi.

Y.K.: I don't know. Haven't you seen production?

B.G.: The production level compiler which
you can plug into a running system?

Y.K.: So there are-

(00:46:58 - dead audio - 00:47:29)

B.G.: Yeah, but those are Valgrind but, which
is not probably-

Y.K.: Sure.

B.G.: I think, what I will say is that,

Yogi is talking about the presence of a profiler
being very important.

I think again it depends on the domain that
you are in.

What kind of company you work for, what your
challenges are.

It could just be documentation for you. Right
or it could be

just the existence of a all-out library for
you, right.

So I think it depends. The answer, real answer
is it really depends.

QUERANT: I have a question. Like when do we
actually

choose a interpreted language versus a compile
language,

is my first question. Like for example,

Ruby's interpreted language, and like Java
is kind of both,

like when do we actually choose that one is
the first question,

and second question is-

H.K.: Just ask one question. Please ask one
question.

QUERANT: Yeah. The question is asked.

Y.K.: So, OK again this is, as Baishampayan
said,

it's kind of a black art. But roughly the
euristics that I used were,

is primarily driven by is the system gonna
be

CPU-bound or IO-bound? What kind of latencies
do you need? Do you want

(00:48:27 - dead audio - 00:48:42)

I'd probably go straight away to

Java or any other static-type language,

which gives those kind of performance.

So I think latency is one. I don't know - you
might-

B.G.: So I would say that the differences
between

interpreted and compile languages, they are
kind of

like blurring these days. I think you, what
you really mean,

is a native language versus a language that
runs in the VM.

OK. So I think VMs are as fast as natively
compiled languages today.

And so for example, one of the lowest latency
languages

would be Erlang, but it's not really a natively

ompiled language for that matter.

So again, Yogi is absolutely right, it depends
on the problem.

If it's CPO-bound, maybe you should use a
language

which spits out a native binary or maybe

has a very fast git compiler inside of VM.

Or if it's IO-bound, which most web-applications
are by the way,

then just use Python, Ruby or whatever, or
JavaScript.

C.F.: Yeah, but in, it is a blurring not only
of that boundary,

but a blurring of concerns.

So like you said you have never used Ruby
for something that

requires that low-latency. That's because
Ruby's not fast enough,

not because it's an interpretive language,
right.

If it were, yeah, so I would personally say
on anything where

I don't mind having the source code present,
which means any

server-side thing for example, I would use
interpretive languages,

because it's a pain in the ass, I don't want
to do that.

And what all of these things do is the answer,
effectively

just compile it for you, anyway.

QUERANT: My question is for all panel members.

From invention of a competitive we're seeing
that

there are so many languages came and gone,

and each language right on the veil,

are serving out their time.

I would say that today Ruby is one of those
languages riding on the veil.

C is the only language which is there for
a long time,

and it is from the starting of the computer
still it is there.

So my question is, how long do you think that
the Ruby will be last,

and what is going to be the next veil? Will
it be Closure, or Scala,

Go or any other language, because the moment
is coming to the market

and total paradigm of programming is changing.

B.G.: Great question. I will just, in my recollection,

the oldest language that is still in existence
is Lisp,

and not C. It predates Unix and C by twenty
years.

And anyway-

C.F.: So that's a huge wave is what you're
saying.

B.G.: Huge wave.

C.F.: We're still in the Lisp bubble, which
will soon burst.

Everyone will realize that was stupid.

Do you really want an answer to that question.
We didn't really answer it.

B.G.: So languages do come and go but paradigms
do stay,

OK. So fine, don't focus on languages,

focus on learning different paradigms.

C.F.: But they don't really come and go that
much.

I mean think about it, like-

B.G.: They might, like PHP fell out of favor.

C.F.: But it's not, not it's out of fashion.
Fashion.

B.G.: It is that.

C.F.: It is heavily deployed, right, you're
running it.

So it still exists.

H.K.: A bit sheepishly but running.

V.K.: But remember one thing. Ruby is older
than Java.

It's been there since 2004.

But how many people started referring to Ruby

until Ruby on Rails came? So it's a solution
that language

or a framework provides this, what inspired
everything.

In fact Ruby on Rails inspired the entire
ecosystem

much more of other languages beyond just Ruby.

So that's in fact, it's Ruby on Rails that
made Ruby popular.

B.G.: It's also Ruby's Achille's heel, by
the way.

V.K.: Absolutely. There's a downside to it,
extra-

B.G.: I'll keep patching FTW, right? Not.

V.K.: But remember, you know, we were doing
all

this web XML business till Ruby on Rails came
about,

and all this other stuff. So what changed,
if you were to call it,

you would call it Ruby on Rails for the better,
rather than Ruby-

H.K.: Are you saying that the whole rest

thing was because of Rails? Venkat?

V.K.: Certainly the moment was more simplification,

convection over configuration,

so that's what the Ruby on Rails was inspiring.

So you could just say that, you know,

people who were doing Ruby on Rails were doing
more

rest than people who were doing dot net

and doing the sub-business.

But by the way, sub seems to be effectively
dead, right.

C.F.: But unfortunately it's dead

in the same way that PHP is dead. It still
exists.

V.K.: That's true. The same that Colba is
dead, right.

C.F.: And Colba, for that matter. Sorry kids.

V.K.: And that will never go away, because
as long as-

H.K.: So the next question that I wanted to
ask is like,

Yogi talked about in his presentation, like,

how using a service architecture,

like for interface-based for, you know like
multiple small

micro-applications, small applications.

So the next question is like how do you go
about

in an organization, you have a product,

or maybe more than one product.

How do you go about building a true polyglot
system,

where you know like programmers are encouraged
to come

and you know like use different languages.

Does this require like some previous thought,

or does it happen automatically, like, yeah.

What are the best practices and everything?

C.F.: It's for one of us isn't it.

Or he says it's for me and I say it's for
you.

OK, so I, actually Yogi did sort of answer
this a minute ago.

You know, you really do need to focus on the

architecture of the system first.

That's essentially what my whole rant was
this morning,

is about the architecture of a system that's

made of small components that interact in
well-defined ways

with very clear responsibilities of each component,

and the components can and will be thrown
away.

I think for us once we have that set up,

I really can say yes, write a service in Rust,

I don't care. I don't even know what it looks
like,

I haven't bothered to read about it yet.

It's fine. Yeah, it's like C++.

So yeah it's excellent. It's battle-worn.

But if it performs well enough

and it actually works and we're monitoring
it

and doing these, and it's deployable in the
way that we can deploy,

I don't need an ecosystem for polyglot programming
then.

I just need to encourage people to try things

and to throw them away if they didn't work
out.

H.K.: Venkat, you had something-

V.K.: Actually there's something

we just talked about this morning.

We have to move away from a language requiring

to be hidden in a web service just to be safe,

and you can throw it away later.

I think the languages will have to find a
way to work together,

where you don't need to hide things behind
rest.

All these languages will have to come with
a way to improve,

thereby they should, Ruby should really

see a world of coexistence with Java,

and a world of coexistence with dot net.

Because in many cases we develop in, like
JRuby,

right. You develop in Ruby and you deploy
it in Java,

or J to E, with all the monitoring tools,

and you talked about profiling.

JVM and the JV-maker system is very great
for deployments

actually better. So in order for you to use
it,

the Ruby language has to become friendly with
Java.

The simplest thing for example is RJB, which
is a bridge to

Java, which is still, we use by the way,

over in JRuby as well as separately.

So you need a way to actually have one language

talk to another in somewhat standardized,
simpler,

less overhead mechanism.

And I think that would really encourage people

to use different languages without having

to build this up layer or risk layer.

Y.K.: So you're saying that at like binary
level,

actually like a foreign function interface
and.

I think the simplest way to do that is still
over the network.

Like when it's rest or it's zero MQO or whatever,
right,

it's like independent processes interacting
with each other,

isolated, not messing with each other.

It just works well. Not convince the RJB or-

V.K.: You're talking about it from an architecting

a bigger system standpoint, but I'm just talking
about

simply, I'm running this web application,
but certain

part has to be paralyzed. I should be able
to do it

with less overhead, less new layers, if a
simpler

problem exists where that's applicable, right.

What you were just talking about, it's applicable,

has certain complexity and certain layer,
but

generally encouraging people to apply multiple

languages to a single solution, right now,

has so much overhead.

I mean, today colleges are teach kids,

people about different languages,

but it's as if, like if you don't get a job

in Java then go and look for a dot net job.

That's really how we are learning multiple
languages,

so but we are not learning, it's not that

we are not learning multiple languages,

but we are not polyglots by default or

by simplicity of the system.

That is I believe, if you want to be,

if you want to encourage polyglotism,

you just have to go to the next level

where languages will have to coexist with
each other.

B.G.: I think-

V.K.: That is what we built with that notion.

B.G.: Fair enough. So I think co-existence
can

be looked at from different angles.

I think what you're talking about is run-time
co-existence,

you know, inside one run-time you have multiple
languages running.

I don't know that that's technically feasible-

V.K.: It may not be run time, it may not be

a single process co-existence- it would be
a multi-process.

B.G.: But it would have to be over some network,
right.

V.K.: No. For example, take RGB.

B.G.: How does it work?

V.K.: It's almost like you're just calling

it into the process and kind of like-

B.G.: But how does it really work?

V.K.: It could even be-

C.F.: It's still one process, right, RGB.

B.G.: Yeah it's still one process.

V.K.: I agree.

B.G.: It's still one process, right.

V.K.: JVM does its own thing, right.

In a way JVM has its own layer-

B.G.: But ultimately it's all JVM bite code-

V.K.: True.

B.G.: So I think we are all building, or have
to

build distributor systems at the end of the
day today,

and we're also trying to build abstractions.

Right, that is the whole goal of building

a software architecture that lets, let me
find out which parts

I can abstract and how.

So what Yogi talked about,

and totally agree with him,

I think the best approach is to abstract away
the optimal concerns

and constructs of the system

and tie them together using one language

that is spoken on the system.

So I think they used JSON in JSON Schema for
the-

Y.K.: It was in HTTP.

B.G.: It was in HTTP, OK, yeah.

So what you could use- you guys use it-

you could use a message queue or maybe use

something like zero in cue sockets to communicate

over and maybe use Thrift or even JSON data
for communication, but-

H.K.: So-

B.G.: The idea is to basically build a system

of optimal components tied together but using
one system,

but then for the message buzz you can either

use a socket or a message queue.

H.K.: So, there's definitely a lot of tools
which are,

like run-times that exist which allow run-time
re-use of languages,

for example like, either on top of the LLVM
or on top of JVM,

you know like how you have Closure collections
you can use

from JRuby actually, there are projects that
allow that.

Do you think that all those are basically
toys

and shouldn't be used in any seriousness?

B.G.: Closure collections are not toys.

But what I would say that, I think that this
idea,

it can be applied to the JVM languages,

but many times you have to use some language

which is not available on the JVM, right.

And you cannot use LLVM for it,

because it's something which is much lower
level

than the JVM. So you'll have to use the network

to communicate over each other.

But as far as JVM languages are concerned,
yeah, why not.

At a theoretical level, inter-opt between
languages

is something that we should shoot for. Absolutely.

QUERANT: I have a complaint and a question
here.

Complaint: You're arguing too much.

You obviously are in disagreement.

So

B.G.: Agreeing too each other.

C.F.: Closure collections are a toy then-

I actually, when he was saying are these things
a toy,

I don't mean Closure collections, but I do
think that,

the whole idea of interrupt in a VM or in
a process is overrated.

And I think it's overrated, like,

I remember being at Fu Camp talking to the
parrot guys

and LLVM guys awhile back in a workshop,

and they were all complaining because they

had tried to do like JavaScript on all these
different VMs.

They realized that like an array in JavaScript

has different semantics then like an array
in Java

and an array in Ruby. You know if you add

something way off in the distance,

past the end of the array, in some languages

it's an error and in some languages it nil
fills,

in some languages it's you know, so like,

that's a really stupid example,

and you can all imagine there's some way to
solve that.

But with the more interesting features of
the language,

that lead us to want to be polyglots,

like I don't really think it makes sense to
instantiate

a Ruby class from Java, for example.

Because the Ruby class does different

things than the Java class and vice versa.

Yes it can sometimes be nice.

So like when you're in Closure

and you want to use someone's ancient

Java library that has been working for years,

you just do it. When you do it, though,

it's hideous, and it like, the Java interrupt

is really not nice. And you know you're doing
-

it works fine. But it's uglier than Closure
code.

Right, so then you want to write something
so it

looks like Closure and feels like Closure.

So personally I think an operating system
is also

like one process, you can think of it that
way these days.

It didn't use to be the case. But I can spin
one up

and start running it, and then have language
interrupt

with multiple processes in there talking via
sockets,

and it's conceptually not very different.
Like if

I describe it to my mom she won't know the
difference

between that and a virtual machine, so.

B.G.: There's domain sockets in Unix, right.

C.F.: Oh yeah domain sockets in Unix. Of course.

This might be the solution, then.

QUERANT: Quick question to all the panelists.

As we stand today, what is the minimum number
of languages,

minimum set-up languages you would recommend
to all the programmers.

H.K.: 01:02:30 - dead audio

C.F.: Did you tell him his question was invalid,
is that it? I disagree.

H.K.: So what I was trying to-

B.G.: I would say it's a really awesome question.

I would say is that maybe don't worry too
much about

the number of languages that you are learning,

but number of different paradigms that you
are learning, right.

H.K.: So the question was like, like a kind
of paraphrasing, like, so-

B.G.: Doesn't matter. Look at the paradigms.

If you already know C, then don't bother about
C++,

you know, for example, or whatever.

H.K.: Yeah so the next question I had here
was like,

I'm just jumping back and forth, but like
yeah,

what next programming languages, like for
example,

you guys are looking forward to. Like you
know

starting with Swami like, sorry, Venkat, like-

V.K.: OK I'm just looking for a better Ruby.

H.K.: What do you mean by that?

V.K.: It's more of- I'm just looking for a

standardized Ruby where I should be able to

switch between the Java world and the MRA
world,

without lots of friction and you know, and
better

performing Ruby generally speaking. When as
much

as we just talked about low-level you know
you talk

low-latency stuff. I think we can't keep saying
that

Ruby's, you know, it's really slow for a reason,
right.

And Ruby can run in a hot spot. I want- Java
was slow

because of hot- before hotspot. But Java became
very,

very fast through that time and lots of new
work has

put in there. So there has to be some research
into

performance in Ruby I think or something.
I'm just looking

for better Ruby essentially. For my investment
of time and

language. But certainly, I mean I would like
to learn Scala

and stuff that like, something.

B.G.: So for me learning a new programming
language is

more like a cognitive exercise to expand my
own thought

processes, not specifically to you know apply
in production.

So the new language that I will be learning
in 2014 is Factor,

and you should check it out.

C.F.: I was gonna say Factor.

We should not sit next to each other. We're
too similar.

H.K.: Why, but why, can you just like say
why exactly Factor?

C.F.: I would say Factor because it really
hurts to,

it hurts in a non-stupid way.

Like if you learn Befunge it hurts in a stupid
way.

Like there's no reason to learn Befunge except
for fun.

Factor, though, there's something clearly
there, right.

It's concatenative programming. It's a different
way of having to think.

And it's a different way that to me feels

like it's deeper than it is stupid. It, so,
actually

I wouldn't probably learn it now, but I almost
said that though.

It was on my list.

B.G.: I already know APL and a little bit
of J maybe.

But APL is, again another concatenative language,

which inspired Factor.

APL is some language which I can read but
cannot type,

because to type APL code you need a separate
keyboard.

That's why I'm learning Factor this year.

H.K.: Yogi?

Y.K.: I don't know, Sanskrit, maybe. (01:04:41
??)

But yeah, I think Go or Haskel.

I think there the most differences from what
I already know, so.

H.K.: Fair enough. So I think a lot of first
-

learn programming languages and then the Dave
Thomas

like his book Pragmatic Programmer recommends
like learn

a programming language a year actually.

And so one of the things that I've been

wondering is like, how do you exactly like

go about learning a language? You cannot,

so like you cannot go to Flipkart and deploy

a production system in Hascal, that, I don't

know if you allow, but we talked about that
already, actually.

So but like how do, how does a person like

when picking up a language go about

learning a programming language, and like
so-

V.K.: So I think I've probably got the -

so yeah like. I actually read the manual.

Yeah, I'm so boring. And so I just read the
manual

just to get a flavor of what it's about and
what's possible.

Without going deeply into it it usually takes

like a few hours, because it's really superficial.

But once I get a sense of what the language
is about,

what the code constructs are, then do a second
pass

to kind of just decide really what's it about

and then play around with some code. But as-

(01:07:03 - dead audio space 01:07:47)

C.F.: I would try to do some simple services

and you know stuff with Actors running in
the background.

And whenever I saw something I didn't understand

I would just go look in the source code for
play.

Then I would look at this crazy Scala type
stuff

and have to then read the manual for a few
hours

to figure out what's happening. But now I
will never forget,

because I encountered it through a painful
situation,

so I have like the emotional trigger to never
let go of that knowledge.

B.G.: That's interesting, yeah.

I think, so every new language brings a different
way

of thinking to the table. So reading the manual

should be the first thing that you should
do I think.

Maybe because, usually the manual is written

by the author of the language,

or at least some supporting material about
the rational

or the ethos of language.

And once you have some superficial idea

what the language, start building something.

And at the same time look at the source code

of the language, or maybe the standard library

or some other products or tools that have
already

been written in that language,

to get a sense of how things are detected,

what the idioms could be.

And basically read more code, and then write.

I think I've always benefited more from

reading a lot more code than writing.

V.K.: Yeah I think the problem comes first
in,

I don't choose a language, just more of a
problem,

and I think this language could be better
to solve that problem,

and then just to find the quickest way to
solve the problem

and learn the crux of the language.

And then go learn further by looking into
the manual and other stuff.

H.K.: So Chad I was talking to you before

and like you said like don't just learn a
language,

deploy something production like similar,

and don't learn a language in a year, like
spend time with it.

Build something, solve a hard problem,

build something complicated, how do you say-

C.F.: Well yeah what I was telling you about
is Dave Thomas,

who is one of the authors of Pragmatic Programmer

who coined this language of the year idea,

he spoke at RubyConf 2010 and he said that
he had

revised his thoughts on what the challenge
should be.

Instead of just learning a language every
year,

I think he has the same problem I do, he can't
retain it.

He challenged everyone to learn a language
and deploy it

to production every year.

Because to him again it's the same thing I
just described for myself,

that he personally can't hold on to the knowledge

unless he experiences the real pain

of putting something into practice.

V.K.: Absolutely.

H.K.: So the pretty much like,

you learn programming languages like a lot
of persons,

but really our day jobs still requires to
programm in Ruby

or Java or whatever, so, one of the key things
like,

you write Lisp, you become a better Java programmer.

That's the wisdom so, like, how do you exactly
go

about adopting features, you know like, for
example,

like Closure or Scala or Haskel or Go, and
you know

like the language the you program in day to
day,

maybe for the dayjob. So like,

B.G.: How do you adopt a new language?

H.K.: How do you adopt features?

B.G.: Ideas.

H.K.: Ideas, yeah.

B.G.: So, as I said, every language has a
different

way of you know solving problems. So for example

if I take the example of Closure, in Closure
there

is a lot of emphasis on data. OK, you don't
hide data

inside objects and stuff.

You basically treat everything as first class
data structures

and then manipulate the data using standard
library

functions and spit it out into a different
format

if you need to. So that, some design or architectural

thinking that can be applied to any language,
right.

I know people who are actual provisional

Python programmers, who learned Closure,

did some real programming in Closure,

and went back to doing Python

and came back to me and told me that my Python
code

is so much better now, right.

So I think it's not just about Closure

or any specific language, but the idea is
that,

get a taste of the language,

see how they think about solving problems,

and you know, you may not be able

to transport all the ideas,

like if you like channels in

Go you cannot build a channel-like thing in
Java,

for example. It would be very hard for you
to do it.

But at least if you have an appreciation for
it,

maybe who knows tomorrow you might

be able to use a third party library to use
it.

C.F.: There's actually a problem that can
happen,

though. So you can take good things,

like the data orientation or the ideas of
immutability

by default in Closure and then just try to
make your

Ruby code be like that, because you understand
the benefits.

Or you could do stuff like try

(01:12:23 - dead audio space - 01:12:36)

it's even possible to then simulate the features

of one of these languages that you're learning
from,

but you emulate them in an environment that's
not friendly to them,

and it's a bad idea. So I would say don't
go too crazy trying

to make Ruby be functional more than it is,

or to be Actor-oriented or whatever.

B.G.: There will always be incidents (01:12:53)

in practice, right.

You'll figure it out if you try to apply it.

Y.K.: I'm gonna agree with Chad, so.

V.K. Yeah, OK, I'm not into this functional
side

or you know the Lisp side of Closure set of
things yet.

So my experience is essentially trying to
play more

ideas from Ruby into Java, and there was a-

you know probably Java at level that we just
talked about.

It's such a, what is it called, a restrictive
language.

There is a lot that I could actually learn
and apply to

Java and Ruby which was really exciting.

There were libraries,

I think there were coming up for like

calling anonymous functions or proc like things

that I could actually use them.

So those are, it was not really really tangible
at

specific example I could give. My Java programming
extensively improved.

Or readability of the code improved by having
written Ruby code.

Some of it will actually happen naturally
I believe.

B.G.: I don't think that -

For example I was doing a lot of Python before

I started doing some real Lisp programming.

Python always had the map and filter and reduce
functions.

I was never able to appreciate those functions
when

I was just a Python programmer, OK. For example,

Closure has something called protocols, OK.

How many people here have heard about refinements
in Ruby 2.0.

C.F.: Refinements, yeah.

B.G.: Yeah. It's a new feature.

So, see, minority. OK, it's a really good
feature,

and it lets you do code monkey patching but
restricted

to a specific module, OK. So I think that,

Ruby guys don't, are often are don't

understand benefits then it's kind of like
a shame, right.

Y.K.: Yeah but that's a point right,

that's something which has to happen at the
language level.

Like as a application developer who's not
working on the language itself,

adoption of features from other languages
will run into bottle necks.

So that's definitely one area where, for example
in the Java world, right,

when you move back from a lot of the ex-Ruby
programmers

move back to Java, and they created some beautiful
libraries.

Like for example I know an ex-thoughtworker
who's done

a library called (01:15:03), which allows
you to kind of mimic

Closures in Java, and it works through

actually hooking up a Java agent at run time.

So the point is it's a beautiful experiment,

but you can't really use that in production

because your IDs not going to recognize it,

you know simple things like that which might

seem like trivial but they actually hurt,
because

another the code syntax highlighting is kind
of

gone for a toss. The debug obviously doesn't
work,

you can't-

So you got to hook up the agent while running
the app.

So it becomes tricky, so I think a lot of
the language

features which get adopted do get a lot of
those frameworks.

For example, Actor systems, even though we
don't have

it in Java, kind of analogies of that have
been funnily

enough systems like Mule (01:15:40) right,
which is again

enterprising and boring, but essentially it
solves

the same problem. Like not at the language
level but

it allows you to coordinate independent Actors

and construct bulges (01:16:01) of flows which
kind

of do something productive and allow you to
scale

out in a very simple way, right.

So frameworks end up kind of taking their
place in a certain way.

I think it's difficult to bring it down to
a language very well.

V.K.: That kind of introduced like using

play framework in Java, right.

It actually brings a lot of Rails goodness

and Rails inspiration into Java, so you don't,

it's not necessarily about the language weights.

It's also things like dimension or configuration,

which can be learned and applied into other
languages.

So just ideas are behind a specific paradigm,

the simplicity or the philosophy behind it
can

be applied into other languages, like Java
from Ruby.

So I think the framework side of it plays
I think a big role.

Y.K.: Yeah that's a great point because there's

funnily enough right like a framework like
Rails

or Sinatra was invented in Java. Why is that?

Because the thought process that's behind
Java

is just not tooled to the kind of thinking
and

such lightweight simplistic services.

And it only took somebody to kind of look
at Ruby,

see its simplicity and be able to kind of
build

something so simple as Sinatra, like it's
beautiful.

And now that thought process has come out.

So yeah play's a great example actually.

V.K.: Yeah I think there's two things you
know,

the discussion kind of weighed towards more
towards

the paradigms, more. But I think there is
an

things like simplicity, conventional configuration

or concepts, which is another side that languages
have,

which are not specific to how to make parallelism
better

which are not specific to how to do functional
programming,

but still something which was not done before
or

easy enough in your language, which you could
have applied.

You know the language is easier.

But those are not new libraries

or nothing to do with really specific functions.

But you could get better in other languages
by

looking at this other philosophy behind

the language just beyond a specific paradigm

of the strength of the language.

H.K.: So we are about to close the panel discussion.

Any questions? We have time for questions.

Actually.

C.F.: Or how about you just raise your hand

if you want to ask a question

and otherwise we'll all get tea. You have
a question.

B.G.: Or we can just move the discussion to
the break room.

We could do that. So let's just you know - OK.

QUERANT: So I worked in different programming
languages.

So about four to five, so I think programming
languages

rose to such heights because either because
the programming

language itself or through its supporting
libraries.

For example, Ruby was not in so much mainstream
until

Rails came into existence. And Python for
scientific calculation.

C for internal system, you know Linux kind
of stuff.

C++ for games and other stuff.

So what all, I mean do these programming languages

have and uh, example like Scala, Closure,
Go, Erlang.

So these are upcoming, like dot also.

So what do these programming languages have

that they'll come on call. I mean what do
these libraries,

I mean what are the bigger libraries that
they have,

so that people like me can use them for certain
purpose.

So what all they are useful for?

C.F.: That'll take awhile.

B.G.: That's a very long-winded question.

I'll very quickly answer that.

Every language probably has a killer app,
right,

to champion it or maybe make it famous or
popular.

Not every, not all languages have one specific
killer app,

for example, while, what would you say the

killer app for JavaScript is, right?

Or what about Objective C?

Right, just that you don't have any other
choice

in those cases, right. If you want to program
for the browser,

JavaScript is your only choice,

Objective C if you are doing Apple programming,
right.

So yeah, I mean, every once in awhile there

are projects or libraries or products which

do come and make something very famous.

But it may not be true for everything.

H.K.: If anybody has any other questions

then I can (drowned out by applause - 01:20:05)

Thank you.