Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Farewell to FRP

elm-lang.org

Post reply on HN
Print view View original

221–230 of 246 posts

Re: A Farewell to FRP

#221

Post by Crespyl »

marcosdumay wrote: post #217
danek wrote: post #196

Earlier quoted context omitted.

I was also confused by it. However I read the last sentence as the author making a meta-point by using purposefully incorrect grammar, a sort of reversal of the first sentence about c++ code compiling but leading to segfault--like an artistic statement. If it was an accident, then all the better!

:) English is not my first language, and it is a rare construct. I thought it was correct. Out of curiosity, how should it read?

I believe the common form is "X is child's play (next to|compared to) Y".

Re: A Farewell to FRP

#222

Post by zalmoxes »

vijayr wrote: post #214
zalmoxes wrote: post #5

As someone who is just getting started with frontend development, I decided to go with Elm instead of learning JS and React. I found the whole experience very pleasant, even as a beginner. Not only is the elm code I write reliable, but I've found that adding more features does not bloat my code. Refactoring a codebase as it grows in elm is pleasant, and following the Elm Architecture guides me on the correct structur…

What resources are you using to learn Elm?

I used https://pragmaticstudio.com/elm to get me started.

Re: A Farewell to FRP

#223

Post by vvanders »

krakensden wrote: post #220
vvanders wrote: post #172

Earlier quoted context omitted.

Ah, sounds like Erlang/Elixir would be a better fit since the BEAM is the king of lightweight threads/processes. You said C++ so that's why I suggested Rust, generally a GC tends to preclude spaces where C++ excels which is why I would think you'd want to try something other than Go. On the Rust side there's things like mio for fast io but coroutine/light threads aren't really a focus afaik. I would still think you c…

You just can't be happy if someone else is using Go, can you.

The parent is already experienced in Go and expressed interests in other languages, excuse me for indulging them :).

Re: A Farewell to FRP

#224

Post by marknadal »

embwbam wrote: post #37
zalmoxes wrote: post #5

As someone who is just getting started with frontend development, I decided to go with Elm instead of learning JS and React. I found the whole experience very pleasant, even as a beginner. Not only is the elm code I write reliable, but I've found that adding more features does not bloat my code. Refactoring a codebase as it grows in elm is pleasant, and following the Elm Architecture guides me on the correct structur…

Bold move, but a good one, I think. I've been considering starting my students (just friends I mentor) on Elm for a while, but it's only this year I've heard of local companies hiring for Elm here in Salt Lake City.

I recently moved out to SLC area, shoot me an email aquiva at Google's mail.

Re: A Farewell to FRP

#225

Post by rubber_duck »

marcosdumay wrote: post #216
rubber_duck wrote: post #206

Earlier quoted context omitted.

>didn't require the annoying C debugging cycle Are we talking C or C++ ? C compiler is basically useless for compile time error checking because C type system is ridiculously weak. C++ on the other hand can buy you a lot of things with templates, richer type semantics, etc. And also keep in mind that C++11 and onward is very different from C++ of yore and it catches a lot of errors at the compile time - move semantic…

Both languages have approximately the same problems for debugging. Explicit memory references are hard to follow, lack of overflowing protection requires a lot of extra caution to catch the errors, and failures lead to an unforgiving stop with at most a core dump. C++ is much better for statically catching errors, but templates and copy/move semantics make it even harder to debug. And yes, I imagine C++11 is much bet…

You avoid explicit references in C++11 and use STL containers which check for overflow.

I agree that C++ can have the same issues but the frequency is not comparable because you don't drop to those unsafe parts if you don't have to.

So with C++14 I get that "if it compiles it runs" feeling comparable to say C#.

Re: A Farewell to FRP

#226

Post by Reefersleep »

timroy wrote: post #145
Morgawr wrote: post #102

Earlier quoted context omitted.

I personally use ClojureScript with type annotations from Plumatic (former Prismatic) Schema and it works really well. Obviously it's not the same as an actual typed language, but it gives me a good-enough starting point to leverage some typing information and perform some rudimentary (runtime) type checking. I also feel it's really nice as some kind of "inline documentation" to be able to see the type of your parame…

I have heard only good things about Schema, and I probably should have invested the time to understand and use it more intensively.

Just dive into it. After wanting to be a bit more descriptive and assertive about the input and output of certain functions in some code I was writing, I must have spent all of half an hour reading documentation and successfully adding Schema to my code. Might be a bit of a rose-tinted memory here in respect to the pastimate :) But it certainly is both easy to understand and use.

Re: A Farewell to FRP

#227

Post by Crespyl »

bakul wrote: post #84
callahad wrote: post #30

Earlier quoted context omitted.

In general, you're unlikely to need them. Instead of cobbling together disparate libraries for a virtual dom (React), state (Redux), immutability (Immutable.js), and types (Flow / TypeScript), the entire language and its core libraries are developed as a holistic (but still modular) unit. In this way, Elm is the BSD to JavaScript's GNU/Linux. Strong typing and immutability are baked directly into the core language, e…

"In this way, Elm is the BSD to JavaScript's GNU/Linux." Is there X such that X is the Plan9 to Elm's BSD?

Perhaps Urbit could fit that description?

Re: A Farewell to FRP

#229

Post by swaroop »

bjz_ wrote: post #207
swaroop wrote: post #152

Earlier quoted context omitted.

My understanding is that the tools are the answer - it's a linter that must be run before landing/merging. See https://youtu.be/hEx5DNLWGgA for a demo of such tools.

Tools are just band-aids over an unsafe type system, and they are all too easy to ignore or never use them in the first place.

It depends on the community. See gofmt & gometalinter in the golang community.

Re: A Farewell to FRP

#230

Post by mrcactu5 »

ccapndave wrote: post #43

I moved from React/Redux/Typescript to Elm a few months ago, and I'm now on my second serious project with it, making mobile application with Cordova. I've found it an absolute pleasure to use, and I especially like that you can be pragmatic about it; if there is something that is annoying to do in Elm then you can simply drop into Javascript/Typescript using ports. Coming from languages like Actionscript/Javascript/…

Did I read correctly that you are using Elm with Cordova?

Perhaps you are using Elm to compile to HTML / CSS / JS which Cordova compiles to native code?

Post reply on HN