skysight-inc/HackerNews huggingface dataset:
Hi,
I made this little app to better understand how A* works. I decided to continue developing it for educational purposes.

Computation is done on worker so main thread should be safe all the time.

I plan to add textual information on each step, to show how algorithm is "thinking".

Also, heuristics is fixed for now, I plan to add heuristics choice. So,

Roadmap:
- different heuristics
- 8 way support
- Detailed explanation of each step

Let me know what you think!
I find myself wishing the question of whether to factor code out wasn't binary. Like if you could transclude parameterized code. You'd get the benefits of not having to keep a stack trace in your head, while still having a canonical version of an abstraction. Like a macro, but always expanded in-place.
In my experience, languages with strict non-null guarantees (and optional types), do the exact opposite of "mask the error". If anything, they are sometimes faulted for being too verbose.

The idea is, by explicitly marking things which can be null (wrapping them in an Option[T], for example), you can be sure that everything else is not null. This alone relieves the developer of a large cognitive load.

Further, the language can provide syntax to make handling optional types obvious without being painful. Rust match statements are one example of this.

Can you provide a specific example of how using an optional type makes a potential "missing-thing" type of bug harder to see?
It appears that they are unwilling to update to the latest Rust-stable release due to the testing burden on the OpenBSD-stable team; which then conflicts with the Firefox Rust update policy of, as I read it, ‘latest Firefox stable will use latest Rust stable’.

https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox
Sorry for the off topic grammar question, but am I the only one who finds it confusing how people have started to use plural pronouns to refer to individual people?
The code is not large enough to need maintenance at a fine-grained level.

There is a secondary rule to the DRY "rule of three": If I can blow it away and rewrite it so easily, there is nothing to reuse or refactor in it. The feature is done, and we are into code golf and speculation, neither of which are productive uses of time. In my experience the success rate of speculative refactors like the one author made has perhaps a 50/50 chance, so no better than the initial strategy. It's the requirements themselves and the application of techniques to avoid various classes of errors that give code direction and structure - not the aesthetics at a moment in time(which is what author took issue with).

If you spot multiple approaches on the first try, you can add a comment with a date outlining alternatives so that the conversation may be resumed later when the new requirements come in. But at all times you're always at the mercy of "discipline", and there's no preemptive measure that avoids that.
It definitely is something that needs to be said, as it is not uncommon to find people doing the opposite: taking a rule-of-thumb and asserting that it is the one true way. The people who are most likely to make this mistake are smart and well-motivated, enthusiastic about the power of abstraction to simplify things, and have some experience but not a lot.
- "Capitals tend to attrack [sic] most inmigration."

- "Not all capitals - it is a question of policy."

- "Interesting. So in Japan people inmigrate [sic] more uniformly?"

... then you don't answer but proceed to compare capitals of the world to each other. I thought we were comparing countryside immigration to capitals vs to the rest of the country. Not between countries.
I have a project I couldn’t use SHA-2 on because of speed and because it was a 224bit or 256bit result.

Is there a way to use Blake3 in a reduced hash result way? Like 12-16 byte results. (IIRC, you can not truncate hashes for smaller results)
Want to Be Less Anxious? This Therapist’s Newsletter Is a Great Start
No, Mozilla does not distribute Firefox binaries for OpenBSD.
I'm finding this kind of issue coming up a lot with the current abhorrence with polymorphism and inheritance.

I like using interfaces and protocols, but I also still very much use inheritance. It's a fundamental tool that was invented for a reason, and, sometimes, it is the best tool for the task.

I've probably weathered just about every "paradigm shift" that has happened in software development. At one time, using variables with names longer than four characters was considered bad programming.

Anyone remember GOTO?

Some older constructs (like the two above): good riddance. Others...not so much. Structured Programming, which was declared The Mark of Satan, at one time, is still very much the basis for all our work.

I love a lot of the new tools and techniques, but I still mix in a lot of the older stuff when I write software. To some, this is "unclean," because it doesn't tick some arbitrary "büzzwürd du jour."

Simple, solid code is always a great starting place.

The author talks about removing repetitiveness (DRY). I think that's excellent, but, in my experience, I need to be very, very careful when I do that, as the original author may have tweaked just one little line, in one of the clones, and my refactoring may break things; sometimes, not until it's been out to the customers for six months.

That's pretty much de rigueur for any refactoring; not just DRYdock. In my experience, having some robust unit tests and test harnesses in place is absolutely required (and development branches -yay new-fangled VCS!).

I tend to write code iteratively. I'll start with some naive, sloppy code that works; maybe not well, then refactor it in stages, testing the heck out of it; each time.

I used to work for a Japanese company. I had many differences with my Japanese peers, but they were the most disciplined programmers I've ever encountered. Whenever they would modify code, they would leave the old code in there, but commented out, and add some comments, explaining what their new code does.

Made for some pretty verbose source files, but it was immediately apparent what was done, and why (I think the practice began before most good VCSes were invented). It also gave you the original code to copy and paste, if necessary. Very old-fashioned, but it made their changes (and bugs, therein), easy to understand. It also helped because the code was often stepped on by many programmers.

I'm thinking that a lot of folks are relying on commit comments to explain changes; which is good, but adds extra time to figuring something out.
This comment would be much improved with a list of those languages.

Kotlin and Swift come to mind, what are others?
> I'm surprised at the harsh negativity in this article. Not that the inquiry into why people become 'haters' isn't intriguing, but to explore it so shallowly and to boil it down to "Well, they are losers", and call in the image of "basement dwellers" frankly, makes pg sound like he is falling into the same trap he is trying to write about - generic hating on others.

I think PG has a very specific audience in mind when he writes: founders. I don't think he's trying to create a holistic understanding of "haters." I think he's trying to tell founders not to think about them. It's a waste of their (founders') time.

Haters, and the accusation of being a "fraud," cut to the quick of the confidence founders need to be successful. They often already feel like frauds (or imposters) and acquiring haters only seems to confirm this for them.

I see this glib (and in my experience accurate) treatment of haters as a device founders can use to stay focused.

But I think the other side of your point is worth exploring. As a founder, how do you assess when you have gone (or are contemplating going) too far? Given the fine line between overconfidence and under-confidence, can founders even expect themselves to be able to make that self-assessment?
AHA

https://kentcdodds.com/blog/aha-programming
Thanks, sorry :(
"Premature optimization something something..." ;)
> Ever watched kids behaviour before and after sugary and non-sugary meals?

Yes, and I've never noticed a difference. I believe that "sugar rushes" are imaginary.
>Are we going to live in a world where we're constantly being recorded and analysed by hidden cameras?

Yes. Worse - the governments don't even have to spend the time and money setting up these cameras, the consumer is buying and setting up more and more surveillance devices on themselves and those around them (Cellphones, Google Home, Alexa, Nest cameras, Ring cameras, etc. etc.) than ever.

All of it piped into communications networks we know they have untapped access to. All of it being stored and analyzed in places like the NSA's data warehouses, the output of which gets added to things like our XKeyscore profiles. Rise high enough on their undefined terms and they'll make extra effort to analyze your appearance in that network traffic.

Might sound dystopian but that's how it is. It's for our own good, don't you know?
San Francisco east of golden gate park is pretty pedestrian friendly ?
> Excel is a much better product than Google Sheets, but having the better product doesn't mean having the winning product.

Much better product? Sheets takes literally seconds to download and install and runs on all your devices. Also it automatically syncs your data between devices and sharing data with other people is as easy as sharing a website. These are very important features in my view and makes Sheets into a better product than Excel. A power user might have different opinions, but to me writing sheet.new in my browser is just so much more convenient.
I think this is a great post, it covers a topic succinctly and agree with its conclusion.

On the topic of actually refactoring code I think we should consider the code as a variable - that is to say, sometimes these variables just happen to equal each other in which case they are two separate things. Sometimes two variables aren't just equal, but they're the same. That's when to factor out the code. Otherwise the second these two variables are no longer equal you end up in trouble. The secret is divining when something is for all intents and purposes the same as something else in this specific situation.
It started in the 14th century. Wikipedia has a good article on it: https://en.m.wikipedia.org/wiki/Singular_they
Guide to Binary Ninja Architecture Plugins
Porn fiends? Doctors don't have the time. But you must admit that the profession brings out some very arrogant traits. They usually express the pointof view that they learned everything they needed to at med school and any new outside information is suspect and not important including IT security.
I think it’d be hard to isolate factors to test your hypothesis. You’re likely not wrong to some extent given that HRT changes the body (almost always for the betterment of voluntary trans individuals), but there’s so much activity going on in the song and dance of society it’d be hard to isolate.
> it's easier to reason about

Consider you have 4 times a block of 10 lines of code, they are identical except for a couple of parameters. The person who reads the code has to 1. figure out what the code does 2. see if the duplicated parts differ in some subtle way.

The alternative is to replace the duplicated parts with a function that has a meaningful name. This makes the code easier to read. It's not a premature optimization. It would make sense to keep it duplicated if you're in an explorative phase and not sure yet what the final design will be, but I wouldn't submit a patch where parts are obviously similar. I'm not sure it would pass review.
With respect, this is terrifying. You can only apparently log in as the Amazon root user, not a restricted IAM account. There's zero "about us" to display who I'm doing business with. The pricing is a joke, particularly at the high end. And the typos on the page do not fill me with confidence that this is a trustworthy business.
I don't agree the issues OP later discovered has anything related to `refactoring` itself, but more a issue of premature optimization.

my 2 cents, an interface is defined, it shall not be modified for no good reason. Even if you do, you can still have some way to make sure it can be compatible with the original system. and I don't believe you can't extract some common behaviors of those repeated code, and use them within the interface, refactoring doesn't mean you have to rewrite the whole project, it can be done by piece by piece. reducing a line of duplicated code can save you a lot of efforts on maintaining the project in its life-cycle. a lot of times, I have seen a code change was made to fix some bugs were forgotten in other place which duplicated the same original code.
Iran plane crash: What we know about flight PS752
I have a friend named Aryan who was not allowed to sign up for a Microsoft account with that name. Support even refused to make the exception when asked, suggesting that he sign up with the name "Ryan" instead.

To this day, emails from that account have "Ryan <lastname>" in the header.
I really love(d) Scala for introducing me to the whole idea of Optionals.

I wish for the life of me I felt like I could approach Scala at a time when it wasn't going through huge flux (I have shitty luck). I spent a good amount of time pre-version 2.10 :( and then recently went to have a look but saw Dotty (version 3.0?) coming by the end of 2020 and I was like "well, FML, time to wait a few more years and try again."

Anyone have any tips for using the Scala ecosystem effectively these days? Should I just wait for 3.0? Is it going to be a long winding road of breaking changes until a "3.11" version?

Is there a good resource for what folks are using it for these days? It seems like all the projects I used to know are ghostly on Github (but that could also be the fact it has been quite a few years, heh). Or do most folks just pony-up and use plain ol' Java libraries while writing their application/business logic in Scala?
If you think reality has a lot of detail, ‘unreality’ will blow your mind. (I’m referring to Hilbert space.)
The problem is updating the rust toolchain requires testing all other ports with that dependency to make sure nothing broke.
Also you can do the stretching in the browser client (“server relief”) without losing security. Historically this would have meant a big performance penalty (and thus an advantage for attackers, who don't need to use your code) but JS and wasm are fast enough now that the price is fairly low.
If there's something that I have learned about refactoring code that is repetitive into "cleaner" shorter code, is that the refactored version looks better but it's way harder to understand. When other people try to look at the "cleaner" version they have to spend more time trying to understand it and mentally untangle the abstraction.

I like syntactically shortcode as long as it's clear. I also understand that sometimes shorter code has some small performance advantages that can add up in languages like JavaScript where the size of the files can become a loading speed bottleneck.

But to be honest it really bothers me when someone tries to make perfectly fine and readable code into something different just to satisfy some weird intellectual urge to make things more abstract.

Sometimes long code is not only easier to read and understand, but it also helps to create a better technical outline of decisions that otherwise will get lost in the reasoning of whoever is writing that code.
Cultures die all the time, and it's usually due to a number of factors - one of them of course being immigration. Pointing this out is not racist. It's a statement of fact, with plenty of history to boot.

>It's just blatantly obvious standard-issue racism.

No, it isn't. There have been entire neighborhoods in e.g. Harlem that have been gentrified out of their cultural heritage. Is lamenting that fact racist? I for one think it's sad, that a culture that was distinctly black is now gone forever - and it's not racist to say this. Now, Harlem is likely a bad example because it's a place in America, where we are supposed to be a melting pot and this kind of thing happens all the time. I don't have enough experience in Europe to give a more pertinent example, but again I still don't think it's at all bad to lament the fact that there's been some cultural turnover - especially when it happens on a very short timeline. That seems perfectly normal.
Growing complexity. Struggling scalability. Overspecialization. Balkanization. Failures of accountability.

OP’s firsthand observation on the awful state of programmer-produced medical software, the original linked article, and notoriously lethal software disasters such as Therac-25 provide frightening cases in point. These things are not accidents. Programmers who only know how to program are as much use as managers who only know how to manage. And this world has far too many of both.

Look, any idiot can hack teh codez. Learning the problem domain; that’s the hard part. It is also the critical core of the job. Because if you don’t/won’t/can’t understand the problem, how do you possibly expect to solve it?

Especially when that problem space is something as vast, complicated, and utterly unforgiving as millions of people’s healthcare.
Cool, thanks for the reply. Are the approved use parenteral? Have you considered aptamers?
you can also try to reason about the situation to figure out if the duplication is incidental or inherent.
I think the catch all term for that is YAGNI.
"First you learn the value of abstraction, then you learn the cost of abstraction, then you're ready to engineer"
Donald Trump is clearly the person with the most power to affect climate change. US presidents generally are the most powerful regardless of the topic. That's why it is important for the American people to vote him out of office. It's our last chance to avoid catastrophic climate change.
I got prescribed Rosuvastatin and got extremely vivid nightmares to the point of waking up unrested. I thought I was the only one because I could find much online. The dreams and nightmares are so intense I have stopped the statin.

Thank you for recommending me exercixe. That might be the answer.
A chemo truther here, if you will. AMA about what I understand about chemotherapy. To the best of my knowledge only very few cancers respond well to chemotherapy - they are testicular cancer, Hodgkin lymphoma and ovarian cancer.

If you contradict any of my opinions, before I reply to you I want to know, your personal experience in investigating cancer therapies beyond what your doctor, medical school or news media told you. For example:

- Have you read at length the articles/books by mainstream train MDs who have a different opinion?

- have you talked to oncologists with dissenting opinions?
There is a delicate balance: a sense of ownership can encourage pride and responsibility, but it can also impede cooperation.

> Better ask for forgiveness than permission.

Not in this case; you are likely to piss people off, especially if there is a consequence you have overlooked.
That is human speed though (better than human speed, even). For most human tasks that need to be done, 5ms versus 5s doesn't really matter.

Consider also that spending an hour at the DMV for them to update a database entry or two is also human speed.
“But you must admit that the profession brings out some very arrogant traits.”

Which one? You know we’re also talking about programmers, right?
I imagine perspective explains a lot of the behavior. San Diego's police department has been getting flack for streetlights with cameras in them for example, but San Diego's police department has also been having trouble hiring enough police officers. From the perspective of the PD the cameras probably /are/ for the people because the people are making the (currently) impossible demand that the police force be both effective and also configured in a way that has led to a staffing shortage. Not that I give the same benefit of the doubt to the FBI, but it seems like the Occam's Razor explanation for why LEO would do something that from the outside looks hostile.
Publishing to Multiple Topics in Azure Service Bus
Reminds me of a study they did for... chance to get parole approved based on time of day. Findings were early in morning and after lunch breaks was the most successful time. Just before clock-off and lunch inmates chances were reduced.
>I am skeptical of the idea of the idea that culture is fixed and immutable.

It's absolutely not fixed and immutable. That's what this whole discussion is about: whether there should be policies directed at preserving culture as it exists.

>It would exist in a time where mass immigration is causing the problems I mentioned above.

That the Far Right has gained power in Germany, Austria, Poland, Hungary, Italy, etc etc (not to mention the US) today is all the evidence I need that we live in that time already.
Principles are not rules. Also, maintainable and readable code are of uttermost importance.
I don't think the research is public, because it's all entirely about internal tools, but yes the conclusion was that the got interface for perforce led to less efficient development across basically any metric you could look at (LoC, commit count, self-reported efficacy, etc.). Note that if you judge developers based on commit count is a bad metric, but comparing LoC throughout of developers who are evaluated on other metrics isn't problematic.
In an environment where all code must be reviewed, when you make a change like this you send it to the original owner for review. Or at least someone on the same team, if they're not available.

"Don't be too attached to your code" means trying to review improvements to the code you just wrote objectively. Can you accept changes with good grace?

But you can't get to the point where you have a smooth-working team if you have philosophical differences about what improvement looks like! If one person's improvement is another person's regression then those difference need to be worked out and some kind of synthesis agreed to. This can take a lot of time, but it's necessary work to get to that ideal.

On the other hand, a lot of work gets done by teams that are not smooth-running teams that are in philosophical agreement. It may even be a good thing to have a diversity of opinion and avoid group-think? You have to be able to accept some messiness though.
Have to push this fantastic article again - if you read it and follow what it says you won't make these mistakes: https://programmingisterrible.com/post/139222674273/write-co...
If we're limiting ourselves only to new languages, then nulls are statically excluded not only by Kotlin and Apple’s imitation of it, Swift, but also by F#, Agda, Idris, Elm, and (sort of) Scala. But the zozbot didn't seem to be talking only about new languages, so Haskell, Miranda, Clean, ML, SML, Caml, Caml-Light, and OCaml are also fair game. (It wouldn't be hard to list another dozen in that vein.) Moreover I think you could sort of make a case for languages like Prolog and Aardappel where you don't have a static type system at all, much less one that could potentially rule out nils, but in which the consequences of an unexpected nil can be much less severe than in traditional imperative and functional languages like Java, Lua, Python, Clojure, Smalltalk, or Erlang, which more or less need to crash or viralize the nil in those cases.
The AOL Time-Warner merger 20 years later
Yeah, the whole "replace a block of text" auto-correct can be a fucking nightmare, but I personaly haven't had bad performance. Maybe I'm just not remembering it... or I'm not thinking of all the uses cases.

On Android the latency of the screen has always bothered me when typing so much I can't notice anything else, but I haven't had a high-end Android device in years where that could be remedied (I was very tempted by the OnePlus 7 but didn't want to fork over the cash just to try).
Precisely the opposite.
I don't think it's Rust specific. It's just that distros are very C/C++ centric.

The fast releae cycle of Rust might not help though.