DanWaterworth

Is there a way to apply without going through the angel.co website?

You obviously have reasons to be angry, but vitriolic comments don't produce constructive discourse.

I only mean it's visibly more obvious, you have an indented block...

Haskell is more similar than you realise, it's the difference between this:

    withSomeResource $ \resource -> do
      someFunctionOn resource

    with some_resource() as resource:
        some_function_on(resource)

As an outsider, you might expect a type-error to mean that you made a logic error, in practice it usually means you made a typo.

What happens is that the type system forces you to write things in a certain way. You internalize its rules and it moulds your style. You don't try random things until they stick, you write code expecting it to work and knowing why it should, just like you would in Python. It's just that more of your reasoning is being verified. "Verified" is the operative word here - the type system doesn't tell how to do anything.

it seems like it's maybe quite unhaskellish to have to rely on a naming convention and remembering not to use the return value of the function?

The Python equivalent of the problem here would be:

    current_resource = a_resource

    with some_resource() as resource:
        current_resource = resource

    current_resource.some_method()

I think the crux of our discussion is about checked vs unchecked constraints.

When you work on (successful) large codebases, whether in a static or dynamically typed language, there are always rules about style (and I mean this in a broader way than how your code is laid out). For example, in large Python projects, there might be rules about when it is acceptable to monkey-patch. These rules make reasoning about the behaviour of these programs possible without having to read through everything.

Large Haskell projects also have these rules, but Haskellers like to enforce at least some of them using the type system. It takes effort to encode these rules in the type system and it is more difficult to write code that demonstrably follows the rules than implicitly follows them, but the reward for this effort is that it gives you some assurance that the rules are actually being followed everywhere.

For some rules this extra effort makes sense and other times it doesn't. The type system is just another way to communicate intent. Writing the best Haskell doesn't necessarily mean writing the most straight-jacketly typed Haskell, but it does give you that option. Beginners often fall into the trap of wanting to try out the new-and-shiny and making everything more strict than is helpful.

For one-man projects, there's really no advantage to Haskell over Python (with the caveat that you may not remember all of the intricacies of your code in six months and using Haskell you may have encoded more of your assumptions in the type system).

I can see why you might think that, being built into the language, using 'with' in Python in a broken way would be easier to spot. However, having used both languages extensively, I can tell you that, at least for me, there's no discernible difference.

I think the reason for this is might be that, in Haskell, a function starting with 'with' is, by convention, using the bracket pattern and the way that you might use such a function would be very similar in structure to the Python way.

Something that is often said about C++ is that, you're only ever using 10% of the language, but that everyone uses a different 10% and it's true, but it's true of every language to differing degrees. Everyone has their own way of forming programs, just like everyone has their own slightly different style of playing chess, cooking or forming sentences.

When you have a well developed style, you will quickly spot any deviations from it. At that point, it doesn't matter if your style was forced on you by the language or whether it's just a convention that you use.

It's certainly true that Haskellers expect a lot from the type system, even compared to other static languages, let alone Python.

If you are consuming an API that provides an object with a destructor, you are correct, you can determine when destructors will be called.

The issue is when you produce an API that contains objects with destructors. Since you are handing these entities off to unknown code, you cannot ensure that they will be dropped. This was a problem in scoped threads in Rust.

Python's "with" construct is analogous to the bracket pattern in Haskell that the article is talking about. It also works in the nested case in the presence of exceptions. Furthermore, the issue that Michael has with the bracket pattern in Haskell can also happen in Python.

The thing is that, in Haskell, even when you attach a function to run during destruction, the runtime doesn't guarantee that the function will be called promptly, or even at all.

However, this is different than the bracket pattern that the article is taking about. No one in the Haskell community advocates cleaning up resources (like file descriptors, etc) using only destructors.

Sad to see you being downvoted when you are correct, see [1]

forget is not marked as unsafe, because Rust's safety guarantees do not include a guarantee that destructors will always run.

This was a problem in Rust when scoped threads relied on destructors being run.

[1] https://doc.rust-lang.org/std/mem/fn.forget.html

SQLite

You're right to complain that conquistadog's comment was irrelevant to your main point. It's frustrating when people miss what you are saying and get so hooked on trivialities. Incidentally, your nitpicking about my use of the word duress is also irrelevant.

Next, you call people childish, when you are acting immaturely. How does name-calling generally work out for you as a means for settling disagreements?

It also bugs me that you are not even technically correct. You see, I looked up the definition of duress before I posted. I am British, so I used the OED and it told me that in the legal sense of the word, duress is, "Constraint illegally exercised to force someone to perform an act." Based on that definition, I don't think I could have picked a word that would better suit my intention.

Off topic, and IANAL, but I believe this website breaks European law by refusing to serve the article to european residents who block cookies.

Under the ePrivacy legislation (and GDPR's redefinition of consent), you must obtain "freely given consent" to use cookies that are not necessary for the proper functioning of the site (and under this definition, analytics cookies are not necessary).

By refusing to serve the site to those who opt to block cookies, they ensure that consent can only be given under duress.

You may prefer this link: https://arxiv.org/abs/1606.03490

I agree with you for the most part here. For the things that I typically use computers for, I would prefer to have both hardware and software protected sandboxes. There's a reason that browsers are switching to using multiple processes.

I suspect you are being downvoted for being overly emphatic. I can certainly think of scenarios where having this extra security is more costly than helpful.

An interesting point of note is that the mill architecture has been designed to have much cheaper hardware protection than other architectures. [1]

[1] https://www.youtube.com/watch?v=5osiYZV8n3U

The rule of thumb for restaurants is the poorer the website, the better the food. Restaurants with Flash-only pages that haven't been updated for 15 years are the best. Also, the cleaner the bathrooms, the cleaner the kitchen.

There's a good reason that the pictures look similar. Both architectures produce somewhat blurry images.

The problem, in BEGAN's case, is that when your idea of similarity is based of mean squared error, high frequency details are just not important. [1] You can see this by doing PCA on natural image patches. BEGAN uses an autoencoder trained on MSE.

RBMs produce blurry images because the architecture is not good at representing multiplicative interactions. You just get splodges of colour.

[1] http://danielwaterworth.com/posts/what's-wrong-with-autoenco...

I have experience using each of these languages professionally, working in a team. Each of them have their own foibles that you'll be constantly railing against:

Python:

Large Python projects require discipline. To make it work, you'll need to adopt a rigid style, like DI, and use it religiously. It can be done; people do it, but if you think using Python will lower the barrier to entry to getting on the team, think again. Large projects in any language require talented people.

Go:

I don't like Go, so I have the least experience in it out of the three. There are positives, like fast compile times, but lacking generics and exceptions just makes Go annoying to me.

Haskell:

I have written a quite incredible amount of Haskell and before using it in a team, I was a huge proponent. Haskell is a well-designed language, but suffers a few major drawbacks. Large Haskell programs can take an age to compile; this is a productively killer. Universally agreed upon good styles for writing large Haskell programs don't exist. Library support is lacking. Space leaks will bite you. I would strongly advise against starting a large Haskell project.

To wrap up, in terms of your criteria, the language you use isn't going to change things very much.

* Each language has a good community for long term support,

* Complex code in any language is buggy; simple code in any language is less buggy,

* Good developers are hard to hire,

If performance is important, Python and Haskell perform similarly for code that people actually write. Go does better.

Disinterested means impartial, you are uninterested.

Also in the medium term, artificially increasing the price of fuel incentivizes research and development of alternatives.

If you don't mind me asking, why do you want to do this?

I think a better way to handle this would be to use subresource integrity [1]. Then, if the browser's cached version matches the hash, it can be sure that it doesn't need to do any requests.

[1] https://developer.mozilla.org/en-US/docs/Web/Security/

Comments like this are why I still read hacker news.

You're not alone: https://www.johndcook.com/blog/2013/02/04/four-hours-of-conc...

What happens is: treatments are evaluated and declared either cost effective or not. They don't refuse people treatment because they've used more than their 'fair share' of some allowance.

One story I heard is that for example in the UK they won't pay for dialysis after a certain age. So public health insurance is not an automatic solution to every problem.

A quick Google search reveals this claim is spurious, so maybe don't believe everything you hear.

You always have to make assumptions in any formal system able to express arithmetic as proved by Gödel.

This has been another episode of the Hacker News Joke Explainer™

Tune in again next time and remember, if you we have to explain you, you just aren't funny.

On the lower end of the spectrum, sound type systems prevent a class of vulnerabilities including buffer overflows. On the upper end, https://sel4.systems/, a formally verified microkernel, is used in security-critical systems.

A method to reliably produce vulnerability-free software is not invented yet.

I beg to differ. We have formal methods, ranging from type systems to full blown verification. This isn't a technical problem, it's an economic one.

You could potentially go via C. https://github.com/draperlaboratory/llvm-cbe

There's also biochar