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

201–210 of 246 posts

Re: A Farewell to FRP

#201

Post by weq »

WorldMaker wrote: post #148
iheartmemcache wrote: post #106

Earlier quoted context omitted.

After reading the article, I went into their IRC chan to post this question (i.e. are they leveraging all the research from really-smart(TM) PhD's at Microsoft Research & production testing that Rx has behind it). This guy has a doctorate, so I'd imagine there was a reason why RxJS wasn't leveraged, especially since it seems like a natural fit especially with Typed.*. And n general the Elm/Haskell community is way le…

I feel some of this. I almost had a Microsoft-first shop let me use Haskell when I pointed out how many of Haskell's lead developers worked at Microsoft Research UK. As for the Microsoft "first party" F# equivalent for the web, that would be Typescript. Typescript's typing isn't yet to the rigor of OCaml, much less Haskell or Elm, but it's getting better every release.

I learnt Haskell at uni in 2000. Now im a c# guy mostly unless im in the broswer. You know u can program in pretty much the same way using C# as u can haskell? I dont see the attraction of going to F#, but thats because i need to consider maintaince costs of the code-base as well as them both compiling down to IL.

Functional langauges are great, dont get me wrong, if i had the choice id probably give 'elixir' a 'rust' ;) but i make do with my existing c# knowledge, sprinkle in some Rx, isolate my side-effects in closures when pure functions cant be had, and im pretty happy with both the look, readability and maintance burden my code generates. The advantage of C# here over a first order functional lanuage is my ability to customise the syntax to make things self-documenting as well.

Re: A Farewell to FRP

#202

Post by rvense »

SOLAR_FIELDS wrote: post #183
rvense wrote: post #141

Earlier quoted context omitted.

You build your system as a box that takes strings in and sends strings out. You then have to do a bunch of checks (as part of your de/serializing) at the boundaries only . Inside the box, all your logic and transformations are type safe, and indeed you can turn some logic issues into mechanically checked type-level issues, which are basically free unit tests.

I like this for lightweight applications. I imagine it could become a bottleneck for anything moderately heavyweight when it comes to data processing. Most web apps are designed to not do any heavyweight lifting on the client side, so it is a nice general paradigm for that.

Why a bottleneck? Static types don't have to add any runtime overhead. In fact, the type information isn't present at runtime at all in some languages. It's a compile-time guarantee that actually allows you to remove some runtime checks and assertions. And I think all bechmarks show that static languages are as a rule faster than dynamic languages.

If you're comparing two different designs in a statically language where one involves making lots of new types and the other just shuffles strings back and forth, then I can't say and it'd depend on the specific case. Generally, helping the compiler is a good thing, and obviously things like switching on an enumeration is much faster than a long line of string comparisons. Actually, strings are just a horrible datatype, so unconstrained and inefficient. Use strings less!

Re: A Farewell to FRP

#203

Post by Paradigma11 »

curried_haskell wrote: post #178
jiaweihli wrote: post #142

Earlier quoted context omitted.

Akka[1] is exactly the library you're looking for. It's available for Scala[2], which lets you use both OOP and FP as needed. (It also runs in Java if you have experience with that.) [1] http://akka.io/ [2] http://www.scala-lang.org/

But Scala is far from a simple language and Akka makes it even less so.

You could try f# or c# with http://getakka.net/

Re: A Farewell to FRP

#204

Post by insulanian »

brightball wrote: post #114
shrugger wrote: post #103

Earlier quoted context omitted.

You might be interested in the Crystal language. It's a statically-typed, Object-oriented, Ruby inspired language. It's Ruby with types, basically. You might also be interested in Elixir which ties in to the Erlang ecosystem, but if you are super into OOP (like me) you might find it slightly more difficult, but since you have experience with static-types, you probably know some FP stuff, and so it's not that bad. Eit…

It's odd how people are in their perspectives on static vs dynamic. I can't for the life of me understand how people tolerate static typing on the web. Every time I've tried it the experience has been so tedious. I just figure, everything is coming in as a string no matter what. It's going back out as a string. The only place it needs to be anything other than a string is something interesting is being done with it a…

Yes everything is a string on the web, but IMO it's not the primitive data types that I'm concerned about so much - it's about the data structure (classes / interfaces). If I refer to my item's description property as `item.descripition`, statically typed language will scream that I have mistyped the property name before letting me run that code or, God forbid, releasing it.

Re: A Farewell to FRP

#205

Post by eggy »

platz wrote: post #177
hkjgkjy wrote: post #60

Earlier quoted context omitted.

Elm is typed, Clojurescript is homoiconic. 2 great features. Wondering if you could make a lisp where `lambda` or `fn` required type annotations, such as (defn add [int -> int -> int] ;; type annotation [x y] ;; arguments list (+ x y)) Then it would be homoiconic - something that has saved me hundreds of lines of code (and the less code, the less bugs as a rule of thumb). Then every function down to the very basic li…

\* add.shen *\ (define add {number --> number --> number} \* type annotation *\ X Y -> \* arguments list *\ (+ X Y))

There was a small thread on the Shen Google Group about adding docstrings [1].

There is an BSD version of Shen that can be forked and docstrings added by whomever wants to pickup the work. The language's footprint is small enough now at the moment, that now's the time to get the first chunk done.

The BSD version is pretty impressive, and could be turned into a great project if people picked it up. A lot of interest has been expressed, but it is the commercial version that is moving ahead with lots of improvements. Shen's creator, Mark Tarver has added Griffin, an optimizing compiler, concurrency, and HTML generator in the form of SML (Shen Markup Language).

It is a very fun project. The small set of instructions it is based upon Klambda, has since been ported to many languages - Ruby, Python, Lisp, Haskell and more. The SBCL port is the main one. Aditya Siram (Deech) has just created an Elisp port, shen-elisp! [2]

[1] https://groups.google.com/forum/#!topic/qilang/FHUNMvOyu2U [2] https://github.com/deech/shen-elisp

Re: A Farewell to FRP

#206

Post by rubber_duck »

marcosdumay wrote: post #164
SomeCallMeTim wrote: post #135

Earlier quoted context omitted.

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.

Well, I find that when my C++ compiles When I first learned Java, still in my undergrad, my first impression (and nearly everybody's) was that when it compiles it works. It was still more work than Perl, Lisp, Prolog, and everything, but didn't require the annoying C debugging cycle. But, anyway, all that is kids play near Haskell.

>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 semantics and RAII really buy you a lot - the downside is that it's opt-in so the compiler won't force you - and it's less strict than say Rust, but it still gets you there 90% of the way.

Re: A Farewell to FRP

#207

Post by bjz_ »

swaroop wrote: post #152
Buttons840 wrote: post #129

Earlier quoted context omitted.

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.

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.

Re: A Farewell to FRP

#208

Post by [deleted] »

brightball wrote: post #114
shrugger wrote: post #103

Earlier quoted context omitted.

You might be interested in the Crystal language. It's a statically-typed, Object-oriented, Ruby inspired language. It's Ruby with types, basically. You might also be interested in Elixir which ties in to the Erlang ecosystem, but if you are super into OOP (like me) you might find it slightly more difficult, but since you have experience with static-types, you probably know some FP stuff, and so it's not that bad. Eit…

It's odd how people are in their perspectives on static vs dynamic. I can't for the life of me understand how people tolerate static typing on the web. Every time I've tried it the experience has been so tedious. I just figure, everything is coming in as a string no matter what. It's going back out as a string. The only place it needs to be anything other than a string is something interesting is being done with it a…

[deleted]

Re: A Farewell to FRP

#209

Post by naasking »

brightball wrote: post #114
shrugger wrote: post #103

Earlier quoted context omitted.

You might be interested in the Crystal language. It's a statically-typed, Object-oriented, Ruby inspired language. It's Ruby with types, basically. You might also be interested in Elixir which ties in to the Erlang ecosystem, but if you are super into OOP (like me) you might find it slightly more difficult, but since you have experience with static-types, you probably know some FP stuff, and so it's not that bad. Eit…

It's odd how people are in their perspectives on static vs dynamic. I can't for the life of me understand how people tolerate static typing on the web. Every time I've tried it the experience has been so tedious. I just figure, everything is coming in as a string no matter what. It's going back out as a string. The only place it needs to be anything other than a string is something interesting is being done with it a…

> I just figure, everything is coming in as a string no matter what. It's going back out as a string.

And everything in memory is a sequence of bytes. I don't see the relevance of this line of reasoning. I guarantee that whatever experience you've had with statically typed languages on the web, it's not a good language. Interfacing with dynamic systems is simply a matter of good abstractions, which many languages simply lack.

Take a look at F#'s type providers to see where you can go with this.

Re: A Farewell to FRP

#210

Post by naasking »

nostrademons wrote: post #157
CuriousSkeptic wrote: post #147

Earlier quoted context omitted.

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

> You basically get SML.

SML is still more usable than the statically type languages in use the most today (C++ and Java).

Post reply on HN