Write Junior Code

Re:Write Junior Code by bauerd on Sunday December 29, 2019 @05:37PM (#21909087)

Wish there was something similar to Elm, but designed with backend/networking/generality in mind, like Go. Take the Haskell core language without all the lang extensions, and accompany it with a solid stdlib. I want an FP ecosystem that's not rooted in research. Can have a more simplistic type system, etc. Basically a functional Go. Maybe an effect system, idk.

[ Parent | on HN ]

Re:Write Junior Code by rashkov on Sunday December 29, 2019 @06:50PM (#21909502)

Have a look at OCaml, and also at its new spinoff, ReasonML. I think it may be what you’re looking for - compile-to-native systems language, great type system with 20 years of development behind it, and functional without being dogmatic and pure about it by easily allowing imperative mutable code as well.

[ Parent | on HN ]

Re:Write Junior Code by zozbot234 on Monday December 30, 2019 @01:53PM (#21915718)

ReasonML is more like 'Ocaml with a different syntax' than an actual spinoff.

[ Parent | on HN ]

Re:Write Junior Code by thrower123 on Sunday December 29, 2019 @05:44PM (#21909124)

I keep telling myself that this is the year I'm going to really learn F#; it has a lot of the nice parts of Haskell, but is a little more on the pragmatic end, and has access to the whole .NET world.

The problem I run into frequently on my abortive attempts is that when things get harder, it's too easy to just drop back and smash something out in C#.

[ Parent | on HN ]

Re:Write Junior Code by Multicomp on Sunday December 29, 2019 @06:18PM (#21909334)

Once you get used to / take for granted the additional compiler features in F#, you will find yourself weaning yourself off C# code more and more. Resistance is futile!

2019 ends my year of F# focus. In 2020, I will take a look at Rust since it is C-but-not-nearly-impossible-to-correct-insecure.

Between Get Programming with F# and Domain Modelling Made Functional, I am a convert for F# and will continue using it into the future. Why?

Quick example: I'm currently hacking together a program for the RPG system used in Star Wars Fantasy Flight Games, so that the game master can input possible player actions during their turns and keep track of player stats, generate NPC encounters etc. and so forth.

Writing the back-end in F# (stored to SQLite) really helps me keep the game rule book (business logic) straight, with compiler-based warnings if I try to, say, stick XP into a function that expects in-game cash.

On the front end, I'm using plain old Windows Forms in C#. The UI is mostly for data crunching and keyboard-first usage (I'm keeping in mind my FoxPro days and gui.cs / TUI / keyboard-first functionality from that twitter thread a few weeks back), and is mostly for gluing UI controls to the back-end itself (maybe this will be a mobile app, website, etc. in the future depending on the GM's needs).

For this program, I wouldn't write any game logic in C#, now that I'm used to F#. C# lets me get away with too many mistakes compared to F#, for the same reasons JavaScript lets me get away with (even more) too many mistakes compared to C#.

[ Parent | on HN ]

Re:Write Junior Code by tylorr on Sunday December 29, 2019 @09:24PM (#21910266)

The problem I've run into is it feels like the language has been abandoned. It feels close to being perfect enough but I can't shake the feeling that the final push it needs will never happen.

[ Parent | on HN ]

Re:Write Junior Code by thelazydogsback on Sunday December 29, 2019 @07:16PM (#21909654)

F# is my most productive language - it's hard to be beat strong typing w/type-inference, modeling with DU's, pattern matching, indent syntax (by default, unless you don't want it), and the .Net(core) lib/runtime. It's especially nice now that VSCode/VStud have plug-in's that show the inferred type signatures.

The tooling is pretty good now, but there are still pain points (breakpointing/stepping pipes |>, inlines, and pattern matching expressions), but even w/that said the tooling is probably above avg. now. If you want the best refactoring and debugging experience (Resharper, OzCode, etc.) the C# is still the best there.

[ Parent | on HN ]

Re:Write Junior Code by reikonomusha on Sunday December 29, 2019 @07:38PM (#21909776)

I would say it’s more “familiar”, not that it’s more “pragmatic”. Haskell is an entirely pragmatic language and is useful for solving very wide ranges of tasks. It’s just not very familiar to most people, in part because it doesn’t plug into a familiar ecosystem, like CLR/Java languages do.

[ Parent | on HN ]

Re:Write Junior Code by verttii on Monday December 30, 2019 @04:23AM (#21912044)

I used to have the same wish as you but then I just decided to pick up Haskell. Haskell's hard part really is the type system. It's also what ultimately enables you to write very high abstraction level type safe code that does exactly what it's expected to do.

Btw you may want to keep an eye on this: https://wende.github.io/elchemy/

Honestly, I wish this would get more traction, it seems like an awesome intersection between type safety and practicality.

[ Parent | on HN ]

Re:Write Junior Code by bauerd on Monday December 30, 2019 @07:03AM (#21912741)

You cannot pitch Haskell to the average industry team. It's not so much about technical merit for me

[ Parent | on HN ]

Re:Write Junior Code by thraxil on Sunday December 29, 2019 @05:50PM (#21909162)

Elixir is pretty great if you're not super hung up on type systems.

[ Parent | on HN ]

Re:Write Junior Code by bauerd on Sunday December 29, 2019 @05:55PM (#21909195)

I should have added that I'd also prefer mandatory typing and natively compiled code.

Elixir/Erlang/BEAM has a lot going for it but it's not as general purpose as I'd like

[ Parent | on HN ]

Re:Write Junior Code by hinkley on Sunday December 29, 2019 @06:51PM (#21909505)

There's at least one other way to read that comment.

Is there an 'Elixir' of Haskell? Maybe someone should write it. What would it look like if you stole the good bits from a framework/library/standard lib in another language and wrote them in Haskell?

[ Parent | on HN ]

Re:Write Junior Code by ramchip on Sunday December 29, 2019 @11:20PM (#21910777)

There is an attempt at it, yes: https://wiki.haskell.org/Cloud_Haskell

Many languages have some variation of Erlang’s processes and/or distribution available as a library, but the key features like live inspection, code reload, or strong isolation between lightweight processes can’t really be done without language runtime support.

[ Parent | on HN ]

Re:Write Junior Code by verttii on Monday December 30, 2019 @04:25AM (#21912054)

There's also some work pushing Haskell to perform better (more like Elixir) in networking/concurrency applications: http://www.well-typed.com/blog/2019/10/nonmoving-gc-merge/

[ Parent | on HN ]

Re:Write Junior Code by unique_username on Sunday December 29, 2019 @06:43PM (#21909464)

You are basically describing ocaml

[ Parent | on HN ]

Re:Write Junior Code by np_tedious on Tuesday December 31, 2019 @12:37PM (#21922788)

It sounds a lot like you're asking for the "junior haskell" (no higher kinded types, few language extensions, etc) that this article proposes and stack's toolchain. Am I missing something?

[ Parent | on HN ]

Re:Write Junior Code by nicoburns on Sunday December 29, 2019 @10:01PM (#21910439)

Rust gets pretty close to this.

[ Parent | on HN ]

Re:Write Junior Code by zozbot234 on Monday December 30, 2019 @01:55PM (#21915741)

Rust is for GC-free code, and it shows in how it deals with closures, higher-order functions, etc. Very different from Haskell or even something like F#/Ocaml/Kotlin and the like.

[ Parent | on HN ]

Re:Write Junior Code by tobyhinloopen on Monday December 30, 2019 @04:51AM (#21912204)

Elixir?

[ Parent | on HN ]