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

Many people who were in positions to know the real conditions and prospects opposed the use of nuclear bombs on strategic and ethical grounds: https://www.antiwar.com/blog/2021/06/05/who-opposed-nuking-j...


Agree. "Fact-checking" can never be more than assertions of a particular bias. I am surprised that this project has received so few critical comments along these lines here.

The idea that "specificity," such as what scientific research aims for, can be better evaluated for truthfulness or approach what "truly matters," as this project purports, is dubious. E.g., why would a notion that is more limited in scope matter more than something more vast (to use the word that it cites as an example)? In addition to its dystopian idea of a "source of truth," it completely dismisses "vague" language in the name of "science" or "factuality," which is utterly the opposite of science, which I thought was to understand ourselves and nature with as few presuppositions as possible.


How is information qualified as evidence (e.g., the “Evidence Crawler” functionality)?

The best case scenario would seem to be that results are derived from certain biases built into the model, unless it weighs “factuality” by the number of occurrences of certain statements on the internet which is as far from a qualification for truthfulness as the biased model.


Happy user of Soupault here. What you described here:

> Markdown processors behavior differences can bite you and there's no way out.

is under appreciated. The lack of “surprises” in Soupault is very appreciated.


It was a little difficult to wrap my head around at first, but for me its main benefit is this:

In many static site generators, if there is a page in a collection of pages (say, a product page) that you want to add a custom layout to (but without affecting other pages in that collection), you often need to create a separate template, or modify the default template to allow for this exception. With Soupault, page content is typically written in HTML and giving a specific page a custom layout is as simple as including an <html> element in that page’s content file and it will be treated as a completely standalone page. In other words, a content file is not as different from a template as in typical static site generators.

This flexibility and HTML-first approach cuts down on complex or sprawling templates introduced to deal with many exceptions. And as a result, someone only needs to know HTML to make most edits to a website. Of course, you can make certain patterns more efficient with “widgets” (basically snippets to insert content dynamically) defined in the main configuration file, but it is not requisite.

At the end of the day, the website is mostly just HTML with a simple project directory structure, which makes it understandable to a wider audience, which is important to me since I want the website to be easily understandable for future maintainers of it.

Edit: Another benefit is that Soupault is a single statically-linked executable with no dependencies, and therefore can be downloaded via a simple link. This also extends the longevity of websites built with it (i.e. it is easy to get the development environment setup).


> Edit: Another benefit is that Soupault is a single statically-linked executable with no dependencies, and therefore can be downloaded via a simple link.

My single executable is called 'docker' for these kind of tools. No need to download anything at all.


I have been very satisfied using https://m-docs.org/ It has pre-built components and a bunch of utility classes that allow basic custom styling in the manner of Tailwind so that I rarely write any css myself. It's also framework agnostic and as simple as just including a <link> and <script>.


The author of this framework is also doing very interesting work on building Haskell server pages [1], taking inspiration from redbean's Lua server pages[2].

[1] https://monadic.systems/post7 [2] https://redbean.dev/#lua


One of the nice features of IHP is that, thanks to Haskell’s strict type checking, it does not just eliminate bugs, it also speeds up development. E.g. if you want to change or build a new feature, you don’t need to write tests for it since the compiler basically does that for you. Since you don’t need to write tests, your work is perhaps half of what it would be normally – and neither do you have to know how to write good tests, which is an entire skill in itself.


Not sure if you're being sarcastic, but Haskell developers should definitely write tests, and good ones know how to write good tests. The type system eliminates the need for some forms of testing, but not all.


Thanks for the feedback. I am definitely a beginner in Haskell, which would explain why I came to this conclusion. Could you recommend some good sources on testing in Haskell?


While of course Haskell has more normal testing infrastructure available (eg. https://hspec.github.io/), my favorite bit of Haskell testing is QuickCheck, which IIUC started life in Haskell and has been reimplemented in other languages with various degrees of effectiveness and various degrees of connection to the original project.

John Hughes (not the filmmaker) gives a great talk about it: https://youtu.be/zi0rHwfiX1Q


Thank you very much! I just finished watching the video and am now reading more on QuickCheck. This approach makes a lot of sense.


Actually it’s common for Haskell devs to write property-based tests that are far more complex than regular tests (identifying useful properties is a true artform). Source: I’ve been a test engineer on a large Haskell product!


Type safety on its own does not guarantee program correctness, nor does it eliminate the need to write tests.


Don't need to write _type_ tests (like you would in a dynamic language). Having strong typing doesn't magically do formal validation on your logic. Leaning heavily on types is good practice, but that doesn't eliminate most of the high value tests you'd have to write.


Haskell's QuickCheck, AFAIK the first prominent implementation of property-based testing, gained its popularity partly because it eliminated a good part of the tedium by inferring the sampling strategies from the types (which in idiomatic Haskell are, due to liberal use of opaque type synonyms, often quite a bit more specific than in any other non-dependently-typed language I've seen). Which does not free the programmer from writing down the properties themselves—in that respect your objection is valid—, but IME still makes it quite a bit more ergonomic than e.g. Python's otherwise functionally equivalent Hypothesis.


You'll find no argument from me there, property based testing has been a real game changer for me. I imagine it would have a fraction of the value without being able to leverage the type system to a great degree.


> Having strong typing doesn't magically do formal validation on your logic

There are plugins for Haskell and dependently typed languages that go much further in the ‘if it compiles, it is formally validated’, but that’s a lot more work; there is a trade-off for now or you will be stuck. Your ‘run of the mill’ tests also don’t formally validate your logic (not even close usually). Our types, even if static, are usually too loose and our type systems not powerful enough; writing tests helps to close the gap between practical and theoretical but a lot more can be done semi-automatically (and will be I hope).


> There are plugins for Haskell and dependently typed languages that go much further in the ‘if it compiles, it is formally validated’

Yes, Lean 4[1] is shaping up to be a Haskell-inspired dependently typed language with monadic IO etc. that can also prove theorems for you. Still a work in progress but looks very exciting.

[1] https://leanprover.github.io/lean4/doc/


See also:

- Idris (https://www.idris-lang.org/)

- Agda (https://wiki.portal.chalmers.se/agda/Main/HomePage)

I'm really excited by progress in this space! :)


Thank you for linking the article. I had never heard of the US Agency for Global Media before. I have not read that much about it yet but it sounds in line with some of the criticisms Chomsky levels at U.S. propaganda. I would be very interested in any other sources of information you might recommend on this topic or hearing more of your own thoughts (my email is in my profile).


I'd recommend reading: https://liberationschool.org/tiananmen-the-massacre-that-was... as well as the WikiLeaks documents and draw your own conclusions. CBS, NYT, and many other American sources all also do not report this "massacre" yet I recall it being in my textbooks and it being "common knowledge".

It's become impossible for me to trust the US on anything domestic much less China. I'd hoped for much better from HN but it seems the critical lens is not being applied as much as a xenophobic one. :(


Thank you very much for the suggested readings. Recommendations like yours are very appreciated since I find it difficult to find such content via the usual means of discovery on the internet. I read through the first article. That and similar critical writings certainly make one doubt much of what one has learned and hears...



Thank you very much! I will check out their website.


Your comment reminds me of Machiavelli’s work “Discourses on Livy” in which he writes, among other things, that discord (between the nobility and the common people) produced the liberty enjoyed by the Roman Republic. Machiavelli’s views on republicanism are very insightful, in my opinion, and offer an understanding of democratic government that may be more prospective of being actualized than what appears to be proposed in much of today’s discourse on democracy.

By the way, I came across one of your HN comments in the past (https://news.ycombinator.com/item?id=18127353) and immediately was impressed by your thinking. Ever since, I look forward to seeing your comments on HN. If you are interested, I would be greatly interested in hearing more of your thoughts expressed in the aforementioned comment of yours. My email is njrc900[at]gmail[dot]com


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

Search: