308 karma · joined June 21, 2021
It's possible to exploit this to read/write arbitrary memory and to execute arbitrary code. It appears that in practice this is very difficult so the issue is ignored.
https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...
https://chriscoyier.net/2023/09/29/css-solves-auto-expanding...
Even without using this new CSS property, the technique that is used (adjusting the "height" of the element) is not ideal and can be glitchy.
A better approach is to use a mirror hidden element:
https://css-tricks.com/the-cleanest-trick-for-autogrowing-te...
The website has lots of information and videos and beginner tutorials.
I view this as a good sign. When two independent parties arrive at the same design it is usually an indication that they have discovered a universal and principled solution.
I consider the "conduit" library to be one of Haskell's "killer features", and sorely miss having something like it when working in other languages.
Maybe when Haskellers dismiss clojure transducers as being "just like conduit" it comes from a place of jealousy? I've seen several articles and discussions over the years of clojure transducers that take place outside of clojure communities and are aimed at the wider programming public, praising the benefits of it. But I've never seen conduit discussed outside of Haskell communities.
http://neilmitchell.blogspot.com/2015/04/cleaning-stale-file...
But I think the best solution (that also works with make) is to have a "make dist" target that creates a final .tar.gz archive of the result. If the rule is written properly then it won't contain any stale files. The disadvantage is for large project it may be slow, but you are not supposed to use this rule during development (where it is useless anyway), only for releases (which still can be built incrementally -- only the final .tar.gz needs to be created from scratch)
Shipping boxes of heavy books costs a lot of money, and the publisher doesn't actually need the books back (because they can always print new copies very cheaply).
So the publisher just tells the book store to destroy the books, and as evidence for their destruction asks only for the covers to be shipped back to them (which is cheap).
This is why books contain within them the text "This book should not be sold without a cover".
So with this printer company, they are effectively "destroying" the unused ink cartridge since it's not worth it economically to have it shipped back to them.
The added bonus is that if the customer renews the subscription then the ink can be "undestroyed"!
https://chrisdone.com/posts/shell-conduit/
It uses a Haskell streaming library so you can do stuff like shell pipelines and file redirection (but in a more structured, safer and more powerful way)
There are places in Makefiles where no amount of quoting will help you, and it simply cannot handle files with spaces.
Yeah, this is a problem with the tool that should be fixed, but my understanding is that it will never be fixed because of architectural reasons. And it's a very popular, useful, and most importantly, ubiquitous tool.
So this is another good reason to simply have a policy of banning filenames with spaces (and there are many more reasons).
One hypothetical example: it decides to "help" us and prevent any more human pain and death, so it cryogenically freezes all humans. now its goal is complete so it simply halts/shuts-down
There are 2 ways:
1. You cheat and use unsafePerformIO. This is discouraged and I won't go into the details.
2. You convert your inner function from being a "pure" function to being a monadic function over some abstract MonadLogger m. Then you can still call your function in a "pure" context by using a Writer monad for your MonadLogger, but you can also call it from the IO monad and get "better" logging (with real-time output and timing info).
Note that you still do need to convert your entire call chain from being pure to use "MonadLogger".
But I would argue that even in non-Haskell languages you should also do this (meaning you should thread a "Logger" object through all functions). Why? Let's say you don't, and now you want to do logging from some inner function. How do you configure the logging? To which file do you save it? What verbosity level? You will need to use a global/Singleton Logger object. But what if you want to call your function from two different places in your code and use a different verbosity setting for each? You can't. So I argue you are always just better off doing the refactor in all languages. The fact that Haskell forces this means that developers don't have the choice and are forced to do the right thing.
Yes. This matches the definition of a mathematical function that I gave above.
> how can I call a function which takes no arguments but which returns a value the user entered on the keyboard?
You can't. If your language allows you to write such a function then I would argue you are no longer doing FP (at least in this part of the code).
I believe that this is why many people like languages like Ocaml, F#, Scala. These are hybrid functional-OOP. You can use FP for the parts of the program that it's suitable for, and OOP/mutable-imperative for the other parts("the best of both worlds").
The purist FP programmers might claim that reading input from a keyboard is "uninteresting" and that programming is really about logic, algorithms, and computation, and therefore FP is enough for them (...in their ivory tower).
I personally am a fan of Haskell, but I don't like calling it FP, because it does allow you to write "code" that reads input from the keyboard. They still claim to be pure FP by using a loophole and saying that "getLine" is not a "function" but rather an "IO action". But to me it doesn't matter what you call it, you are still effectively allowed to write code that does I/O and mutates external stuff, doesn't matter if you call it a "function" or something else.
Of course the big advantage that Haskellers claim is that the language enforces the separation of effectful code from "pure" functions. In the other hybrid FP languages it is possible (and happens often) where you have a deep call chain of "pure" functions and then you realize you need some small side-effect somewhere, so you just add it. Haskell does not allow this at the language level, and forces you to refactor your code. In my opinion this does lead to cleaner architecture and more maintainable code in the long term.
But to me Haskell is really interesting for a different reason. I don't like to call it an FP language, because like I said, a lot of the code you write isn't really "functional". A better name would be: "mathematical oriented language". And by math I mean that the code is built using logical systems that have mathematical rules that can be reasoned about.
Going back the I/O (reading input from the keyboard): what the Haskell people have done is realized that you can actually model this behavior of user input as a mathematical model. This unlocks a type of thinking that allows you as the developer to go beyond the thinking of telling the computer: "do this, then do this, then do this, if this happens then do this, ...".
An example: the mouse-position on the screen. There are haskell libraries called FRP that model the mouse position as a "signal function" (a well-defined term they invented) that is a 2D coordinate that changes over time. You can then combine this signal function with others to create behavior such as an image that follows the mouse. You can build complete GUI applications using this approach, and the code looks nothing like imperative programming, and more like an electric circuit of different components connected together.
And that is just one example. The Haskell community has also come up with mathematical models for streams (think unix pipes) that allows you to write streaming code that is much more powerful and cleaner then what you see in other languages.
So my summary: Yes, functional programming is limited, but if we go one level deeper, we could say that the essence of FP is really mathematical thinking. And if we embrace that and run with it then we can open up entirely new possibilities.
There is no definition of what FP is that is agreed upon by everyone, but the key is the word "functional" in FP.
This comes from a mathematical function, which is a mapping of input values to output values.
You could write a definition of a function f(x) to be such that the value of f(x) is the result of the execution of some imperative-looking code (including loops that mutate variables).
Mathematicians would be satisfied with such a definition and would confirm that f(x) is a function just as valid as any other.
And so functional programmers should also accept such a function. In fact, Haskell has specific syntactical support ("do" notation) to allow you to write functions using imperative-looking code including mutations (the ST monad, or other State monads).
Yes, this could end up being a fine of $10,000 for stealing a $150 phone, but there is an argument to be made that it is justified (and just).
What are the arguments against?
So Twitter would need to sue itself to demand that it take down the content. And the judge would reject the suit and scold Twitter for wasting the courts time, and tell Twitter that if it wants something removed from its own website then it should just remove it.
I am curious if there is actual data on the number of man-hours that are spent on open source per year, and how many of those are funded by corporations. My guess is that it is less than 1%.
Examples: Python Software Foundation, Haskell Foundation
In practice this seems to work well.
It may be written in the fine print, but it's not something that most rational consumers willingly agree to.
And if you try to use AWS just for S3 then you will pay a lot extra for the bandwidth charges of bringing the data from S3 to your server (something that is free if you were to use EC2 or other AWS services).
I often hear the argument that there is nothing really new in programming and that everything was already done in some way or other back in the 1960s.
I completely disagree with this and find it harmful. There is genuine innovation and new research happening in computer science all the time. The example you gave, the Rust language, is based on linear type theory that was first developed in the 1990s. Nothing like it existed in the 1960s and that is why it offers real improvement to software development.
Today, software development is slow, buggy, expensive and late. We owe it to ourselves to continue to research and search out ways to improve our craft. And this is happening. Newer programming languages and tools DO incorporate innovations from recent computer science research and are better for it. We should celebrate this rather than cynically pretend that all computer science research halted in 1969.
Does HN publish this statistic? My guess is that >50% of users/traffic to this site is outside of the USA
The solution is to require that all PR must be rebased/synced to master before they can be merged. GitHub has an option for enforcing this. The downside is that this often results in lots of re-running of tests.
It uses the actual PostgreSQL parser against your project's database schema to give 100% accurate results. Guarantees that all of your queries are valid, and that all input and output types are correct (and will also auto-generate/quickfix the output types for you in VSCode)
"Game maker Valve appoints in-house video games economist" https://www.bbc.com/news/technology-18456171
But it is worth pointing out that it is actually possible to maintain "perfect" accuracy when doing arithmetic even when sqrts (or other irrational numbers) are involved.
The idea is to store numbers as an AST consisting of an expression. Then you can perform any arithmetic on them by growing the AST. After each operation you simplify as much as you can. Once you have your final result you can evaluate the AST up to any precision that you need (and sometimes your final AST will already be a rational number because sqrts cancelled out)