agbell

I'm the podcast host. This is an interesting story about trying to get someone's money back on the Ethereum blockchain. There is also a discussion of the ethical dilemmas and game theory of a truly decentralized world. I'd love feedback on the episode.

I'm the author. Its not as if I've never heard anyone say how amazing new language X is. That seems to be about the only thing I do hear.

I love programming languages and play around with them all the time and have interviewed creators of programming languages. Clearly there is progress being made in the field of programming language design.

The article was saying that you can't necessarily take people opinions in the SO survey at face-value when considering programming languages that are still in a honeymoon phase. There are no 15 year old Julia code bases. Once you have taken over a large code base in a language and have the experience maintaining it that is something else.

Good catch. I have fixed it.

   It's because writing something new is cognitively less demanding than the hard work of understanding an existing codebase, at least initially.

Also they can only dread what they use. The question SO uses specifically asks only about things that you use extensively. That is what makes this interesting to me. It isn't people dreading APL because it looks funny, its people dreading something are using it day to day.

Author here. I wanted to dig a little into data from the Stack Overflow survey on what made programming languages loved or hated and I think what I found is pretty interesting: it seems like people don't like the languages where they have to do maintenance work.

Python and C# seems like outliers here though. People really love them.

Hi, Good idea, I'll add that.

Right now you can do -> "Podcast Player" -> "RSS", but I realize that is non-obvious.

Updated

People currently at Apple, is the culture of working 80 hours a week to hit unreasonable deadlines year after year still a thing?

I never understood how you get teams to work that much but one of the factors at least in this case is not wanting to let your team down.

Hi, podcast host here. I got the transcript done through rev.com and didn't proof read it because usually they are pretty solid. That was a mistake, I am fixing it right now.

Thanks! It's been a fun journey learning how to make tech stories entertaining in audio. I'm sure I still have lots more to learn.

I don't have any monetization happening right now, but it is a great idea. Words of encouragement certainly support the podcast as does just sharing it with people you might think enjoy it.

Host here. David Shayer worked in the hardware org of Apple as a software engineer at Apple from 2001 to 2014 and he specialized in writing filesystems.

I think his story is an interesting window into the culture of Apple. Let me know what you think.

Host here, Casey Muratori has been building a game from scratch on twitch for 6 years now. From scratch for Casey means no third party libraries and barely using more than c.

He built up a fan club of viewers and started using the game building as an opportunity to teach people programming fundamentals. His approach to programming and teaching, as someone not familiar with the game programming world, is fascinating and seems to have resonated with a lot of people.

Yep, it's based on the package dependencies you list, looking for packages with know reported issues.

There are for some languages.

https://github.com/dhall-lang

You have a point. A mess of shell scripts doesn't really sound like an improvement. If the config is too complex and the config consumer can be changed to simplify things then that should be the way to go.

However, if the config is a travisCI YAML file that is really just a glorified list of commands I don't think bash or a makefile is a bad solution. Take as much as possible out of the CI config and use a neutral standard format like a makefile to encapsulate much of your logic.

Then when TravisCI stops offering free usage for open source, its easy to move, because your format isn't specific to a vendor.

It is definitely not the fault of YAML. It has its own issues but that is another story.

The problem is when you use YAML (or an ad hoc interpreter embedded in YAML, or a templating system built on top of YAML) for things that should really be a programming language. Things like imports and functions and composition are useful. Templating is a more ergonomic form of string concatenation.

Depending on the use-case, I think you may be right. Especially if you can use a language that the team understands and has tooling for and you don't take in outside configuration.

Pulumi is an interesting tool in this direction. Rather than write in something like teraform, you just use your programming language of choice. Pulumi is just a library you use.

https://www.pulumi.com/

Author Here. Thanks for reading. I am not trying to be misleading. I'm trying to point out that although each step along the way of adding things to config seems to make sense, you arrive in a bad place.

People start with some YAML, and everything is fine. Then a simple condition is added, so ok, we are treating code as data, LISP style but in YAML. Then the logic and branching grows, and we introduce templates and so on.

You start with config, then the config ends up with its own config, and eventually, you are using Skaffold to configure Helm, which generates your YAML. That can't be the right solution, can it?

https://skaffold.dev/docs/pipeline-stages/deployers/helm/

Author Here. My point is not that YAML is a programming language, and that is horrible. Instead, it is used sometimes used to embed a vendor-specific unnamed programming language in, and that is horrible.

People start with some YAML, and everything is fine. Then a simple condition is added, so ok, we are treating code as data, LISP style but in YAML. Then the logic and branching grows, and we introduce templates.

It not that anyone wants to get where we've ended up. It's that each step along the way seems to make sense until you end up trapped in complex templates, and scripts to configure your config and it's too late.

It is a vicious local optimum that everyone keeps falling into.

Author Here.

Yeah, I am really excited about Dhall. I think this is the future, it supports the types of abstractions that we need without the mess of full templating or full turing completeness.

The one downside to Dhall is you really want to have an implementation for it in each common language. You can use it to generate YAML, but I think it would be better if tools understood Dhall and that is a bigger ask because it is a more complicated implementation.

Let's build Dhall implementations for every major language, convince Gabe to format things in a way that makes it look more familiar to non-haskell people and consider this problem solved.

Yeah, thanks for reading my rant. I agree. Its not that I have a problem with YAML itself - although it is bad.

My problem is people embedding a DSL inside or ontop of YAML. Then you end up with the worst combination of config and an adhoc programming language.

Author here.

I was growing frustrated with the increasing about of programming that seems to happen in YAML files. At the same time, my friend Krystal was telling me about INTERCAL, an esoteric programming language that is designed to be hard to use. I had fun observing the ways that these two are different and the ways that they are the same.

I'm happy to hear what people think of this article. I am assuming because 'programming in yaml' is so prevalent that many people don't agree with me.

- Conversations with Tyler

- Deep Questions With Cal Newport

- CoRecursive - Coding Stories (This is my own podcast, so not a listener so much as a creator)

Agree, it seems like the limit of one looks like the other and we should talk about them together. And Property testing has some of the same practical implications that Rob Pike mentions of fuzzing, can it take a long time and its not clear how to do it in CI without slowing things down (or at least it seems that way to me).

Is there a clear dividing line between fuzzing tests and property based testing? They seem to use different words, but do similar things, like generate interesting input and making sure things still work when that interesting input is applied.

Is the difference instrumentation vs hand written generators and hand written invariants?

1. Reddit /r/programming and others

2. Twitter

3. Star Slate Codex https://slatestarcodex.com/ - I've been reading through some of Scott's great writing since the whole NYTimes things brought Scott to my attention.

reply

I agree that a AOT scala would be great. But don't JITs have the ability to react to real world usage and do hotspot optimization and stuff. I assume they are very complicated to build, and if you do thing ahead of time you should, but aren't the things that can only be done in a JIT important?

I liked the first part of his book, that was a biography. The second part with the principles seemed strange. Meetings had realtime feedback dials so you tell the person listening you were bored? Every meeting is recorded and kept forever. I'm working from memory, but it seemed cultish and strange.

Scala is a great language. I haven't done that coursera course, but many people swear by it.

To me, Swift and Kotlin look like they have taken inspiration from Scala. I think Kotlin explicitly did. That idea transfer from one area to another is how we get better langauges.

Interesting! I can see why that might be a better model for the places it can work.

Great Analysis! I agree that languages are becoming more like Scala.

I'm not sure about the JIT part though. Aren't many of the recent language success stories now about AOT compiled languages like Go, Rust and Swift?