232 karma · joined January 4, 2016
Website: https://www.lezgomatt.com
> Hence what, for lack of a better name, I'll call the Python paradox: if a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it.
[1] https://www.microsoft.com/en-us/research/wp-content/uploads/...
Another great book on FP is "The Functional Approach to Programming" [2], which is a bit like SICP but using Caml (OCaml without the O) instead of Scheme.
Kernighan also co-authored a (imo) really great book with Rob Pike (once an assistant of Penn & Teller [3]) called "The Practice of Programming" [4]. Unfortunately, this one is a bit over the 200 page limit.
[1] https://en.wikipedia.org/wiki/The_Elements_of_Programming_St...
[2] https://www.youtube.com/watch?v=8SUkrR7ZfTA
[3] https://youtu.be/z4iVAcYyWN0?t=180
[4] https://en.wikipedia.org/wiki/The_Practice_of_Programming
Also, a related HN discussion: https://news.ycombinator.com/item?id=21357638
Once set, authentication will require confirmation via a GUI dialog provided by the ssh-askpass command. However, it does not mention the command or process requesting for authentication.
It works great on Linux, but I couldn't get it to work on macOS with the system keychain.
Background: JPEG XL is a combination of Cloudinary's FUIF [1] (successor of FLIF [2]) and Google's Pik [3].
Committee Draft (Aug 2019): https://arxiv.org/abs/1908.03565
Technical Details: https://www.spiedigitallibrary.org/conference-proceedings-of...
Features / Goals:
- high quality compression (> 60% over JPEG-1)
- royalty-free with open source implementations available from the start
- versatile: supports alpha transparency, high bit depth (16-bit), lossless compression, animations
- progressive decoding / "responsive by design"
- legacy-friendly: reversible transcoding of JPEGs with 22% size reduction (demo available [4])
Comparisons:
- JPEG 2000, JPEG XR: only marginal compression improvements
- WebP: limited (8-bit, 4:2:0), no progressive decoding
- BPG/HEIF (HEVC): patent-encumbered (not royalty-free), no progressive decoding, complex
- AVIF (AV1): no progressive decoding, complex, slow?
[1] https://cloudinary.com/blog/introducing_fuif_responsive_imag...
Not only did they plagiarize your work, but they did a really poor job of it too. The print is full of formatting issues. The code blocks are not properly indented, which is not only poor style but also broken given that python is white-space sensitive. And bizarrely enough the letter "q" is continuously in bold throughout the whole book. You can easily verify this from the pictures by the reviewers. I don't actually own a copy of the book myself.
To make matters worse (or better?), they only decided to include the first four chapters, ending at "Conditional Execution". Yes, the plagiarized book claims to be a guide "from beginner to expert", yet it didn't reach the chapters on loops and functions!
If you read the reviews, you'll quickly notice that it's full of fake five-star reviews with very vague sentences, some of which don't even make sense. You'll also (now) see a lot of real one-star review, which means that quite a number of people have fallen for this scam.
Surprisingly, one of the fake reviewers even got in Amazon's top 100 reviewer list. Check the profile of "Kip Krenz" [2], who is currently at rank #53. Somehow he managed to review two to four books on a near daily basis for maybe a year or more, mostly five-stars (the rest are four-stars) and full of generic sentences. The books reviewed are most likely "fake" as well. They often fall under one of the following: a beginner book, a self-help book, a cookbook, a trading book, or a book on one of the latest fads.
This book is unfortunately just one of the many fake books (not the jazzy kind) that have proliferated on Amazon. If you look at the other recommendations, you'll probably find another one of these books (Python seems to be one of those profitable topics).
A common technique used by these books is to put themselves under some niche category in order to get a high rank. For example, this book categorized itself under "Microsoft C & C++ Windows Programming" [3], and is currently at #9 there (it used to be #1, but thankfully the real reviews probably dragged it down). For a more peculiar example of this, take a look at what's #1 under "Windows XP Guides" [4].
Sorry for going on a tangent with such a long wall of text. I spent a night "investigating" this whole thing a few weeks ago, and after seeing this post, thought that it would be best to spread awareness of the issue here.
[1] https://www.amazon.com/Python-Programming-Beginner-Intermedi...
[2] https://www.amazon.com/gp/profile/amzn1.account.AGXMOOP4UKWV...
Using Murphy's Law is not very convincing. Even with action creators Murphy's Law guarantees someone would have just constructed the objects manually anyways. Having to grep the tag is not ideal, but it's not likely to be a problem in practice.
I doubt that the bundle would be significantly larger (especially after compression). Using actions creators introduces additional (function call) overhead too (and that would be insignificant as well).
While I'm sure the author did not intentionally try to make TypeScript look bad, (imo) they didn't put enough effort to make it look good either. There's a lot more to TypeScript that this post fails to mention. ReasonML is a good language (I think OCaml was just fine though), but TypeScript is good too.
The author says "ReasonML is everything TypeScript tries to be (and a bit more) without all that JavaScript weirdness.", but I strongly disagree. Embracing "all that JS weirdness" is the whole point of TypeScript, and what makes it so successful. Unlike most typed languages, TypeScript (for better or for worse) adapts its type system to the developer's code, not the other way around. This is why its type system is much more expressive than many other type systems including ReasonML's.
If you insist on having the action creators, they can easily be written as one liners each, which is a lot less bloated than the original example.
export const addMovie = (movie: string): Action => ({ tag: "AddMovie", movie });
What's the issue with passing object literals? I know it looks a bit hacky and messy, but if it's typesafe (which it is) then it doesn't seem like a real issue. interface State {
movies: string[]
}
// you may also use { tag: "Action", payload: string }
// if you prefer something more structured
type Action =
| ["AddMovie", string]
| ["RemoveMovie", string]
| ["Reset"]
const defaultState: State = { movies: [] }
const reducer = (state: State, action: Action): State => {
switch (action[0]) {
case "AddMovie": return { movies: [action[1], ...state.movies] }
case "RemoveMovie": return { movies: state.movies.filter(m => m !== action[1]) }
case "Reset": return defaultState
}
}
const someAction: Action = ["AddMovie", "The End of Evangelion"]
TypesScript's type system is actually very flexible and advanced [1] compared to most type systems since it had to adapt to the very "dynamic" structuring of JavaScript in the wild.[1] https://www.typescriptlang.org/docs/handbook/advanced-types....
Also, for "Set-Cookie", the relatively new "SameSite"[2] directive would be a good addition for most sites.
Oh, and for CSP, check Google's evaluator out[3].
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Re...
[1] https://iu.instructure.com/courses/1735985
[2] https://github.com/IUCompilerCourse/Essentials-of-Compilatio...
The talk is by the fourth member, Geo, who also frequents HN (geocar).
Another similar idea is Fowler's software development attitude [3]. He uses the terms "enabling" and "directing" instead.
[1] https://plus.google.com/110981030061712822816/posts/KaSKeg4v...
[2] https://news.ycombinator.com/item?id=4365255
[3] https://www.martinfowler.com/bliki/SoftwareDevelopmentAttitu...
Don't worry too much about choosing the "wrong" language or framework. What you build matters more than how you build it. For example, many would recommend Postgres over MySQL for good reasons, yet those who use MySQL are doing just fine [2]. Their advantages are often insignificant in practice, so feel free to ignore the hype (especially here on HN)!
Angular, React, Vue are all fine choices for building SPAs. Rails is kind of out of place here (it's not a front-end framework). The hype around it has died, but Rails itself is still very much alive, and it's very mature. ClojureScript and Elm may need a bit more getting used to depending on your experience. Their communities are relatively small though, so you'll have less resources available.
[1] PHP gets a bad rap for its past, but modern PHP really isn't so bad (very Java or Ruby like, depending on the framework that you choose). jQuery is "old", but reliable. Not a good idea if you're building something highly interactive, but if you only need "a little bit of JS" then it seems like a good fit. SPAs have many advantages, but are also much more complex, so avoid building one if you don't need to.
[1] https://github.com/Engelberg/instaparse
How can you check if a variable is NaN then? Well, if it's not equal to itself then it must be NaN!
Many of us here would really love to read up on the ideas behind each iteration, the specifics on what went well, what didn't go as expected, the target market and their feedback. It doesn't need to be a fancy paper, even a short but detailed bullet list for each iteration would be fine.
From my outsider perspective, it seems like you were trying to build a "silver bullet". For example, both FiveSquare Eve and WikiEve look promising. FiveSquare could be a great WYSIWYG website/app builder. WikiEve could be a great note taking tool. Just because they aren't the future of programming, doesn't mean they aren't useful!