skysight-inc/HackerNews huggingface dataset:
I use Windows 10 pro out-of-the-box on all my machines. I change few default settings. Seeing a tile for the latest Microsoft game in the Start menu just doesn't bother me. I like Cortana. I just checked on the weather.

I note that Macs have an unremovable Siri, but nobody here is upset about that.
I can't speak for the GP, but my interpretation is that the wasted effort comes from doing what you describe when, instead, one could have chosen a simpler language and produced understandable (albeit "ugly", "not eloquent") code the first time round. Then one can turn those intellectual wheels on a more interesting problem to solve.
Never is a strong word
I find the opposite is true. It too often means the focus is on fiddly and tedious book-keeping - instead of writing some code that says “please do a thing”, I write some code that says “please perform these 20 steps to do a thing in excruciating detail even though you are much better at deciding how to do this than I am”. It’s noise that detracts from the readability of the code far too often for my taste.
I assume the idea is that the technology is still in its infancy and in a few years it will be competitive.
> google really wants people to stop using them but isn't dumb enough to straight pull the plug quite yet.

I have my Google life spread out across a couple of (grandfathered) Google Apps account, and don't use any @gmail.com accounts for Google services, so it would suck if they pulled the plug.
Most Interesting Facts
So does he just glide through books understanding everything on the first be pass? If so what a lucky guy.
>>Weak/lost/compromised password means that, the account is gone.

Not if you have 2FA enabled.

Not that SMS-based crap either. I'm talking about the _real_ stuff, such as TOTP.
TypeScript's complexity comes from trying to model typical JavaScript patterns using a compile-time type system.

It turns out trying to model a dynamic language's typical usage at compile-time is lead to some complicated stuff.

Personally I think it's mostly worth it since most of that is hidden behind API-boundries or (more commonly) in type-definition files and your own code typically either has really simple type annotations or is inferred (i.e. not explicitly type annotated).

But I see your point and it does sorta feel a bit C++-like in this respect sometimes.
I recently had to install Windows 10 and ended up installing "Windows 10 LTSC". Right after install i used "O&O shutup" and "Win10-Initial-Setup-Script" to get some sane defaults/strip all the crap.

It's sad that Windows itself has become bloatware...

https://www.oo-software.com/en/shutup10

https://github.com/Disassembler0/Win10-Initial-Setup-Script
For perspective: the people cooking your business lunch probably don't get a break of any kind, let alone a 30 or 60 minute lunch.
If it's provided because of its benefit to the employer, it's not taxable (same reason company computers are a business expense and not a taxable perk to the employee).

The logic is that the company gets benefits from providing meals that exceed the costs, e.g. shorter lunch breaks since employees don't even have to leave the building. And given that meals can be provided at scale for under $10/head, then even shaving 5 minutes off a lunch break is worth it at Big Tech compensation levels. There's also benefits to having employees eat more meals with other employees, and thus some work gets done over lunch.
"Correlation" being the key here. All of those things are also correlated with having a good upbringing and environment, as well as nutrition in childhood, as is IQ, so IQ is basically an irrelevant reflector of environment/inheritance factors.

https://www.youtube.com/watch?v=8wcSSLo9TIs
One of the nice things about having a repository/store interface is that it’s easy to make an in-memory fake for testing, so you can have at least some subset of your tests that don’t need to spin up a database container/vm in order to run
Isn't Seaborn famous for this very reason? matplotlib is a bit difficult to write code in but seaborn makes it easy.
i agree with you. go is not the simple language its creators wanted. and i feel like it's only going to get more complex from here on.

for example, i couldn't get a library to work the other day because of one of the dependencies needed a specific version of another library but "go get" (1.13.4) was getting utterly confused.

i never looked into the modules thing and i found that there is a 4 parts series of articles on the official blog explaining modules are and why we need it. i just gave up at that point and decided to manually copy the version i wanted to the $GOHOME/src folder and it got me going...
Joe Doffy argued, in my view persuasively, that Go missed an crucial opportunity by not requiring that users actually do something with returned error codes.

http://joeduffyblog.com/2016/02/07/the-error-model/#forgetti...

> It’s surprising to me that Go made unused imports an error, and yet missed this far more critical one. So close!

Result/Option/Maybe types force unwrapping, which makes ignored return codes auditable and allows you to manage technical debt.

This doesn't speak to Go's simplicity so much as it does to Go's conservatism. Having the Go standard library use sum types, establishing a precedent and a culture, would be no more complex in the absolute, but would have been more of a stretch for its initial target user base.
What’s a Digital Marketing Strategy?
I agree. I wonder if Apple put a little tile up to show the new Mac Pro, or of Red Hat put a little widget up to show Red Hat cloud suite would we hear the same complaints.

It's just a little tile that shows a Microsoft product.

I run Windows 10 out-of-the-box on all my machines. I don't run any special "cracks" to remove features, but I may have turned off a few things from Control Panel; I don't remember.

It's a very good operating system. Rock solid. Runs 64- and 32- bit Windows programs, Linux Programs, and anything I want in a VM.
In Go's case, it's too early to tell how it scales. It has the opposite approach to readability as Perl.

I wonder if Go ends up sharing Perl's fate. Two languages that make people feel very productive, but don't seem to scale very well.
Gentoo also has it: https://www.gentoo.org/get-started/philosophy/social-contrac...
I think this is a major reason you often see such a stark personality split between cofounders—one being more freewheeling when generating ideas, and the other being deeply pragmatic.
Bullion is usually not the basis for a credit economy. I remember reading Graeber's "Debt: The First 5000" about this point, but I forget the details. And if we're talking about an "illusory basis" (i.e. much more money than there is bullion) - so in a sense it doesn't matter all that much whether it's Gold or BitCoin. You won't have the distributed nature of BitCoin then, because banks would create "BitCoin-backed credit", i.e. banks create the money.
Tao's Solving Mathematical Problems: A Personal Perspective (https://www.amazon.com/Solving-Mathematical-Problems-Persona...) mentioned here is an excellent book that provides keys to mathematical approach to problems and is now a classic ranking there with Polya's How to Solve It.

One thing the article doesn't touch on is Tao's prominence in massively collaborative math research through his blog (latest such work from there was discussed on HN a day ago https://news.ycombinator.com/item?id=21542054). This new approach, first proposed by Tom Gowers (https://gowers.wordpress.com/2009/01/27/is-massively-collabo...) in 2009 has successfully solved a number of open problems in the past ten years (https://polymathprojects.org/2019/02/03/ten-years-of-polymat...).
>The original specification, created by AMD and released in 2000, has been implemented by AMD, Intel and VIA.

>Intel's project was originally codenamed Yamhill. After several years of denying its existence, Intel announced at the February 2004 IDF that the project was indeed underway.

If Intel wasn't so focused on the Itanium they would of beat AMD by years.

Anybody who was following the industry at the time knew about Yamhill at least by 2002, though Intel had conceptions on how to extend x32 to x64 well before that in a natural way, but instead went the resource and engineering draining Itanium route, allowing AMD to produce the first available chips.

While I only know murmuring on the peripherial about Intel's early x64, I'd love to hear insider knowledge about why management decided Itanium was so hot that they dropped everything about bringing x32 to its logical x64 conclusion.
If you're not sold on Utility-first CSS, your gut reaction would be, how's it different from inline styles? The author does a great job at listing out the differences, but I think that kinda misses the point.

If you've to accept Utility-first CSS, you should unlearn the fact that there is something inherently wrong with inline-styles. Often, they are much cleaner solutions than creating an entirely different class that won't be used more than once. Utility-First CSS only makes it easier to use inline styles (by reducing verbosity) and provides a standard set of classes so you don't end up creating 100 variants of margins.

I have found it hard to convince folks this is indeed a good approach because inline styles have acquired a reputation of being a disgusting hack. A while ago, my outlook was not very different. But then, I started seeing how often I was writing the same styling rules again and again. Our 1MB stylesheet was nothing more than a repetition of a few basic rules. Utility-first CSS builds on that idea and to me, it feels natural.
Compute derivatives of any order to machine precision
It may help to adapt some tools. For example, in the tabletop RPG world, a lot of random tables are used to develop new concepts for stories, characters, interactions, missions, and so on. You roll the dice a few times and suddenly you have a very unique and imaginative idea indeed. You can draw up your own random tables and tweak them over time, like creating software.

There are also sensory cues: You might choose a new location to do your gaming, play some appropriate mood music, etc. On one of my first ever "software guy does graphic design" projects, I asked the client what music they liked, and then listened to that for about 3 days straight. It really helped me get into the correct problem-solving lens where more appropriate colors, shapes, fonts, and textures were concerned.

On top of that you may find there are supplements that help you out. Personally if I'm running on 8+ hours of sleep and take about 100mg caffeine, I feel like I can solve just about any problem and new ideas are more likely to seem fun. ;-)

In the past I wrote some randomization software to help me solve problems. One of my favorites simply picks random words out of a dictionary. Each word is treated as a metaphor. I remember once a client said, "I thought I knew exactly what you'd say, but that is an idea that never would have occurred to me." This was my goal.

IMO there's a lot of space to grow in this area even if you feel like a potato where your imagination is concerned, and the process can be really enjoyable. Good luck to you.
I think some of your premises are mistaken.

>>If I ask 'what is the weather in this city?'
>>Does that question make sense without mentioning the city's name either before or after?

Yes, it does, if we're standing in a city when the question is asked. "This" would obviously refer to the city we're in. Likewise, in this instance, "this" obviously refers to the question that is currently being asked.
I'm fairly sure this applies to content creators, not consumers. To avoid storage and bandwidth for content that doesn't show ads but has a high maintenance cost.

If they really intended to remove the bandwidth cost from people watching youtube without ads they would start by implementing ad blocker detection.
The reason that IBM/Motorola stop being competitive was the cost of staying competitive was to great compared to the number of processors they hope to sell. By the time that Apple made the switch to Intel, they were the only PPC customers besides game consoles and mainframes that had different needs. Apple was only selling five or six million computers back then.

Now, Apple sells about as many ARM based devices than all of the PC manufacturers combined [1] sell x86 chips. Apple will be its own best customer.

[1] Apple sold about 230-240 million iPhones, iPads, watches, AppleTVs and if it start selling ARM Macs it will add about 16-20 million to that number.
I agree that Go forces you to focus on mechanics of your code more so than some "fancier" languages.

However, Go's poor type system also forces you to write worse and less safe code than you want.

For example, the lack of enums and sum types means it's hard to represent, safely and efficiently, anything that should be the same type but have different values within a strict set of allowed values. The nearest you get in Go to an enum is:

type Color int
const (
Red Color = iota
Blue
Green
)

Alternatively, can do the same with a string:

type Color string
const Red Color = "red"
// etc.

This gives you some type safety, since a Color requires casting to force an int or string or whatever to become it. But that doesn't give you real safety, since you can do:

var c Color = Color("fnord")

This comes up whenever you're handling foreign input. JSON unmarshaling, for example. You can override the unmarshalling to add some validation, but it won't solve your other cases; it will always be possible to accidentally accept something bad. Not to mention that the "zero value" of such a value is usually wrong:

type Color string
var c color // Empty string, not valid!

A more safe way is to hide the value:

type Color interface {
isColor()
}
type colorValue string
func (colorValue) isColor() {}
var Red Color = colorValue("red") // etc.

Now nobody can create an invalid value, and the zero value is nil, not an invalid enum value. But this is unnecessarily complicated and shouldn't be necessary in a modern language in 2019.

The case of genuine sum types is worse. Your best bet is to use sealed interfaces:

type Action interface {
isAction()
}

type TurnLeft struct{}
func (TurnLeft) isAction() {}

type MoveForward struct{
Steps int
}
func (MoveForward) isAction() {}

There are some downsides. You have to use static analysis tools (go-sumtype is good) to make sure your type switches are exhaustive. You get a performance penalty from having to wrap all values in an interface. And if you're going to serialize or deserialize this (e.g. JSON), you will be writing a whole bunch of logic to read and write such "polymorphic" values.
Audiophile equipment is nothing like a multistage cryogenic refrigerator. It's made of pumps, seals, heat exchangers... and when you're using helium 4 as a coolant you really need zero leakage because it's an extremely expensive.

And yeah, microwave systems need amplifiers going up, and filters going down. But they need to be extremely efficient -- and also entirely non-magnetic. But unlike audio, these components need to be linear in the gigahertz, not kilohertz. There's some similarity, but huge differences.

It's weird that the title focuses on cables. There's a ton of expensive, labor-intensive components that can be bottlenecks.
My business partner's kid runs a cracked Windows 10 LTSC when he plays games because "he doesn't like Microsoft spying on him" as if he's some valuable target.

Because it's hacked, it's crashy (and also his "rig" is overclocked and badly integrated.) And of course, he blames "Windows" for being so crashy.
Depends on the city. In some - mainly EU - places old cars are a killer. Everything is set up to strongly discourage use of old cars. e.g. Cars going for peanuts? That's cause it costs a fortune to safely dispose of it as required by law (i.e. recycle). Easily solution is to sell it.

See also Norway's rules about electric cars. That sky high adoption is a direct result of weapons grade carrot & stick to force it
Code-duplication and goto statements have something in common: neither is inherently bad, and both are zealously maligned inappropriately by the developer community in aggregate. Sometimes two functions perform the same abstract operation on the data but have subtle differences in the implementation: fully duplicating the common parts in two different functions is not a bad thing necessarily. But "testability" and "reusability" zealots will turn blue in the face arguing that one should carve the functions up into a mess of abstracted spaghetti to support them both. The result is code that isn't any easier to read or maintain and, worse, is less performant.
> Isn’t DNA sequencing my medical information and protected by HIPAA and other privacy laws?

It would depend on the context of how the DNA sequencing was provided.

If your Doctor ordered it as part of a treatment plan and billed your health insurance, then yes, it's a medical record covered by HIPAA.

If you personally ordered DNA sequencing and gave the results to GEDmatch, then HIPAA does not apply. GEDmatch is neither a Covered Entity[1] nor Business Associate[2] of a Covered Entity. From a legal perspective the DNA database at GEDmatch is no different than phone or banking records.

[1] https://www.hhs.gov/hipaa/for-professionals/covered-entities...

[2] https://www.hhs.gov/hipaa/for-professionals/privacy/guidance...
What if you lose your phone?
> For CLI it’s true to the Go mantra. If the flags library is “good enough” why not just use it and avoid being fancy?

Users of a command line utility ultimately don’t care what language it’s written in; having a familiar interface is a much more important goal. Since the vast majority of Linux utilities these days use GNU-style rather than Unix-style long options, it stands to reason that the latter is a better choice for users. (There are also technical advantages I won’t get into.) I know Rob Pike probably isn’t a fan given his background, but why not give developers the choice to build what they want to build, instead of shoehorning them into something they dislike? What’s the point of being opinionated here? (Edit: Sorry, didn’t mean to imply that the standard library ought to have it; however, I do find it strange that in the ten years of golang the community didn’t bother to come up with a reasonably good library for it.)

Btw, flags is very primitive and can hardly handle anything complex, even if you accept the Unix-style.
If you care about a rich standard library, and static self-contained executables, I would strongly suggest Crystal. I have used both Go and Crystal, and the latter is much more productive as well as simpler. It’s standard library is richer. See, for example, the things you can do with strings with the provided functions. I used to love Go. But after some time the verbosity got tiring. I moved to Crystal, and there is nothing I miss from Go. Two big caveats: 1. I dont work in a big team. 2. My main use case is a web-backend.
People who like "Go's simplicity" are talking about a completely different kind of simplicity than Lisp's or Forth's or Smalltalk's.

The latter are simple in that they're built around a few core concepts which are available to the developer, almost any tool the language designer had is available to the end user. They're simple in the sense that old school legos or meccanos are simple.

Go is simple in the sense of simplistic, it provides a much larger number of restrictive features and most definitely doesn't give end-developers access to the language designer's tooling. It's the simplicity of playmobil or duplo: the developer is provided with much more concrete (and effective in a way) but much less flexible "primitives".

And this is no secret, there's a pretty famous quote from Rob Pike explaining the design and purpose of Go:

> our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

Making codebases look uniform and preventing building abstractions (by the language being actively hostile to abstractions which are not built-in) is in line with that.
Ad blockers get rid of ads.
Detecting Photoshopped Faces Using AI
Most cases are not caught because there is a direct march, but because there are multiple distant relatives that match and allow detectives to triangulate the suspect. Final confirmation is done w/ direct testing after probable cause.

Faking your own dna has little effect on this process of triangulation and can easily be identified as you won’t share expected traits with relatives.

Good luck...
Eat Like the Ancient Babylonians
TOTP isn't any more real than SMS. Social engineering easily defeats both. Use FIDO2 or U2F.

[Cue usual HN discussion about loss or unavailability of physical tokens]
> Compare that to JS or even Python, where I have to either use libraries for even the most basic stuff or have a huge amount of syntax and keywords.

in python, you don't have to. same for javascript, before the whole jquery era, and the nodejs era that followed, we didn't even know what javascript libraries were.
why does matter? it's a serious question. it sounds like if they just renamed it Jawa instead of Java your complaint would disappear?
Citing Kathy Sierra’s book, Badass (pp 91–92)

> Evidence has been mounting for decades that for most non-sport domains and for most people,“natural talent” is not an absolute requirement for reaching high levels of expertise.

> Other than the sports that depend on specific physical prerequisites, few domains have hard genetic limits for expertise.There is a way in which natural ability might contribute to high expertise in non-athletic domains, but it’s not domain-specific “natural” gifts... it’s a natural ability for focused practice.

…

> Even at the very top levels in most non-sport domains, there’s little evidence that “natural talent” is a hard requirement. But where it might exist, it’s most likely to show up at the beginning of the curve and the very very very top.
If you have access to friends or family with children the next time you're hanging out you should try asking the kids a simplified kid friendly form of the problem you're trying to solve. They'll usually give you a completely correct answer that interprets the question in a way you never would. It's both interesting and enlightening.

Since they haven't internalized the exact definitions of the words they're using or hearing, or even how the world works from a physical or logical perspective you literally can't replicate it with your adult brain. You know too much. It's kinda cool.
For what it's worth, I get the feeling that the reason TypeScript is growing so much complexity is not because the language designers expect you personally to use it all.

It's there primarily so that your development environment can give you accurate feedback when you're using your favourite JS libraries.
Define "scale"... Large codebases? Teams? Long-lived projects? So far Go looks excellent at all of these
> It can be easier to maintain a small amount of code that you duplicate and check in

> compared to a general library imported for one routine that you have to think about

IMHO, that's why small, one-utility-function libraries in the JS ecosystem([0], [1], [2]) are useful. (Unlike the general tone in HN where npm and left-pad gets a lot of hate.)

Look at Quickutil[3] for examples of other languages. (In this case, Common Lisp.)

[0] https://github.com/sindresorhus/mem/blob/master/index.js#L7

[1] https://github.com/sindresorhus/tempy/blob/master/index.js#L...

[2] https://github.com/zeit/ms/blob/master/index.js#L48

[3] http://quickutil.org
You could also say that Google wouldn't have gotten anywhere without Linux, as they really depended on lots of cheap hardware and software. Humans are connected, which is a great thing (that what makes us human).