lomnakkus

In a former life I worked with a codebase that used that style. Let's just say it isn't enough.

No, but you can easily end up missing some because somebody wrapped them in some sub-type of RuntimeException because they were forced(!) to. This happens all the time because the variance on throws clauses it at odds with the variance of method signatures (well, implementations, really -- see below).

A new implementation of a ThingDoer usually needs to do something more/different from a StandardThingDoer... and so may need to throw more types of exceptions. So you end up having to wrap exceptions ... but now they don't get caught by, say, catch(IOException exc). If you're lucky you own the ThingDoer interface, but now you have a different problem: It's only JDBCThingDoer which can throw SQLException, so why does code which only uses a StandardThingDoer (via the ThingDoer interface) need to concern itself with SQLException?

Checked exceptions in Java are worse than useless -- they actively make things worse than if there were only unchecked exceptions. (Because they sometimes force the unavoidable wrapping -- which every place where exceptions are caught needs to deal with somehow... which no help from the standard "catch" syntax.)

Parent poster explicitly said "under pressure". What more do you want?

> Copying is encouraged. Like I said, having the algorithm there is a good way to make it apparent what the code is actually going to do and the associated cost of the solution.

It's also a good way to make bugs proliferate throughout your code base. IIRC bug count correlates well with line count regardless of the language(!).

Present tense -- it's (almost?) always a little shorter, so you can fit more information into the "subject" line.

Using min() seems like it could be incredibly dangerous as an "implicit" behavior, not to mention surprising.

I'd wager it'd be much better to just specify that abort() gets called in the "overflow" case. (Given that overflow is basically never what you want anyway.)

Yeah, it'll crash but at least it won't be suprising/undefined behavior.

> IMO Lambda calculus should be taught wider in CS programs. It brings useful models, builds (if one likes theory) good background to functional programming paradigms, etc.

I'm surprised than anyone thinks this. Unless you're in a very specialized area, it's about as useful as getting practice with writing algorithms using Turing Machines.

(Yes, it offers a very different perspective to the usual Von Neumann machine, but learning graph reduction as evalation is just as valuable, if not more.)

Honestly, it seems like a pretty clear intention to co-opt a term ("commons") which has usually meant "let's share things!" to mean something entirely different. (And shame on them for doing that.)

I believe it may be because the email only mentioned Intel explicitly and had a "I won't be buying Intel in future" (paraphrased) comment. However, I personally wouldn't assume that AMDs HT implementation doesn't have similar issues.

If I were being pithy, I find that when you're doing this type of thing it's more a feeling of "working fun" rather than "working hard".

(Of course this means that one is probably not always going to do "production ready" things, but it's for fun, so it doesn't really matter. Sometimes it's fun to just go nuts and sprinkle "undefined"[1] all over the code base and just go from types to implementation as fast as humanly possible.)

[1] This is a Haskellism, but basically means any of:

    assert(false)
    throw new NotImplementedException(...)
    ???
    etc.

I think you mean the "biosphere" rather than "we". Modern humans have existed anywhere from 50k-200k years. Just to put the time scales into context.

EDIT: Just to clarify: As long as disasters happen slowly enough and there are actually local maxima for the species to evolve "into", everything may be fine for "humans"... but those assumptions may be overly optimistic.

If the array structure itself were being modified, the "i < a.length" check would have to be done every iteration, but in this case there's no mutation of the array itself, so it's OK to move "a.length" to a constant outside the loop... and from there it's trivial to move bounds checks outside the loop (and from there: eliminate them entirely)

I suppose that's true in some sense, but at least string theorist have done some interesting math?

(It may not be math that applies to the real world, but math being math is eternally valid as long as the axioms hold... and sometimes you get surprising applications later on.)

Damage-by-software usually isn't spectacular (and therefore not likely to get noticed) or not necessarily very directly costly in terms of human lives, but I'd argue it's actually more significant in the long term and in the grand scheme of things. Software rules everything and even slight errors or inefficiencies have absolutely incredible incidental cost.

Um, mix in a second randomly-chosen UUID?

My point wasn't so much that I had the perfect solution and that I'd thought of everything. It's that there are much better systems and that we should actually strive to get there.

I can second that recommenadation.

Indeed. Java is in fact a sort of worst-of-all-worlds in that it's even possible to catch things that are really unrecoverable errors like StackOverflowException or OutOfMemoryError. To to uninitiated it might not like appear that catching these is that bad, right? In addition to the problems with finally clauses not necessarily running to completion under such circumstances catching these exceptions can cause extremely hard-to-debug deadlocks because object locks won't be released properly.

This is an area where the design of Java/JVM is badly screwed up.

[1] JVM, really. It's pretty unavoidable on most (all?) JVM languages.

Personally, I think even having to choose a UID at install time or dynamically is a pretty sad indictment of just how broken the user system on Linux (and pretty much every UNIX-like) is. It leads to a huge amount of incidental complexity where there's a much simpler way: User IDs should just be randomly chosen UUIDs -- either generated by upstreams or by the distros. Any metadata attached to the user UID could just be preinstalled for all possible daemons[0] -- and it should be separate from the mutable /etc/passwd stuff.

Obviously there's so much inertia in the existing system that it could realistically never happen at this point, but one can dream, right?

[0] Kind of like e.g. /etc/services but with UUIDs.

Did you read what I said at all?

"Order total: undefined" is hugely different from "There was an error -- maybe just leave the page, yeah?".

For the hard of hearing, non-native speakers who are used to subtitles from non-dubbed movies, etc. etc. I suppose.

I do know that, as a non-native English speaker, I've always appreciated having English subtitles for English-speaking films. It helps immensely if you miss a word, there's a little too much mumbling, or whatever. One of the best (in both ways) examples being the movie Snatch.

That seems... short-sighted.

There's a huge amount of 'interesting' things one can do which are illegal, immoral, depraved and worse. (I'd argue that stealing is generally at the very least illegal and immoral, but opinion may vary depending on who the 'injured' party is.)

This has nothing to do with undefined vs. exceptions, sorry. You can do example the same with a powerful enough sandbox -- e.g. what WebAsm does to avoid hostile code taking over your computer.

It has everything to do with sandboxing (or not). Ads being served by third parties should not be able to influence the JS running in the page.

How is "there was a JavaScript error on this page" informational icon any worse than an order total of "undefined" or that the page just doesn't seem to be reacting to clicks? I'd argue that the former is much better UX -- at least the user isn't confused whether it's them that's doing something wrong or it's the page that just shoddily implemented.

The JS way is a mistake, intentional or not.

Here's a little thought experiment: Your program ends up with an "undefined" in some variable 'x'. How did that happen? In JS it can happen in any number of weird and wonderful ways, e.g. you called a function which did a 'v[i]' or it could have just fallen off the end because someone forgot to check a return path, or...

In Python there's much less scope what the problem could be. Since v[i] will just throw an IndexError, you know that the problem couldn't possibly be stray index or similar.

That is a much better experience for finding problems in one's code.

Oh, I'm sorry, I misread. Your nyms both start with 'd' and... that's about the end of my excuses for that mistake.

> I’m not sure why you’re mentioning women historically being keepers of the house It’s not relevant to the topic, people in general don’t value that role anymore.

My point was in the asymmetry -- so I found it odd that the blog author (not you!) would point to this as somehow being evidence of "loss of meaning".

In the context of the US and "the way things used to be", if would have to be the wife. Btw, it doesn't really matter which one it is -- the point was that it's asymmetrical.

> The role is eroding because the expectation is, that regardless of gender both partners in a relationship need to be working.

Why would both partners working be a problem in the first place? What about socialized (gasp!) child care?

Obviously, you'll want both parents to be spending as much time as possible with their children, but the underlying problem here seems to be... money. If there were less pressure to earn then maybe both parents could change to a 3-4 days work-week, etc. etc.

(EDIT: I'll actually add a counter-point to my own assertion here. It may not actually be the case that spending more time with one's children is always better. There may be a Goldilocks zone.)

> This is to facilitate the rising cost of a raising family in large city environments.

I think I understand the symptom. Cost means money.

Obviously, things will have to change on a massive scale for "my" conception of the future to be feasible everywhere, but I still understand what this has to do with meaning (as your original blog post was about).

(I can only apologize if the quoting gets weird. The side-notes on the right-hand side of your site got interspersed weirdly into the main text by copy/paste. I think I've managed to separate them properly, but if not... please forgive me.)

> We're watching the entire meaning infrastructure in this country be destroyed. >

Ok, so we're clearly in a very US-centric context here.

> 1.Religion is going away.

> [Sidebar:] As an atheist I think there is a lot of good that comes from discarding religion, but as a humble realist I also need to acknowledge the downsides.

What downsides? Please state them explicitly. (I could read this as a conceit to the general political climate in the US where atheists seems to be viewed unfavorably by the majority.)

> 2. Most people will not have a good job or a good paycheck.

Clearly some type of Basic Income type system will eventually become necessary as more and more things are automated. That, or we figure out what purpose the concept of money actually serves and come up with a better implementation.

> > 3. Being a homemaker is no longer considered meaningful for a lot of parents.

I don't understand how you can claim that this is "destroying meaning"?

Let me ask a pointed question: Who do you envision as being the homemaker -- the wife or the husband?

> > So where is the meaning coming from?

I get the feeling that either I'm completely missing the point of what you're writing, or you're writing from a pretty "conservative" position.

(EDIT: HN is really absurdly shit at quoting others. I'd apologize for my bad formatting, but I really don't understand how this shoddiness is acceptable in any world. Anyway, I did my best and will probably proceed to try to delete my account at this point.)

I just (well, a few days ago) explained to you that your suggested "solution" would result in UB.

Then you come up with the "solution" that everybody must always check for NULL pointers before dereferencing them. If everybody always did that we might as well just define the behavior of reference-after-free, because what you said either a) requires you to keep a reference count (or null-check before every deref which may be even more expensive) at runtime(!), or b) requires a program-level proof.

So... no. What you suggested is not a solution in any meaningful sense.

I think you're missing the point that this is a type of ratchet in getting the intermediates to stop doing arbitrary traffic shaping/queueing/etc. (Ideally it would end up being a ratchet for net neutrality, but let's see...)

A lot of Chrome traffic is already QUIC-based[1], and I think people will be pissed off it their experience is suddenly degraded because some asshole ISP decided to wholesale drop UDP over TCP.

Regardless of any of that -- the only way forward for privacy is end-to-end encryption and QUIC helps achieve that, up to "secret key availability"[2].

[1] I think Firefox is also experimenting with it?

[2] That is, any entity serving you a page must have the right secret keys. This is basically the case with SSL-only web sites already.

> Imagine if we had that same attitude with regards to HTTP.

Well, many do. You wouldn't believe the number of broken HTTP clients/servers out there.

The difference is that most HTTP clients/servers have to work with some significant subset of the pre-existing HTTP infrastructure (otherwise why would anyone use them?) and so that constrains their implementation to be "mostly correct". It's literally network effects :).

Libraries on the other hand usually start out with a single consumer and have no such constraints on their implementation so you end up with various levels of ossified brokenness or breaking non-ossification.