501–510 of 513 posts
Earlier quoted context omitted.
It isn't just log(n), it's also L1 vs L3 access times and an extra level of pointer chasing.
Just to confirm, you are talking about L1 and L3 caches, right?
I will certainly be downvoted for this, but I want to be honest so here it is anyway: In all my programming years, 20+ years that is, I've met hundreds of programmers, and 95%+ of them handled imperative programming languages just fine, with very few actual bugs coming from each one. Each time there is such a conversation, I have yet to see some actual concrete proof that functional programming provides a substantial…
My viewpoint, as a functional programmer, is software is a young field.
We don't know much of anything about it.
We're living in the first 100 years after the Gutenberg printing press.
All I know is NLP code generation will be a dramatic change.
Everything else, we are still figuring out.
Earlier quoted context omitted.
That's duplicating part of the structure. That uses more memory than just modifying a value in-place, but less than duplicating the whole tree.
Sure, but let's assume that the program has more than one thread and that another thread could still be using the old value. In that case, an imperative program might be required to copy the whole structure or sleep until the existing users are done, which is often less efficient and is always more complicated. If it's ok to support only a single concurrent user of the value, then a mutable structure is indeed more e…
If you're multi-threaded, you have to choose: Do I go with immutable, which means that the other thread gets something safe? It also means that the other thread gets something stale (out of date), which can have its own consequences.
Or do I use a lock or mutex, which means that I have to place guards in all the right places, which is error-prone and can break in weird ways if I miss one?
Or do I use mutable data without guards, and just let it crash? (Because it's probably going to crash if I do that...)
Earlier quoted context omitted.
An anecdote of one person with bad manners shouldn't be representative of the whole. I'd estimate there are three kinds of FP advocates: 1) People (like me) who have experienced personal pain in building or maintaining complex systems in imperative or other paradigms, and are genuinely astounded and relieved when we learn how Haskell and other FP languages can mitigate or eliminate that pain. They tend to advocate FP…
> An anecdote of one person with bad manners shouldn't be representative of the whole. It is so incredibly widespread, it's not just "an anecdote of one person". The entry-level courses at TU-Berlin where I studied had just been taken over by FP disciples when I started studying, and it was crazy. "Let me tell you about our Lord and Saviour Functional Programming, Hallelujah". And of course the reality didn't come cl…
Can you provide a link?
Earlier quoted context omitted.
Pure functional languages model IO with monads, which are very much functional (function composition within a context) and IMO easy to use. This ease of use is probably why JS adopted the pattern with native promises -- async/await. They fit well into otherwise imperative code and people seem to to like them.
Pure functional languages can very well have normal IO. It's Haskell's lazyness that mostly forced it to use monads for IO, for better or for worse. In a pure FP language with strict evaluation semantics, IO can easily be implemented as a pure function foo -> (World, Input) -> (World, Output).
Earlier quoted context omitted.
> In fact, I challenge you to develop a first-person shooter in Haskell (Have fun). https://hackage.haskell.org/package/frag > There are many types of applications where functional languages are perfect, but there are more that it would be a disaster. Can you give an example or two of an application in a functional language would be a disaster? > To make broad sweeping claims, such as this article, just encourages un…
frag-1.1.2 failed during the building phase. The exception was: ExitFailure 1 Go fix that for us. ``Can you give an example or two of an application in a functional language would be a disaster?`` Sure, code that tests its self. Not happening. Which means, most embedded applications where fault tolerance is a must. If you don't know what caused the error, well, lets here your ignorant response. Explain how you trap t…
Isn't there an error message just above saying that you need to install the development version of the GL library? Fix it yourself; we can't!
Granted, that error message could be made easier to read.
I will certainly be downvoted for this, but I want to be honest so here it is anyway: In all my programming years, 20+ years that is, I've met hundreds of programmers, and 95%+ of them handled imperative programming languages just fine, with very few actual bugs coming from each one. Each time there is such a conversation, I have yet to see some actual concrete proof that functional programming provides a substantial…
The opinions of programmers who have only used one paradigm are less than worthless, since they are demonstrating a basic lack of curiosity and lack of willingness to invest in their craft.
You can always find excuses not to learn.
Earlier quoted context omitted.
Please, no. Node tooling is such a mess and I can almost never get anything running easily on Nix because Node developers download binaries from the internet without understanding the system. All of these executables fail because of linked libraries. If instead they told you what libraries and executables you'd need instead loosy-goosy installing garbage all over my system, more things might work.
Sure npm is not silver bullet. But I want the npm experience. Technical implementation can be improved as you say and I agree.
Earlier quoted context omitted.
PSA: Visual Studio for Mac[0]. I know you're on Linux but for others. [0] https://visualstudio.microsoft.com/vs/mac
And just for clarity, it's not proper Visual Studio, but rather an updated MonoDevelop. Was missing quite a lot of functionality (for Unity/C#) compared to VS, so I used Rider instead.
Functional programming won't succeed until the tooling problem is fixed. 'Tsoding' said it best: "developers are great at making tooling, but suck at making programming languages. Mathematicians are great at making programming languages, but suck at making tooling." This is why Rust is such a success story in my opinion: it is heavily influenced by FP, but developers are responsible for the tooling. Anecdotally, the…
Even refactoring was easier because the types are sometimes left to be inferred and not named everywhere. The type inference in F# being weaker also even helps with both compile speed and readability where annotations are needed both to help the compiler and the reader.
Perhaps on larger projects other things become important, but I got the sense that it's on the devs to name things well, use type annotations where helpful, and otherwise document non-obvious aspects.