A Farewell to FRP • Hacker News Board

Re: A Farewell to FRP

#151

Post by junke » Tue, May 10, 2016, 9:21 PM UTC

iheartmemcache wrote: post #115

junke wrote: post #78

Earlier quoted context omitted.

Synchronous Programming of Reactive Systems, Halbwachs Synchronous Languages for Hardware and Software Reactive Systems, Berry Designing Embedded Systems with the SIGNAL Programming Language, Gamatié The Synchronous Languages 12 Years Later ( http://www-verimag.imag.fr/~halbwach/PS/iee03.pdf ) There are some resources at Verimag ( http://www-verimag.imag.fr/Tempo,32.html?lang=en ) and the Esterel website ( https://ww…

I'm a huge INRIA fan so I decided to play with Esterel a while back. If people call Haskell an 'academic' language, I have no idea how an average person would describe Esterel. "Thinking in" Esterel is going to be a huge shift for the traditionally trained CS guy who's never touched a circuit. Half the people in our field didn't even go to go to school for CS[1]. Hell, I've got a decent amount of LabVIEW and Verilog…

> Do you have a link to your thesis?

There is only a French version:

https://tel.archives-ouvertes.fr/tel-00680308/

The context is about using a constraint programming approach (in Prolog) to model Lustre/Scade programs and automatically generate traces of input/outputs that satisfy a given test objective. With the help of my advisers I extended the GATeL tool to introduce what is known as "clocks" in Lustre and integrate them with other constraint domains to prune the search space efficiently.

Re: A Farewell to FRP

#152

Post by swaroop » Tue, May 10, 2016, 9:24 PM UTC

Buttons840 wrote: post #129

swaroop wrote: post #117

Earlier quoted context omitted.

The new C++ Core Guidelines & Guidelines Support Library and related tools are interesting efforts to specifically solve those problems.

If the issue is that "C++ compiles stuff that may or may not work at all" then I don't see how those guidelines will help the situation. A C++ project may or may not follow those guidelines and then we're back where we started.

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.

Re: A Farewell to FRP

#153

Post by frostymarvelous » Tue, May 10, 2016, 9:26 PM UTC

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/…

I came across it researching time travelling debuggers to implement in my flux implementation for android.

My mind was blown but never really got enough time to study it since it was low on my priority list.

I think you just pushed it to #2!

Re: A Farewell to FRP

#154

Post by t1amat » Tue, May 10, 2016, 9:29 PM UTC

dominotw wrote: post #49

embwbam wrote: post #44

Earlier quoted context omitted.

Evan wants to design Elm as thoughtfully as he can, and has been deliberately resisting community evolution. Eventually it will get too big and too useful, and he'll lose the ability to make big breaking changes easily. So he's tried to maintain control of the direction of the language and community during these early years while he figures it out. He's trying to reduce the feedback loop and come up with the best pos…

' during these early years' should feature prominently in their docs/website if that is case. If you go to http://elm-lang.org/ they make it looks like its production ready. No mention of breaking changes/beta ect. You have to choose one or the other .

The Elm community is very strict about semver. Given this context, in Evan's defense, the 0.17 version is not a mistake as the API is still in flux.

Re: A Farewell to FRP

#155

Post by doppioslash » Tue, May 10, 2016, 9:39 PM UTC

Learn2win wrote: post #96

Are there type classes in Elm?

No, and they're not planned either. There has been much discussion about them in the years: https://github.com/elm-lang/elm-compiler/issues/1039

Re: A Farewell to FRP

#156

Post by vvanders » Tue, May 10, 2016, 9:42 PM UTC

SomeCallMeTim wrote: post #135

astrodust wrote: post #110

Earlier quoted context omitted.

Rust has some really good compile-time checking, it really makes you express everything in a completely non-ambiguous way. C++ on the other hand compiles stuff that may or may not work at all, it doesn't care, which can lead to all sorts of undefined behaviour down the road. Compilers are not all created equal.

Huh. I find that when my C++ compiles, it almost always works. Correctly. But I used the language for nearly 20 years, so maybe it's experience and the patterns I've learned? Not that Rust or Elm aren't better options; don't know, really. Despite feeling like I'm an expert in C++, I don't actually like the language much. I've used Go some, and I like it, but I haven't tried Rust or Elm yet.

You really owe it to yourself to give Rust a shot. A lot of things that you've encoded in convention(as any good C++ programmer should) are right there at the language level.

Ownership? You get an awesome sliding scale of Borrow Checker Boxed Rc/Arc

Mutation? Covered in Copy+Clone/Cell &/&mut RefCell

Thread Safety? Sync + Send guarantee that things which need to stay on a specific thread cannot be shared.

Combine that with Sum Types, Pattern Matching and much stronger functional constructs makes for a very compelling language.

Re: A Farewell to FRP

#157

Post by nostrademons » Tue, May 10, 2016, 9:47 PM UTC

CuriousSkeptic wrote: post #147

andybak wrote: post #132

Earlier quoted context omitted.

Modern static typing isn't remotely related to typing from the "1970's"

Ok, 1969, but fairly close! https://en.m.wikipedia.org/wiki/Hindley–Milner_type_system

The type systems in modern languages like Swift, Rust, Scala, Haskell, and even Kotlin go way beyond classical Hindley-Milner. Classical Hindley-Milner gives you parametric polymorphism over algebraic data types, along with an inference algorithm. No subtyping, no casts, no coercions, no overloading, no polymorphic literals, no interfaces. You basically get SML.

Consider that in 2006, MPTCs with fundeps was the preferred way to represent "a collection of items that can be compared via equality" [1]. Associated types were a vague research idea [2] that showed a lot of promise, but hadn't been implemented in any language with type inference (they did exist in C++ templates, but C++ isn't exactly what people think of when you say "modern type system"). Now both Rust and Swift feature polished implementations of associated types and use them pervasively in the standard library.

[1] https://en.wikibooks.org/wiki/Haskell/Advanced_type_classes#...

[2] https://prime.haskell.org/wiki/AssociatedTypes

Re: A Farewell to FRP

#158

Post by im_down_w_otp » Tue, May 10, 2016, 9:50 PM UTC

nilkn wrote: post #93

What I really want is a language with Elm's type system, simplicity, and syntax, but aimed for backend software instead of HTML apps and with strong support for an Erlang-style actor model of multicore, distributed concurrency. Basically something like Elixir, but with Elm's syntax and type safety. In the meantime Elixir will do for me, but I'd really like more type safety without going full Haskell.

For whatever reason the Elixir community doesn't seem to really strongly point people at dialyzer, but what you want is dialyzer, and yes you can use it with Elixir.

Re: A Farewell to FRP

#159

Post by aarpmcgee » Tue, May 10, 2016, 10:07 PM UTC

ccapndave wrote: post #45

empath75 wrote: post #21

Is parsing json still an ugly mess? That was what put me off actually using it for anything.

Its a little wordy, but now that I'm used to it, it takes no time to write decoders/encoders. There is also a tool to automatically generate them from JSON input at http://noredink.github.io/json-to-elm/

didn't know about this! thanks!

Re: A Farewell to FRP

#160

Post by mhd » Tue, May 10, 2016, 10:15 PM UTC

Has the elm installation on Linux improved in recent months? Last time I tried my system's GHC was too new to install it from source and the node installation went kablooey in weird parts(too recent ncurses, the automatic "reactor" browser repl not finding the Html package etc...)