161–170 of 300 posts
If I want to do functional programming, I can do that just fine in most languages. If I want to do imperative programming, I can do that just fine in most languages, except for functional programming languages .
Earlier quoted context omitted.
I haven't used an IDE in years. Just VSCode. Which is not really an IDE. I haven't missed it. I think that if a language depends on an IDE to be useful, it's a design smell.
VSCode is an IDE. Otherwise, what is am IDE according to you? Is Emacs an IDE? Eclispe?
I think it's great that Keli is designed with IDE support in mind. However I believe that this is only half of the reason why FP still doesn't really break through in the corporate world. The other reason is that many FP users are too enthusiastic about creating abstractions. This is of course something that FP is exceptionally well suited for. An api that was written to simply process a list of Orders into a Report…
>The other reason is that many FP users are too enthusiastic about creating abstractions. Elm lacks typeclasses, yet I've found this lack is what keeps a lot of libraries at bay that would have otherwise turned out overly abstract (see any mainstream Haskell library, really). It's the same reasoning behind Go: With great power comes great responsibility. At large, programmers shoot their own feet with powerful langua…
Earlier quoted context omitted.
> An api that was written to simply process a list of Orders into a Report might be abstracted into a fold on some monad, which at first seems a great idea. But if you're not careful, readability suffers a lot. It's much easier to get to know an application when its code deals with business objects that you already understand well, than to read hundreds of lines of code that deal only with abstractions. Do you have a…
Well, we're used to the AbstractBeanHandlerFactoryFactories already. A slight discomfort of learning something new can seem much bigger when you're already acclimated to abuse.
That also makes the language not about a "good user experience" as given in the docs, but "being compatible with modern IDEs". No thanks, I would rather improve tooling for an existing language that already has a community and ecosystem.
Earlier quoted context omitted.
I'd prefer readability to suffer because the fold over a monad needs something clever that requires a bit of reasoning to understand than because vast amounts of "readable" boilerplate (for example, trivial getters and setters) hide a needle in a haystack.
folding over a monad (or any other combinator) doesn't require extra reasoning or anything clever, that's the point.
Earlier quoted context omitted.
I don't know much about modern IDEs because I don't use them, but I suspect that the very powerful lisp macro system can be an issue for good IDE integration. Think of something like the "loop" construct in Common Lisp: http://cl-cookbook.sourceforge.net/loop.html That's related with the problem the parent is talking about: it's very easy to create DSLs in in languages like Common Lisp, so people use them a lot. But…
Perhaps if Macros where not such a mainstay and powerful element of some FP langs (I am not arguing against them), this argument would not be so strong. Macros in C/C++ are difficult for IDEs to deal with too, save for constants. Seeing though that macros are near fundamental to some FP langs, I understand better the driver for the design of Keli.
Why is no one talking much about Scala? ( https://docs.scala-lang.org/overviews/scala-book/functional-... )
Because we're trying to turn people on to functional programming, not off EDIT: Downvotes already? Look, Scala is NOT noob-friendly, and it's a rational argument, not a preference. Here's an example: There are at least 10 (TEN) different uses of the underscore character (_) in Scala. JFC. I can go on, such as the proliferation of bizarre operators everywhere that are impossible to Google (again, not noob-friendly), t…
Scala is eminently beginner friendly when introduced to developers familiar with OOP. This approach was how I first experienced Scala and it ended up becoming a gateway drug into FP proper.
Regarding underscores in Scala, yes there are many technical terms for each thing it has the capability of representing... but in reality, you just use it wherever you want to ignore a value with a placeholder or pass a provided value through.
Earlier quoted context omitted.
I get this might just boil down to preference but I absolutely hate named parameters. They’re biased towards new users of a language and quickly become painful to write once you’re familiar with the function call. Plus they don’t always improve writability outside of IDEs because you then have to memorise the parameter names and in some functions there’s several terms that could equally apply (if you’re using an IDE…
I disagree that named parameters are just biased toward new users. They're also biased toward reading rather than writing. I find that as a code base becomes bigger and more non-trivial, I end up reading code many times, and the more I appreciate named parameters.
Thus, you can be writer friendly and reader friendly, considering the reader uses an IDE.