Applied computing != computer science

Where was the World Wide Web born? Where was Linux written?

I don’t see the point with this exercise.

This is excellent news for those of us who’ve been writing bash scripts for a long time. We have decades of experience with an idiosyncratic, designed-by-oh-fuck-it language that barely has a syntax and performs in all sorts of surprising ways! This is practically the same thing, it’s a new flavour, there are fewer people who know it, so the consulting rates are higher…

That’s about how I feel … There are a lot of useful platforms locked behind YAML.

But it looks like there is a way out: JSON is a subset of YAML, so I changed my .travis.yml and sourcehut YAML to be generated. So I have .travis.yml.in, and .travis.yml, the latter of which is just JSON. [1]

So I can change the source language to be something else, but I didn’t yet. My configs are like 30 lines now, so it may not be worth it. But I have worked on big services that are thousands of lines of config (e.g. when I used to work Google) . I would say that’s the norm there, and tens of thousands of lines is pretty common too.

I remember someone saying that Facebook is written with like hundreds of thousands of configuration like this? https://research.fb.com/wp-content/uploads/2016/11/holistic-configuration-management-at-facebook.pdf

I’d be curious if people like it or dislike it.

So it looks like you can already replace YAML with Jsonnet, Cue, probably Dhall, etc. Does anyone actually do it? Anecdotally, it does seem like templating YAML is more popular? I wonder why that is. I only work with a handful of services that accept YAML now.

https://leebriggs.co.uk/blog/2019/02/07/why-are-we-templating-yaml.html

I think the functional languages are a little unfamiliar. Oil will use Ruby-like blocks for configuration, sort of like Vagrant or Chef but more succinct.

Oil should will be more familiar to people who know shell / Python / Ruby. If you know those languages, I don’t expect that Jsonnet, Cue, or Dhall is very familiar. They feel like an “extra” thing. And the last thing we want in infrastructure management is yet another config language. (That’s why I think it makes sense to bundle into a shell.)

Ditto for Nix. Nix is very similar to these languages – it’s basically an expression language over dynamically typed JSON-like records, but in this thread there is some negative feedback about that.

Anyway I want to fix this problem with Oil, but I’m not sure in which cases people would actually accept the extra “compiler”. It seems like people are very eager to template YAML, and embed shell in YAML, which is weird to me. I wonder why that is.

[1] https://github.com/oilshell/oil/blob/master/.travis.yml.in

https://github.com/oilshell/oil/blob/master/.travis.yml

Github almost beat you to it, except:

if: ${{ github.event.label.name == 'publish' }}
runs-on: ubuntu-latest
steps:
  - uses: actions/checkout@v2

clearly needs to be

if:
  cond:
    op: ==
    left:
      op: .
      left: github
      right:
        op: .
        left: event
        right: ...
    right: publish

runs-on: ubuntu-latest
steps:
  - uses: actions/checkout@v2

:-)

from:

https://lobste.rs/s/oeelem/using_github_issues_as_hugo_frontend_with

https://github.com/shazow/shazow.net/blob/master/.github/workflows/publish.yml

I work in a place with a lot of Node JS, but it’s not my day to day. I quickly went from enjoying javascript to hating it. Recently I have been enjoying doing some small stuff on my own again. I think I’ve decided that hell is other people’s javascript.

yep. I’m in the midst of a large feature-add to an angular 1.5.5 site. I’m a bit envious of other teams working with new angular and Typescript.

I think vosper is right - there’s going to be plenty of work available to those who are willing to maintain older frontend tech.

I’d argue switching companies in order to use better tech is what a professional engineer does. Strong type systems are equivalent to constraints in CAD for mechanical engineering or ECAD for electrical engineering. They are absolutely crucial for proper engineering.

A mechanical engineer that wants to use something like Solidworks or Onshape at a company using TinkerCAD would not be looked down upon. Engineers need to use the right tools to actually engineer things.

So yes, switching companies to use and practice with proper tooling is a damn good engineer.

Start caring about that when everything else about the company makes you happy. Your happiness is more important than being a “good engineer”.

TS has evolved from a flavor to simply being a better version. The switch to TS is so easy there’s no reason not to. There’s a difference between a challenge and intentionally handicapping yourself.

I generally strongly agree with your sentiment, and am not a fan of the degree to which developers place their identity in one particular technology over another.

But in this specific case I imagine OP is associating untyped JS projects with tech debt and difficulty of maintenance that all too often can contribute to low morale. I’ve definitely been there before when it comes to large codebases with foundational technical debt and no type system to help one find their way around. There’s something uniquely frustrating about e.g. a poorly formatted stack trace coming back from a bug monitoring tool due to broken or buggily-implemented sourcemaps. We can definitely debate whether language choice vs other factors (bad processes, low technical budget) contribute more to system quality. My guess is that language is not one of the largest factors, but it’s probably nonetheless significant. Otherwise we wouldn’t hear about stories where people left their jobs due to being sick of the shop tooling.

At Notion we have some OO-as-state-encapsulation Typescript on the front end, but we have even more functional Typescript, and plenty of code somewhere in-between. We use the advanced Typescript types like as const inference, mapped types, and conditional types much more than we use inheritance or implements interface.

Honestly writing a large from-scratch codebase in Typescript focused on type correctness and make-invalid-states-unrepresentable has been very fun and productive. Our biggest issue with the language is error handling - dealing with all the errors from external libraries, the DOM, exceptions vs Result<S, F>, etc is the most annoying and error-prone aspect of our codebase. Shoehorning optionals into our style has left me paining for Rust’s try features… and I’ve never really written rust either…

Although TypeScript is a bit OO for my taste

My limited experience with TypeScript is that it’s only as OO as it would be if you were writing plain JavaScript. Not sure if that makes sense - another way of saying it would be: JS has adopted some OO trappings, like class, but if you aren’t using them in your JS then TypeScript isn’t going to push you in that direction - you can write functional TS to the extent that you could write functional JS; and OO TS to the extent that you could write OO JS.

Unless you’re refering more to the naming of new keywords, like interface? I see how those could be associated with popular OO languages, but really there’s nothing making you write actual OO code.

I would extend that to “make fewer basic mistakes than your competition.”

You’re more likely to kill your business by screwing up a database backup or password storage than you are to double your revenue with a 10% more efficient application.

Of course, what the basic mistakes are and how to avoid them is an exercise left to the reader!

That’s a good point - re-reading the article, I get what you and the author are saying here.

Yeah. I mean it’s “the most remarkable legacy system” and it’s written about banking software. I was expecting a literal dust-closet server from like the 70s or some old guy’s PC in the backwoods of appalachia.

Ah, thanks for pointing that out. This particular story is from 2002. I still love reading it every time.

• Accessibility
• Composability(heavily related to a couple of others)

These map onto software architecture “quality attributes” which are discussed in detail in the SEI book Software Architecture in Practice. The ones in the book are:

• Availability
• Interoperability
• Modifiability
• Performance
• Security
• Testability
• Usability

Of course certain domains or projects will have different quality attributes than these, but these ones are fairly universal so they get discussed in detail in architecture.

Part of the purpose of software architecture is to get people thinking about these quality attributes and prioritizing them early in the design process because there are usually tradeoffs between them (e.g. performance often comes at a cost of modifiability) and architecture is to some extent about making sure that everyone is on the same page about what the priorities are, so the decisions don’t get made on-the-fly by developers based on their own preferences.

The schema distribution has been pretty much solved, for us, by using a shared protobuf git repo. Go can load that as a dependency without much ceremony, and other langs with a submodule.

I really like that you have things organized into a grid, it makes it so that I don’t have to do a separate search once I’m already on the site.