Hacker Newsnew | past | comments | ask | show | jobs | submit | progne's commentslogin

Blown up hospitals can be secondary to firing rockets from the parking lot and using them as ammo dumps and military headquarters. You can take this line of reasoning back to the big bang without addressing the quality of evidence of a severe food shortage.


They can be, but given how many times Israel's made the assertion only to go "oopsie doodle, our multibillion dollar intelligence apparatus made a boo-boo and it turns out that there actually was not an installation under this civilian infrastructure", this isn't as robust a premise as you think it is. Anyway, the quality of evidence seems to suffice for doctors, NGOs, human rights watchdogs, practically anyone who isn't an Israeli official or an apologist thereof, probably something worth considering.


The fact that the two highest profile examples of starvation in Gaza have confounding conditions makes me suspect otherwise. If it is as widespread as feared, it should be easier to find pictures of starving Gazans than fat Gazans.

It is notable that in the same famous photo of the emaciated Mohammed Zakaria al‑Mutawaq in the NYT article, his not-malnourished looking brother Joud was cropped out. And their mother is not emaciated. Is she supposed to be starving her younger child to feed herself and her other son? To me this is evidence of press cooperation with a propaganda campaign.

I submit that if you find either side in this propaganda war to be credible by default, you do the other side a disservice.


>The fact that the two highest profile examples of starvation in Gaza have confounding conditions makes me suspect otherwise. If it is as widespread as feared, it should be easier to find pictures of starving Gazans than fat Gazans.

Sure, if Israel wasn't actively targeting journalists and cutting off telecoms from within the strip, and the case for starvation rested entirely on a couple of photographs in mainstream US broadsheets.

>It is notable that in the same famous photo of the emaciated Mohammed Zakaria al‑Mutawaq in the NYT article, his not-malnourished looking brother Joud was cropped out. And their mother is not emaciated.

You're right, just like it's notable that in the retraction, they didn't mention that his 'confounding condition' was caused by her malnutrition during pregnancy, per the same report that was used to force said retraction. Also, emaciation is not present in all cases of malnutrition.

>To me this is evidence of press cooperation with a propaganda campaign.

But, not say, calling it the 'Hamas-run Gaza Health Ministry' to diminish the credibility of the casualty figures which were good enough for the WHO and UN? Odd.

>I submit that if you find either side in this propaganda war to be credible by default, you do the other side a disservice.

If you were sincere about this standard, you would apply it to yourself. Even this statement is implicitly propagandistic, if not conspiratorial.


“Automakers have been making hybrids long enough that they’ve gotten really good at it. Plus, many hybrids are also made by manufacturers that tend to produce reliable vehicles overall, such as Toyota, Hyundai, and Kia.”

It's anti-intuitive that hybrids would be more reliable than pure ICE cars. But it would be explained by this if hybrids are somewhat less reliable than the ICE cars from these three makers. Presumably Consumer Reports has that data ...

For the big picture you need to compare the relative reliability of components after X million have been built. I would be surprised if the reliability of EV tech hasn't improved faster just because it has developed more recently.


What's even less intuitive is that while hybrids are the most reliable category, plugin hybrids are the least reliable. Aren't they just a hybrid with a bigger battery and a charging port?


Just 12 years full time with Ruby here, I'm a noob. But when I see that I could replace

  def initialize(text)
    @text = text
  end

  def inspect
    "#<#{self.class} #{text}>"
  end

  def ==(other)
    other.is_a?(Word) && text == other.text
  end
with

  def initialize(text) = @text = text
  def inspect = "#<#{self.class} #{text}>"
  def ==(other) = other.is_a?(Word) && text == other.text
I start drooling a little. That's 3 lines to replace 11. We have a soft limit on class length of 100 lines, and I like the extra conciseness this allows.

You can also do it like

  define_method(:inspect) { |text| "#<#{self.class} #{text}>" }
and we do that in some places, but that extra verbosity makes for more lines.


Unnecessarily cramming more density into one line to avoid soft limits seems like a poor tradeoff.

Ask any typesetter. Blank space used well gives text breathing room, making it easier to parse visually.

In the former example, it is extremely easy to pick out what each method name is and a decent idea of what it does at a glance. In the latter, I have to read to even see the method names.


Ask a typesetter? No thank you.

What is a typesetter? Someone or something which takes tree-structured sentences, cranks them into a linear sequence of words, which is arbitrarily chopped into a rectangular form, with the goal being that the rectangle appear evenly gray from a distance. Sometimes ugly hyphens are inserted into the middle of tokens.


I feel like I'd still want the body on its own line from the signature definition just for readability. And with the parser problems described in TFA, I'd say that parens should be mandatory coding-style enforced by linter.

  def initialize(text)
    = (@text = text)
  def inspect 
    = ("#<#{self.class} #{text}>")
  def ==(other) 
    = (other.is_a?(Word) && text == other.text)
seems like a good compromise.

edit: this is similar to our standard when writing one-liner methods in C#. A bit noisier because of types and visibility, but still pretty concise, imho.

  public void Initialize(string text)
    => Text = text; 
  // I actually hate the above a bit because "=>" 
  // originally implied functional/no-side-effects 
  // in C#, but the world moves on.

  public string Inspect()
    => $"{this.GetType().Name} {text}>";

  public static bool operator== (Word a, Word b)
    => a.Text == b.Text;


Personally I'd never let your first example through a code review. If you're going to break it up, use end. Where the one line format makes sense is when the body is trivial and often when there are multiple related methods that can be lined up to highlight their similarities and differences in the single line format.


Hah, I'm a firm "no alignment allowed, indent only" reviewer, so that use case would never even occur to me.


I can't stand that. It dramatically reduces code readability to me.


I tend to agree with Google on this one:

https://google.github.io/styleguide/jsguide.html#formatting-...

> Terminology Note: Horizontal alignment is the practice of adding a variable number of additional spaces in your code with the goal of making certain tokens appear directly below certain other tokens on previous lines.

>

> This practice is permitted, but it is generally discouraged by Google Style. It is not even required to maintain horizontal alignment in places where it was already used.

>

> Here is an example without alignment, followed by one with alignment. Both are allowed, but the latter is discouraged:

  {
    tiny: 42, // this is great
    longer: 435, // this too
  };

  {
    tiny:   42,  // permitted, but future edits
    longer: 435, // may leave it unaligned
  };
> Tip: Alignment can aid readability, but it creates problems for future maintenance. Consider a future change that needs to touch just one line. This change may leave the formerly-pleasing formatting mangled, and that is allowed. More often it prompts the coder (perhaps you) to adjust whitespace on nearby lines as well, possibly triggering a cascading series of reformattings. That one-line change now has a "blast radius." This can at worst result in pointless busywork, but at best it still corrupts version history information, slows down reviewers and exacerbates merge conflicts.


TXR Lisp:

  1> (defstruct (word text) ()
       text
       (:method print (me stream pretty-p) (put-string `#<@(typeof me) @{me.text}>` stream))
       (:method equal (me) me.text))
  #<struct-type word>
  2> (new (word "abc"))
  #<word abc>
  3> (equal *2 "abc")
  t
You wouldn't define a print method for a struct like this, because it's counterproductive. You're throwing away print-read consistency in exchange for no benefit.

I usually define print methods for complex structures with many slots, that are not expected to be externalized. Particularly if they are linked in a graph structure, where (even if you have the circular printing turned on to handle the cycles) the prints get large. You know, you wanted to just print the banana, but it was pointing to a gorilla, and basically a dump of the whole jungle ensued.


You wouldn't define an `inspect` method for this simple example in Ruby either, because Ruby provides a default inspect that'd do just fine in this example. The exact same tradeoff for when to define inspect as for when you'd define print methods exist. In other words, that wasn't the point.


> We have a soft limit on class length of 100 lines, and I like the extra conciseness this allows

I'd recommend your team to stop code-golfing... Even better: with this new syntax you MUST reduce the soft limit to around 50 lines per class, right?


I agree that it shouldn't be used for anything complex, even if it reduces to one line. But I do like it for simple things. Maybe it's staring at very similar code all day, but such short statements read fluently for me.

And even if an extra line of separation is used, it's still 6 lines instead of 11.


> We have a soft limit on class length of 100 lines, and I like the extra conciseness this allows.

The "compact" line format is something that is very information dense and really really hard to parse for a human's eye, compared to the clearly visually structured prior format.

Personally, if I'd see something like that outside of a code golf tournament, I'd run because that kind of code density means that at least one of the developer(s) believes themselves to be some kind of code wizard who loves Matrix-style display, and it means that new developers have a very steep learning curve ahead of them.


What can be good, but requires discipline, is to replace some of the syntax that's no longer needed with a comment to help explain the what and why and goal. You reduce or eliminate the line savings, but overall may increase the information and understanding of intent.

I do this commonly in the Perl I write. If I'm using a complex set of maps and greps to reorganize a structure, doing that inline can be useful to the developer because it can match mental state, but the later reader may be somewhat lost when seeing it depending on how much of the data state they've internalized. A nice comment to explain the intent is useful, and when you're already saving space by eliding syntax, keep a good ratio of action to code on the screen (which is really what we're optimizing for here most times anyway, right?)


Seems counter productive to me.

The first snippet is much easier to read, and using this technique to get around your 100 line rules seems to be missing the point of the rule - or purposely subverting it.


In other words, to get your mass emails read, mimic personal emails more closely. It's a hack to use our noise filters against us. It's not exactly a dark pattern, even if it does make it a little harder for us to distinguish the signal.


See also Senator Paul going after the PATRIOT act in particular.

https://www.paul.senate.gov/issues/protecting-privacy-civil-...


Even a stopped clock is right twice a day. (not referring to Wyden)

Really, the best reason (from the security org point of view) not to collect so much surveillance on your home population, is because it creates a single point of failure for foreign adversaries to gain access. Most of the interesting data is already commercially available for advertising.


Excellent and very WISE observation. Why, oh why, do people in charge never consider the Law of Unintended Consequences?


Because to keep their jobs they have to be seen as doing something and the old 'this is something therefore it must be done.' truism still hold. They never look farther ahead than the next election, were lucky if the look farther than the next nights news most of the time


The people who make these laws are not affected, and the people who execute these actions are not the people that make these laws.


They will be. And they will be surprised.


Oh, I never said they weren't due for an ass whipping, I'm just describing how it happens.


We learned this lesson the hard way when China stole a ton of military members' personal info.


I don't think they learned anything.


Don't forget then house representative and now senator, Bernie Sanders.


Unfortunately, Bernie talks the talk, but has failed to walk the walk in recent years. For example, congress was within one vote from passing a law that would require warrants for surveillance and missed it because Sanders wasn't there to vote.

The Senate on Thursday took up a key bill to reauthorize domestic surveillance programs while making changes to the Foreign Intelligence Surveillance Act, with several substantial amendments on the line. One of the amendments, introduced by Democratic Sen. Ron Wyden and Republican Sen. Steve Daines, would have required authorities to obtain a warrant to access internet users’ search histories and browsing information. Uh, yes, pass that??

The amendment, however, met an extremely Senate grave: It “failed” with 59 yeas to 37 nays, one short of the 60-vote threshold it needed to overcome the streamlined vestigial filibuster. The splits didn’t fall neatly along partisan lines: 24 Republicans voted for it, while 10 Democrats voted against it. (Would you like to see the names of the Democrats who voted against it? Their names are: Tom Carper, Bob Casey, Dianne Feinstein, Maggie Hassan, Doug Jones, Tim Kaine, Joe Manchin, Jeanne Shaheen, Mark Warner, and Sheldon Whitehouse.)

Source: https://slate.com/news-and-politics/2020/05/bernie-sanders-a...


SEC v. Jarkesy is a current SCOTUS case recently discussed here that's very much about interpreting the body of the constitution:

https://news.ycombinator.com/item?id=38441401


> Kissinger saw combat with the [84th Infantry Division] and volunteered for hazardous intelligence duties during the Battle of the Bulge.

Thank you for your military service Mr. Secretary. Fighting real Nazis earns my gratitude.


When you hire according to which candidate has worked hardest to fight against oppression, it isn't surprising when their academic work is about gathering evidence for the fight against oppression.


> AI is useful and transformative, but it is nowhere close to "general intelligence."

Whether the intelligence is general or not, it is sufficient to automate and replace many many jobs now held by intelligent people. That by itself is quite sufficient to sustain many doomer narratives, even if nobody ever declares it "general".


We talk about the evil wages of hate but seldom about those of love. People love those flat little anthropomorphic faces, often very fiercely. That love creates demand for an unhealthy creature by the millions. This particular love has proven wide spread and enduring.

It was never about whether the motive is hate or love, both are correct in their place. It was always about the short- or farsightedness of their pursuit. We're probably just not farsighted enough to freely make those cute dogs rare.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: