cycomachead

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.)

The salary is as high as it is in part due to the Union -- but the UC starting salary for lecturers regardless of discipline and location is around $60K. But computer science is in a roughly better position because a few tenured faculty advocated for higher wages so they could actually make hires. Still multiple people are leaving because the workload/stress/salary are out of alignment.

"Entry level" is tough to define. Perhaps entry level for Berkeley, but these are positions which still require an advanced degree and a good bit of teaching experience.

Not sure how common it is in the US, but at Berkeley the cafeterias are not free. They are a bit cheaper, around $9 for lunch if you prepay, but $13 if you don't! To be honest, I don't even think faculty are told how to take advantage of this... they're off campus too and in the last couple of years, the hours have not been great. Food is totally fine for what it is, though!

I find it incredibly hard to meal prep and bring meals to work too. So, I also often eat lunch out. As others have said, Berkeley is really quite expensive. Even if I go the "smoothie" route for lunch, I'm still looking at $7 with tax and tip and I'm definitely not full... Most days I was on campus I walked 5 miles in total up and down hills, so I often wanted a filling lunch.

I think I don't mind spending the money, but it is a significant change compared to working from home, or working in an office with food, or just making so much more money that you don't care. (Which is how it was when I was a SWE that worked in an office without free food.)

Yeah, the thing is, as someone in the same position as the OP, I feel stupid for always sticking around.

Pamela already addressed the inflexibility part. And I'll just echo that I find it worse than how she described. But I've probably over-committed myself, too. Engaging in research-like stuff is very fun, but it is often unpaid for someone who is a lecturer.

As for job security: Non-Tenured folks (like the OP) get relatively short term contracts. And it's easy for the University to not renew them, especially when there are budget constraints. Sure, I never had a contract like this as SWE and I could have been fired before my 1-2 years were up, but my job there felt much more secure. I knew my manager and how the company was doing. In contrast, while I'm friends with everyone - I don't yet have security that I'll be returning in the Fall, even though my name is on the schedule.

It's definitely not just supply-demand. The application pool for lecturers are places like Berkeley is much smaller than you think, when you start filtering for qualified folks.

Now, at least some of this is academia having too strong of a filter, but the year I joined Berkeley - I was 1 of 4 to accept the offer.