SomeCallMeTim

As I said in my grand-child reply, I don't use almost any Windows-only tools on a daily basis.

As to strategy: If they want people to buy their app, and they're getting all of this great publicity, then "branching out" later will have missed an opportunity to market to Windows users. Heck, Windows users will likely be turned off by their heavy "Can a native Mac code editor really be that much better?" marketing message...

I know I won't be likely to try out their app ever. I mean, if I wanted to go with a well-supported, fast, and clean editor, I'd just use Sublime.

Nova seems to be specifically targeting the Mac-snob crowd as their main selling point, and I don't think that deserves the front page of HN.

Almost every tool in my current weekly use is cross-platform, with the one exception being Visual Studio (and that only when I'm working on a C# app and I don't really have a choice in the matter).

And I use a ton of proprietary tools: SmartGit, Beyond Compare, DataGrip, Postman, Word/Excel, Sublime, Docker Desktop, Blender, Slack, Discord...

The only thing I can find that's Windows-only are the two tools that make up for the shortcomings of Windows shells: MSYS2 and ConEmu.

Seriously; cross-platform (or at least multi-platform) is the future. The frequent posting of Mac-exclusive apps seems to be more about Mac-snobs trying to brag about (and justify) their decision to rely on Macs.

In the notes:

http://www.paulgraham.com/saynotes.html

Note 9.

At least Dictionary.com validates the concept that "gyp" is from "Gypsy" [1]:

> Origin of gyp > An Americanism dating back to 1885–90; back formation from Gypsy.

Same with Miriram-Webster: [2]

> History and Etymology for gyp > > Noun > > probably short for gypsy

In either case, it is rude for the word to be used, contrary to what PG implies.

[1] https://www.dictionary.com/browse/gyp

[2] https://www.merriam-webster.com/dictionary/gyp

Commendable..? Or short-sighted?

I exclusively use Linux and Windows; I see something like this and ... it's a disappointment.

I think what's "commendable" is cross-platform development, breaking out of walled gardens to support everyone.

Some of us learned Lisp and really hated it too.

TypeScript, though? TypeScript I love.

Which seems entirely too familiar for some reason...something that came up a lot for four years but then stopped about two years ago?

¯\_(ツ)_/¯

Very much the same experience.

The whole "They Are Just Go Templates" is a pretty pathetic cop out. Sorry, but it's true. If I'm trying to use Hugo, I don't want to be digging in Go docs at the same time, and as you point out, you can't know things like scopes and what Go variables might actually be available.

And yes, most of the actual syntax is simply not documented.

I subsequently gave up on Hugo entirely and ported my Hugo sites to Next.js, which is in fact documented--and can work well with TypeScript, so complex pages are fully strongly typed, which makes work in an IDE a breeze.

As long as you consider "can just fail if it gets too busy" to be "predictable."

Which I don't. I'd rather see reliable operation than "predictable except for when it fails outright" in almost every situation.

If you've encountered that other situation, where failures are fine? Then great. But I still assert that's a tiny minority of real-life DB use cases.

In my experience, NoSQL is almost never the right answer.

And DynamoDB is worse than most.

My prediction is that the future is in scalable SQL; CockroachDB or Yugabase or similar.

NoSQL actually causes more problems than it solves, in my experience.

Click the "Cloud" option. Free to 1M events.

But...MySQL? Sigh...

I migrated to PostgreSQL later than most, and I've still be using Postgres for six years...

It's extra weird when you know Zooko. One of his kids shared a kindergarten class with my oldest and I used to hang out with him.

Clicked on this to see if it was something he'd done.

So are laws like the Right to be Forgotten. [0]

Which, as soon as one of them is violated, the entire system will be torn down to stop it.

[0] https://mtsu.edu/first-amendment/article/1562/right-to-be-fo...

> ...it's pretty tough to argue such languages really shouldn't exist.

"Shouldn't exist" is too strong.

Dynamic languages that let you create a new variable via assignment shouldn't be used to create non-trivial software. How about that?

Scripting languages have a place. That place is 100% in creating quick-and-dirty scripts and tools. Or in doing some kind of one-off data transform (as is common in machine learning scenarios). Anything that has a life span of two weeks or less, or a code length of fewer than a hundred lines? Yeah, script languages rock for that.

Explicit/static typing adds vastly more value to large projects than the cost of the overhead. The fact that you can't really gain that value in Python means that Python should be relegated to quick and dirty scripts.

Same for JavaScript, Ruby, and other completely dynamic languages.

You'll note that all of these languages are getting types one way or another, meaning that there are a lot of people who do recognize their value. Though TypeScript is years ahead of the rest in the completeness and sophisticated of its type system; bugs like the comma bug detailed by OP, along with simply every JavaScript "wat" bug, simply can't happen in TypeScript in strict mode. And static types enables entire other categories of bugs to be detectable via a linter as well.

It's also propagation.

Article is blaming a misconception on the terminology. Terminology is correct. DNS actually uses both push and pull for different parts of propagation, in fact.

Telling recruiters what I'd expect from a salary, and then never hearing from them again, is something that I consider a feature, not a bug.

It means I'm not getting nagged by recruiters weekly. I still get a new one every month or two, but the frequency is much more manageable now.

Node can run multi-process with the Cluster module. Node being written as a monolith but running it in 100 instances is also an option. Roles can be implemented in software. There's much less "orchestrating complexity" when you're deploying a single service.

So Node being single-threaded is not itself a reason to use microservices.

I tend toward writing a monolith for the core API of a service, but then break out microservices for tasks that need to scale independently (or that need to run on high-memory/high-performance instances, for example). So I'm not totally against using microservices. But we should choose to use them when they're to our advantage to use them, not just "because they're already written that way."

It's not a problem that they start as CRUD apps. That's exactly the place where ORMs or query generators should be used: CRUD code is always the same and as such should be 100% automated.

So then when something different than CRUD happens? You use the ORM, a query generator, or completely custom SQL, depending on which is the most appropriate to the situation.

Performance doesn't need to be an issue if the query is extremely rare; if it's core to your app, by all means, write completely optimized SQL. But if it's an extremely rare query or only shows up for your admin page? ORM code should be fine.

That's the point of the parent comment: When you get good enough you learn where to use each.

>You can treat people kindly without having to agree with their opinions, or taking their PRs.

I think that having your PR rejected, no matter how "kindly" you phrase the rejection, is not going to feel good.

So "treating them kindly" and "rejecting their PR outright" is a contradiction. Sometimes you just have to tell someone their PR isn't going to work out; that it doesn't just need a few tweaks, but rather a start-from-scratch approach that's 100% different. Flowery language aside, that's going to sting.

The "game day" analogy is maybe not a great one, but I get what they're saying: Sometimes you can't afford to spend the time that would be required to educate everyone on exactly how to change their PR so it would be appropriate. Where truly "treating people kindly" would take more of a time commitment than writing the code yourself the correct way, where it would really mean training a junior developer up to mid-tier or senior developer level? It's just not compatible with getting the work done you're responsible for. You can't spend all of your time coddling every potential contributor.

So sometimes you just have to say, "Sorry, no, this PR just won't work." Where that's the kindest thing you can say given your constraints. Maybe that's all you mean by "kindness," but the person receiving that comment probably won't see it as very kind. Rejection simply never feels good.

>The majority of most things is not good

"90% of everything is crap." -- Sturgeon's law [0]

The problem is that once someone has put in the time to create a PR, declining it is never going to feel good for the contributor.

Yes, they can maintain their own fork with their changes. But to be told "this doesn't work for our project," no matter how politely, is often emotionally interpreted as a form of rejection.

Which is what spawns the kind of rant above in the original link.

[0] https://en.wikipedia.org/wiki/Sturgeon%27s_law

I passed an Amazon interview by saying almost exactly that, so given Amazon is one of the FAANG companies? I can back up my statement.

> no one is skating under the radar at MIT

Funny you should say that.

A past CEO I worked with was a CS grad from MIT. He would laugh about the fact that "he could code, but no one would want to use the code he wrote."

I've also heard another anecdote about an MIT grad who had excellent grades but who somehow couldn't get any work done on a relatively straightforward project.

So yeah, even MIT graduates CS students who aren't the best at code. CS being "Computer Science" means they need to understand the theory, but even an MIT grad isn't guaranteed to be capable and talented in writing code in practice.

If there were a "software engineering" major (or certification?) which, among other things, required the student to write nontrivial code, and it was judged by experts, including using subjective design criteria, then maybe we could start using that degree or certification to prove that, at least at the time of the tests, that person could code. But the devil is in the details even then...

I actually did end up hiring a W2 employee who didn't work out. He moved cross country for the job too.

Let him go after only a couple of months--but that was several months of pay that produced literally no positive results. And I was running a small development house at that point; dumping two months of salary down the drain was not a good thing for the bottom line.

So yeah, totally agree. Paying everyone who "seems good on paper but who just can't pass the programming test" really doesn't work, despite wishful thinking to the contrary.

Funny you should describe it like that, but ... what you've just described is almost indistinguishable from pair or mob programming.

Where one person needs to describe clearly what code needs to be written so the other can type it. Actually pair programming requires more effort in that regard, since describing what you're doing is easier than describing exactly how to write it.

I don't do 100% pair programming gigs, but I know they exist, and I've used pair programming in short bursts as a tool for knowledge transfer.

It sounds like the study points to the idea that "talk through your reasoning" is a bad interview approach.

The last interview sequence I needed to do they put me in front of an online IDE and said "go code." They also said I could use my OWN IDE if I had it set up. One even said "you can finish it later (post-interview) if you want."

The candidates giving up: Some nontrivial percentage of CS students are just ... not capable developers. That's why we use programming tests to begin with.

Programming tests may be the worst possible way to assess candidates, but they also seem to be the only way to assess candidates that doesn't involve paying them for a trial period, which really only works for companies large enough to be able to waste a lot of money. "Democ­ra­cy is the worst form of gov­ern­ment, except for all the oth­ers."

And for 1)--a good interviewer won't actually mark you down for not knowing some fact, or not being able to think of some trick. I've passed interviews where I've just said, "Hey, I don't know [that particular thing]. How should it work?" or "I'd Google the exact algorithm for X; I'll pretend I wrote that and call it here..." or similar.

Good interviewers want you to pass, and aren't just giving you a test of arbitrary programming trivia.

What you describe is orthogonal to whether a developer has empathy, though.

1. UX design is a trained skill that most developers don't have. It's not a lack of empathy if you have no idea how to create a better user experience.

2. Many developers are in it only for the paycheck. They do exactly what they have to in order to keep being paid, and not a minute more of effort goes into their work product. They may be an excellent people-person, and in fact may be able to talk themselves into raises and promotions at work due to their excellent empathy skills. But if they really don't care about the end user or the work product, that's not a lack of empathy as much as a lack of pride in work.

3. RTFM may be misplaced if there really is no good manual, but a significant fraction of the time I've seen it employed (or more polite variants) was because there was a manual that had the exact answer the developer asking the question was looking for, and the questioner just didn't bother to look. I spent an entire year and a half on a project answering questions to the same developer with links to the documentation where he could find the answers he was seeking. I swear he would ask me something at least weekly, and I always could just point him to exactly where I'd already answered that question. It's not a lack of empathy to just start saying RTFM. It's a failure of PATIENCE with someone for asking the same question you've already answered a hundred times because they're too lazy to look up the answer themself.

And telling an end user to RTFM goes back to point #1 above: If the user feels the need to ask how to use a product, then that's a failure of UX. See Don Norman's many books on the topic: He's fond of saying that an ideal user interface shouldn't require instructions. An as in point #1, if you needed instructions to begin with, that implies bad UX, which isn't the fault of a programmer, but rather of a UX designer. Most programmers also shouldn't be front-line on helping end users anyway because of the patience issue I mentioned.

There are developers out there who just lack any form of empathy. Granted. Anyone with the skill to code can likely find work, regardless of their shortcomings; demand is such that they will be hired even if they're generally jerks. But I don't accept that programmers are in general less empathic than an average person. It's just that empathy isn't a job requirement.

The problem is that the law isn't being enforced with any consistency.

You know what's required for a patent to be awarded? It has to be non-obvious. It has to be something that someone "the typical person in the field" wouldn't think to do, when given that problem to solve.

If the patent office (and later, the courts) would just apply the non-obviousness criteria reasonably we wouldn't have these problems.

And yes, that means they'd likely need to consult with people in various fields. It's not exactly free to get a patent; some of that money could go to pay those same consultants to judge the obviousness of each patent as it is reviewed.

> If it causes you financial pain it's gonna be felt as a punishment.

So...when you go to a restaurant and eat, paying feels like a punishment?

When you go to an amusement park, paying the entry fee feels like a punishment?

When you pay for a plane ticket...a new appliance...a movie...?

No, the only reason that "taxes are a punishment (or theft)" is a meme _at all_ is that there are a bunch of entitled, privileged, well-off folks who have decided that they have theirs and they don't want to spend anything that will improve or support society.

I've gone through these arguments a few times, and ... yeah, the naivete on the other side is profound. You're right that I won't "win" an argument with someone who espouses that, or at least I won't convince them of anything, but that's due to them ignoring reality.

In this particular case? A usage fee, for cars, that supports roads, for cars? Seems pretty damned natural-consequences to me. You're paying to use something, not "being punished" in any way.