Season 1 Episode 8 Jun 24, 2020

Our Least Favorite Things About Our Favorite Languages

Pitch

Developers can be pretty evangelistic about their preferred coding language, but no language is perfect. We chat with Addy Osmani, engineering manager at Google, and Ridhwana Khan, senior engineer at DEV, about what they dislike about their favorite language.

Description

In this episode, we get into what are our pet peeves and grievances about the coding language we love the most. Guests Addy Osmani, engineering manager at Google, and Ridhwana Khan, senior engineer at DEV, both chose JavaScript, and they dig into why the language could be more opinionated, whether there should be a standardized library, and more. We also hear from our audience about what they dislike most about their beloved coding languages.

Hosts

Ben Halpern

Ben Halpern is co-founder and webmaster of DEV.

Jess Lee

Jess Lee is co-founder of DEV.

Guests

Addy Osmani

Addy Osmani considers himself to be an occasional JavaScript Janitor, who cares about improving user-experiences on the web. He is also an engineering manager working on Google Chrome at Google, focused on web performance and tooling.

Ridhwana Khan

Ridhwana Khan is a senior software engineer at DEV

Show Notes

Audio file size

58248802

Duration

00:40:31

Transcript

[00:00:01] JL: Hey, DevDiscuss listeners, we’ll mail you a small thank you gift if you send us a screenshot of your Apple Podcasts review by June 30th. All you have to do is fill out the form at tiny.cc/devdiscuss. This season of Dev Discuss is sponsored by Heroku. Heroku is a platform that enables developers to build, run, and operate applications entirely in the cloud. It streamlines development, allowing you to focus on your code, not your infrastructure. Also, you’re not locked into the service. So why not start building your apps today with Heroku?

 

[00:00:33] BH: Fastly is today’s leading edge cloud platform. It’s way more than a content delivery network. It provides image optimization, cloud security features, and low latency video streaming. Test run the platform for free today.

 

[00:00:45] JL: Commerce.js is a headless ecommerce platform built for developers. With Commerce.js, you can rapidly build and ship custom ecommerce integrations without needing a ton of experience or a big engineering team behind you. Head to commercejs.com/devto to sign up for free now.

 

[00:01:04] BH: DigitalOcean offers the most easy to use and developer-friendly cloud platform. It simplifies managing and scaling apps with an intuitive API, multiple storage options, integrated firewalls, load balancing, and more. Get started on DigitalOcean for free with a $100 credit DO.co/devdiscuss.

 

[00:01:26] AO: PHP is one of those beautiful languages where it’s easy to get started. And because it’s easy to get started, it’s also easy to make a ton of mistakes as you’re building something up.

 

[00:01:35] RK: PHP does get a lot of shit.

 

[00:01:50] BH: Welcome to Dev Discuss, the show where we cover the burning topics that impact all our lives as developers. I’m Ben Halpern, co-founder of Dev.

 

[00:01:57] JL: And I’m Jess Lee, also a co-founder of Dev. Today, we’re talking about your least favorite things about your favorite language. We’re joined by Addy Osmani, Engineering Manager at Google, and Ridhwana Khan, Senior Software Engineer at Dev. Thank you both so much for being here today.

 

[00:02:12] AO: Thank you. Glad to be here.

 

[00:02:13] RK: Thank you for having us.

 

[00:02:14] BH: So Addy, before we start tearing apart our beloved programming languages, would you like to tell us a little bit about your coding background and what you do professionally?

 

[00:02:25] AO: Sure. Sure. At different points in my career, I’ve kind of referred to myself as a JavaScript janitor, but my title at Google, I’m an Engineering Manager. Most of the work that my team does is in the developer tooling and measurement space. So we do projects like Lighthouse, PageSpeed Insights. We work on DevTools, that type of thing. I’ve used JavaScript for a very long time that I love-hate relationship with it, but there’s lots of love there. There’s a lot that I wish was better.

 

[00:02:54] BH: I’d be suspicious if a JavaScript developer or a programmer of any kind didn’t really have a love-hate relationship with their environment or what they deal with every day.

 

[00:03:02] JL: Ridhwana, will you tell us a little bit about your coding background?

 

[00:03:05] RK: Yeah. So currently, as you mentioned, I’m a Senior Software Engineer at Dev, but I started in the industry around 10 years ago. I worked in corporate for a while. I worked with a couple of startups. And around 10 years later, I’m now working at Dev.

 

[00:03:21] JL: Awesome. Can you tell us about what you’re working on here?

 

[00:03:24] RK: Yeah. So I work, of course, it’s all open source. So I’m currently working on sort of the community aspect of Dev. We’re working on generalizing the code base. I do a lot of Ruby on the backend. I also do JavaScript. I think throughout my career, I’ve really done a lot of JavaScript, I think it seems though. Recently at Dev, I’ve been focusing a lot more on Ruby, which is also really nice.

 

[00:03:52] BH: And it’s really awesome to work with you. Addy, what is the language you’re going to choose for this discussion and what are your least favorite things about it?

 

[00:04:02] AO: The language I’m going to choose for this discussion perhaps unsurprisingly is JavaScript. And there’s a long list of things that I feel could be better in there. An overarching theme is that JavaScript could be a lot more opinionated. Lots of feels about things like null and undefined, const and lets and then just the kind of lack of a standard library in JavaScript and whether or not we should have one. Those are some of the things off the top of my head that I’d love to chat about.

 

[00:04:31] BH: Yeah. Can you talk about the issues with it not being opinionated? Do you see any sort of resolution to that or is that inherent to the language?

 

[00:04:42] AO: So I think JavaScript could be more opinionated, doing so is inherently difficult for a language because opinions can have very long lasting effects and you can make an argument that if you give developers a strong enough foundation with a language, they can hopefully build their own opinions on top of it for their own projects. Now the kind of lack of opinion in JavaScript has caused us a few interesting challenges over the years. I think one of them that’s pretty common is the inconsistencies in how folks approach things like null and undefined. In theory, null and undefined map pretty clearly to the concept of no knowns, known unknowns, so null, and then and then unknown, unknowns, so undefined. And the challenge there is people keep using null and undefined pretty inconsistently. That type of thing complicates input validation. Nobody knows really what you should use where. Sometimes people will use undefined to represent the implicit absence of value. Sometimes they’ll use null to specify that a variable is defined, but it’s not usable. And there’s been a bit of a recent call from well-known people in the community, folks like Sindre Sorhus, Crockford, maybe even Brendan Eich, suggesting that you should be using undefined instead of null. Some people have suggested, “We can’t really get rid of problems in the language like null and so maybe we should just pretend that they don’t exist at all.” And then other people feel that they’re semantically different enough that maybe it’s fine that these two concepts that are kind of similar should just continue to coexist. But in the absence of having agreements on things like this, it just means that especially for beginners, they’re going to be just as lost as the rest of us were when we first decided, “What should we use where?” And I wish that the language could get a little bit more opinionated in saying, “Here’s where you should use this and here where you should use that.” You could probably say the same thing for other things. So like const and let. Some people feel that there’s just way too much cognitive overheads to constantly thinking about which one to use and maybe it’s not worth it, having to make that decision on each project. What I personally do for const and let is that I use const kind of for top-level module scope constant. I otherwise use let for a lot of things, but it’s another case of where you end up requiring a team or a company to make a decision about what to use and people will like bicker and argue for what their preferences are about const and let leading to another place where language could be a little bit more opinionated.

 

[00:07:21] JL: What are some languages that contrast to JavaScript in this way?

 

[00:07:26] AO: I think that there are languages that try to think about how maybe we can simplify the differences between null and undefined. I’m not sure to what extent it solves as well, but I’m a big fan of Elm. If you’re into functional languages, Elm kind of compiles to JavaScript, it tries to have like no runtime exceptions. So ideally like no null and no undefined is not a function, uses type inference to detect corner cases. But I feel like this is one of those places where the language like in general could just say, “Well, just use undefined and that’s it. We’re not going to make you have to choose.”

 

[00:08:03] BH: Ridhwana, would you say your favorite language is JavaScript?

 

[00:08:06] RK: Yeah, definitely. I absolutely love working with JavaScript.

 

[00:08:10] JL: What are your feelings on JavaScript being more or less opinionated?

 

[00:08:14] RK: I definitely agree with Addy and I think that JavaScript could be a little bit more opinionated. I mean, I have a love-hate relationship with JavaScript just because JavaScript itself, isn’t opinionated. I think there’s a lot of libraries and frameworks that have come out of it in order to make it a little bit more opinionated and that gives developers so many options. And whilst that’s a really good thing, I love a lot of options. It sometimes gives me paralysis when I’m like trying to just build something new. I’m so focused on what to use instead of actually just building it out in, for instance, [INAUDIBLE 00:08:51] JS or something. It’s just because there’s so many options that have come around because JavaScript is inferior opinionated. I also think that a lot of developers, especially new developers, find it really easy to get started with JavaScript. It’s very flexible, very versatile. It’s easy to get up and running. And so you can have something together really, really quickly, more so than with other languages that I’ve worked with. But I find that when you’re hacking these things together, it can easily become spaghetti code. It can be unmaintainable and fragile because the bad practices are not really defined by JavaScript. But again, it’s sort of defined by this complimentary tooling. So things like bringing in linters like JSHint or ESLint and things that allow you to flag bad practices and customize it to be more strict and more relaxed. So again, you are sort of catering with other tools in order to sort of deflect from our JavaScripts and our opinionatedness.

 

[00:09:53] BH: All right. Great. So we can say two for two on people whose favorite language is JavaScript and how much they hate it or however strongly they want to express their dislikes.

 

[00:10:06] JL: Addy, are there any other things that bug you about JavaScript?

 

[00:10:10] AO: I was working on some tooling this last week. I needed a quick utility. I needed to balance a function. And as anybody, I went straight for Lodash and was using it. Then it reminded me that there are still open questions about whether or not programming languages, JavaScript specifically, should have something like a standard library. We do have a little bit of a standard library in JavaScript. It’s just very small. We have things like the data object. We have regex as well, but nothing that would necessarily replace a full utility library like Lodash. And I guess that there are questions about, “Should TC39, should JavaScript be building something baked in here? Should we be looking to standardize existing libraries and put them into the platform, given that they’ve got confirmed adoption and are generally pretty ergonomic?” It’s a tough problem and it’s an interesting discussion to have because the lack of a standard library in the language, you could argue that it’s one of the things that have help drive so much innovation in the JavaScript community and even if TC39 was to look at, you know, trying to spec out utilities for the most common patterns, it would probably have to stay relatively small and be focused on things that makes sense across all of the environments where JavaScript is being used without polluting the global namespace too much. I firstly still get like a lot of value out of things like Lodash and I’m sure that it’s not the last of its kind that we’re going to see. There’s going to be plenty, more Lodashes in the future, lots of collections of nice functional operators and things like that. It’s a tricky thing to balance. I’m hopeful that we can at least evolve the language to a point where at least some of the most common utilities could be potentially baked in. I don’t know. Is Lodash something that Dev.2 use? What do you all do about utilities?

 

[00:12:04] BH: We tend to use the minimum amount of utility libraries we can just so that we can send fewer bites across the network, like in order to render our basic functionality. So we’re sort of like painfully under tooled in some ways, but we sort of make the choices to go sort of bare bones where we can, even if it means not including like simple libraries, and that doesn’t mean that Lodash would specifically cause a problem, but I think we have this like culture of just kind of doing things the hard way in some ways. And to that point, I’m wondering how you feel about how the JavaScript language and the bundle sizes and things like that sort of play off one another and whether the language, as it is now, is sort of hurting that battle?

 

[00:12:53] AO: Yeah. I think that whenever, we’re building web applications today, we’re taking small Lego bricks out of the ecosystem. We’re trying to put together as many of them as we can. And ultimately, unless you have something that’s giving you guardrails or checks and balances, whether that’s your framework or you’re a linter or other tooling, you can easily end up with a crazy, megasaurus worth of JavaScript and a ton of stuff being shipped out to your users accidentally that that’s bloating up the experience. I often see very big popular sites who have got bundled challenges and it’s usually not one thing. They’ve add in utility libraries. They added in those one or two things they thought would just give them the carousel or the modal or whatever UI that they wanted. It’s pulled in a ton of different dependencies in its own right. And by the end of it, you suddenly have like a megabyte’s worth of JavaScript compressed being sent down to your users when maybe that’s not actually the right thing. And so how do we balance that with the language? I think that, in some respects, there are areas where the language has evolved to help us on the web performance front. My favorite feature in JavaScript of the last couple of years is probably been dynamic import. So the idea of like being able to import a module on demand or conditionally. It works great with async/await, enables a lot of lazy loading patterns, but I think that we need to take extra care. And when we’re adding things to our bundles, it’s filling gaps in the language. Just sanity check that there is a good correlation between the value of those dependencies and the cost that they’re adding to the overall user experience. If it’s not benefiting the user experience in some major way, I questioned whether those dependencies should maybe be replaced with something custom or smaller or whether those dependencies should maybe be loaded at a more opportune time. Maybe there’s more we could be doing in JavaScript as a language here to give you more utilities. But more broadly, I do think that there’s a lot that just culturally we can do about being careful about the things we’re adding to our bundles.

 

[00:15:02] JL: Going back to this idea of a standardized library, what are your thoughts on potentially shipping libraries within the browser?

 

[00:15:11] AO: Interesting. Interesting topic. Every year, someone will propose, “Hey, maybe we should take the top 10 or the top 100 JavaScript libraries and just ship them with the browser.” I think at the moment, I believe Mozilla might have a proposal that’s thinking about this space. Chrome are collaborating on it as well. There are some interesting challenges around the idea of baking libraries into the browser. The first big one is how do you tackle things like versioning? If I ship a version of saying, “React or Preact or Vue,” or something like that in the browser and then suddenly there’s a critical security fix or a critical performance fix that comes in a version that’s not shipped in the browser, how do you reconcile that? Right? Because browsers have their own release cadence and release schedule libraries and frameworks have their own one. And we also want to be relatively cautious about including potential attack vectors accidentally by pulling in these libraries. The other interesting ecosystem aspect of including libraries in the browser is if we pull in the top 100 libraries that are popular today, do we give some level of favoritism to what is popular today versus what could be a really innovative solution that comes out next week but doesn’t have the same benefits of being locally cached and easily accessible? There’s a little bit of nuance to the idea of shipping libraries in the browser that I think we need to think through. I personally think that there are opportunities for us to look at, adding in at least more functionality into either the language or bringing in a finite set of small modules into the browser that do very common things. So maybe some of the things that a Lodash does. But we do need to be cautious about not stifling innovation when we explore these ideas.

 

[00:17:18] JL: Commerce.js is an ecommerce platform that is changing the way developers are introduced to and experience the world of custom ecommerce. Commerce.js sits around your code, your designs, your stack, not the other way around. This means that you can actually take full control from the storefront, to the checkout, to the receipt. Head to commercejs.com/devto. It’s free to sign up with platform wide features and no trial windows.

 

[00:17:44] BH: With DigitalOcean’s cloud infrastructure, you’ll be able to build faster and scale easier from predictable pricing, to flexible configurations, to world-class customer support. You’ll get access to all the infrastructure services you need to grow. Plus, DigitalOcean’s community provides over 2,000 tutorials to help you stay up to date with the latest open source software, languages and frameworks. Get started on DigitalOcean for free with the $100 credit at DO.co/devdiscuss.

 

[00:18:16] JL: Ridhwana, is there anything else that bugs you about JavaScript?

 

[00:18:18] RK: I’m particularly related to what Addy said about shopping too many libraries with you code. At Dev, you’re right. We’re very particular about what we shop because we’re very conscious about how big we want our application to be and sort of performance and optimizations. So one of the things that I didn’t mention earlier is I’m actually based in South Africa. And so I’ve found that when applications are bought without like performance in mind and when they shipping too many JavaScript packages, it really is to the detriment of African countries because you’d find that most people within Africa, a large population of at least South Africa, doesn’t have the good infrastructure and it’s lacking in under-resourced communities. We don’t have constant access to high quality internet. We use 3G or 2G networks. And then also we need to take into consideration that a lot of the smartphones that are used in Africa, actually not smartphones, sorry, they’re feature phones. And so they don’t have a very good CPUs and also data costs are just really high here. So even though our earnings compared to a place like the US, we earn less than 50% as compared to employees in the US, our data costs actually are sort of on par with the US and Canada and China. So about $10 per gig. So I find that if we’re not thoughtful about the packages that we ship with our applications, we find that it really impacts users in under-resourced communities. So I’m actually like really passionate about that topic and about how we should build our applications in a thoughtful manner.

 

[00:19:58] AO: Yeah, plus 1000 on that. I think that it’s useful to remind folks that today there are really like two major costs when it comes to shipping JavaScript down. There’s download costs of your bundles and then there’s the JavaScript execution time that can be important for phones that have very slow CPUs. There are a lot of things that a slow phone can be impacted by thermal throttling disparities and just the performance of high-end devices that will sometimes be developing on versus low-end ones that our users have. And so we really do need to encourage our communities to look at how we can keep JavaScript bundles small, especially for those low-end devices in countries where you don’t always have the best CPUs, improve your execution time, avoid any long JavaScript tasks and work that keep the main thread busy. I’d love to get to a place where maybe and at least some of our frameworks we can enable progressive delivery of JavaScript in a little bit more of an automated way so that we can still be able to build relatively complex UIs and only load and execute code when it’s needed in an automated way, but definitely a lot more than we could be doing here.

 

[00:21:08] JL: Ben, what is your favorite language?

 

[00:21:10] BH: Yeah, I really have a hard time not saying Ruby because a favorite language is just kind of arbitrary. I certainly value the power of what I can do with JavaScript and if I were to maybe have to forget a language, I probably wouldn’t mind forgetting Ruby, but we chose Ruby for our framework. And long before that, I’ve kind of become one of these Ruby fans. So my favorite things about Ruby are the simplicity of spinning something up, like just how in JavaScript that runs in the browser and it’s pretty easy to get going. And Ruby, it’s really easy to spin up a Repl and just kind of hack with it and get things done. And that’s a lot of fun. My least favorite thing about the language is probably that it’s just kind of over simplistic when you really need it to do something more interesting for you. The lack of any sort of asynchronous programming seems kind of like Stone Age when you look at JavaScript or like pretty much anything else in programming. I love that it sort of forces you to dumb things down a little bit and then gives you abilities to do fun and interesting things with like other monkey patching and things which can lead to some really cool programs and certainly it’s easy to express what you think into code pretty quickly. But compared to a JavaScript, which has a little bit of this built-in chaos with a lot more powerful sort of features and environment stuff, like really it doesn’t really bring a lot to the table in power. Everything good about it is kind of in its syntax and its delightful care that’s taken for the language, but definitely can kind of complain that, like, it’s just not that powerful and it’s kind of easy to stub your toe at the same time. So sort of worst of both worlds sometimes even though it is my favorite language. So Jess, what’s your favorite language?

 

[00:23:16] JL: So I’ve been dreading this question. I knew it would come to me. But my favorite language is Ruby and that’s really only because that’s what I’m most familiar with and it’s easy to like something that you feel like you’re pretty good at. The other language that I write in more frequently is JavaScript, but I always kind of dread writing in JavaScript, especially if I’ve been spending more time on the backend, which is why I’m leaning towards Ruby and I think JavaScript because you really do have to be a little bit more deliberate in making your decisions like we’ve discussed. I think Ruby is easier for somebody who doesn’t code day to day. And yeah, on that note, I don’t feel like I code enough to have certain gripes about it, but it’s very interesting hearing the details and what we would all like to see improved in your favorite languages.

 

[00:24:06] BH: Yeah. I think when you do almost all your programming in one language and that was the first language you were taught, you started just code in that language and it’s kind of like a great place to be. If anything, I loved Ruby so much more when I was doing like only Ruby programming. So they’re not complaining, “Oh yeah, it doesn’t have this. It doesn’t have that.”

 

[00:24:25] JL: Yeah. You get used to it. And then like the learning curve, like if you have a side project you really want to dive into you and you want to make it work, then you’re going to gravitate towards the language you’re more comfortable with and then it can just be a little difficult to learn a new language sometimes. I have read about people who try and learn like at least two new languages every year, but that’s just not in my personality.

 

[00:24:48] RK: I find that when I swap between Ruby and JavaScript very often because, I mean, at Dev I’m writing a lot of Ruby, but usually on my like side projects, I use a lot of JavaScript and I am constantly writing console.log in Ruby and it’s so annoying. I’m constantly like mixing up the debugging techniques between languages.

 

[00:25:09] BH: I think if I stuck with one language more, I’d be more familiar with the debugging tools in general. I think like that’s the problem with like any debugging tools I find like they’re the easiest thing to kind of forget across environments. I wound up sticking to console.log or put statements or whatever the equivalent is and whatever language. I just can’t find myself adopting complicated debugging tools, like if I’m moving from thing to thing.

 

[00:25:40] JL: Well, given that there are flaws and both the favorite languages here, JavaScript and Ruby, Addy and Ridhwana, if you could create the perfect language, what would that be like?

 

[00:25:51] AO: Well, one of the things I’m thankful for in the JavaScript ecosystem right now is that we have things like TypeScript that can experiment with ideas around supporting concepts for code complexity and large projects. And I’m kind of curious over time how much we’re going to see the ideas from TypeScript folder way back into JavaScript and whether or not they should, because for me, some of that could be ideal. So things that I find in TypeScript being interesting are its support for static analysis based on the structure of your code, the tight annotations, support is great. I kind of liked the idea of errors, meaning findable and correctable during compile time, instead of just errors being found during runtime with JavaScript. I liked some of the ideas around TypeScript supporting strong typing, both with static and dynamic typing. Some of the things I like less on that front are like the need for so much tooling. Ideally, you wouldn’t need a compiler or to deal so much with type definition files and that type of thing. Maybe my ideal would be a language that includes some of the features that TypeScript currently gives you.

 

[00:27:08] RK: So from my side, I think that I would use JavaScript as like the base foundation of this new language and then start removing things or putting in things. So all the things I dislike about JavaScript I’d essentially take out. So for instance, as I already mentioned, like the fact that it’s a weekly type with aggressive coercion, like TypeScript sort of counters that are a little bit where we can use TypeScript to be able to write code that’s easier to read and just a little bit easier to navigate. And also, I’d wish my language would be able to execute across all browsers without having to have these little quirks for each browser. So currently I’m with the JavaScript, you build something and you realize that it doesn’t work in browsers because you’ve got to check if that web API actually works in certain browsers. So I just wish this new language would work across all browsers without me having to actually check whether it does or not. Since this is my fantasy language, I’m allowed to sort of add whatever I want to. I get the syntax to look a lot like Ruby. I do like Ruby syntax. It looks a lot cleaner. There’s no curly brackets, which is amazing. I really liked like the debugging tools that JavaScript comes with. So I definitely keep that. Also, like I already mentioned that JavaScript does have a habit of failing silently at runtime because synthetic errors, but sort of having a compile time around would mean that we’d catch those errors much earlier. Yeah, I’d keep the flexibility of JavaScript whilst adding a couple of libraries that I believe are sort of commonly used ones. I think that will be my fantasy language.

 

[00:29:03] JL: Awesome.

 

[00:29:04] BH: So I don’t think I’m very good at it answering this in a really practical way, but somehow the language lets me write my whole program in one file no matter what in a way that doesn’t break everything. So that’s one thing. I don’t know how that works, but I would love the idea to just open a file and go, even if I have to use Command F or something, I don’t know, like something like that, one file. And then of course, it’s going to have to work without an IDE, but so long as we’re building these really cool editors, I think it would be awesome if the program could like automatically express itself in really bold and outrageous ways within my IDE so it would have big, screaming GIFs at me when things are going wrong. I want a programming language that treats me like a human in some way and like in its outrageousness and all is in one file and I’d probably want no dependencies somehow. So I’m just kind of railing on my completely impossible programming language, but I think be like a more tactile environment.

 

[00:30:15] RK: I really like the idea of having GIFs on my editor screaming at me. That sounds like the perfect thing ever.

 

[00:30:22] BH: Yeah. Just like this is wrong and the GIF would like express how wrong it is. Depending on how bad it is, it would be that much more like the personality would like ramp up to 11, like way quicker, if there was a huge problem. But if there was like a small problem, it would just be like a little thing. And maybe what I’m describing is just a different type of linter and we don’t need a whole new language, which is kind of how these things actually work. And I really don’t think the language is the right way to start something new anyway, but maybe I’m asking for a linter that like really tells me what’s going on in a way that’s like a little bit more nuance than just what you can do with that.

 

[00:31:25] BH: Empower your developers, connect with your customers, and grow your business with Fastly. It’s the most reliable and performant-edge cloud platform. Fastly CDN moves content, data, and applications closer to your users at the edge of the network. It helps your websites and apps perform faster, safer, and at a global scale. Test run your platform for free today. We use Fastly at Dev and we’ve been really happy with the results.

 

[00:31:47] JL: Over nine million apps have been created and ran on Heroku’s cloud service. It scales and grows with you from free apps to enterprise apps, supporting things at enterprise scale. It also manages over two million data stores and makes over 175 add-on services available. Not only that. It allows you to use the most popular open source languages to build web apps. And while you’re checking out their services, make sure to check out their podcast, Code[ish], which explores code, technologies, tools, tips, and the life of the developer. Find it at heroku.com/podcast.

 

[00:32:29] BH: Now we’re going to move into a segment where we look at the responses that you, the audience, have sent us to a question we asked in relation to the topic of this episode.

 

[00:32:40] JL: The question we asked you this week was, “What is your least favorite thing about your favorite language?”

 

[00:32:45] BH: Lisa responded, “I absolutely love, love, love, love, love Ruby, but I’m so tired of all the fricking underscores or snake case.”

 

[00:32:54] JL: Snake emoji afterwards.

 

[00:32:57] BH: This is like a funny one because I feel like this is what people love about Ruby. And if you don’t like snake case, it’s kind of a funny thing, but I think it’s like just the perfect thing to not love about a programming language because we do have to stare at these things all the time. And if you find it kind of unpleasant, you sort of aren’t going to like it.

 

[00:33:14] JL: I know there are a bunch of cases, camel case being another one. What are the other ones again?

 

[00:33:19] BH: upper case?

 

[00:33:22] JL: And Alistair wrote in, “JS is my favorite, but I really dislike the class syntax that was introduced in ES6. The prototype chain is easy to understand and doesn’t need to be hidden beneath Class, Extends, and Super, which feels more like Java.”

 

[00:33:35] AO: You know, I think in particular over the last year or two, we’ve seen that there are strong preferences in some parts of the community, turning towards things like functional programming, React, Hooks, those types of ways of containerizing functionality. I personally, occasionally do still use classes, perhaps less so these days. I’m heavily using ES modules in my own constructs for the most part. I feel like classes are one of those things where it’s okay to still use a lot of the rest of the language without them, if you don’t strongly need them.

 

[00:34:05] BH: I’ll add that I definitely take advantage of the freedom to use like older JavaScript techniques, especially if I’m just hacking away on my own. And maybe that stumps my ability to like actually evolve as a programmer, but I haven’t felt compelled to always sort of adopt to sort of the new syntax, if I find it’s not really making my code more readable or anything like that. All right. I want to jump to this one. Roloff writes that PHP is wonderful and you can quickly get things running. The most recent updates to the language are amazing and I’m loving all the new things that I can do like error functions, type hinting, and class variables. The one thing that annoys me a lot about PHP is the completely inconsistent names and argument order for built in functions. And then Roloff give some examples that are pretty ugly. Why does one have underscore and the other one doesn’t? It feels like there’s a lot of legacy code in there.

 

[00:35:03] JL: I love that their favorite language is PHP. I feel like PHP gets so much shit and I’m just happy that they have a supporter.

 

[00:35:11] AO: PHP is one of those beautiful languages where it’s easy to get started. And because it’s easy to get started, it’s also easy to make a ton of mistakes as you’re building something up.

 

[00:35:20] RK: PHP does get a lot of shit.

 

[00:35:23] BH: Yeah, just this past weekend, I was playing around with like a very simple static site generator I was sort of whipping together and I asked for a feedback, like the ideas, and someone recommended just doing it in PHP, which is just like not something I thought about because my association with PHP is just like the worst stuff ever when I ever did it, which is a long time ago, but that actually was sort of an aha moment that PHP is actually perfect for that sort of thing. It’s so ready for like basic web stuff. And even then like if you try to get more complicated or do anything special, you’re going to like start hating all the things. But in that moment, I was like, “Oh, wow. I love PHP again.” It’s so much more built for this job, which really was the only thing you were doing on the web 10 or 15 years ago was the stuff PHP was built to do.

 

[00:36:22] JL: So Jeremy wrote in, “I love Guion, but it lacks documentation. It lacks a community. It could have more libraries. It could be better written. Yup. That language is my main CI projects. It is a tool I use for music shows. I’m working on a SWIG fork right now to address the library problem and I’m continuously trying to get the code better. The other problem remains unsolved and are definitely the ones I could use a hand on. I’m updating a SWIG fork to make.” Is Guion a language that anyone here has heard of?

 

[00:36:54] AO: I don’t think that Guion is a language that Google has heard off because I’m having a very hard time finding it. It’s too far ahead in the future, this Guion thing.

 

[00:37:08] BH: One of those dark web languages. Arpit writes, “I’m one of the few people who actually love Java. It’s a solid language that gets the job done. In the recent past, Java has started to incorporate functional paradigms, which is great. Unfortunately, stack traces that used to be effective for debugging are absolutely crap now. Each stack trace is 200 lines of absolute mess with no useful information, whatsoever. I miss the good old STFO paradigm.”

 

[00:37:35] RK: At my previous job, I built an open source Java library and I had not used Java since University. And I had to follow the same library in Java and JavaScript. And the one thing that I could not wrap my head around in Java was that JSON wasn’t supported by default in the language. And you had to pull in this library and it was just so painful to work with. That’s like one of my least favorite things.

 

[00:38:04] BH: I can definitely relate to the idea that if the stack trace isn’t giving you any favors, it’s like impossible to program. That’s kind of how I feel about anything. I kind of rely on some evidence about what I’m doing wrong, if I’m doing it wrong. And if I haven’t written in Java in quite some time, so I’m taking Arpit at their word for it. But if the stack traces are getting worse, the language is probably getting worse. So that’s definitely one of the number one things a language can do to be pleasant is to give good stack traces and good error messages.

 

[00:38:37] JL: Well, since we have JavaScript fans here, Omar wrote in, “I love JavaScript, but I dislike the fact that it does not support immutability out of the box. Also, I dislike that it doesn’t have a proper standard library.

 

[00:38:50] AO: I can empathize entirely on the lack of a standard library. I think that a lot of us are jumping for utilities or writing our own custom functions in the absence of it. So I very much empathize with that.

 

[00:39:04] BH: Sarah writes in to say, “Is it bad that I don’t have a favorite?”

 

[00:39:09] JL: No, not at all. It’s okay.

 

[00:39:11] BH: You’re probably in a pretty good place if you love all Earth’s programming languages equally.

 

[00:39:19] JL: Addy and Ridhwana, thank you both so much for joining us.

 

[00:39:23] RK: Thank you so much for having us.

 

[00:39:24] AO: Yeah. This was a blast. More than happy to come on and complain about JavaScript any time.

 

[00:39:40] JL: I want to thank everyone who sent in responses. For all of you listening, please be on the lookout for our next question. We’d especially love it if you would dial into our Google Voice. The number is +1 (929) 500-1513 or you can email us a voice memo so we can hear your responses in your own beautiful voices. This show is produced and mixed by Levi Sharpe. Editorial oversight by Peter Frank and Saron Yitbarek. Our theme song is by Slow Biz. If you have any questions or comments, please email [email protected] and make sure to join our Dev Discuss Twitter chats on Tuesdays at 9:00 PM Eastern, or if you want to start your own discussion, write a post on Dev using the #discuss. Please rate and subscribe to this show on Apple Podcasts.