Free Address Verification by EasyPost - <AUTHOR> http://blog.geteasypost.com/post/40684464899/free-address-verification <comment><USER2> Is it safe to assume that the developers have forgotten that there's a very big world beyond the US borders? The title doesn't say so, the blog post doesn't either, and the website makes no reference to the countries supported. But as the API doesn't take a country field, it's the only conclusion I can come to.

<comment><AUTHOR> No! We're a US company so that's where we're starting but we'll be working on international next.

<comment><USER2> Then please make that clear in your blog post and home-page.

<comment><AUTHOR> Added to homepage (bottom right)

Added to blog post

<comment><USER2> Belatedly - thank you. Good to see feedback being acted on.

</comment></comment></comment></comment></comment><comment><USER3> IDEA: Stripe + EasyPost for an EBay that doesn't suck or price-gouge. You put stuff up for sale/auction, the payments go straight to your Stripe account and shipping is calculated/charged fairly. Emulate AirBnB for handling trust issues (reviews, email/phone verification and social graph connections).

Start with a niche like used Apple products.

<comment><AUTHOR> I like it!

</comment></comment><comment><USER4> I am curious how you guys are getting around the terms of use of the carriers especially address validation as it strictly forbids serving that information for others not associated with the developer key.

<comment><USER5> I would really like to know the answer to this. If they are just turning around and hitting USPS data for this, then last I checked, they are violating the TOS. Even if you have your own account, you can only use the address validation IF you are also going to ship to that address with USPS.

Perhaps they are using some other address validation service/data that allows for it.

</comment></comment><comment><USER6> Hmm... Does this validate that the address exists, or that an individual lives at that address? Just because someone has entered the incorrect address doesn't mean that the address doesn't exist.

<comment><AUTHOR> It validates that the address itself is valid and you can mail items to it

</comment></comment><comment><USER7> To be clear, is this CASS/DPV-style validation? Is it certified CASS/DPV? If so, that would be awesome. Any info on usage limits for the free tier, etc? Can we use this for address verification only or is it required to purchase as well?

<comment><AUTHOR> Indeed it is! And there's no usage limits

<comment><USER8> What's the preferred request rate to be polite?

<comment><USER9> For testing - try to keep it reasonable (a few req/s).

If you are worried about exceeding our limits in production (via bulk or your site has that much traffic) feel free to email us: firstname.lastname@example.com

<comment><USER8> Well within what I was planning (1 request per minute).

Thank you!

</comment></comment></comment></comment></comment><comment><USER10> It's nice to see startups tackling shipping APIs - they really are ugly.

What I'd _really_ like to see is something that reaches down to the inventory level, I.e. I'm shipping these 5 SKUs, what's the best price among the carriers I support.

It's a complex problem (from experience) but it would provide real value to smaller shops who want to implement economy shipping but don't want to deal with all the APIs.

<comment><USER9> The idea is awesome, but handling products via a SKU is hard. For instance, if you had the SKU 517030000077284 (a Gibson Les Paul) how would you determine the package size that each customer individually uses? Or determine how much extra weight was added by packaging to keep the guitar safe?

I would love to solve this problem but it is definitely a hard one to solve.

<comment><USER10> Like I said, it's complex - for our internal solution we just queried for rates for all of our box sizes, and then our software suggests the cheapest it thinks will fit, but allows the warehouse guy to override it. It has a really simple formula for "learning" when he chooses something different.

A general solution would be much harder, but if it had existed we would have forked over money without too much thought.

</comment></comment></comment><comment><USER11> Looks like Shipping/Postage APIs are about to heat up:

<https://www.postmaster.io/>

<comment><USER4> I doubt it. Carrier terms of service make the SaaS model for this difficult if not impossible. I also don't understand why anyone would pay a percentage per label when the carriers offer free APIs. Sure the APIs are a pain but there are good libraries out there for them.

<comment><USER8> I could see people using this to get up and running quickly, but then flushing out their system to integrate directly with carriers once size dictates.

Example: DailyCred lets you drop in authentication on your site, but when you get big enough (or have the time resources), you can dump out the bcrypted password hashes into your own built-out auth system.

MVP/Prototype->Iterate->Grow. These services that are reducing pain points let you get the first parts done fast, so you can get to the growth stage faster.

</comment></comment></comment><comment><USER12> I think you should have a form where users can try out your address checks. This is just so devs can quickly make sure if you know the difference between good and a bad address before they try out the api.

<comment><USER9> If you want to try some out via curl it is pretty quick. See <https://www.geteasypost.com/docs#addresses>

I do agree tho and a quick form to test out all of the APIs is in the works so users can quickly see what the API will return.

</comment></comment><comment><USER13> What are the units here? Says -d 'parcel[length]=10.0' \ -d 'parcel[width]=5.0' \ -d 'parcel[height]=8.0' \ -d 'parcel[weight]=100.0'

<comment><AUTHOR> Those are ounces and inches

<https://www.geteasypost.com/docs#parcels>

<comment><USER13> thanks

</comment></comment></comment><comment><USER14> Does EasyPost support negotiated rates? Many larger shippers have negotiated special rates with the various carriers.

<comment><AUTHOR> We're working on that! Once we integrate UPS and FedEx that will be an option

</comment></comment><comment><USER15> What's the source of this data? USPS? Fedex? UPS? Google? A hamster with a video camera?

</comment><comment><USER16> The example doesnt really work

        $ curl https://www.geteasypost.com/api/address/verify \
        >   -u cueqNZUb3ldeWTNX7MU3Mel8UXtaAMUi: \
        >   -d 'address[street1]=388 Townsend St' \
        >   -d 'address[street2]=Apt 20' \
        >   -d 'address[zip]=94107'

        You are being redirected.

<comment><USER17> This is because their demo uses https, as recommended in their documentation ("We suggest that you make API requests over HTTPS..."). But, if you switch to using the http protocol, the request will return a response correctly. It's a bug.

Also interesting because their website redirects http requests to the https protocol (eg. <http://geteasypost.com/docs>).

<comment><AUTHOR> Yes, sorry about that. It's fixed so both work now

<comment><USER17> Great, thanks!</comment></comment></comment></comment>


The original Macintosh: insanely great - <AUTHOR> http://www.youtube.com/watch?v=zJ12vNZ5yMY

<comment><USER2> Funny how it's really not THAT different than computers today, right? We just have more colors and higher resolution, and slightly better text-to-speech. ;)

<comment><USER3> When I saw this, as part of a class, I was surprised that we had text-to- speech way back then. I'd always assumed that came much later.

I also love Jobs' dramatic flair. He was kinda campy when he was younger.

<comment><USER4> We had that since the late 50's:

<http://www.youtube.com/watch?v=UGsfwhb4-bQ>

</comment></comment></comment><comment><USER5> Worth watching if only to see Steve Jobs wearing a suit!

</comment><comment><USER6> Insanely inferior to the Amiga 1000 which came out shortly after and cost 1/2 as much.

<comment><USER7> Can we put 30 year old flame wars to rest? We need to concentrate on modern ones instead. Please and thank you.

<comment><USER6> I didn't submit the article.</comment></comment></comment>


Java Exception Handling - <AUTHOR> http://neverworkintheory.org/2016/04/26/java-exception-handling.html <comment><USER5> The pragmatic programmer book has a great quote about exceptions. Something about how once an exception is caught your stack starts to unwind and a new program is now running on your system. Can't find it right now.

The worse production bugs I have seen involve complicated exception handlers that generated a second exception while trying to write to the filesystem or something. In that case some other exception handler now starts to execute further up the stack. It really is as if a new program is now compiled and installed on your production servers. A new program that has read/write access to the production db. A program that most likely was never executed in QA and has never been seen by any person.

It is a bit hyperbolic but I have never seen an exception handler over four lines long that did not contain a bug.

My attitude towards exceptions is like a fire alarm. If I hear a fire alarm it means one thing and I have one action to take. Any notion of providing different pitched fire alarms to encode information would be absurd and dangerous, that is how I view exception hierarchies.

It is my understands that the Go language from google decided not to include this language feature.

I have heard that Java's checked exceptions are now seen as an important, failed experiment.

<comment><USER6> > I have heard that Java's checked exceptions are now seen as an important, > failed experiment.

Sadly, this is what people often say these days, I still think they provide far more value than unchecked exceptions. I really liked it when I didn't have to provide any exception signatures and didn't have to think about where to catch them. I didn't like it so much anymore when unchecked exceptions started crashing my code, because there were exceptions thrown at points I never expected them to be thrown.

Either no exceptions or checked exceptions, but unchecked? My head :(

<comment><USER7> I still don't understand the complaint against checked exceptions.

I've concluded that unchecked exceptions (above the runtime) and exception chaining are painful artifacts necessitated by using overwrought frameworks like Spring, J2EE, JPA, etc.

Most useful anti-checked exception TL;DR I've gotten is "What do you do when your code can't act (recover) on a checked exception, like some library fails on I/O?"

My answer remains "I handle it." After demo'ing my code, buddies conceded that my strategy works because I'm coding "close to the metal". In that case, it was an ETL/workflow engine (framework) that used hand-coded state machines (eg get next, data error, retry, restart).

Looking forward, I'm keen to learn Erlang and Elixir. I have the impression they would provide for free all the error handling and recovery I painstakingly hand-coded.

<comment><USER8> Checked exceptions don't play well with high-order functions, and basically anything else where one piece of code is calling into another piece such that it doesn't know what it is at compile-time (dynamically loaded extensions, DI, UI event handlers, and even plain old virtual methods in many cases).

Basically, at those boundaries, you either have to say that the called code can throw anything - but then what about your own contract? you will either have to swallow everything; or rethrow everything, making it a part of your contract; or wrap everything in an exception type that you declare vas part of your contract, which is really a disguised version of rethrowing that doesn't add any meaningful value. Or else you say that the callee cannot throw anything, and then it is forced to swallow exceptions at the boundary.

Here's a very simple example of how it affects design: try implementing Java's List<T>, or even Iterable<T>, on top of a file. Something really simple, like one string element per line.

You'll find that it all works, except for error handling - because every read can fail, and neither List.get() nor Iterator.next() let you throw an appropriate exception type.

In contrast, in .NET, File.ReadLines will happily return an IEnumerable<string>, which will throw IOException when a given line couldn't be read - because IEnumerator is not limited with respect to what exceptions it cannot throw.

To properly deal with this problem, you need value-dependent types. Then you can do things like write, say, a generic implementation of map() that takes any random sequence, and throws the same exceptions that said sequence can throw when it's iterated.

</comment></comment></comment></comment><comment><USER9> This is flawed thinking.

I'd say in many cases it is perfectly desired to either swallow or re-throw exceptions. As just one example, many business rules can be correctly implemented as best-effort and if some resource (network or service) is unavailable simply let the failure propogate, or log, or backoff and retry some other time.

And most certainly but in fewer cases more robust handling is called for. Even if only 10% of exception handling is in this category, then try/catch is still a valuable tool.

I find it really faulty to reason that "this feature is only used 'correctly' 10% of the time, therefore it's a failed feature."

<comment><USER9> Here's a common pattern for sleeping on a thread you do not expect to be interrupted and both are equally valid and fine ways to implement it:

      try {
         Thread.sleep(1000);
      } catch (InterruptedException e) {
         throw new IllegalStateException(e);
      }

      try {
         Thread.sleep(1000);
      } catch (InterruptedException e) {
         // never happens
      }

In other words, the _correct_ handling is to swallow or throw. The former is likely preferred by those who do assertion-based coding. The latter for people that prefer to discover their bugs in other ways.

<comment><USER10> One should never expect a thread not to be interrupted.

When I see code like the latter in PRs it drives me nuts, to the point that I start building up a case to have the knucklehead that does it moved off onto another project.

<comment><USER9> Why should one always expect a thread to be interruptible? If I don't run my thread within an Executor or some other framework that could interrupt my thread, then I should be able to consider that an illegal state.

<comment><USER11> When a program is shutting down, its threads are interrupted.

</comment></comment></comment></comment></comment><comment><USER12> The great thing about exceptions is that they allow you to put arbitrary distance between the point of detection and the point of handling.

The problem with exceptions is that they allow you to put arbitrary distance between the point of detection and the point of handling.

</comment><comment><USER13> See this article ([http://norswap.com/checked- exceptions/](http://norswap.com/checked-exceptions/)) on why exceptions are generally misused.

</comment><comment><USER14> A lot of opinions about error handling in this thread, but I don't see the main thing mentioned: difference in requirements of different projects and subsequent difference in technical strategies.

Some applications need to fail fast, fail hard, and restart automatically.

Some applications need to present any failure or error condition to the user and give him power to decide.

Some applications need to be restored to some sensible state at all cost.

Needless to say, all possible error handling strategies, from C return codes to Java checked exceptions, have their fair use cases; discussing which one is better and which one is worse without specific project in mind, at least as an example, is completely pointless.

</comment><comment><USER5> The best use of exceptions in java that I have seen in production is when an exception is used to roll back a database transaction or when the web layer is able to catch all exceptions, log them, and then redirect the end user to a nice looking page telling something went wrong.

Another anti-pattern is subclassing Exceptions to have things like "UserNameInUse" exceptions during a sign up path to indicate that a selected username is not unique in the db. This becomes a poor man's message passing implementation. Using an exception to signal that is very inefficient as the exception has the entire stack trace as part of its data.

<comment><USER15> Using an exception to signal a semantic error is only expensive if the language implementer has made that expensive.

Technically, all the exception throw needs do is pop stack frames until it finds a handler. Getting a stack trace is optional, but keeping track of the return addresses (pushed by the CPU's call instruction) is sufficient to materialize that on demand. An array of integers isn't expensive either.

I don't believe transactional programs using exceptions for rollback is an anti-pattern. It's not the best pattern - a transactional language, with transactional data structures, is much harder to get wrong - but it's not worst, not by a long shot.

<comment><USER5> sorry - I didn't mean to indicate that using transactions to signal a roll back is an anit-pattern. I started out that comment listing good things I had see exceptions used for. Then that example of the userNameInUse exception came to mind. I realize my choice of words made that less than clear.

</comment></comment></comment><comment><USER16> The volume of logging in production systems is such is that it is impractical to act on individual exceptions. You would typically send log events to a centralized logging service or have an agent-based code monitor logs locally for well know sequences or error codes. And that's where Java exceptions can be improved - a built-in facility to assign error codes so that downstream tools can handle exceptions based on a rule book which takes application- specific error codes into account.

<comment><USER17> If you don't want to use regular expressions for matching exceptions, you can simply calculate hash code of exception class name and, possibly, of it's cause and message and pass it downstream.

</comment></comment><comment><USER18> I think this is fine. Java is verbose as it is, it would be even worse if Exceptions were handled "as intended" and every Exception type was treated individually. Log and move on can be appropriate in some cases. And even if 80% of the time you're ignoring all Exceptions, the 20% of the time you have specific code could be very, very important.

</comment><comment><USER19> Java exception handling is very successful, and does exactly what I want as a system designer.

The article objects to the fact that applications handle many exceptions by logging them and giving up. What's wrong with that? That's perfect. For the class of exceptions that I _can_ just log and give up, that's often what I want to do. If I had an open TCP socket to a remote host, then I can't "recover" from an exception indicating that the connection was broken. Instead, I just want to tear down everything related to that connection and carry on.

Exceptions can rarely be recovered from at the level of abstraction where the exception occurred. For example, I can't repair a socket that's been broken. I cannot retry the request at that level - it might not be idempotent; the socket processing code can't know. The connection pool doesn't know. The HTTP client might or might not know. However, I _can_ recover from the exception at a higher level -- at the level of the code that understands what the task is, it might retry the top level processing job, which might invoke a call on a service client, which will invoke a call on an HTTP client, which will invoke a call on an HTTP connection pool to open a new TCP socket as needed. This is exactly the pattern that we see commonly in Java applications: a higher level module calls a lower level one, and then variously logs exceptions and tries again (possibly with exponential backoff over multiple attempts), or logs them and give up, or does something else.

You don't really "repair" or "recover" from exceptions. You mitigate them by handling them and carrying on with the job. To achieve this, you unwind up to the level where it makes sense to retry or abort a task. When you retry, you retry from the right level of abstraction needed to start over.

The extremely valuable property that exceptions have, that they give you, is confidence about what specifically went wrong. They constrain it. If I try to interact with a socket and I get an IO exception, then I know the error is constrained specifically to that socket. The rest of the program is working fine, and I can either try to recover from that error (sometimes possible), or close the connection and open a new one, or give up processing the task.

Exceptions are also valuable because you don't have to add error-handling logic at each layer in an application. Many layers can be ignorant or agnostic of the exceptions that will propagate through them, and that's a good thing because it reduces coupling. These layers might be inserted between the high- level logic that understands task processing, and that will make the judgment call about retry/backoff/give up, and the specific code that can fail and throw an exception. I don't want all layers of code to _have_ to care about exceptions that might pass through them; they can't and shouldn't do anything about it.

It is valuable to be able to build abstractions and build code that exceptions _pass through_ , without handling them. You might add logic to handle them later, or you might do so at a higher level, or a lower level.

<comment><USER20> Retrying on any exception might be wrong thing to do. For example, the I/O error many levels bellow might happen for wildly different reasons, and handling them all the same way might be wrong. If not, then the correct behavior of the project depends on exceptions originating from different modules being handled the same, and that _increases_ coupling.

<comment><USER19> You make a good point and I agree. However, code also doesn't exist in a vacuum; when it's first written it's not perfect. Systems are built iteratively as the problem becomes gradually more understood. The wonderful thing about exceptions is they fit well into this evolution process. I can wrap the top level application processing step in a try/catch block, and I can be confident that we have a plausible starting point. In the very least, I can be confident that I will detect all reasonable failures, and I can be confident they won't spill over into anything else the application is doing. It's very difficult to crash a Java application that's designed to be robust.

If any of my low-level exceptions bubble up into the top-level catch block, when we're expecting to handle all exceptions at lower levels, then I have the ability to do something reasonable in my catch block: abort the task, emit metrics, and log the full stack trace as part of my "unexpected exception" routine. That's really useful: it's one way to discover exceptions that the system ought to handle but isn't handling yet. You might write one of these catch blocks with the expectation that it "should never happen", but if it does we'll detect it and supply a reasonable default behavior.

For example, if my application is a microservice, then I will wrap each microservice operation in a try/catch block, and in the catch block I will include logic to convert the exception into an appropriate failure return code from the operation. Or even better, my service framework will handle this for me -- that's an example of the decoupling that exceptions provide as an abstraction. If any microservice operation throws an undeclared exception, then the framework can surface it as the equivalent of HTTP 503. We might set the expectation that all exceptions should be declared exceptions, but if we ever miss one and have an undeclared exception, then the framework can return an appropriate error response.

The right thing happens by default: we don't need detect-and-propagate logic in each call frame. Some of those layers could also catch and retry the exception, or catch it and refine the exception type, or just catch and log it and emit task-specific log entries or metrics. For example, perhaps I have a try/catch block around some logic that calls S3. A catch block around the S3 calls can emit metrics describing the failure rate of calls to S3, which are useful to alarm on, and to examine distinct from the overall failure rate of my microservice operation which might call other services too. This is an example where a simple catch-observe-propagate-or-rethrow adds meaningful value.

At the same time, those failures could happen for many different reasons. Perhaps my credentials have expired, and so I'll see a 100% failure rate with that step: emergency. Perhaps I'm using a presigned URL, and it's past the expiration time. Perhaps there is a random transient failure. Perhaps the file I'm uploading is too big, or perhaps its checksum doesn't match, and so on. We can start with a basic naive catch block around S3 and refine it over time to handle these cases if we observe that it's relevant to do so.

Exceptions are an excellent foundation for confidently evolving system behavior in these sorts of ways. Plus, I can implement this evolution in the most convenient place for me. I don't have to go to a lot of trouble propagate all down the call stack to where it's thrown; that code can pass it on without knowing what it is. Yes, any of these exception handling blocks is coupled to the exceptions it catches, but higher level blocks aren't, and code in between can pass them on without understanding them -- that's valuable.

</comment></comment></comment><comment><USER21> There are two kinds of exceptions. A bug in the data or a bug on the code. The only action to take is to pass detailed info to the user and/or the coder. Fix the bug and try again beats any precanned exception recovery code one might waste time implementing.

<comment><USER6> See jcrites comment here [https://news.ycombinator.com/item?id=11842726](https://news.ycombinator.com/item?id=11842726) for an example where neither the code nor the data has a bug. Broken sockets are simply a part of distributed systems the code has to deal with.

(If you feel that "the network should be reliable" is a valid answer, see: [https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing))

<comment><USER21> We should classify exceptions by the _action_ required to fix them, not by the circumstances in which they appeared. "DivideByZeroException" is useless, "User error: 31st of February is not a date" or "Internal error: count is zero" are a whole lot more actionable. Java's menagerie of exceptions is an anti-pattern.

I grant you that there is a third class of exceptions, "remote unavailable", for which the error handling is to retry X times, then promote to "system broken" and let the user retry later.

For all intents and purposes, "system broken" is a better name for "code error", covering also cases where the DevOps team should fix the hardware or dependencies on third party systems. [Configs are funnily written code].

Often times the "retry X times" logic is wrapped nicely in one's RPC infrastructure of choice, so what the app developer has to deal with is either "user error" or "system broken".

</comment></comment></comment><comment> guard-of-terra Exceptions are maddengly, insanely efficient in some settings, such as making a server handling multiple requests at once.

They allow you to confine errors on any single request to that request. Many languages/platforms suggest you to use multiprocessing for that.

Also helps that servers usually have well-understood failure modes (DB error, data validation error, network failure) compared to other kinds of software (e.g. a missing file may lead to a whole investigation there)

For e.g. desktop programming, exceptions are kinda less useful.

<comment><USER22> > They allow you to confine errors on any single request to that request

I don't understand this, returning error codes has the same effect. In fact you can do that with most forms of error handling, short of segfaulting?

<comment><USER6> The problem usually is: What is the error code if your return type is int? Sure, you can define all negative ints as errors, or you provide a reference which is set when an error is encountered and so on, but that ends up being just another type of "very ugly".

At the moment, I'm mildly intrigued by Rusts result types which force you from the start to handle "all cases". They strongly remind me of checked exceptions.

<comment><USER23> > The problem usually is: What is the error code if your return type is int? > Sure, you can define all negative ints as errors, or you provide a reference > which is set when an error is encountered and so on, but that ends up being > just another type of "very ugly".

Many languages support multiple return values, algebraic data types, or box types, allowing you to return an error value out of band.

<comment><USER6> What is the difference between an exception and an "out of band" return of an error value?

<comment><USER23> I was addressing your specific assertion with regard to encoding error conditions as reserved values in your return type's codomain, which I agree is ugly.

One benefit of not throwing an exception is that you can maintain referential transparency, which exceptions generally break. You can't substitute a function call with its value because throwing an exception will have different effects depending on the context, which consequently hinders the composability of such functions.

Exceptions are also generally not type-safe, e.g. the return type of a function tells you nothing about what exceptions it may throw. If you go the checked exception route like Java, you do get some degree of type safety, but you do so at the expense of higher-order functions, which can't reasonably be expected to know about the specific exception types its arguments may throw.

On the other hand, ADTs are composable. They work for functions that aren't defined for some inputs (maybe an input type that can't be constrained by the type system). They avoid bugs because they force the caller to deal with the exceptional case (unlike returning null, a sentinel value, or throwing a RuntimeException), but without the boilerplate of exceptions, particularly in languages with pattern matching. The caller gets to decide when, if, and how to handle the exceptional case.

<comment><USER6> Thanks for the thorough explanation. I agree that ADTs are less ugly due to reduced boilerplate and the composability, if your language of choice has exhausting pattern matching (I really don't think "I don't care if my program works, let it crash" is a good default, so non-exhaustive pattern matching is out for me).

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> There's a lot of misconceptions around errors, and this article isn't free of them either. Java's checked exceptions feature derives almost entirely from a misconception around the nature of errors: that errors should, as a rule, be handled. Only a small subset of errors should ever be handled, usually quite close to the site of the error - an unwound stack seldom has enough information to anything useful other than log, inform client, or abort. If the error is to propagate, there's little win in forcing the whole call tree to need to know the details, since the nature of the error conveys less and less information the further away it is from its occurrence - context is necessarily lost through abstraction.

Errors can be grouped into 3 categories: programming mistake, semantic error and non-deterministic error.

The first category are bugs that are discovered through sanity checking and defensive programming - conditional code that is only invoked in the case of a mistake and is always avoidable. Depending on the environment, a whole program abort or restart might be a valid response; a localized response (like handling an exception) isn't going to be useful. Fall back to the event loop / request-response loop, log and continue usually suffices for non-critical apps. Checked exceptions are not a good idea, but that's OK - Java uses unchecked exceptions for these, even if not all libraries do the same.

The second category are semantic errors, typically where a client or end user has tried to do something invalid, and something like exceptions come in handy to unwind a partial operation, a bit like rolling back a transaction. Starting out with optimism but rolling back once a problem has been discovered isn't an unusual or technically flawed approach; exception handling is perhaps an error-prone way to do it, but it is a way. And it's a case where localised exception handling again isn't a good idea. This is a problem area in Java, as far too many applications use checked exceptions here.

The third category is non-deterministic errors: something outside the world of the program didn't conform to expectations. The other side of a network socket disappeared; a file was deleted; a device was disconnected; etc. You can't detect the error before attempting the operation, and the resulting error is, in a way, a type of return value - unexpected information - from the attempt. Fixing the problem is almost certainly only likely to be successful if it's local (hacks like lazy creation of files, automatic reconnects of sockets, etc. aside). Propagating the error is fine if it can't be fixed locally - <USER2> code isn't written to have alternative strategies for these scenarios - <USER3> forcing callers to handle this specific type of error - that's not terribly useful. Again, checked exceptions - specifically, typed checked exceptions - not giving up the benefit they promised. The fact that something might fail in a non-deterministic way is useful information at the API level, but it also violates modularity. The "fix" in Java is for every module to throw its own hierarchy of checked exceptions, which, of course, is no fix at all: now you have even less prima facie information, and useless exception handlers and exception specifications proliferate until the meaning behind them is lost.

Other languages that use option types to propagate errors work fine for the third category; they usually have a different scheme for the first category; but on the second category, they are usually silent, and that's a bad thing in my opinion. Something exception-like is very valuable in the absence of strong tools for transactional modifications of program state. You shouldn't take away exceptions without providing a solid way of throwing away partial work. Erlang - tear down the process - that's OK; functional languages - <USER4> state necessitating immutable, persistent data structures - that's OK; something like Rust - well, it's going to need panic for more than just the first category.

<comment><USER24> _There 's a lot of misconceptions around errors_

No surprise. I've seen books that fail miserably explaining exceptions, some of then using wrong code for the examples.

Now there is also people that _opposes_ the concept of exceptions. Not sure what the article conclusion is:

 _The only conclusion I can draw from this is that exception-based error handling has failed to achieve what its creators intended._

Is he talking about mandatory checked exceptions or any exception in general?

</comment></comment><comment><USER25> Are there guidelines for using exceptions in a correct way?

<comment><USER26> My thinking would be:

First, don't catch exceptions unless you really can handle them. Swallowing and emitting a log line is _not_ handling an exception.

Second, and this is a corollary, only catch the exception classes you _can_ handle.

The classic antipatterns of swallow-and-log or swallow-and-convert are very frustrating.

Swallow-and-log means that you don't see the true state of the world upon exceptional conditions arising. It is _particularly_ harmful for gutting the usefulness of acceptance and unit testing.

Swallow-and-convert means that you deny the rest of the stack a chance to properly handle the exception. You also suppress the information which checked exceptions provide to consumers of your method, converting something that can be solved at coding time into runtime error lotteries.

Edit: per the comments below, my meaning for "swallow-and-convert" is the practice of turning meaningful exceptions into `RuntimeException` because it's "too hard" to add exceptions to consuming method signatures.

<comment><USER27> There are cases where 'swallow-and-convert' is a reasonable thing to do. This often comes up in multi layer architectures where an exception from a lower layer makes no sense to a higher level and some sort of semantic conversion/translation is needed.

<comment><USER26> Agreed, I overlook that case. I've done exactly that in Java and Ruby.

</comment></comment></comment></comment><comment><USER28> Exceptions!

There is a book solely dedicated to the topic: [http://www.amazon.com/dp/0131008528/?tag=stackoverfl08-20](http://www.amazon.com/dp/0131008528/?tag=stackoverfl08-20)

Had it mentioned (together with another only-one, but fpor ASP) in an [http://programmers.stackexchange.com/questions/14831/how- to-...](http://programmers.stackexchange.com/questions/14831/how-to-teach- exception-handling-for-new-programmers) answer, which the proud professionals then dewnvoted and eventually deleted :)

</comment><comment><USER29> Most of the time, checked exceptions remain an unused language feature, because:

      A.) String to Integer with null handling
          for HTTP GET/POST transformation isn't
          worth the effort, because you're users
          are drunk idiots, and they won't
          pay attention to your carefully stratified
          error messages anyway. So just tell them
          to sober up, straighten out, and fly
          right, and barf a hideous, uninformative
          stack trace at them to scare them off
          until they go away, and come back in
          the morning.

      B.) Developers are so rushed to just get shit
          done that NullPointerExceptions,
          NumberFormatExceptions,
          ArrayIndexOutOfBoundsExceptions and so
          forth, are useful enough, and probably
          don't need much more differentiation
          anyway. As middleware developers, we're
          really not dealing with anything too
          exotic, and so we mostly don't need to
          re-interpret things like sensor or transducer
          state, or spin dial knob rotation angle,
          or leaf spring load, or magnetic flux.

So, just because 90% of server side web developers don't use it, doesn't mean it's a failure. It just means that interpreting discete character data from noodniks on the other side of a keyboard and pointing device, behind a TCP/IP connection can only get _so_ complicated.</comment>


Hacker Typer - <AUTHOR> http://hackertyper.com/ <comment><USER2> Doesn't seem to do anything on iOS.

Does anyone have a video of what this is supposed to look like?</comment>


What the Front Page of Hacker News Told Us - <AUTHOR> http://blog.techcareerhq.com/post/64880296341/what-the-front-page-of-hacker-news-told-us

<comment><USER2> Good summary of lessons learnt!</comment>


NetNewsWire Is Available for iOS - <AUTHOR> https://nnw.ranchero.com/2020/03/09/netnewswire-for-ios.html <comment><USER2> NNW is a fine piece of native software, both on macOS & iOS, and refreshing in the flood of not so native technologies, i. e. middleware.

I just hope Fever sync will be added soon.

</comment><comment><USER3> I'm currently using Fiery Feeds on iOS, mostly because it supports NextCloud News very well (for me it's the most important feature).

It's also very well designed, switches to "Reading Mode" automatically (if you choose) and lets you switch to to Excerpt/HTML views when Reading Mode is ineffective.

<comment><USER4> I didn't get on with it. The sheer number of disjointed settings sheets made it seem like a second job to get a proper understanding of how the app worked. Then, despite paying the subscription, I could not even download the Mac version (which is an iPad port using Catalyst) without being asked for another $35 up front.

<comment><USER3> Yes. I agree the UI is a bit overwhelming. Slick though and looks great on an iPad too. But since I host my own, I did find it useful. Also supports Pocket, like I guess you've seen. Would love to hear recommendations for another app which supports NextCloud.</comment></comment></comment>


Seymour: Live Programming for the Classroom - <AUTHOR> https://harc.github.io/seymour-live2017/ <comment><USER2> This seems like great, quality work. Teaching is an ideal laboratory to explore these ideas, because you're helping students to build mental models with these interfaces, rather than merely aiding developers who already have mental models. Building the models in the first place is the hard thing. But having production tools that would allow experienced developers to more efficiently do this kind of thing is also a great boon.

Introspecting into how I prototype new ideas and algorithms, the kinds of intricate tracing and exploration that are automatically done by Seymour are things I often do "manually", using a cobbled-together set of tools (one of which made it into Mathematica [1]).

Sometimes, because its fairly easy to do in the language, I quickly code up once-off tools to help me verify solutions. For example, I recently finished a new type inference system for neural network layers that allows very flexible 'backwards' and 'sideways' inference of tensor rank and dimensions. Surveying its behavior on all the possible inputs on the various kinds of layers is not feasible via manually typing REPL examples or unit tests. So I ran the inferencer against all possible cases of a certain form, and by visualizing the results as little squares (with various other info behind tooltips and mouseovers), I checked each result very rapidly [2] and soon found cases I hadn't thought of.

One thing I wonder from my experience of doing this kind of thing (I've written various visual debugging and logging frameworks, and code visualizers of all kinds), is whether a prescribed framework and set of workflows is actually preferable to flexible tooling that you can inject in precisely the way you want.

I've often abandoned my visual tools because they are too hard to customize into the exact thing I need to answer a specific, scientific question that comes up during debugging or implementation. Also, when you are already overloaded with thoughts and ideas about what might be going wrong, you kind of want to be able to ask and answer extremely precise questions, rather than swamp yourself in visual data that you have to interpret in light of your hypothesis. Clever presentation can only help the overload so much.

I wonder if what is needed is a kind of "side program" that one could use to annotate the main program in very precise ways and ask questions of its execution, or to produce maps or timelines of aspects of its behavior. But not via interactions with a GUI, although those are useful too, but as actual code that lives alongside the real code, using the same language. Something a bit like a souped-up, visual dtrace, perhaps. I don't know what is already out there like that, but I would love to see work in that direction.

[1] [http://reference.wolfram.com/language/ref/Echo.html](http://reference.wolfram.com/language/ref/Echo.html)

It's not really shown well in this documentation (I didn't write the docs), but Echo is very easy to insert because you can just write "Echo @" as a prefix, anywhere in ordinary code, and it basically a no-op. I have a macro system that makes it even easier: the single quote character (which normally means Derivative) can be put next to any expression and does the equivalent of an Echo. Being able to inject and remove these little probes anywhere in the codebase with a single keystroke makes the good old "print debugging" actually pretty effective in a lot of situations. And various forms of cleverness make it more useful, like putting it next to an assignment will also print the variable being assigned.

[2] [https://imgur.com/l7XwbCQ](https://imgur.com/l7XwbCQ)

The first two lines of each grid represent the inputs to a CatenateLayer, the last line is the output. Red indicates an invalid shape. Gray is "unknown". The other colors are fixed dimensions like 2 or 3, or dynamic dimensions (used for var-length sequence inputs). This display is from a buggy version of the inference system, don't try to check it!

<comment><USER3> > I wonder if what is needed is a kind of "side program" that one could use to > annotate the main program in very precise ways and ask questions of its > execution, or to produce maps or timelines of aspects of its behavior. But > not via interactions with a GUI, although those are useful too, but as > actual code that lives alongside the real code, using the same language. > Something a bit like a souped-up, visual dtrace, perhaps. I don't know what > is already out there like that, but I would love to see work in that > direction.

This is a great idea. I find it ironic that so much of programming consists of 'simulating the computer' in one's head while sitting in front of a computer.

I would love to be able to visualize many things that a compiler does internally, for instance, to see how generic code looks when specialized in a certain context.

</comment></comment><comment><USER4> This will be presented at the Live programming '17 workshop next Tuesday (10/24 in Vancouver @ Splash). For a complete program see: [https://2017.splashcon.org/track/live-2017#program](https://2017.splashcon.org/track/live-2017#program)

<comment><AUTHOR> This is quite impressive Sean. Live programming is just getting started ;)

</comment></comment><comment><USER5> If you want to try the interactivity in Firefox, run

      $$('.controls').forEach(controls => controls.style.display = 'inline')

in the console. I didn't see any breakage and I have no idea why the browser sniffing was deemed necessary in the first place. If it had been broken, the disclaimer would have been warning enough; no need to disable features.

It didn't work anyway: hovering over the videos toggles the visibility of controls, which fires the mouseover event again, which toggles the controls off, which leads to really annoying flickering. Of course nobody thought to sniff for that.

</comment><comment><USER6> Here's the code

[https://github.com/harc/seymour](https://github.com/harc/seymour)

[https://github.com/harc/seymour-live2017](https://github.com/harc/seymour- live2017)

</comment><comment><USER7> I can't appraisal the quality of the work, but I really liked the homage to Seymour Papert : [https://en.wikipedia.org/wiki/Seymour_Papert](https://en.wikipedia.org/wiki/Seymour_Papert)</comment>


"I need a backup of all our servers for all time." - <AUTHOR> http://whereisbob.wordpress.com/2008/08/20/welcome-party-for-dave-part-i/

<comment><USER2> _"Bob's initiatives, literally reeking with an overwhelming stench of incompetence, were consistent only in their absolute absurdity."_

I, for one, would love to know how an initiative can "literally reek" of anything.

<comment><USER3> Ironically, one of the definitions of 'literally' is 'figuratively.'

Go figure.

</comment></comment><comment><USER4> Sounds pretty straightforward - he wants backups of all server content and he wants to have them maintained not overwritten.

If this was a problem explain why. I can only imagine resources being the problem. If the servers were particularly large you may need to explain that some sectors would take longer to backup.

</comment><comment><USER5> "You are one of those people who say NO all the time. No, we can't write our own operating system! No, we can't have a backup of everything! People hate that! You impede progress!"

Now I find myself wondering, why would he want them to write their own operating system

<comment><USER6> ...no. no you don't want to know.

I bet it was one of those insane "I was reading in a management journal about writing operating systems and..." kinds of stories.

</comment></comment><comment><USER7> whereisbob is the new DailyWTF... I feel like I just hate a lot of empty calories.

<comment><USER8> And it didn't even have a technical twist. Just whining about vagueness from a boss. So what?</comment></comment>


Bloomberg stocker chart trading game - <AUTHOR> http://www.bloomberg.com/features/2015-stock-chart-trading-game/?ticker=dell&gameid=1454223359427 <comment><AUTHOR> This game is fun and addicting. I got pretty high scores too.

Unfortunately it's kind of easy to game, in that the window actually adjusts before big changes because I believe it's trying to predict the range. Also, if your reactions are fast then it's pretty easy.</comment>


Envy's hidden hand - <AUTHOR> https://aeon.co/essays/why-inequality-bothers-people-more-than-poverty <comment><USER2> A beautiful society. But one that I fear is inevitably outcompeted by other societies.

Let me explain. The article says that this society frowns upon the accumulation of wealth or excellence in individuals because those things damage the egalitarianism.

This is great for social stability, but it's not so good for the accumulation of capital, division of labor, and specialization. If one wishes to build a mill on a river to grind grain, then one MUST accumulate food first so one can spend time building the mill. This is the accumulation of capital that precedes investment.

If one wishes to be a miller, one must, almost by definition, stop hunting and stand out among one's peers by doing something different.

A society like this can exist on a planet that is devoid of other societies ... but once your neighbors start accumulating capital and climbing the technological ladder, you continue to exist only on their goodwill and charity.

The egalitarian hunter-gatherer with wooden spears is, after all, no match for the iron spear wielding Zulu who is organized into professional warbands and has absolutely no pity for other civilizations.

<comment><USER3> I understood it that their society does not simply frown at one member standing out, but rather its framework is such that, if one becomes better than others in some regard, one has to overall "level it out" as it were by suffering ridicule and/or making some nuanced changes to one's behavior.

My primary objection is to the first paragraph of your comment, though. Becoming out-competed by other societies is only an issue as long as this framework is not adopted on higher scales. I know this is out of this world, but it's interesting to consider.

The true "global village", possible thanks to modern connectivity, might be the great enabler; although the same technology also facilitates community fragmentation and bubbles, which are obstacles in context of establishing global egalitarianism Juǀ'Hoansi-style.

</comment></comment><comment><USER4> and look at how much their egalitarian society achieved over the hundred thousand years that it has existed.

inequality is how evolution works. something becomes better and dominates. then the next iteration comes, and the next.

having a society that cares more about the distribution of wealth and power rather than its total sum is a dead end. as someone who likes achieving things i also find such a society just morally abhorrent.

<comment><USER5> _" For instance, on the planet Earth, man had always assumed that he was more intelligent than dolphins because he had achieved so much—the wheel, New York, wars and so on -- whilst all the dolphins had ever done was muck about in the water having a good time. But conversely, the dolphins had always believed that they were far more intelligent than man -- for precisely the same reasons."_

What I find much more morally abhorrent than Ju/'hoansi's extreme egalitarianism is our society's inequality, greed, corruption, sociopathic derision of the concept of greater good and short-sighted disregard for our future.

If I were forced to choose between the extremes of living in an uninspired and underdeveloped society as described by Douglas Adams in my quote, or accepting this pathological glorification of rampant capitalism as the pinnacle of social evolution, I would rather choose to be a dolphin than human.</comment></comment>


Our physiological processes become increasingly simple as we age - <AUTHOR> http://nautil.us/issue/68/context/the-real-secret-of-youth-is-complexity-rp <comment><USER2> I'm in my late twenties and increasingly worry about things like this. I sometimes wonder if my best "thinking days" are already behind me. Business sense and practicality (i.e. "wisdom") still seem to be increasing with time, yet I can't shake the feeling that understanding highly complex or novel topics is going to become vastly more difficult over the next few decades. For instance, if I wanted to learn homotopy type theory, would this have been easier five years ago, or will it be easier five years from now? It's well known that the number of neural synapses in the human brain decreases by almost an order of magnitude over a lifetime. I can accept that my body will degrade physically, but psychologically, I have a hard time stomaching the idea that my mental faculties are likely to erode as well. Hopefully exercise and eating well are enough to at least delay this as long as possible.

<comment><USER3> I'm in my early forties, and I've been having the same worries you list the whole time.

And the answer (for me, so far) is....it's complicated.

I definitely think I have a harder time processing new ideas. OTOH, I have a lot more context to connect them to, so I feel like I end up with a better understanding when I DO get them. I also have a wider perspective to decide WHAT I want to spend my precious time learning. When I do learn something, I'm less likely to think it's the answer to everything, while I'm still able to get excited and enjoy how much easier this makes many of my tasks.

And it's really hard for me to say how much is REALLY having a harder time grasping new ideas, and how much is a mix of (1) that additional context, which makes it harder/longer before I feel the sense that I truly "get" it (2) the overwhelming sense of how many things I DON'T know that makes it feel like "I'm not learning like I used to".

Docker has been on my list to learn for ~4 years, even though I've used it indirectly for most of that time, for example, but it's not that I haven't been learning new concepts in that time - I've just not been able to find free time where Docker has been on the top of my list. Kubernetes shows up on HN, and I've not done more than googled the general idea. Are these omissions because I don't have the capability to learn as well, or because I've got a very full schedule and mental web of connections to fit them into? No way to be sure - I don't know of any way to quantify them.

I try to make sure that I end each week being able to say I learned something new, and while those bits are often small, they are also often significant in my day-to-day.

Also, don't discount the impacts of physical decay on the psychological. Being unable to sit comfortably for long stretches, the wear and tear of a million tiny aches - they may as much to blame for psychological limitations from age as any direct neurological degradation.

<comment><USER4> I'm 40 and it's less that I can't learn new ideas and it's more that I have fairly settled ideas about how the world works and it's hard for me to fully integrate new concepts without relearning a lot of other things at the same time.

I can learn new things as well as I could before, it just takes a bit of effort to clear space for it, as it were.

<comment><USER5> That you used the word " _re_ learn" responding to a comment that mentions docker kinda hits it exactly for me: it's hard to get excited about a new way to do the same old thing, whereas when younger you don't yet have enough understanding/experience for it to have reached "same old thing" status.

</comment></comment></comment></comment><comment><USER6> I think fasting is a process helping me against the aging peril. I'm not convinced if it will help me live longer (if nothing else goes wrong) but I can say my focus is increased and compared if I ate 2-3 meals per day. I'm skeptical if fasting triggers cells into the claimed "garbage collect" process or if my focus is just a hunter gather sense of I'm in danger from low calories kicking in. I assume endurance exercise is the best for the mind. I doubt non-physical games directed at improving thinking really help at all. The only supplement I've had benefit with is fish oil.

<comment><USER7> How do people know if their focus increases as opposed to a placebo intervention?

<comment><USER8> Have you ever been so hungry that you cannot concentrate on something difficult? Once you master fasting, you don't get to that point anymore.

Does it increase focus overall? I have no idea.

<comment><USER9> I'm dieting at the moment (mainly trimming down after Christmas, and making some room for a winter bulk routine).

Quite a few times, I've been so hungry that it interfered with my thinking. I had to eat _something_ to get my focus back. Currently sub-10% body fat and a pretty seasoned dieter, so I think I have a fairly good feeling for what's real "hunger" and what's just "craving food".

In 2 weeks I'll switch to a weekly 36 hour fast, but I have no idea how I'm going to deal with the hunger pangs affecting concentration. Maybe, as you say, it is something you can train yourself out of.

<comment><USER8> When you feel that way, it's because your blood sugar is low - your body i quite literally out of fuel. Once you adapt to not constantly providing an easy source of carbohydrates, it will activate other metabolic pathways. That's when you can go for an extended period without food.

If you want a softer landing, I recommend the 16+8 fasting for a week before diving into multi day fasting. You eat at the latest at 20 (8pm), and not until 12 (12am) the next day. It will take some adapting, but it's better than the headache inducing "withdrawals" you'll feel jumping headfirst into 36h fasting.

</comment></comment></comment></comment></comment><comment><USER10> I'm almost 60. I trained as a s/w engineer / coder in the 1980s and then transitioned in the 90s into a customer-facing consultancy role with good domain knowledge. Here are some specific observations on cognitive / corporate skills and how mine have varied, YMMV

I definitely have more work 'wisdom' and can often spot problems that are not obvious to younger colleagues and even offer workable solutions, albeit not usually in the low level technologies.

I have massively improved self-confidence that sometimes gets me through situations where my own knowledge / competencies are lacking.

I can still learn, e.g. picking up C# and Visual Studio as a hobbyist to implement a Lisp interpreter [0] (I started six weeks ago and am on step 8 of 9 now, working on it in the evenings and rainy weekends). However, I think that it takes me longer to learn than it would have done once. I am definitely slower at navigating user interfaces, especially jumping immediately to a specific but not often used menu item. Younger me would have gone straight there.

Improved search tools / repositories of online information make up for poorer memory of language syntax and APIs. I don't now have access to the code I first wrote to check it's complexity.

Looking at documents I wrote several years ago, I don't think my vocabulary and writing skills have declined significantly.

I have to continually remind myself not to be too dogmatic, especially where my knowledge is potentially out of date, or where I realise that my improved self confidence is masking the fact that I am actually wrong.

[0] [https://github.com/kanaka/mal/blob/master/process/guide.md](https://github.com/kanaka/mal/blob/master/process/guide.md)

</comment><comment><USER11> Much of the advice in the article boils down to keep doing new things, and exposing yourself to new experiences- physical, mental. Significant to me is how little the comments here speak about the note on social groups. It emphasizes a diverse, robust social group. Do I know that many people not in tech? How would I do that?</comment>


Microsoft releases declaration in support of Epic Games - <AUTHOR> https://siliconangle.com/2020/08/23/microsoft-supports-epic-games-apple-alleges-fortnite-maker-asking-special-treatment/ <comment><USER2> To be honest, Microsoft, Apple, Epic and other large tech companies... they seem to all try to lock software down to their platforms, want more control and profit from it. Not sure how I would position myself here.

They could have not released their software on Apple to not be dependent.</comment>


A Tale of Two Apples: AirPods and the Touch Bar - <AUTHOR> http://www.jeffgeerling.com/blog/2016/tale-two-apples <comment><USER2> I kind of brushed off the AirPods when they were first introduced.

Now that I'm seeing the first round of reviews, I'm seriously lusting for a pair. You're right - they have that user experience delight that's been missing in the last couple of products I've purchased from Apple.</comment>


AIG sues BofA for $10 billion alleging "massive fraud" - <AUTHOR> http://www.cnbc.com/id/44059438

<comment><USER2> AIG's Exhibit 1 on trial should one copy of "The Big Short" by Michael Lewis. You'll never trust any bank ever again after reading that book.

</comment><comment><AUTHOR> Hypothetically, if BofA failed, could the government even afford to cover FDIC?</comment>


Bids Start at $300,000 for Chicago's Old Post Office - <AUTHOR> http://www.nytimes.com/2009/08/05/realestate/commercial/05chicago.html <comment><USER2> Awesome building, but with $12.5 mil for keeping the lights on, $300,000 is too much.

Interesting how technology improvements (new letter sorting technology) has made a building of that size essentially unusable.</comment>


Ask HN: Would a temporary coronavirus section be useful here? - <AUTHOR> I'd like to separate our usual news and the virus news. Just have a new link on the top besides "new". Do you also think it's a good idea? <comment><USER2> HN generally eschews tagging and categorization, because it's intrinsic to the site that it be non-siloed: everybody sees the same site. This has deep consequences for community: [https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...](https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20silo&sort=byDate&type=comment).

/ask and /show in the top bar are partial exceptions, but those are not exactly topic categories.

</comment><comment><USER3> i think very much. There is a process for merging threads, if they are similar enough but "coronavirus" is too general of a tag for merging on that basis.

i wonder how much extra work would be required to branch topics off into "hyperthreads" or something like that.

</comment><comment><USER4> You could suggest it as a new category for this site? [https://bestofshowhn.com/](https://bestofshowhn.com/)

</comment><comment><USER5> absolutely. great idea</comment>


The Future Internet Regulation - <AUTHOR> https://web-greensefa.streamovations.be/index.php/event/stream/the-future-internet-regulation <comment><USER2> This is almost a 4 hour video (as such, with a surprising upvote velocity)

The relevant 4 minutes (9:00-13:00), as claimed by the page title: 1) Common rules for the internet 2) Liability exemptions will be the same for all internet and hosting providers. 3) Create a single marketplace for digital services. 4) Ensure that digital services are guaranteed to everyone in the union. 5) Ensure that countries receiving digital services are not prohibiting services

#5 is the weird one as it's not clear at first if he's for or against prohibiting services targeting some countries, as a retaliatory or punitive measure.

<comment><USER3> _> The relevant 4 minutes (9:00-13:00), as claimed by the page title_

You are mistaken. 9:00 and 13:00 refers to the CET times when this 4 hour session was scheduled to start and end.

</comment></comment><comment><USER4> I don't plan on watching a 4 hour video to understand the Greens party's position on internet regulation. Is there a condensed version with their positions and proposals available?

<comment><AUTHOR> video is hosted by the green. But the panel is the "Directorate‑General for Communications Networks, Content and Technology" (DG CONNECT)

they are present in pretty most of the policy and standardization discussions which makes it highly relevant imo.

Aral Balkan has more info on his blog describing his part of the talk: [https://twitter.com/aral/status/1197090688426491904](https://twitter.com/aral/status/1197090688426491904)</comment></comment>