mnarayan01

Since you're presumably intending to at least glance at all the output, it's hard to imagine speed being a limiting factor here.

Also internal bookkeeping done by the terminal is probably going to limit how much command speed matter, e.g. word/line wrapping: https://stackoverflow.com/questions/21947452/why-is-printing...

Bah I can't read...you two are correct.

You could potentially add something like:

  HISTIGNORE='dpg *'

to e.g. your .bashrc -- not sure if the version of bash on OSX supports HISTIGNORE though (plus many other issues).

The Accept-Encoding header is used to specify the acceptable transfer encodings. Certainly all browsers set it, and most "advanced" frameworks will at least handle the common values of Transfer-Encoding regardless; a "malicious" crawler will almost certainly have to, as plenty of sites use Accept-Encoding along with User-Agent to block undesirable bots.

At least according to https://github.com/rust-lang/rust/issues/28728#issuecomment-... this is a more general issue with clang/llvm -- even e.g. `while(1);` in C is being optimized out.

A semi-esoteric bovid does not strike me as easily distinguishable given the style of the illustrations.

> it simplified the business logic aspect to such a degree that even non-devs were able to be productive with it

* bash (or any shell) -- Might seem odd to call it a DSL, but it certainly embodies the abbreviation.

* Matlab/R/etc.

* Excel (and even VB depending on usage) -- This even plays into "business logic"

You're probably more talking about something along the lines of Gherkin (Cucumber) though. While I've certainly seen it make devs unproductive, I don't know that I've even heard of it achieving the converse unless you loosen the criteria to meaninglessness.

No. This is just an ad for why you'd use their service, disguised as a blog post.

I think the point of this post is: You can use https://cloud.google.com/spanner/ to work with a CP model (typically much less of a headache than AP), while sacrificing so little availability that it's essentially CAP.

The big concern I'd have (assuming using a Google-hosted database was practical) is the SLA. Unless I'm misreading https://cloud.google.com/spanner/sla, it seems like the SLA is...not very strong. Given how they discuss availability elsewhere, it seems like they're totally unwilling to put their money anywhere close to where their mouth is.

That said, it does seem like going with Spanner to have the ease (and power) of consistency while also having reliability and scalability would be something to consider in a whole lot of situations. (Though I'd be reluctant to jump on it this early.)

> In what way is this not strictly better for the defender than if that same process was running as SYSTEM?

You need to make sure there are no holes in the IPC. Like I said, it's presumably not infeasible, but it would have to be done right.

Are you asking about Defender itself or the emulation component? I'd think that Defender does need the higher privilege level for obvious reasons, though conceivably the more "risky" emulation could be done in a separate process with reduced privileges. It would be a pretty big undertaking though; just consider e.g. DoS on a multi-user system by attacking the process with dropped privileges. Not saying it's infeasible, but I think it would be complex.

Yea this seems like the key question. I don't know if Level 5 in two years is feasible, but if it's Level 5 or bust, then LIDAR won't fly (AIUI; would certainly welcome corrections).

On one hand, not pulling in potential safety improvements because they only work in good weather seems wrong, but on the other hand...that might be what needs to happen from a cost/marketing/legal perspective.

Yes. I believe Windows requires you to specify a maximum reserved stack size in the program executable. That's...not going to happen for e.g. Linux.

No: See http://en.cppreference.com/w/c/string/byte/memset#Notes -- if you don't read from it, the call may be optimized away.

Yea I'm in the same boat. It's nice, though there are definitely warts. For third-party stuff stubs are a big help. For stuff I'm actively working on I've found comments/docstrings (I've used reStructuredText) to be useful:

  self.ivar = 1  # type: int
  
  self.ivar = [1]
  """ :type: list[int] """

  def fun(arg1, arg2):  # type: (int, str) -> str

  def fun(arg):
      """
      :param int or str arg:
      :rtype: str or None
      """

I like the comment version (e.g. `# type: int`) better (plus its officially defined in PEP 484), but sadly they tend not to work as well, sometimes due to not being able to `import typing`, and sometimes for other less clear reasons.

If you do the work suggested in https://www.jetbrains.com/help/pycharm/type-hinting-in-pycha... which references https://www.python.org/dev/peps/pep-0484/ and https://www.python.org/dev/peps/pep-0526/ then it can do a pretty good (though not perfect) job. That said...getting it there can take quite a bit of work, particularly w.r.t. third-party libraries.

"Indent with tabs, align with spaces" (e.g. [1]) would be my strong preference in a perfect world. In addition to its "ethereal" benefits, some languages which support HEREDOCs have nice "tab ignoring" versions (e.g. <<-).

That said, in the imperfect world we live in, I always use spaces. "Indent with tabs, align with spaces" is obviously not rocket science, but its just too opaque unless you have a strong code review process.

[1]: https://dmitryfrank.com/articles/indent_with_tabs_align_with...

If foo/bar does not exist, it should be silent. Via http://pubs.opengroup.org/onlinepubs/007904975/utilities/rm.... on the -f option:

> [...] Do not write diagnostic messages or modify the exit status in the case of nonexistent operands. [...]

The big upside to Markdown is that unprocessed readability is fully first-class; if something doesn't provide at least some utility when reading the raw document, then it doesn't exist. Of course, that's also one of its downsides.

I'm not sure that I've ever seen a CEO get extensively criticized on HN for their pay. I feel like this needs at least a single anecdotal comparison from both the WSJ and HN for the question to get any sort of real answers.

You got my point in your first comment in this thread. Unless that comment was the result of hours of striving, it doesn't seem as if the point was hidden well. If you did spend hours working at it, then I apologize and commend you on your success.

  // ... Well typed things ...
  if (arbitrary_well_typed_function()) {
    v = 0xF00 + "bar"
  }
  // ... Well typed things ...

Let's say this program is well typed iff `arbitrary_well_typed_function()` is falsy. If a static type checker can not compute `arbitrary_well_typed_function`, it needs to make a trade-off which a dynamic type checker need not.

> What is the undecidability result you are referring to?

Just the correspondence between static type safety and the halting problem.

> I kind of have the feeling you are trying to make a point about formal languages being "the same", whereas the article uses "the same language" to mean "a single programming language" that allows, but does not require, type declarations.

Yes this. To me, it felt like the article was making the "stronger" claim, at least until the end when it starts talking about co/contra-variance.

The article could probably do with at least some discussion of https://www.python.org/dev/peps/pep-0484/.

Also:

> Our optional type system was designed from the perspective that a single language can consistently contain the semantics of both a dynamically-typed and a statically-typed language.

The obvious meaning of the word "consistently" here would preclude Turing-complete languages from this (recognition of the same language + undecidability), unless you adopt a fairly idiosyncratic definition of "type safe". I haven't read the whole thing, but it seems like there's a lot of dancing around this without actually coming out and saying it. For me, at least, headlining what you're not claiming would make this substantially more readable.

Edit: Okay, read some more and the "Parametric Types and Stanza's Captured Type System" and "Implications for Safety" sections "dance closer", but it feels like the implications need to be pulled out and moved way up. The covariance assumption in particular...let's just say that I was expecting something substantially different by the time I got to that point.

Finally, if you want some nit-picky editing advice: The terms "Thus" and (to a lesser extent) "Hence" are used...frequently. Possibly just me, but I found it fairly jarring.

True, though note that the limit is on active requests on the browser end (obviously). If your subrequests are "heavy" and the user refreshes a bunch, you're now going to have 6x (or 8x or whatever the limit is on their browser) the number of "zombie" requests still being processed on your server.

Having 32 bits of 1-second resolution time and 128 bits of random payload makes the idea that these are "semi-sortable" a bit odd. Consider:

1. Let's be super-lenient and say that we'll consider an average size bucket of up to 64k (2^16) equivalent entries to be "semi-sortable".

2. If you generate anymore than 2^48 (2^32 * 2^16) IDs over the full 100ish year lifetime of the ID, then your giving up on even that super-lenient definition of "semi-sortable".

3. If you're only ever going to generate 2^48 IDs, then 2^128 bits of random payload (in addition to the 32 bits of timestamp!) seems like absurd overkill.

Given the amount of thought that obviously went into this, I'm guessing that there's probably a good reason that they decided to go with 32 bit timestamps (I can certainly think of many, SHA1 length assumptions being a likely component), but if it's in the article, I missed it.

It would be interesting to have a language with first-class(ish) support for "tagged" aliases, where an IDE could then expand to short/long versions as configured. To some extent you could already do it in a lot of languages which support annotations/decorations, but it might be nice to have it more built into the language for "standardization" if nothing else.

Political discussion tends to be of a fundamentally different type vis-à-vis technical discussion. Discussion mechanics like voting and flagging (particularly apropos here) which work well for technical discussions are often...lacking...when it comes to political ones. This is literally what much of the article is complaining about.

If someone is pounding in nails with a screwdriver, I might suggest that they use a hammer instead. That doesn't mean that I think nails are beneath me.

That one jumped out at me too. Particularly since, given the multiple spellings, entering "How to spell gray" (cf. just "gray") actually makes sense.

Possibly related to conversion to/from https://en.wikipedia.org/wiki/ECEF which uses ellipsoidal height (Geodetic), potentially in ways which would be problematic for negative values.