cycomachead

To be fair, most of the work environments people are romanticizing are not about the cubicles, but the startups. Smaller teams, kinda scrappy, but mission driven.

In a way, it hasn't changed a ton. Except, the startups now are not so scrappy, and the mission is pretty hotly debated (and for understandable reasons0.

Assuming no one surreptitiously swaps out the pages!

You still gotta keep it secure. ;)

The Web is meant to have links and interactive content and be navigated, sure.

But to expect every author also upload a PDF? I mean, TeX is great for what it is, but there's a reason _the web_ adapted print stylesheets.

Even if (La)TeX (or Typst, or Postscript or anything else) were easy to learn, you're left with maintaining 2 copies or a compilation system which is also a challenge.

It's ridiculous this is a problem, and has been for many ages.

I do a lot of teaching, and for many reasons share PDFs of articles in addition to the web pages and URLs. I know how to work around these things, but lots of reasons to print and article and what are normal folks supposed to do? Hell, sometimes I don't even notice until the cut is buried in the middle of the long document...

While everyone probably should learn something about their devices, the defaults you provide to users should be good ones.

Drawing a line can be hard, but clearly the basic font should be contrast-y enough so that most people can read it, no? The user can control the defaults of many things on their devices, but we shouldn't require them to change settings to have a good experience. We already customize websites a lot.

I think it depends on the goals of the print version, but people spend a lot of time picking fonts and styles so things look good on a screen. I take this as saying you should supply the same type of attention to your print style sheet.

I teach CS at Berkeley, as a lecturer. i.e., I'm contingent and on a contract. And don't really have grant money—though, y'know I actually try to supplement my income so I can live in the Bay Area. I spent years working in EdTech as well.

Others have already say why TA's (and graders) often do the grading. That's also not the same as the prof not paying attention to the work students do.

But I do want folks to think about the time faculty are actually allocated to teach courses. I have a 2 unit course I teach, ~70 students this term, and 2 hours of class. I'm paid for maybe 8 hours per week for all the prep class time, planning. Doesn't actually leave much time at all for grading. There are definitely qualified students who could be TAs who would give the students much more time and feedback than I am able...

For other courses, I have a bit more time allocated, but hundreds of students and still one of me. The only way students get feedback is when TAs grade.

Anyway, that's just the practical bits...

A lot of faculty are moving to 100% proctored assessment, and I think it sucks. For me, reading at least some of the student responses and seeing the data are helpful. Faculty do want to engage with their students and are similarly demoralized when everything is reduced to a transaction. It's hard not to be nihilist about it. Our own jobs, even at a public University are just capitalistic transactions with fewer profits. Students want the degree because it's the only thing they can hold on to as a token of hope for the next few years. Both students and faculty can fall into patterns of really low trust, and it's hard to be the 'outlier' trying to trust students when most of your colleagues say people don't do the work.

I don't actually have great solutions for building intrinsic motivation in students, except talking to them and minimizing the extent to which everything is a transaction. But I'm required to assign grades, still.

Parsing basically works!

Whether using text with LLMs in Snap! is actually a good idea is up for debate, but it is doable.

To some extent, that’s not the point. You don’t need to learn all of CS in one tool.

That said, I think you can learn good fundamentals of SWE with tools like Snap!. You can still learn testing, design patterns, working with APIs, modularity etc.

No it’s not a distributed system, and perhaps the biggest pain point is collaboration is tricky. But still you can learn a ton of cool things without going that far into CS. :)

Honestly this is still a great way to deploy apps and still some of the best DX there is, IMO.

Costs a crap ton for what it is, but it is nice.

I don't think complexity comes just from the number of tools, but the disparate things you "need" them to do. Redis, Vite, large CSS toolkits -- you're learning a bunch of large components.

I mean complexity comes from many places, but compared to the 'Unix philosophy' most of these tools are quite large. Obviously, there's quite a bit to learn about the way a *nix OS works, but if you treat tools as small and composable for simpler interfaces it helps a lot.

The web dev example of pub/sub is funny, because chances are if you're using Rails your primary DB (probably Postgres) already has a pub/sub system in or. Or you can just use any RDBMS for your job management system.

I mean, I think the problem with SPA-like client-side approaches are that there aren't any that have felt _good_ with Rails, let alone great.

Absolutely true that not every app needs to be a SPA from day one, but I do with there were a few more common solutions for "hybrid" apps, which use some pages as a SPA. That said, it's not that bad once you've got it setup. I like that Rails offers a solution like import maps, but I do also wish there were better core functionality for using some kind of package manager.

Like the redis analogy: Whether or not you need Redis, there are good defaults and very good 'third party' solutions for background jobs (or caching). You don't even need Redis is many cases, but it's easy to grow into.

Lapis is very cool, but I really struggle with a lack of examples and pre-built solutions for some things.

Leafo's itch.io is built with it and I maintain snap.berkeley.edu. A great tool, but I'm also many times more productive in Rails. (It's an unfair comparison, to be sure!) and Openresty + Lapis is quite performant and low overhead which is great.

I believe cloudflare has quite a bit of Lua in some of their products (there's some very good Nginx lua integrations and variants like Openresty).

Agree, especially because it'd be nice for projects that use LuaJIT if you could swap the versions as needed.

I love JS and Ruby, and I spent a bit of time maintaining a web app in Lua.

There are parts about the language I really enjoy. I like dynamic languages; I don't run into type issues so often it bothers me, but the tooling around Lua still leaves me wishing for me.

Part of this is really my own ability, or lack thereof, but I feel slow and constrained in lua. I have a hard time debugging, but I don't feel these things in other languages.

I have a close friend, who's an Azure dev -- uses his MS laptop for work, his phone for everything else. And I do mean everything - taxes, trip planning, etc.

It's not just crazy kids who "know nothing but phones". Even engineers.

That said, phones operate too much like appliances. I will not give up my Mac.

I've been wondering about this... It definitely doesn't feel great to be on the receiving end of something auto-generated. But a "unique" message is at least more interesting to read, and doesn't feel quite as frustrating.

A yet if P(someone unknown is a robot) gets too large, it's going to be a weird adjustment period.

Oh I think they are! Gruber is by no means alone in his praise. And the technical details are impressive. (Plus the 14" and 16" are fantastic improvements.)

No I read it that way too.

Guard clauses are great, and when used appropriately clean things up. This is pretty much my only use of the pattern.

(Ending boolean-returning methods with a ? is also a great convention in ruby.)

Yeah, it's not usually an issue in practice. But I do see students get confused trying things out...and it's likely because learning in an interpreter doesn't often look like "real" code does.

There's a bunch of things to pay attention to in Ruby. I wouldn't say these get too hairy, but they trip students up for very understandable reasons.

* `a ||= b` is not just `a = a || b`, but `a || a = b`

* The distinction between defaults arguments and hash arguments in functional signatures has many edge cases -- but it's much much better in Ruby 3.

* There are still 2 pieces of syntax for hashes (`{a: 1}` and `{:a => 1}`) They are the same.

* Curly bases show up a fair bit for a language that's not a braces language. :) They're in hashes, blocks, and % strings. e.g. `%w{a b c}` is the same as `%w|a b c|`. They're also used in string interpolation, e.g. `"Hello, #{name}"`.

* There are sometimes many ways to do the same thing. There's Procs, blocks, and lambdas. % strings work with many characters.

* `unless` for `if not...` and get wonky.

* Overusing "surprise if" e.g. `do_thing if other_thing` can be hard to read.

* It's so easy to monkey-patch and extend primitive classes, you might not realize when libraries do it.

All of these are features that I actually find nice to use in the right contexts. But they can pop up when you don't expect, and they can definitely make Ruby a challenge to learn. That said with a little discipline (or just a linter ;)), I find a lot of Ruby code a joy to read and write.

In that case -- I definitely agree Ruby usually gets out of way. It's often my go to for hacking on something, unless it's data science-y.

I'll mention: implicit returns, return if, and safe navigation, the &. operator. Ruby's newer pattern matching features are really cool[1], especially for things like JSON structures, but I've only use started using them. Classes are also super easy to extend.

Many of these things are also incredibly easy to abuse - but they have their places.

[1]: https://docs.ruby-lang.org/en/3.0/syntax/pattern_matching_rd...

Comparing Apple Silicon and x86 as the difference between having modern plumbing or not...not exactly where I expected the review to go! Gruber's hyperboles can be entertaining for sure.

But damn, I can't wait for the time for me to upgrade my Intel Macs.

This is a valid point, but definitely a misleading title.

More productive is really hard to say... But I personally prefer Ruby to Python. For smallish scripts, I really like Ruby's backticks for easily executing shell commands. And I find the metaprogramming support in Ruby great for some tasks. I'm not sure if that's what you're getting at.

But especially with "modern" Python features like f-strings and the walrus operator there's not tons of differences that really stand out as "productivity".

One thing to just remember: Ruby is not just the Ruby on Rails community. Rails is a dominate space, but it's not the only thing out there. At the same time, when it comes to scientific computing, ML, etc. the Python ecosystem is incredibly robust. There's plenty of awesome Ruby tools for these things too, but it is not the same.

Ruby and Python are the two languages I primarily teach courses in, and used professionally. Ruby is my cup of tea personally, but they're both modern dynamic interpreted languages.

The fact of the matter is that it wouldn't even necessarily need to increase tuition. The UC system is a $50bn/yr enterprise. Lecturer salaries are a tiny amount, and really only about 20% or so of tuition money right now is directly attributed to instruction costs. If the University worked on a budgeting model that valued instruction, then I think the pay gap could be significantly reduced.

This is true, but it also sucks if we assume "part of a career path". That means there's virtually no teaching-focus career paths in the UC system which is terrible for basically everyone. (Students as well as other faculty.)

In reality, there's spots where it very well could be a career path but it's incredibly difficult to make it work in CS. (And in many many other fields too!)

That's really not quite true. There are thousands of lecturers in the UC system, and many thousands more where it is a career choice. Because tenure track is simply just not possible at many places, especially if you want to teach and do not want to do, or do not have a research background. The UC system especially has a career progression for lecturers, though it is somewhat challenging to make it through.

I would honestly say that you should consider this! If you think you'd enjoy teaching at a place like Berkeley and have experience, there is a need!

https://aprecruit.berkeley.edu/JPF03311 -- this is the CS job posting https://aprecruit.berkeley.edu/apply -- this has all the lecturer postings, including related fields.

It's really hard to find folks who are going to enjoy the tradeoffs. (Also feel free to contact me directly. Append gmail.com to my username.)