skysight-inc/HackerNews huggingface dataset:
As a JS dev, this actually offends me. I wouldn't expect a specialised package to silently convert strings to numbers.

I think is-odd and friends are the aftermath of the microlibrary craze that followed the popularity of "toolbelt" libraries like jquery, underscore and lodash (which featured some equally inane methods but bundled them along with a load of far more complex helpers you wouldn't want to implement and maintain yourself).
Tesla Model S Crushes Large Luxury Car Competition in USA
But most ticketed events are on private property. It’s not so much as public but that you have been invited in.

Also different regions have different rules about filming in public for commercial content as an example about where permission of everyone in the background might be needed to be granted see France https://www.diplomatie.gouv.fr/en/press-room/terms-and-condi...
Since this is going to be flagged and killed, I wanted to try doing an experiment here:

<script>alert('XSS vuln')</script>

';alert(String.fromCharCode(88,83,83))//';alert(String.fromCharCode(88,83,83))//";
alert(String.fromCharCode(88,83,83))//";alert(String.fromCharCode(88,83,83))//--
></SCRIPT>">'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>
> apologies for the previous short comment.
> Jeez that reads harsh. Apologies, it's late.

All good, friend.

> ... It's really time to move on.

But is it? I fear that if this is a genuine issue, why would I want to move on from it? Essentially npm is enabling people to build bridges in the same way steel is helping people to build actual bridges. If there was a flaw in some steel production process, I wouldn't ignore it. People could suffer.

Extreme(?) examples a side, if it's an issue, why not aim to solve it? This seems to pop up a lot, so perhaps it's time for a (long-term) solution?

> Use org modules/private modules and the problem is solved.

Yes! This is where I personally see the long-term solution: pick your top-level deps, (permanently) cache them locally and validate them, then implement/use them. Only update the cache when you're confident the remote, official copy has been changed in a manner that's safe for you and or your users.

> I absolutely believe that npm is ripe for *potential abuse, although I have yet to have any issues.

How do you know you've not had any issues? If I was attacking you via some sort of "side channel" attack, like breaching and injecting bad code into an NPM module I know you're using, how would you know it's happened?

Are you using a CI/CD process? The changes are high that you are and therefore unless you've version/commit pinning, it's likely you're blind to those deps being updated during your build process, enabling me to perform said "side channel" attack.

> No one has time for Breitbart-esque fearmongering, or the regurgitation of stale points while an ample selection of real world problems exist to be solved.

If it's being regurgitated so much, perhaps it is a "real world" problem to be solved.
We already do it when making salt.
We just throw most of the none NaCL salts away.
Yes. No. What it does is too complicated. And I hear that consistent implementations are not a reality for Xml, either (at least regarding implemented features).
I bought my new work laptop from System76 in January this year with 32 GB RAM for around $1800 (including VAT paid upon importing the device into the EU). They are one of the few vendors that make it simple to configure a laptop with 32 GB RAM.
You can get used to it quite quickly and it is really useful. By adding your expenses right after the purchase you're all the time up-to-date with your budget. You know where you're with your plans, whether they need any modifications or not. I restarted using YNAB this January after a 2 years long pause and now I have again money at the end of the month. :>
US mortgage rates are generally quoted for 30 year fixed rates (about 4.5% currently.) Rates in the U.K. are much lower but those tend to be variable rates which will increase in line with central bank interest rates when those economies begin to recover.
<SCRIPT SRC=http://xss.rocks/xss.js></SCRIPT>
If you are renting, you are renting it from someone who owns the place. I am going to assume that whoever is the owner will at least break even, but more likely will make a profit off the rent income. Therefore, buying is cheaper than renting.

Can anyone explain to me what's wrong with this argument?
I'd totally love to see that happening. Except it isn't. I would even accept Electron if the primary motivation was to enable such a rich terminal interaction experience. But that's not what's the case here, apparently.
It's also the case for Firefox.

It's because Erlang uses a symantec-owned certificate, while Symantec is now distrusted.

https://sslmate.com/blog/post/ct_redaction_in_chrome_53
https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...
Kinda makes you think the person you're replying too is not a JS developer and hasn't touched the ecosystem at all, and yet it's here spewing nonsense.
If I want to keep other people from accessing the account then it's irrelevant whether or not I know the password.
<IMG SRC=javascript:alert(&quot;XSS&quot;)>
Read the linked previous post[1]. Flow doesn't ensure exhaustiveness unless you ask it to, by telling it that any case that goes to "default" is invalid (impossible).

[1] https://blog.jez.io/flow-exhaustiveness/
Turtle [0] indeed is a much more useful "shell" (it's not actually a shell, but so isn't this electron thing)

[0] - https://hackage.haskell.org/package/turtle
Yeah, part of the underlying problem here is a strong view that anyone who likes low-density must be NIMBY or just trying to protect their property value.
It's the typical "no one who knows what i know could possibly have a different perspective and value system than me" attitude.
> not living in the home as their primary residence.

Which makes it disingenuous to the initial headline.

> Renting Is Throwing Money Away Right?

Yes. Given a choice, you always want to own (or at least be building equity). That's the nature of the phrase in the headline. Having money act as an investment (growing/working) for you is preferable to not.
The Pirx stories, esp. Ananke and The Haunt are among my favourite short stories of all time. I've always seen them as parables rather than Sci Fi novels, because in the end the "problem" is always human nature, not technology per se. The're also parables in the sense that Lem wrote about political things he couldn't address directly in the political climate at the time.
No, pretty much all serine hydrolases are affected by organophosphates (assuming they can reach the active site). For example, the compounds IDFP[0] and MAFP[1] can both be used to inhibit serine hydrolase activity in vitro. Diisopropyl fluorophosphate can also be used, although that one actually is pretty much a nerve agent (it's volatile).

The only reason the wholesale disruption of hydrolases is not the thing that kills you with nerve agents is that acetylcholinesterase is particularly susceptible to organophosphates (wide open active site) and essential to nerve signal conduction. Thus although sarin (for example) will wreck most hydrolases in your body, this won't really matter when you'll be dead in a few minutes from your nervous system being unable to tell your lungs to breathe.

[0] https://en.wikipedia.org/wiki/IDFP

[1] https://en.wikipedia.org/wiki/Methoxy_arachidonyl_fluorophos...
>No, transpiled code is bad

Not my experience. While GopherJS ( a Go-JS Transpiler ) has it's warts ( blocking activity in callbacks, filesize ) none of them is "the transpiled code is more buggy than it should be".

The code that GopherJS produces is in my experience very reliable and errs on the side of being slow rather than incorrect.

Transpiling isn't complicated or magic, you can get any C compiler to "transpile" your code into assembly and then compile that without any issues (same for C-LLVM "transpiling").

It also means we get that "sweet" "run same code in client and server" feature that Node.js always rave about.
> Left-pad had a fairly trivial implementation but that implementation is easy to get wrong, so it's something you want to make sure you have covered by tests

...What? That makes no sense. `left-pad` is trivial to implement and test. There may be edge cases but for most people, writing tests to cover the edge cases they care about rather than pulling in a dependency just to handle something as simple as padding a string.

Not to mention, Node's near-complete lack of a standard library is at fault here, not developers, nor the ECMA technical committee.
When you absolutely need that "tar xf" to take 23900 times longer.
> A mortgage payment is a lot lower than current market rent, however.

How do you figure? Rents in London are substantially cheaper than a mortgage. In my current house, a mortgage with 10% down would be around 30% larger than the rent I'm paying. Unless you bought 5-10 years ago, but that's not really a fair comparison.
'';!--"<XSS>=&{()}
> select from orders table where basket size is the biggest. We will then email a nice thank you note to this customer and attach a small coupon/voucher....
...Guess what? 99% of these people became repeat customers

Sounds like you definitely need some ML there, in the form of statistics. Was there a difference in probability of repeat customers between sending and not sending the voucher? Was there a difference between basket sizes and probability of repeat customers? Is there an interaction between the two?
Why do you need to use CSS specifically?

macOS built-in Terminal.app has had transparency (even varying transparency for focused vs background windows) for years.

Edit: oh, maybe you were being sarcastic? It's been a long day.
Long-Tail Keyword: Your Own Key to Success
> we don't tie GA or any other usage analytics to individual users

You may not identify individual users but Google probably do...

> we should put this somewhere more prominent

You should make it opt in by default. Or stop doing it!
Http-kit 2.3.0
> Don’t trust package managers, every dependency is written by some random developer somewhere in the world.

How are we to take that seriously?

Ever heard of not invented here syndrome?

npm has problems, I won't deny it... but its not unique to javascript developers (which your comments about come off as extremely offensive), and its difficult to take seriously given the lack of any meaningful alternative offered.

Its just a rant... and people love to hate on javascript... so... click bait.

(also submitted what 3 times previously? And here I was hoping it would just wash away without triggering a js rant this time too..)
There is something close to what you're describing:

1) You train a complex ML model (say, deep neural net) to get the job done, solve your problem with high accuracy.

2) When you want to explain one of your model's results, you train a simpler more explainable model (say, linear regression) in the neighborhood of that point, such that it is locally similar to the more complex model. The task is too complex to be explained by a linear regression model over all possible inputs, but it often is simple enough around a specific point.
Not me. Objective-C is lovely.

For me the addition of Automated Reference Counting was key. That took a while bunch of tedious but essential boilerplate out of the language. Before ARC, Obj-C was a weird but interesting language that I didn’t want to use. With ARC it all came together into a nice expressive high-level language with raw C power available when you need it.
The Death of the Consumer Camera (2016) [video]
Go didn't have any significant track record until glide came. But it still doesn't have a central repository so every update check means querying all the individual repositories, chokes sometimes on hg repositories, takes tens of seconds even with a few dependencies...

I also don't like how all people became "X developers". We are software developers. I don't think anyone who can code JS would have difficulty switching to Go or vice versa (unless you are a mostly non-technical person, probably from marketing, who learned just enough jQuery, something which I also respect - I never learned just-enough marketing).
"Electron is horrible to deal with as an end-user" - this is not reflective of your average user at all. Most people are just happy to have an app that looks, acts and feels native.
You can use Postgres or whatever as backend to the Blockchain if you wish. Blockchain solutions are maybe 20% Blockchain, 70% cryptography and 10% caching/traditional tech around it (percentages are my rough guess from what I’ve seen). They actually can solve some problems in large corporations relatively easily compared to centralised systems. If I had to summarise in few words why - I’d say it’s because of cryptography patterns and immutable/verifiable/temper resistant, distributed ledger that has completely different security profile from traditional systems - ie there’s nothing to hack except from stealing private keys in which case the damage is limited to areas that this key is covering (usually very small). This has implications in corporate setting because now you can deploy ambitious projects without worrying about security that much...
I've been playing with Flutter and it seems pretty good. Dart isn't too hard to get your head around and isn't too annoying, although I do find myself disappointed that I have to learn yet another language for it. I don't have a particular problem with learning languages, but it's another speedbump on the way.

And Dart is about a million times better than JS for the way I like to think about code.
I see them as a "worse is better"-style half-implementation of Org Mode's tangling functionality on a more mainstream stack. For iteratively building a document that's mixed with some code and some output and looks kinda-nice, Jupyter is good enough.
In downturns you can leave without losing a penny. But the owner can't, as a sunking market already means some lost value.

This is a risk, you can basically price it.

Real estate and renting is usually thought as a very efficient market, so it quickly adjusts to new equilibria. But that just means it's flaws (differences from ideal market and from market clearing) are usually the same as the context (regulations, population flows, regional economy) they are embedded in.
Assume, for a moment, a situation where buying is more expensive for the first five years, but then becomes cheaper (as rents rise, but the amount you repay on the mortgage stays static).

In that situation people buying to rent will make a profit after about ten years. It's therefore not worth it for the short term.

Also, buyers are responsible for maintenance on the building, and for some maintenance, which renters aren't.

So there are trade offs.

(Also, a landlord has to find renters, deal with some of them not paying, invest time and effort into managing their small business, etc)
I see npm has "crazy, mental" because of HOW it's used, not for its sheer existence as a "thing." Technically it's a good solution. Very solid.

For me, it's more the mentality around just accepting a dependency tree made up of thousands of modules, with little to no validation or vetting, versus doing something to make sure what's being pulled is safe and even worth it.

With a Go application, I would 'dep ensure' to vendor what I needed and then actually look at what was pulled. Once I know what's been brought down and I'm happy with the code, I "off line" (cache) those dependencies and never update them again unless I need to (security, bugs or big features.) Also now that they're vetted and off line, I can reuse them over and over in confidence.

Thoughts?
Bill Gates, EarthNow wants to show us every inch of our planet in real-time
For the Appendix: Idris is also a functional language that can compile to JS. I wouldn't say the output is very readable, but except for a couple of JS interop issues, I haven't had too look at it at all :)
Ask HN: Those of you who deleted FB, have you stopped using Google too?
> As a Go developer

Pardon my ignorance but last time I checked Go deps where a mess: you list deps as github repos always pointing to latest master. The concept of version control did not exist. I have written some go and write a lot of js. I'd choose npm over that everyday.

> I assume server-side NodeJS code bases are the same their front end cousins in terms of deps pulled(?)

Most frontend code bases use actually very little dependencies, the big blob of (dev) dependencies are in the build pipeline: you need to transpile, compile, optimize, bundle, etc. the codebase. You only need those if you want to compile the frontend.

In order to run go code you need the compiler which is a binary of at least 100 megs. You can of course compile manually on your machine and push an executable, but you can do the same with a frontend (if your NODE_ENV is production npm will not download all compile deps).
Does editing text with the keyboard alone make sense to you? That's the gist of it, you use commands to manipulate text. It's hard to grok at first when you're only used to textarea style editors without modes.
Because you get state of the art Unicode decoding and support.

What does this even mean? UTF-8 decoding is trivial. In fact it's designed to be simple: it's a prefix code that is self-synchronizing.

Rendering glyphs and composing characters is hard in comparison. But Cocoa, Qt, etc. have had great support for rendering unicode for ages now.

I have no recollection of having problems with iTerm, Terminal.app and many Linux terminals for rendering unicode the last decade or so. (Only with people setting their locales wrong.)
The average end-user has less than 4GB of RAM and would struggle to run electron apps at all. They would get frustrated with the computer being slow but would not know who to blame.

Aside from that, electron apps do not look, act or feel native.
>As I said elsewhere in this thread, personally I use the term "pass-by-pointer-value"

Well, that doesn't apply exactly to ints and longs though...
In other languages, a function with that many parameters would be close to unusable. Far too easy to get them mixed up. The way Obj-C forces you to name each argument is great.
Yes, so let's all keep reinventing the wheel, over and over again.

I know the author uses pretty extreme examples, but I still don't see what's inherently wrong with the mentioned packages.

- it does what you think it does:

`isOdd(2)` is a lot easier to understand than `value % 2`

- even though most of these are one liners, it's one line of code less that you have to maintain

- if the package is at least somewhat popular, it's highly likely it has measures for edge cases; stuff I wouldn't have thought of when writing it myself.

On top of that, mentioning left-pad is really cliche and weak at this point (bear in mind this happend 2 years ago), npm has taken measures and nothing similar has happend since then, and even then, it was still a fairly isolated event - the whole thing actually took 10 minutes.

I'd much rather take a rare, yet-to-happen-again chance that a package goes down, over having to rewrite simple utility functions over and over again, every month.
Sometimes I look at the bug database, pick up the next highest priority bug, have zero idea what the problem may be, sometimes there isn't any screenshots and the description is worded so poorly it is hard to make sense of. So I follow the repro steps, which perhaps take 15 minutes and trigger the issue.

After that I may pause execution and examine some variables and work out what is wrong. From there I need to work out what has caused this to go wrong, perhaps a hardware breakpoint and reloading part of the scene will help.

From doing that may be I see what triggers the hardware breakpoint, a for loop not ending correctly or taking too long to end.

With edit and continue it maybe possible to make the fix, trigger the function again and close the bug. Without it may require a compile, link and the 15 minutes of repro steps.

So edit and continue can massively cut down the amount of time required to fix a bug.

It seems really weird it would be described as amateur or not professional. As usual I suspect it is part of the trend of making everything black and white rather than looking at things on a case by case basis.

Sure if some maths needs to be solved to fix a collision bug when the use is drawing a line on the screen, I would work out the maths and make sure the function is right. But if the maths is right or I don't know what is causing the issue, edit and continue is just another tool for fast and efficient debugging.

In my opinion...
If someone had something as basic as logistic regression or k-means clustering in a production app they are already ahead of the vast majority of ML practitioners
The mentality I see around Go development in general is: what does that dependency you're bringing in do and why do we need it?

The tooling is irrelevant. It's about how it's all brought together and used.
This is great copy writing / presentation. The non slick design comes across as being personal, cheerful and nerdy. I think it works very well for what you are trying to sell.
I don't see that the article says we /should/ give hormones to transgender people at all. Just that dismissing the idea on the basis of (1) maleness being trivially categorisable or (2) transgender being a psychological disorder are baseless.

Whether or not it's the right solution is, obviously, a much more complicated question (and one that is probably rather better left to experts than armchair psychiatrists on discussion boards). But it's also an entirely separate question.
I disagree. I think the design is straight forward. More important is the copy on the page which is far superior to pocketsmith. It tells me about what your product does without having to click around.
It would be much easier to emit if they were standard. For example, in XML each element is self-contained; I can pour it into the data stream without knowing if it is preceded or followed by a sibling. With JSON I have to manage the context.
> last time I checked Go deps where a mess: you list deps as github repos always pointing to latest master

Time to check again.
Of course it can.

Someone (A) can loan Bitcoin to another person (Bank), with the terms that if he asks he can have it back at any time, and he'll also receive a small percentage of interest each year.

Bank can then lend 90% of the money to a third person (C), betting that A will not ask to get all his money back at the same time. To decrease this risk, he does this with lots of people so he is covered in case only a few ask all of it back (but still is in trouble if too many of them do at the same time).

A still has money (his assets are very liquid as he can ask for them back at any time, very liquid assets are what we call money), C has money, the sum is more than the initial amount, so money was created through fractional reserver banking.

That's all fractional reserve banking is, and nothing about Blockchain prevents it.
> Parents that don't want their "kids" engaging in "risky" activities.

Penn State is a university for adults, no? Not a nursery or something.
There are no good options for languages or VMs on Qt in the Java/C#/VM/Jit range of the language performance spectrum.

Qt had pretty good Java support with Qt Jambi. But nobody cared and they cancelled the product.

https://en.wikipedia.org/wiki/Qt_Jambi
Renting is a market.

Why would it be such a special market that every seller is guaranteed to at least break even, when that doesn't hold in any other market?

The market rent isn't whatever it takes for every owner to make a profit.

In particular, not every owner will have the same cost of capital or the same expenses.

Imagine one owner who paid off the mortgage years ago and is able to rent a unit for $200 while another owes the bank 100% of the value at 5% interest and needs to charge $300 just to break even.