It may be less bad, but I don't think there's a right way to retroactively add a type system to a dynamic language. I generally like working in JavaScript, but I have no desire to ever see TypeScript again.
We already had "_1", "_2", etc., for inline block arguments. Adding "it" increases the surface area of the language without adding any new functionality. I think the underscored names are actually better for readability. They jump out at me, while "it" looks like every other variable name.
I agree that `it` is unnecessary, but I'm really confused by the push for a type system. It adds a lot of clutter to a language that optimizes for expressiveness. I would prefer to work in something like Go, which is designed to have types, rather than awkwardly patch them into Ruby.
Does anyone know of a good tutorial for getting starting with Tcl/Tk that still makes sense in 2024? I'm really intrigued by the idea of building and shipping simple, cross-platform GUIs, but I'm completely overwhelmed by all of the installation and configuration options. It seems like tclkit is supposed to be the go-tool tool for self-contained executables, but I honestly can't even figure out which site is the source-of-truth for downloading it, let alone installing it.
I used Zulip at a previous job some years ago and was pretty happy with it. I honestly don't remember whether it had a better strategy for DMs in particular, but the general policy of "everything is a thread" seemed to solve a lot of problems.
When I have this problem, it's usually via a private Slack message. I'm happy to direct people to the appropriate channel, but there's really no good way to link to the original question, even if I wanted to be "warmer". Asking someone to copy-and-paste into an appropriate channel has always worked for me, and I'm not so sure that that isn't the best approach in general.
There was a time when "Black" was considered offensive and "African-American" was the generally-approved nomenclature. You seem to be implying that the "-American" pattern emerged as some sort of white conspiracy to paint everyone else as less American, but my understanding is that the opposite is true. Language and social preferences evolve over time, and that one has simply come and gone as the "correct" option of the day.
As a generally "white" person (of roughly western European descent), I will happily use any set of labels that keeps people from glaring at me. I feel pretty strongly that unpleasant language is a symptom of prejudice, not a cause. If changing words could change hearts and minds, I think we would have seen it happen by now.
You characterized Zig as "not a language for grown-ups" because it enforces a consistent syntax. I was expressing the opposite opinion. You seem to be objecting to a whole bunch of things that I didn't say. I'm just a guy who likes consistent code formatting and good faith arguments.
Ah, then I accept your advice. I happen to like programming, but I also view it as a practical skill and a means to an end. That's the lens through which I was viewing your post. If your central point was that you personally enjoy Lisp, then I don't have an opinion one way or the other.
I've also been dabbling in Go recently, and I'm finding that the culture surrounding it is one of actually understanding what your code does. My main language is Ruby. It hits many of the same high notes that Lisp programmers talk about, and I enjoy writing it. There's just something about the practical, concrete nature of Go code that appeals to me.
A PG article about "doing what you love" was recently shared and discussed on HN [1], and I think a lot of the same logic applies. The nature of a job is that someone is paying you to do what they want you to do. If we're talking about what makes you happy in your free time, then sure, learn any obscure language that appeals to you. If you find something cool that you can do in CL and nowhere else, that's an amazing opportunity. If you just happen to think that life is too short to use a practical, established language, then I don't want career advice from you.
I'm still fairly new to Go, but I've been iterating on the idea of approaching HTML as basic string generation and ditching all of the other complexity. I have a single function that generates HTML tags from name, content and property arguments. Everything else just builds on it. [1]
I'm really curious to do some benchmarking and see how this compares to template-based HTML generation. It seems theoretically possible to accumulate raw data first and then build the document from top to bottom (instead of piecing together a lot of intermediate strings), but I'm not sure the complexity would justify the performance gains.
I also just learned about `gocomponents` [2] in another thread here, which seems to be a similar idea with a substantial headstart. I could probably just switch to it, but I kind of like the idea of following a pattern instead of installing a dependency.
Sure, but that sounds like a culture problem, not a problem with the meeting schedule. If you have abusive higher-ups, avoiding them is not a solution. Honestly, the whole premise of the discussion is kind of silly at that point. If you don't have the power to improve the meeting experience, then you definitely don't have the power to abolish the meeting.
If you lack the confidence and the comfort to report "no interesting progress" once a day, I either pity your emotional state or your team dynamic. Daily standups should not be overwhelming, and abolishing them is an avoidance strategy, not a solution.
This sentiment is commonly summarized as "work to live, don't live to work", and I frankly categorize it as defeatist position. I'm living at work just like I'm living when I take a shower or prepare a meal. I strive for satisfaction and well-being in all that I do. I couldn't possibly have enough fun in my hours of true "free time" to justify joylessly slogging through the rest of them.
Did you pick up any management experience on your way to becoming "too old for this crap"? I just passed the decade mark in my software career, and I've gone from individual contributor to tech lead twice now. I've mentored multiple developers through their junior years and into mid-level positions.
I'm not an expert on agile or waterfall or whatever methodologies people write books about. I genuinely don't know or care what the big tech companies are recommending. I just know that standups are an effective tool for managing a junior team.
Well, the question was about junior engineers. In my experience, they will occasionally burn a whole day without making real progress. Communication is one of the many skills that differentiate juniors from more senior resources.
You'll find yourself choosing between getting "your" work done and doing everything else on the list. It's important to accept that enabling everyone else is part of your job. In my experience, code review is the single most important thing you can do to mentor your team, maintain your code quality, and monitor your progress.
A daily standup ensures that no one spins their wheels for more than a day without giving you a chance to do something about it, which is really helpful for a junior team. However, remember that this meeting is for surfacing issues, not for solving them. Schedule follow-ups with the people who need it and let everyone else get back to work.
Document things when you get tired of answering the same question repeatedly. Focus on ROI, not some higher principle of best practice. You can get a lot of mileage out of conventions and tribal knowledge.
I don't see an obvious mechanism for leaving said feedback. If I'm dumb enough to miss it, maybe others are too. Could you point us in the right direction?
Not documenting the existence/process/details/outcome is exactly the distinction that I intended to make when I called it a "sanity check". I was really just offering a data point, not a comprehensive guide to best practice.
We also built our Stripe integration using only the testing tools they provide. The first real payment in production was completed by our product guy, but only as a sanity check. Maybe we got lucky, or maybe Stripe is just that easy to integrate with, but we haven't been surprised by any production behavior.
In my mind, having a separate bank account is no different from being a physically separate human being. The taller partner will be the one who grabs more things off of high shelves. The partner with a higher salary will pay more of the bills. I don't think it's fair to characterize this arrangement as a lack of commitment.
However, my wife and I do not particularly struggle financially, in part because we do not yet have children. We both have careers and steady incomes, so our individual spending habits are not a major source of conflict. We expect to have a joint account when we become parents. This would be especially important if one of us stopped working.
I share your frustration, but not your confidence that it will impact the success of the game. The "daily challenge" format, though annoying, does seem to hook people.
Using htmx allows you to completely skip a layer of JSON serialization and parsing. It eliminates the complexity of maintaining a second, frontend application, as well as all of its build tools and dependencies. It even opens up the freedom to work exclusively in your preferred language. All of these are examples of removing elements, not just hiding them somewhere else.
I've been following projects like Hotwire and HTMX for awhile now, and I haven't seen anyone argue that scraping is a major reason to adopt this approach. I also don't see a lot of opposition to the idea of incorporating something like alpine to add some UI niceness.
What you see as a "terrifying" disregard for "two decades of advancements", others see as a liberating departure from two decades of unnecessary bloat. It's healthy to have more than one strategy available for building web applications.
I don't disagree, but I also hear "table stakes" used more often as a hand-wavy justification for a feature list than as a genuine, informed evaluation of customer demand. This seems to align with the sentiment of the parent comment. At some point, "common usage" become unassailable, no matter how much it irks me.