Re: [elm-discuss] Type Checking in non-Pure Languages

[John Orford]

I suppose, what I am getting at, is what do you lose when you lose the
preciseness you get w purity. What's it feel like compared to Elm for
example? Anyone have any anecdotes?

On Mon, 13 Jun 2016 at 16:09 Joel McCracken 
wrote:

> I think you get a lot of value.
>
> I think the question of strong types is somewhat orthogonal to the value
> of purity. But, having strong types allows you to be sure about what is
> actually doing what, and where, so you can track side effects.
>
> Pattern matching and algebraic data types are wonderful ways to encode
> domain rules. But, with something like ocaml, you won't be sure that when
> you call a function the only thing that happens is you get an object of the
> return type.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Type Checking in non-Pure Languages

[John Orford]

A little off topic, but how much bang for the buck does type checking get
you in languages like Reason, OCaml and F# etc.?

It's one of my favourite features in Elm, and I suspect you would lose a
lot by relaxing purity - even though a major selling point of though those
languages is of course the expressive type system.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Static Tzpe Checking in Elm vs Java

[John Orford]

the first rule of Elm Type Club is you don't have to talk about types.

adding them back into the mix'd prob be hairy for a lot of people - then
again if you could do it in a v friendly way, there's lotsa benefits... I
heard Matz of Ruby fame talk about something similar once.

On Thu, 26 May 2016 at 12:17 Zachary Kessin <zkes...@gmail.com> wrote:

> I have thought about the idea of building a next gen elm with idris style
> dependent types. To be called "Pine" of course ;)
>
> Mind you I have neither the skills nor the time to do such a thing. But
> its a cool idea
>
> Zach
> ᐧ
>
> On Thu, May 26, 2016 at 9:56 AM, John Orford <john.orf...@gmail.com>
> wrote:
>
>> Thanks for the answers guys,
>>
>> Summing up, because the language is more restricted (doesn't have a lot
>> of the Java kitchen sink semantics for example) the type system can more
>> precisely describe what's going on in the program...
>>
>> Meaning that when you are type checking, it is a much more precise test
>> of the program's internal consistency, leading to more robustness.
>>
>> i have been reading the Idris book, would be interested whether anyone
>> has any comparisons on using coding dependently typed languages vs Elm or
>> whatever.
>>
>> It must become overkill eventually! But I like how Idris feels so far,
>> and I like the extra inference features you get from the extra type
>> precision too...
>>
>> Zachary Kessin <zkes...@gmail.com> schrieb am Mi., 25. Mai 2016 04:13:
>>
>>> A major issue is the "Maybe". In Java a type can be null so you always
>>> have to check for that. WHile in Elm there is difference between "Maybe
>>> User" and "User". So the type system will prevent any form of null pointer
>>> exception.
>>>
>>> Zach
>>> ᐧ
>>>
>>> On Tue, May 24, 2016 at 10:06 PM, Joey Eremondi <joey.eremo...@gmail.com
>>> > wrote:
>>>
>>>> Are you interested in the actual type checking algorithms, or just the
>>>> type systems?
>>>>
>>>> Big differences of the type systems:
>>>>
>>>> * Elm has tagged union types, meaning that you can make a value that
>>>> many have one of many types, and pattern match on its possible variants.
>>>>
>>>> * Elm has type inference, Java does not. When you declare a variable in
>>>> Java, you need to know what type it is. There's no such need in Elm.
>>>>
>>>> * Elm has first-class functions, so variables can have type a -> b, and
>>>> you can build arbitrarily complicated types using function types, put them
>>>> in tuples, etc.
>>>>
>>>> * Java has classes, subtyping, inheritance, etc. Elm doesn't have that,
>>>> because subtyping gets in the way of inference, and because it's not nearly
>>>> as necessary when you don't have mutable data.
>>>>
>>>> There are many other differences between the languages, but they're not
>>>> necessarily differences in the type system. For example, Java has mutable
>>>> variables and Elm does not, but there are strongly typed functional
>>>> languages, like ML, which have mutable variables.
>>>>
>>>> As for the actual typechecking algorithms, Elm uses something like 
>>>> Algorithm
>>>> W
>>>> <https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system#Algorithm_W>,
>>>> but a more advanced, constraint-based version which helps with speed and
>>>> can actually accept a few more programs.
>>>>  Typechecking is based on unification.
>>>> I can't speak too much about Java, but I imagine they're using
>>>> something like abstract interpretation to typecheck.
>>>>
>>>> On Tue, May 24, 2016 at 10:49 AM, John Orford <john.orf...@gmail.com>
>>>> wrote:
>>>>
>>>>> Can someone /wittily/ sum up the experience of type checking in Java
>>>>> vs something pure like Elm?
>>>>>
>>>>> I feel purity, preciseness and descriptiveness is the main difference
>>>>> somehow...
>>>>>
>>>>> Java is too long in the distant past for me, but it's something I love
>>>>> about Elm and never really cared for in languages like Java etc.
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Elm Discuss"

Re: [elm-discuss] Re: Elm-Material Collaboration

[John Orford]

+1

On Wed, 15 Jun 2016 at 19:00 Joe Terry  wrote:

> I am looking forward to working with your
> *elm-mdl *
>
>
> It is very well thought out and managed. You are obviously an experienced
> and prepared OSS manager.
>
>
> On Friday, April 1, 2016 at 2:51:56 PM UTC-7, debois wrote:
>>
>> Happy to see you're making progress!
>>
>> Most components in the elm-mdl library—including Layout—has some form of
>> state, and so requires you to save that state in your model and forward
>> actions to component update functions.
>>
>> Writing out all that stuff in Elm is very verbose, I know, but to the
>> best of my knowledge, nobody has found a good way to remove the boilerplate
>> so far. I'm working on finding a way to reduce the boilerplate as much as
>> possible, but it'll be a couple of weeks before a new release of the
>> package comes out.
>>
>> Hope this helps,
>>
>> Søren
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Static Tzpe Checking in Elm vs Java

[John Orford]

Can someone /wittily/ sum up the experience of type checking in Java vs
something pure like Elm?

I feel purity, preciseness and descriptiveness is the main difference
somehow...

Java is too long in the distant past for me, but it's something I love
about Elm and never really cared for in languages like Java etc.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Trying to understand the community overlap between Elm and Elixir

[John Orford]

> Elm on the backend is ultimately the way to go.

A little tangential - have you seen this?

http://noisycode.com/blog/2016/06/27/introducing-mlfe/

On Mon, 18 Jul 2016 at 18:15 Rex van der Spuy  wrote:

>
>
>> Can someone help clarify why Elixir is appealing to Elm developers
>> specifically (as opposed to Elixir being appealing on its own merits)?
>>
>
> Actually, Elm is appealing to Elixir developers, not the other way around
> ;)
> A lot of the talk you see around Elixer in Elm's discussion forums seems
> to be from Elixer developers who have found Elm to be a useful front-end
> solution.
> Elm on the backend is ultimately the way to go.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: elm first impressions (and frustrations)

[John Orford]

> Just imagine a workflow where you change one model working in the front
end and the compiler throws and error that the back-end does not implement
what you need.

+1

On Mon, 1 Aug 2016 at 09:57 Peter Damoc  wrote:

> Zach,
>
> Of course being backend agnostic is an amazing thing.
> That being said, I would love to have a backend that could be implemented
> in Elm and one full-stack solution that has perfect impedance match.
> This way, the data models can be shared between the backend and the
> front-end and with a little bit of convention, the whole Json encoding and
> decoding could disappear (it could be handled automatically by some
> library).
> Just imagine a workflow where you change one model working in the front
> end and the compiler throws and error that the back-end does not implement
> what you need.
> A user learning Elm for the front-end could also leverage his/her
> knowledge to move from front-end to full-stack.
> This could be huge for freelance lone developers.
>
>
>
>
> On Mon, Aug 1, 2016 at 10:32 AM, Zachary Kessin  wrote:
>
>> I think that being backend agnostic was / is a good choice. When I
>> started SquareTarget http://squaretarget.rocks I was able to reach for
>> Erlang/OTP and WebMachine on the backend, which is a stack that I know well
>> and I know how it performs under stress etc. Others have used Ruby, Elixir
>> or Haskell. While getting the benefits of Elm on the frontend.
>>
>> As for having to context switch between erlang and elm. That is an issue,
>> on the plus side, the Elm Architecture and an Erlang gen_server are pretty
>> similar in how they do things. But the two languages are quite frankly very
>> different, in that they were both built to solve a problem, but two very
>> different problems. Elm wants to catch all errors in the type system.
>> Erlang was built on the assuption that there are some errors that can only
>> be caught in real time and in an external process such as a server hardware
>> failure.
>>
>> Honestly, I think the actual problems being solved by frontend code and
>> backend code make the idea of a whole stack language not a really good one.
>>
>> Zach
>>
>>
>>
>>
>>
>>
>> ᐧ
>>
>> On Mon, Aug 1, 2016 at 9:06 AM, Peter Damoc  wrote:
>>
>>> Hi Neil,
>>>
>>> Few comments on the issues you've raised:
>>>
>>> 1. Elm plans to go to the server side too. There are already
>>> proof-of-concept that allows one to use Elm server-side and with the advent
>>> of 0.18 (next version) we might see official support for that. Also, one
>>> could use something like Horizon and bypass the server-side completely.
>>> 2. Actually, people who had success introducing Elm into production
>>> started within a very small corner of the app and gradually implemented
>>> more and more in Elm. You can read the latest blog post
>>>  that talks more about
>>> this.
>>> 3. What would qualify as a moderately complex example? To me, ToDoMVC is
>>> moderately complex. Also, you could find more moderately complex stuff   on
>>> builtwithelm.co
>>> 4. Interop from JS to Elm is beautifully simple through the mechanism of
>>> ports. Basically you can push messages into the Elm app. Of course, Elm
>>> does not allow direct state mutation of its program because that would
>>> defeat some of its purpose.
>>> 5. There was a proof of concept for a native version of Elm via
>>> react-native but you are right, there is no native-app framework in Elm
>>> yet.
>>> 6. redux was inspired by Elm Architecture so... if you use that, you are
>>> already getting closer to Elm.
>>>
>>> Elm is not ready for the early-majority yet, I'm not sure it is really
>>> in the realm of the early adopter either. Most of us here might be
>>> innovators and there are a set of advantages that come with that but also
>>> disadvantages. :)
>>>
>>> So, if you're looking for a full-stack battle proven solution, you have
>>> come to the wrong place.
>>> If you are looking for something to take some of the pain of web
>>> development away, you might be in the right place.
>>>
>>>
>>>
>>>
>>> On Mon, Aug 1, 2016 at 8:25 AM, nrser  wrote:
>>>
 thanks dude.

 i read a considerable amount more before going sleep last night...
 checked out the compiler repo (which has a much more clear description of
 elm - "Elm is a type inferred, functional reactive language that compiles
 to HTML, CSS, and JavaScript.") and played around with trying to compile
 something i could use from js (didn't seem possible).

 i think the conceptual architecture is fantastic. i've been down the
 road you talk about... managed large products with javascript /
 actionscript UI front ends... the state management was a disaster. constant
 source of bugs, which at the scale we were operating translated into very
 serious amounts of lost time and money.

 the canonical 

Re: [elm-discuss] What concepts and models did you had to learn in order to be able to write good Elm code?

[John Orford]

the two themes I learned were:

simplicity & accuracy

simplicity: fewer concepts to learn than most languages

accuracy: following on from simplicity, lack of 'features' to shoot
yourself in the foot, leads to type checking and guarantee goodness

On Thu, 11 Aug 2016 at 16:59 Leroy Campbell  wrote:

> I'd say learning how to make illegal states unrepresentable.
>
> https://vimeo.com/162036084
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: [ANN] elm-mdl 7.0.0 — supports all components of Material Design Lite

[John Orford]

Wow!

On Thu, 4 Aug 2016 at 07:15 Max Goldstein  wrote:

> Seeing so many people adopt and contribute to this package is at least as
> impressive as the code itself! Great job!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] How would you generalise Elm?

[John Orford]

even values are functions (if we squint hard enough and think about church
numerals etc. : )

so I would just amend, "everything's" a type or a function

On Tue, 12 Jul 2016 at 12:26 Peter Damoc  wrote:

> I think you can reuse Haskell's generalization: "everything is a function"
>
> In my mind, with Elm, "everything is either a value or a function." :)
>
> On Tue, Jul 12, 2016 at 1:13 PM, Galfarragem 
> wrote:
>
>> Using the mental model "everything is a" [1] as a way to generalise
>> something how would you define Elm?
>>
>> [1] - http://c2.com/cgi/wiki?EverythingIsa
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Czaplicki on Elixir Fountain

[John Orford]

at the end Elm mentions the technical similarity between Elm & Erlang -
pity they didn't talk more about that...

On Tue, 12 Jul 2016 at 13:48 Luis Arias <kaa...@gmail.com> wrote:

> Nice!  Thanks!
>
> On Mon, Jul 11, 2016 at 9:05 PM, John Orford <john.orf...@gmail.com>
> wrote:
>
>> Great interview
>>
>>
>> https://soundcloud.com/elixirfountain/elixir-fountain-evan-czaplicki-2016-07-11
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Luis Arias
> +33 6 14 20 87 93
> instagram: @kaaloo
> "Think like a fundamentalist but code like a hacker" - @headinthebox
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Trying to understand the community overlap between Elm and Elixir

[John Orford]

My feeling is that their conception was at about the same time and had
broadly the same goals.

I.e. make complicated programs sane.

On top of that, I see the adopters being similar.

Those who are looking for a better way and open to new ideas.

I agree with you.

Elm has many nice features that Elixir does not. Until we can run Elm on
the BEAM Elixir is probably the way to go server-side : )

On Sun, 17 Jul 2016 at 15:56 Charlie Koster  wrote:

> For those of you who learned Elm before learning Elixir can you describe
> the appeal of Elixir from an Elm dev standpoint? I'm having trouble finding
> appealing similarities between the two.
>
> While there are some similarities to be found, Elixir doesn't appear to
> have a lot of what makes Elm great. For example, Elixir is dynamically
> typed, uses impure functions, has try-catch, and has other language
> constructs that remind me why I prefer Elm over Javascript.
>
> Can someone help clarify why Elixir is appealing to Elm developers
> specifically (as opposed to Elixir being appealing on its own merits)?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Czaplicki on Elixir Fountain

[John Orford]

Great interview

https://soundcloud.com/elixirfountain/elixir-fountain-evan-czaplicki-2016-07-11

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: elm news

[John Orford]

yup really nice - well done, and thank you

On Wed, 29 Jun 2016 at 11:16 Robert Walter 
wrote:

> Instant bookmark ;) thanks!
>
>
> On Wednesday, June 29, 2016 at 1:16:04 AM UTC+2, Jacob Oakes wrote:
>>
>> I just wanted to share a project that I have been working on called elm
>> news. It allows you to see everything happening in the elm community from
>> elm-discuss, elm-dev, reddit, and hacker news all in one place. If you are
>> interested you can find it at https://oakesja.github.io/elm-news/
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] An Evidence-Oriented Programming approach to designingElm

[John Orford]

there's a podcast about this

https://www.functionalgeekery.com/episode-56-garrett-smith/

On Fri, 8 Jul 2016 at 21:34 Raoul Duke  wrote:

> See ppig.org
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] What languages do you write your back-ends in?

[John Orford]

what libs do you use to that? how idiomatic is it in the end?

On Sun, 11 Sep 2016 at 20:55 Eric G  wrote:

> Python at the moment (on Google App Engine), increasingly written in a
> Elm-y/monadic style ;)
>
>
> On Sunday, September 11, 2016 at 12:36:03 PM UTC-4, John Mayer wrote:
>
>> I'll buck the trend and share that I'm happily using Java 8 as my
>> backend. I use protocol buffers over websockets to communicate.
>>
>> https://github.com/jmpspace/jmpspace
>>
>> https://github.com/johnpmayer/elm-protoc
>>
> On Sep 10, 2016 3:41 AM, "Mario Sangiorgio"  wrote:
>>
> Hello,
>>>
>>> I was wondering what programming language you use to implement the
>>> back-end for your Elm single page web app.
>>>
>>> Reading around I see that the Elm/Elixir combo is popular but for how
>>> much I think BEAM is an awesome VM I'm a bit sceptical due to Elixir being
>>> a dynamic language. How much do you miss the compiler when you write Elixir
>>> code?
>>>
>>> If you're not using Elixir, to what do you use? I played a bit with F#
>>> (using Suave.io) and I think it's quite nice.
>>>
>>> Now I'm in the mood of learning something new so I'd like to know what
>>> you use and maybe get an idea of what to look at next.
>>>
>>> Mario
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Elm Discuss" group.
>>>
>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to elm-discuss...@googlegroups.com.
>>
>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Any tricks for debugging?

[John Orford]

any ballpark guesses on when 0.18 will happen? before the end of the year
perhaps?

On Thu, 15 Sep 2016 at 21:37 Zinggi  wrote:

> You could wait some time on the 0.18 release which will most likely bring
> back the time traveling debugger, with object introspection.
> This is much more comfortable than Debug.log.
>
> For now, you could use this library
>  which
> also works quite nicely. (except if you have many messages per second, e.g.
> for game/animation things)
>
> Debug.log covers all the the other cases. However, if I wanted to print
> all messages, I'd do it like this:
>
> update msg model =
> case Debug.log "Msg" msg of
> Foo -> ...
>
>
> On Thursday, 15 September 2016 12:24:46 UTC+2, Rupert Smith wrote:
>>
>> I am finding it useful to know which Msgs are being triggered through my
>> update functions, so have been putting in code like this:
>>
>> log =
>> Debug.log "myModule"
>>
>> ...
>>
>> Add ->
>> let d = log "add" in
>>...
>>
>> Now I have decided it would be easier to just print all Msgs rather than
>> add this to specific ones:
>>
>> debug : a -> a
>> debug a =
>> Debug.log "myModule" a
>>
>>
>> update : Msg -> Model -> ( Model, Cmd Msg )
>> update action model =
>> update' (debug action) model
>> -- OR even update' (debug action) (debug model)
>>
>> update' : Msg -> Model -> ( Model, Cmd Msg )
>>
>> And am considering pulling up the 'debug' function into its own module,
>> so I can easily globally turn on/off debug tracing by switching it between
>> the identity function or the logging function.
>>
>> Just wondering if anyone has any helpfull debugging tricks they like to
>> use with Elm?
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Functional programming, or why should I use Elm instead of vanilla javaScript?

[John Orford]

what's the betting, typescript3 implements immutable data structures, and
everyone will be cooing about them (like they are know with non-nullable
types ; ) imo, immutability is the biggest missing feature in js...

On Fri, 7 Oct 2016 at 00:06 Zinggi  wrote:

> > And all this stuff about immutability, can be easily achieved in plain
> javaScript.
>
> You claim that you can achieve all the the things that elm does by being
> disciplined enough, but that's not true. Here are a few things that only
> elm can provide that JavaScript can't.
> These things are only possible because of elms limitations:
>
>   - Easy serialization/deserialization of application state *including
> state from external libraries*
>   - *Enforced semantic versioning* for all packages
>   - A sane package ecosystem
>   - A time traveling debugger *that works no matter what code you write
> or libraries you use*
>   - *No runtime exceptions*
>
> So by removing a bunch of features from JavaScript, namely mutable
> variables and arbitrary side effects, elm can provide all the above.
>
> On Wednesday, 5 October 2016 19:50:52 UTC+2, Sarkis Arutiunian wrote:
>
> Recently I read article about Functional programming, all 5 parts
> .
> Yes it's pretty interesting article, written in interesting way. And I
> really like pattern of 'functional programming', immutability and etc.
>
>
> But there is a question. Where the line between propriety and paranoia?
>
>
> I prefer use native javaScript for everything where I can do it without
> any libraries. Yes exactly you should use some UI libraries like React and
> some module bundler like webpack. But I think propriety of using this tools
> is obvious. It's better to use JSX then use native js to create DOM or it's
> better to use webpack at least to uglify and optimize your code because
> some things just impossible to achieve without webpack.
>
> And we have absolutely opposite situation with Elm. Yes they have some
> features to make function a little bit shorter than you'll do it in vanilla
> javaScript and only in some case. It's not that difference like create
> nodes with JSX or js.
>
>
> And all this stuff about immutability, can be easily achieved in plain
> javaScript. Eventually is Elm code will be converted to plain javaScript
> and not vice versa, so that's mean you can do all that stuff in javaScript
> but for sure there are some features in javaScript which you can't do in
> Elm. And using Elm you are limited with one pattern. And what if it's not
> enough or it's not best solution in some case, what than? For example right
> now I'm working on new CMS for one of my projects, on React/GraphQL/Nodejs
> and hybrid storage MongoDb with mySQL. I would like to use this pattern in
> some cases but I just can't use it everywhere, so that's mean I shouldn't
> use Elm?
>
>
> Don't think that I'm against to Elm. I just want to see opinion of others.
> And I want to see that line, between propriety and paranoia.
>
>
> Thanks.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] No Runtime Exceptions - Still not computing

[John Orford]

+1 Peter

Elm forces you to explicitly handle failures - whereas you in many other
languages the use of exception handling is optional.

this freaks some people out, because it's so deeply baked in, that they can
miss it's there at all : )

On Fri, 7 Oct 2016 at 09:32 Peter Damoc  wrote:

> On Fri, Oct 7, 2016 at 5:13 AM, Dave Ford  wrote:
>
> So, based on my understanding, the whole "no runtime exceptions" concept
> is just not computing.
>
> But I am new to Elm. Surely I am misunderstanding something. Please tell
> me what I am missing.
>
>
> Programs will always have code that could rise "exceptions" or errors.
> A runtime exception is a kind of exception that bubbled up to the surface
> and causes the application to either crash or end up in an unstable state.
> No one wants these kind of exceptions.
>
> No, back to you example.
> It is very useful that you said that  "It's kind of like having two
> returns" because that is a GoodThing™!
> Elm makes this explicit.
> In Elm, in those cases, you return a type that can have 2 kinds of values:
> a success value and a failure value.
> You can either return a Maybe (a simpler type where on failure you just
> say that it failed) OR you can return Result (a more sophisticated type
> where failure has its own informative type).
>
> You will have to handle ALL these failure values, even if it is just to
> silence them by unpacking the Result or Maybe using a default value
> (Result.withDefault and Maybe.withDefault).
> This means that there is no exception that will bubble up unhandled at
> runtime and crash your app.
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Elm, Objects and Components

[John Orford]

(I found MDL web components to be pretty hit and miss when used with Elm -
perhaps that's changed since 0.16 - would love to hear more on this topic)


On Tue, 20 Sep 2016 at 10:21 Richard Feldman 
wrote:

>  Or you can define a Web Component
>>>  like
>>>  and then call node "myRadioButton" to create one. No
>>> C++ involved.
>>>
>>> What's wrong with that?
>>>
>>> Nothing.
>> If Elm provides an official way to use TEA in order to implement Custom
>> Elements the discussions around Components will go away.
>> If someone comes and says "What if I have many small components that are
>> unavoidably stateful" the answer would be, "just use
>> elm-lang/custom-element"
>>
>
> If nothing is wrong with Web Components, why not use them?
>
> There are a ton of them
>  you
> could use right now, for MDL in particular, that work right off the shelf.
>
> Why block on a hypothetical future language feature when there already
> exists a way for you to code your Elm application the way you would if that
> feature existed?
>
>> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] PSA for beginners

[John Orford]

Thanks, this was really good. Really good. Really really good!
On Tue, 20 Sep 2016 at 11:52, Peter Damoc  wrote:

> Watch Richard's talk from the elm-conf.
> https://www.youtube.com/watch?v=IcgmSRJHu_8
>
> Understanding the ideas presented there will improve your code in way that
> will make you want to cry with joy.
>
> What I think Richard is doing there is a demonstration of how to take a
> piece of brittle Carbon and turn it into Lonsdaleite.
>
> Thank you for your attention. :)
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Convincing my team that Elm isn't just going to die like CoffeeScript

[John Orford]

I think *convincing* is besides the point.

Tech comes and goes.

I would rather read through the features of Elm, and make a checklist.

Pure functions
Immutability
ADTs
Explicitness (avoiding type classes and other abstractions)
User friendliness
...

If your team buys into these features, then they should go with Elm or any
other setup with the same features.

I.e. I suppose, set out what everyone agrees is the basis of good code, and
then go from there.

Worst case, if Elm vanishes tomorrow, at least you're all on board with the
same goal of writing code in to this standard, and can code move to
PureScript or Typescript or whatever else matches in years to come.

On Mon, 7 Nov 2016 at 18:57 Rex van der Spuy  wrote:

> Just a few comments:
>
> > The one thing I'm not really sure I'm prepared to answer is how I can be
> sure that Elm isn't just another CoffeeScript or Dart, and in 2 or 3 years
> we'll have an impossible time hiring anyone > > who knows how to use it
> because everyone's going to go back to JavaScript.
>
> Don't invest in any single technology or workflow - just invest in your
> own ability to adapt quickly to constant change.
> Front-end software for the web is essentially disposable - let's embrace
> this!
> If you get a couple of years of mileage out of your front end app before
> it you need re-write it from scratch using a completely new or different
> technology, you're doing great!
> My advice is just grab the best technology you can at the moment, milk it
> for all its worth, jump to something better when it comes along - and don't
> look back.
> The path my career took over the past 25 years was: Basic, Hypercard,
> Director/Lingo, Java, Flash/AS3, JavaScript, and now Elm.
> Nothing is forever in this industry, and most things are deliriously short
> lived.
> Just relax and enjoy the ride! :)
>
> ... However!
> Until Elm reaches v.1.0 (which could be years from now, nobody knows)
> every version bump, every six months or so, results in API breaking changes
> at the language level.
> Some of those changes, like from 0.16 to 0.17 have been huge and have
> required quite a painful upgrade.
> (For example It took me 7 hours to upgrade a 3000 LOC app, making over 200
> changes. All of those 7 hours, except the last five minutes, was done blind
> just following the compiler's messages.)
> Are you prepared to invest in upgrading your entire Elm codebase with
> every version bump to keep it current?
> In that regard, although you can definitely use Elm in production, its
> still very much an experimental technology - and we are the lab rats.
> But, it says a lot for the dismal state front end web development even
> under these conditions Elm is way better than anything else out there!
>
> Regarding learning Elm:
> I'm a non-talented, slow learner who has to do everything about 10 times
> before it sinks in.
> And then I have to do it another 10 times just to make sure.
> It took me about 2 weeks of true beginner-level head-banging to get to
> grips with Elm, and another 2 weeks of tentative experimentation before I
> started being productive.
> But, the time I spent learning Elm has been paid back many times over by
> the time I've saved debugging my apps.
> Elm has unquestionably saved me **months** of debugging time.
> I've had experiences with Elm's compiler that have bordered on the
> supernatural - it's pointed me to bugs that would have taken me weeks of
> laborious mine-sweeping if I have had been using pure JS.
> And, the best part about learning Elm?
> It makes programming fun again!
>
> Regarding hiring:
> A search for companies hiring Elm programmers will turn up exactly 1: No
> Red Ink.
> There is no statistically significant demand for Elm programmers
> whatsoever.
> However, the smartest programmers in the world are all here on elm-discuss!
> Elm users self-select as top talent that you would never find in such high
> concentrations anywhere else.
> So, just post your job applications here and I'm sure you'll have dozens
> of high-quality applications.
>
>
>
>
> On Saturday, November 5, 2016 at 6:01:42 PM UTC-4, Zacqary Adam Xeper
> wrote:
>
> Hey Elmos,
>
> I've finally gotten an opportunity to pitch Elm to my fairly large dev
> team. I feel like I'm prepared to make the case for it against a lot of
> objections: i.e. how will we learn yet another programming language, do we
> really need something that never throws exceptions, etc. etc.
>
> The one thing I'm not really sure I'm prepared to answer is how I can be
> sure that Elm isn't just another CoffeeScript or Dart, and in 2 or 3 years
> we'll have an impossible time hiring anyone who knows how to use it because
> everyone's going to go back to JavaScript.
>
> How do I convince Elm skeptics that this thing is here to stay? I can do a
> great job of incorporating a small bit of Elm code into our stack to show
> how great it is, but they won't even let me merge it into prod unless I can
> make the 

[elm-discuss] Modulus Error

[John Orford]

I get an error when I try

8 % 0

In 17.1.

Is this old news?

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Modulus Error

[John Orford]

Ahh, much quicker than me : )

On Wed, 9 Nov 2016 at 19:31 Janis Voigtländer <janis.voigtlaen...@gmail.com>
wrote:

> Yes, quite old news: https://github.com/elm-lang/core/issues/590
>
> Am 09.11.2016 um 19:27 schrieb John Orford <john.orf...@gmail.com>:
>
> I get an error when I try
>
> 8 % 0
>
> In 17.1.
>
> Is this old news?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Is Elm really wrong?

[John Orford]

+1

On Wed, 9 Nov 2016 23:20 Kasey Speakman,  wrote:

> I read the article.
>
> Summary: "I expected Elm to be much more like Haskell, but it wasn't.
> Therefore, I'm exerting all my saved-up anger."
>
> Meanwhile, I'm getting actual work done in Elm.
>
> Elm's not perfect, but it's a quality of life improvement versus other
> things I've used for UI work.
>
>
> On Wednesday, November 9, 2016 at 3:27:50 PM UTC-6, Gaëtan André wrote:
>
> Hello,
>
> A bit of a bad buzz today around Elm:
> https://news.ycombinator.com/item?id=12906119
>
> As a newcomer it puzzles me. What are your opinions on it?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Update Delay

[John Orford]

I have fallen into this trap a few times,

1) I update my model

2) The View doesn't change

3) Some other action occurs

4) My view changes with the first update

My view is one step behind.

I have fixed this before a few times (been a while ago).

And rather than tinkering, I thought I would ask what the canonical
solution is.

It's a simple mistake, but suspect common also, might help others.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Is Elm really wrong?

[John Orford]

I remember hearing the creator of F# talk about their lack of type classes
too - basically he didn't /want/ the abstractions you can have in Ocaml.

On the other hand, listen to Haskell people talk about the lack of
standardisation, it's a kitchen sink of optional abstractions. And hard to
teach.

Upshot is  - *suprisingly* these languages & ideas are still left-field.

Elm is quite a radical proposition, to both beginners and functional
language veterans.

But it's one that I think has a good shot of succeeding.

On Thu, 10 Nov 2016 at 08:04 Peter Damoc  wrote:

> On Wed, Nov 9, 2016 at 11:27 PM, Gaëtan André 
> wrote:
>
> As a newcomer it puzzles me. What are your opinions on it?
>
> People look for different things in Elm. Some look for a Haskell
> replacement in the front-end domain.
> Some of these people do not spend enough time to understand *why Elm is
> not Haskell* and become frustrated.
> This frustration ends either with a silent move to another language (e.g.
> Purescript) or with a violent, bitter outburst like the referenced article.
>
> I believe Elm is not only "not wrong" but actually "very right".
> Main selling points of Elm are learnability and maintainability.
>
> In order to get there Elm provides a context where developer willpower is
> less needed for creating readable and maintainable code.
>
> It's a trade-off.
> It has less clever facilities than Haskell but this means the less people
> are puzzled by Elm code.
> A larger percentage of Elm code is readable by a person starting with the
> language.
> *This is not a trivial advantage*.
>
> We've seen this happening in the Elm community with the change from 0.16
> to 0.17.
> In 0.16 The Elm Architecture (TEA) became the prevalent way to write code
> and a very powerful but also problematic part of the language, the Signals,
> were delegated to a library (StartApp).
> This allowed for the removal of the Signals in 0.17.
> This moved pissed off the people using the power of the Signals BUT it
> made the code easier to learn and more maintainable for the large majority
> of people getting started with Elm.
>
> If Elm keeps doing this kind of stuff it will end up becoming a very
> simple language. It will be a different kind of simplicity, the simplicity
> from these quotes:
>
> "I would not give a fig for the simplicity this side of complexity, but I
> would give my life for the simplicity on the other side of complexity.” -
> Oliver Wendell Holmes
> “Simplicity is complexity resolved.” - Constantin Brancusi
>
> Python community has the Zen of Python to guide them to good code.
> Most of those ideas happen by default in Elm.
> This means that Elm beginners can create good code accidentally. :)
> *This is not a trivial advantage*.
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] why no more primes on 0.18 ?

[John Orford]

I am coming around to the make things as easy as possible for newbs
approach.

Elm is a big jump for people coming from JS, every little helps, including
removing string syntax misinterpretations.

Having said that, I suspect a total programming newcomer would find Elm
right now easier than JS...

On Wed, 19 Oct 2016 at 08:39 Martin DeMello  wrote:

> Agreed; I'll definitely miss being able to use primes in variable names!
>
> martin
>
> On Tue, Oct 18, 2016 at 6:28 PM, mbr  wrote:
>
> just learned that primes and backticks won't be on elm 0.18.
>
> What are the reason for their removal?
>
> I will miss the primes quite a bit. Am I the only one here that feels this
> way ?
>
> For instance, I would have to write headerModel___ and headerModel__
> instead of headerModel''' and headerModel''
> In the prime case I count the 'while on the underscore case I will
> compare its length.
>
> at the end of the day, I will just skip the underscore and use number like
> headerModel03 and headerModel02.
>
> And my case for backticks, I understand it will make the andThen API
> easier, but why completely remove it from the language ?
>
> I guess my main question is, What is the motivation for their removal ?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] OT: Elm Style formatting for other languages?

[John Orford]

The standard elm code style is v nice - anyone know whether you can
/similar/ styles to use with auto-formatters for other languages? I.e. very
spread out, with no aversion to adding to LOC counts : ) Commas beginning
lines etc.

Perhaps not idiomatic in Python or JS, but new good ideas rarely are : )

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Metalinguistic abstractions over databases

[John Orford]

like graphql?

On Wed, 19 Oct 2016 at 10:54 Peter Damoc  wrote:

> *The problem *
>
> I know how to implement a REST API and interrogate that API from Elm but
> that *seams very low level. *
>
> I was curious about a language abstraction that would isolate my Elm
> program from the actual database strategy.
>
> How do you approach dealing with the databases? What is your strategy?
> What options are there?
> Do you have any pointers to interesting perspective/approaches?
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] why no more primes on 0.18 ?

[John Orford]

For the record I loved using primes for the first time in Haskell - it gave
me the feeling of doing maths again, but while programming : )

I agree with your '_' point. Perhaps it should also be nixed following your
line of logic... But I love my underscore and forget variables also : /

On Sun, 23 Oct 2016 at 17:57 Bob Hutchison <hutch-li...@recursive.ca> wrote:

> On Oct 19, 2016, at 2:59 AM, John Orford <john.orf...@gmail.com> wrote:
>
> I am coming around to the make things as easy as possible for newbs
> approach.
>
> Elm is a big jump for people coming from JS, every little helps, including
> removing string syntax misinterpretations.
>
> Having said that, I suspect a total programming newcomer would find Elm
> right now easier than JS…
>
>
>
> I’ve got no problems catering to newbs either, as long as nobody forgets
> there’s non-newbs using elm too. The suggestion that model’ is less clear
> than model_ is ludicrous. Further I’d say that the set of newbs coming from
> JS who are able to get past functional programming, infix functions, types,
> and immutable data and then get confused by model' is empty. The arguments
> that there usually clearer ways of doing things other than using a prime is
> undisputedly often true, but sometimes the prime is the best way to convey
> meaning to the reader. Anecdotally, when I was first learning Haskell I
> found the prime distinctly clearer to not having it when I learned erlang
> (but, then, I absolutely was not a newb coming from JS). When showing
> Haskell to (very skilled) C and C++ programmers, using a prime when showing
> how to deal with immutability, results in an “Ah! Okay.” not confusion. And
> I *often* (as in always) use them when first writing a function because I
> don’t necessarily know how to name them better at the time, then fix the
> naming later when cleaning up. If you think primes can be abused, wait 'til
> you see what newbs come up with on their own to ’solve’ the problem. And
> yes, backticks are another thing for the newb to learn to not abuse, but
> sometimes they solve a syntactic problem very nicely.
>
> Of course this is now a done deal so my whining about catering to
> non-existent newbs is pointless.
>
>
> On Wed, 19 Oct 2016 at 08:39 Martin DeMello <martindeme...@gmail.com>
> wrote:
>
> Agreed; I'll definitely miss being able to use primes in variable names!
>
> martin
>
> On Tue, Oct 18, 2016 at 6:28 PM, mbr <markuz...@gmail.com> wrote:
>
> just learned that primes and backticks won't be on elm 0.18.
>
> What are the reason for their removal?
>
> I will miss the primes quite a bit. Am I the only one here that feels this
> way ?
>
> For instance, I would have to write headerModel___ and headerModel__
> instead of headerModel''' and headerModel''
> In the prime case I count the 'while on the underscore case I will
> compare its length.
>
> at the end of the day, I will just skip the underscore and use number like
> headerModel03 and headerModel02.
>
> And my case for backticks, I understand it will make the andThen API
> easier, but why completely remove it from the language ?
>
> I guess my main question is, What is the motivation for their removal ?
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] 2 yr. quest to learn front-end programming

[John Orford]

Doug,

I have been rereading the Evan's elm tutorial. Actually I don't think I
read it before, so it has been enjoyable.

I know Elm pretty OK, so my opinion about the tutorial is...

Elm is a bit like Mario Kart.

The basics are easy, and when you read the tutorial, you have covered a
good 90% of everything you need to know.

But those basics are also deep.

A week to learn and a life time to master.

Take your time, do every exercise in the tutorial, and you will be in great
shape.

Enjoy.

John

On Mon, 24 Oct 2016 at 18:50 Duane Johnson  wrote:

> These two might be helpful:
>
> https://www.gitbook.com/book/sporto/elm-tutorial/details
> https://johncrane.gitbooks.io/ninety-nine-elm-problems/content/
>
> On Mon, Oct 24, 2016 at 10:34 AM, douglas smith <395curra...@gmail.com>
> wrote:
>
> Hey everyone-
>
> Over the past 10 years I have causally studied various programming
> languages. For personal interest more than anything.   I have never written
> more then really basic code. I am 60 years old and over the next 2 years I
> am determined to learn enough about elm-lang to be employable as an
> entry-level coder.  It has been very enjoyable following Evans well written
> guide. I seem to be understanding and appreciating  the simplicity and
> power of functions. I think Evan and the whole elm-lang community is in an
> excellent position to bring powerful, flexible and "learn-able" tools to an
> otherwise very large and complicated JS ecosystem.  I am willing to bet
> that elm-lang skills will be in demand when I am ready. My question would
> be: What would be a good basis of knowledge -say in the first 4 to 6 months
> for me to get a grasp of?
>
>
> Thanks, Doug
>
> some homework:
> embedded elm counter in html
> https://dougie-.github.io/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] What Elm needs to move forward

[John Orford]

On the perennial CSS-in-Elm topic - I think Elm's lack in this regard
reflects a general lack of being able to do CSS in an elegant manner
(correct me if I am wrong).

I am pretty sure if there was a clear way to do CSS right generally, Elm
would've jumped on that band wagon.

Having said all that, I'd love to hear suggestions on how best to do CSS,
in an Elm context or not...

Perhaps I need to be educated : )

On Thu, 24 Nov 2016 at 09:56 Matija Srček  wrote:

> I'm having fun learning programming as a hobby and Elm is the most
> beautiful, friendly, clean and focused language that I've tried, including
> JS frameworks. I see it as a great solution for building logic and
> structure (HTML) of an app. It's true, styling (CSS) is almost completely
> absent. Elm definitely needs it's core CSS library or some official
> approach for building UI elements that is clean and optimized. For example,
> HTML library is awesome, It's easy to transition from writing regular HTML
> to writing one using Elm syntax. It would be great to have something like
> that on the styling side.
>
>
> On Thursday, November 24, 2016 at 8:31:22 AM UTC+1, Peter Damoc wrote:
>
> I beg to differ.
> There are a lot of intro talks to Elm syntax and some of them touch a
> little bit on some libraries but we are doing very poorly in addressing
> important concerns like styling, persistence or deployment.
> Of course, one might argue that this falls outside of Elm concerns but
> should it be outside of Elm's concerns?
> Are we trying to build reliable webapps or are we trying to reliably
> generate html?
>
> The domain covered by CSS is virtually unexplored in Elm. It is taken as a
> given that people will solve this on their own using previous knowledge or
> by learning CSS somewhere else.
> There are a few libraries that attempt to address this but most of them
> are bindings to CSS with a little bit of type safety thrown in and do a
> very poor job at documenting use-cases.
>
> The topic of reusable components is still in limbo.
> If someone asks me how would they do a dropdown in Elm I still don't know
> what to say (other than implement it from scratch).
> Have the sortable-table solution and the auto-complete examples been
> imitated? Do we have a large pool of reusable UI elements?
>
> The topic of build tools and end-to-end development, again... it rests on
> people reusing outside knowledge.
> There is very little documentation on producing a deliverable.
>
> Were do we want to be in 3 years time?
> How would we want Elm to have changed the webapp domain?
> What would be the less than desirable future that we might risk ending up
> in?
>
>
> On Thu, Nov 24, 2016 at 8:30 AM, Zachary Kessin  wrote:
>
> Glad you liked the blog post.
>
> I thinkw e are doing well on the intro talks and case studies part of the
> Elm story. But there are other stories to tell around elm that might appeal
> to the developer who has been doing elm already for 6 months.
>
>
> Zach
>
> On Thu, Nov 24, 2016 at 8:04 AM, Peter Damoc  wrote:
>
> I've seen a short blogpost by Zach
> http://get-finch.com/2016/11/23/what_elm_needs_to_to_move_forward.html
> and it got me curious.
>
> What do the rest of you think Elm needs to move forward faster?
> (it is already moving forward and will continue to do so but... maybe some
> things can accelerate the process.)
>
> I've seen also this comment:
>
> https://www.reddit.com/r/elm/comments/5dox3b/reddit_uses_elm_for_internal_apps/da6cyu9/?st=ivvxoob1=4476d8ec
> and I think the point made there is relevant.
>
> I think Elm needs a common story around some kind of web-framework.
>
> With one framework that multiple entities use and improve it is easier to
> build shared ground and shared knowledge and this gives the impression of
> stability and predictability. In theory, it would be easier to find
> multiple developers with the same subset of know-how.
>
> Attempting to implement such a framework would also make salient the
> issues that still remain (CSS) and will stress the tools (elm-format,
> elm-test) enough to push them forward faster.
>
> Constrains liberate.
>
> What do you think?
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss...@googlegroups.com.
>
>
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Zach Kessin
> SquareTarget 
> Twitter: @zkessin 
> Skype: zachkessin
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss...@googlegroups.com.
>
>
> For more options, visit 

Re: [elm-discuss] What Elm needs to move forward

[John Orford]

Oliver,

I understand. But... we are swimming in a sea of imperative programmers. A
lot of FP is not obviously better for them.

>From my POV, this is Elm's greatest strength and weakness.

It would be so easy to be a PureScript and corner a hardcore niche, where
'power' is everything.

Elm has a larger goal - to bring FP to the masses.

I am sure abstractions will come in good time, but they will be added
carefully with a lot of thought.

So... I totally understand, but there's not a lack of 'powerful' FP out
there, there's a lack of FP for the masses.

This is extremely challenging in all sorts of ways, and an open question of
whether it's even possible.

But this I believe is what Elm is aiming to do.

Who knows whether it will fail or not. No one really knows. I know it's
worth a shot though!

John

On Thu, 24 Nov 2016 at 11:34 Oliver Searle-Barnes  wrote:

> I'm definitely still in the process of moving my thinking into a
> functional approach (currently working through Programming Haskell and Bartosz
> Milewski 's Category Theory
> series on youtube, both recommended by other Elmers so thanks!). The lack
> of abstraction in Elm does seem like a major stumbling point at the moment,
> the problems I mentioned above are abundantly obvious for anyone that
> starts to use it (I say this with big love for Elm). I want more people to
> be able to enjoy Elm but these issues make it very difficult for beginners
> or even mid-level developers to get going quickly.
>
>
> On Thursday, 24 November 2016 11:00:36 UTC+1, Peter Damoc wrote:
>
> On Thu, Nov 24, 2016 at 11:17 AM, Oliver Searle-Barnes 
> wrote:
>
> The fact remains though that I don't feel I can offer a sound
> justification as to why it's far more complicated to do these things in
> Elm. Elm strives to be easy for users to understand, in this area it is
> decidedly more complicated than the existing alternatives.
>
>
> The class of problems you described is precisely the class of problems
> that Object Oriented Programming solves easily.
> It is the class of problems where, as a library developer, you provide and
> API and you allow the client to do multiple implementation of an interface,
> (e.g. the interface of a web-component or the interface of a debounceable
> app).
>
> Implementing something that solves this issue is non-trivial because it
> can be a source of chaos (complexity).
> Approaching the Expression Problem
>  Elm chose defer
> solving it for later implementing only a few practical facilities like
> toString (allows extension of cases without recompilation)
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Elm's SSCCEs

[John Orford]

I really loved that talk - thanks for reminding me : )

On Thu, 3 Nov 2016 at 19:30 Jacek Panasiuk <panasiuk...@gmail.com> wrote:

> I think Jamison Dance gives great concrete examples in his talk from React
> Conf https://youtu.be/txxKx_I39a8?t=9m45s
> As for JS's shortcomings... there is no shortage of those:
> https://gist.github.com/MichalZalecki/c964192f830360ce6361
>
>
> W dniu czwartek, 3 listopada 2016 10:23:29 UTC+1 użytkownik John Orford
> napisał:
>
> We all love Elm, but when talking about it with people who know only JS,
> are there any nice Simple Self Contained Correct Examples, of JS'
> shortcomings and Elm's advantages.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] 0.18 Below the Hood

[John Orford]

>  let-bound values can be given type annotations that reference type
variables from the top level

that's v thoughtful actually, I hadn't heard that before, just local
variables in any case, makes a lot of sense for tricky functions.

is this an elm specific creation or do you also see it in Haskell? (iirc,
never)

(what I wouldn't give for let-in in Python right now...)




On Tue, 15 Nov 2016 at 14:55 Max Goldstein  wrote:

> I'm personally looking forward to three longstanding bugs being fixed.
> First, recursive definitions like x = x are caught by the compiler. Second,
> a bug caching compiled forms of modules has been resolved, forcing a
> rebuild when necessary. Finally, let-bound values can be given type
> annotations that reference type variables from the top level. This makes
> certain code much more readable.
>
> 0.17 was a groundbreaking release. 0.18 is a much more polished one. It's
> true that we don't have server-side rendering yet, and the debugger UI
> needs a few tweaks, but this is forward progress and I'm happy for it.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Update Delay

[John Orford]

I have attached a simple example.

I have a model with a field called 'currentQueryTips'.

A list is filtered using the current query string, coming through an input
field.

If you run the test you will see that the view is always one step behind
the input.

In a previous iteration, I had the query filter function in the view and
everything worked well.

As I said before though, I think I did this more elegantly a few months
ago, trying to remember how...

Any help is appreciated!



On Thu, 10 Nov 2016 at 16:51 OvermindDL1 <overmind...@gmail.com> wrote:

> Not something I've ever experienced and of which should be fairly
> impossible.
>
> Do you have a simple reproduceable test-case that we can play with?
>
>
> On Thursday, November 10, 2016 at 8:43:30 AM UTC-7, John Orford wrote:
>
> I have fallen into this trap a few times,
>
> 1) I update my model
>
> 2) The View doesn't change
>
> 3) Some other action occurs
>
> 4) My view changes with the first update
>
> My view is one step behind.
>
> I have fixed this before a few times (been a while ago).
>
> And rather than tinkering, I thought I would ask what the canonical
> solution is.
>
> It's a simple mistake, but suspect common also, might help others.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Test.elm
Description: Binary data

Re: [elm-discuss] Re: Update Delay

[John Orford]

My mistake! I was querying the previous list of strings rather than the
updated one. Good exercise though, simplifying helped me find the bug
On Sun, 13 Nov 2016 at 19:48, John Orford <john.orf...@gmail.com> wrote:

> I have attached a simple example.
>
> I have a model with a field called 'currentQueryTips'.
>
> A list is filtered using the current query string, coming through an input
> field.
>
> If you run the test you will see that the view is always one step behind
> the input.
>
> In a previous iteration, I had the query filter function in the view and
> everything worked well.
>
> As I said before though, I think I did this more elegantly a few months
> ago, trying to remember how...
>
> Any help is appreciated!
>
>
>
>
> On Thu, 10 Nov 2016 at 16:51 OvermindDL1 <overmind...@gmail.com> wrote:
>
> Not something I've ever experienced and of which should be fairly
> impossible.
>
> Do you have a simple reproduceable test-case that we can play with?
>
>
> On Thursday, November 10, 2016 at 8:43:30 AM UTC-7, John Orford wrote:
>
> I have fallen into this trap a few times,
>
> 1) I update my model
>
> 2) The View doesn't change
>
> 3) Some other action occurs
>
> 4) My view changes with the first update
>
> My view is one step behind.
>
> I have fixed this before a few times (been a while ago).
>
> And rather than tinkering, I thought I would ask what the canonical
> solution is.
>
> It's a simple mistake, but suspect common also, might help others.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] 0.18 Below the Hood

[John Orford]

Can anyone add to the headline features in the blog?

*http://elm-lang.org/blog/the-perfect-bug-report
*

Just want to geek out, but too lazy to follow / look at Elm dev.

Happy Elm Day.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Elm's SSCCEs

[John Orford]

We all love Elm, but when talking about it with people who know only JS,
are there any nice Simple Self Contained Correct Examples, of JS'
shortcomings and Elm's advantages.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Good Vibes

[John Orford]

Peter, thanks for pouring bit of cold water on my positivity : ) ; )

I share your concerns, but every stack brings its own.

Official addressing of concerns is one thing, and organic bubbling up of
ideas is another.

The way I see it, Elm in Action will be released alongside Elm 1.0.

We'll have the first stab at something 'official', workable and widespread.

And following on from that there'll be small innovation or hacks on the
edges of the model and evolution into something better...



On Sun, 16 Oct 2016 at 12:48 Peter Damoc <pda...@gmail.com> wrote:

> On Sun, Oct 16, 2016 at 12:01 PM, John Orford <john.orf...@gmail.com>
> wrote:
>
> I think we are almost past humming and hawing about whether to use Elm for
> future projects. The caveats you hear about using Elm, will be ancient
> history.
>
> What is the official, recommended and documented way to do layout and
> styling in Elm?
>
> Elm is on the right road but basic front end concerns are still not
> officially addressed.
>
> So yeah, a reasonably advanced front-end developer could integrate Elm
> into their projects by using the familiar technologies (HTML+CSS+JS) and
> adding bits of solid implementations with Elm BUT, starting in Elm and
> staying in Elm is still so far into the future that I would not dare
> venture a guess as to when will that be available.
> It will happen tho, it is unavoidable. I was recently watching a talk
> about CSS4 Grid layout and realize that, at least in theory, that
> functionality could be implemented in Elm and made to work in a large
> percentage of the browsers way faster than it would take for the official
> technology to be adopted. Same with web components. :)
> Elm could be the ultimate polyfill. :)
>
> I would like to end by saying that you are not alone in perceiving Elm as
> being more far along than it actually is.
> There was this poll
> <https://twitter.com/luke_dot_js/status/777328702820671488> that shows
> that Elm users are way to optimistic about how far Elm has come.
> I think we are still in the innovation phase, well bellow the 2.5% mark.
> If someone has hard data that shows otherwise, I would love to be proven
> wrong.
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Elm Remote Meetup #3 Videos (and #4 tomorrow)

[John Orford]

I just started watching Soren's video - good stuff, keep it up - best of
luck with Daily Drip also. I subscribed to your initial Elixir videos, they
were v helpful.

On Wed, 21 Sep 2016 at 03:12 Josh Adams  wrote:

> It took me almost the entire month to actually get this done due to
> ElixirConf and ElmConf/StrangeLoop, but I published the videos from the Elm
> Remote Meetup #3.  Here they are.
>
>- Elm Remote Meetup #3, all-in-one:
>
> https://www.dailydrip.com/topics/elm-remote-meetup/drips/elm-remote-meetup-3
>- Implementing a UI Library in Elm: The Good, The Bad, The Ugly, by
>Søren Debois -
>
> https://www.dailydrip.com/topics/elm-remote-meetup/drips/implementing-a-ui-library-in-elm-the-good-the-bad-the-ugly-by-soren-debois
>- Frolic: A Desktop Tool to Learn Elm, Faster; by Mukesh Soni -
>
> https://www.dailydrip.com/topics/elm-remote-meetup/drips/frolic-a-desktop-tool-to-learn-elm-faster-by-mukesh-soni
>- Controlling a Browser with elm-webdriver, by Jose Rodriguez -
>
> https://www.dailydrip.com/topics/elm-remote-meetup/drips/controlling-a-browser-with-elm-webdriver-by-jose-rodriguez
>
> Also, don't forget that tomorrow, September 21, is the 4th Elm Remote
> Meetup: https://www.bigmarker.com/remote-meetup/Elm-Remote-Meetup-4
>
> Hope to see you there.
>
> Thanks!
>
> Josh
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Elm Test building custom generators

[John Orford]

Zach, did you find an answer for this in the end?

On Sun, 28 Aug 2016 at 11:52 Zachary Kessin  wrote:

> I am banging my head against the elm-test fuzzer API.
>
> I have a record like this
>
>
> type alias Location =
> { id : String
> , latitude : Float
> , longitude : Float
> , name : String
> }
>
> That I wish to create a fuzzer for, my first thought was to do something
> like this
>
>
>
> locationFuzzer : Fuzzer Location
> locationFuzzer =
>  Fuzz.custom
> (Random.map4 Location string.generator
>  (Random.float -90 90)
>  (Random.float -180 180)
>   string.generator)
> (\{id, latitude,longitude , name }
> -> Shrink.map Location
>(Shrink.string id)
>`Shrink.andMap`(Shrink.float latitude)
>
>`Shrink.andMap` (Shrink.float longitude)
>`Shrink.andMap` (Shrink.string name)
>)
>
> But that is not right, is there a good way to create custom fuzzers for
> complex data, it really should be pretty easy I would think
>
> Zach
>
> --
> Zach Kessin
> SquareTarget 
> Twitter: @zkessin 
> Skype: zachkessin
> ᐧ
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Good Vibes

[John Orford]

A few days ago I realised something - Elm is in a great place.

This mailing list shows how good things are.

And then yesterday I saw this very nice talk about the future of
JavaScript... Jafar Husain is an engaging speaker.

But the presentation was rounded out by this:

https://youtu.be/3pKNRgResq0?t=34m

I think we are almost past humming and hawing about whether to use Elm for
future projects. The caveats you hear about using Elm, will be ancient
history.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Ducked Inference

[John Orford]

I am in the middle of watching a video about 'ducked inference' in Ruby

https://www.youtube.com/watch?v=1l3U1X3z0CE

basically, static type checking / inference without the type annotations.

The annotations will be kept in the background for compile time check,
documentation or IDE purposes...

Any thoughts?

I like my annotations, but I also like Matz's take, foo for thought.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Ducked Inference

[John Orford]

I think Matz is taking the 'compiler as assistant' idea to a logical
conclusion.

You know, the idea that compilers/interpreters shouldn't barf at you, but
give you a helping hand to write your code, which is where Elm is at also!

The thing is, I find it hard to how how this could work well in Ruby. Even
with everything going well I suspect type aliases are an absolute must...

But I like the core principle - over-work the type checker in order to keep
the code as clean and minimal as possible.


On Wed, 30 Nov 2016 at 04:22, Max Goldstein  wrote:

It's an interesting perspective, but Matz is doing what's right for ruby.
Ruby is dynamically typed; Elm is statically typed. Ruby is mature and has
a lot of users counting on stability; Elm is pre-1.0 and has a smaller,
more adventurous user base. Granted we have upgrade guides and elm-format
to help with new releases, but it's still somewhat painful. But I'm hopeful
because 0.19 is focusing mostly on elm-package and not the language itself
(last I heard) which may mean the big breaking changes are mostly behind us.

That said, Elm likes DRY but not to a fault. It's possible to refactor code
in Ruby and, if not Elm, Haskell, that is twice and short and three times
as cryptic. Elm's annotations are helpful when programming, enforced by the
compiler, and used in documentation. It reflects the curried nature of Elm
functions. I think type annotations are great, and so do most Elm users.
They should stay exactly how they are, except perhaps for tooling to help
you fill them in.

-- 
You received this message because you are subscribed to the Google Groups
"Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Error Repository?

[John Orford]

Where do I send an, as a suggestion to improve the error message output?

I accidentally swapped the inputs of a fold lambda,

e.g.

foldr (\ a c -> ... )

instead of

 foldr (\ c a -> ... )

which started complaining about infinite types etc, rather than(in this
context at least) nudge me towards having the variables in the wrong order
(switching back and forth between languages, does this to you...)

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Emphasizing /r/elm more

[John Orford]

That struck me as well - I am going to switch my name to the real one, if I
can on Reddit...

On Wed, 4 Jan 2017 at 12:54 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> On Wednesday, January 4, 2017 at 6:51:28 AM UTC, Richard Feldman wrote:
>
> I don't think that makes /r/elm the automatic best choice, but I do think
> it makes it worth a shot.
>
>
> I like how on google groups everyone tends to use their real name. On
> reddit most people post with nicknames. It feels more professional and
> appropriate to use real names - perhaps we'll meet each other in the flesh
> at a conference or something.
>
> Will people moving to /r/elm do so using the same real name they use on
> here?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] elm-i18n: convert elm code to PO/CSV and back

[John Orford]

+1 - thanks for this

On Wed, 29 Mar 2017 at 14:04 Felix Lamouroux  wrote:

> Hi folks,
>
> I have updated the elm-i18n tool to automatically convert between elm
> source code and PO/CSV-files.
> https://github.com/iosphere/elm-i18n
>
>
> This is currently "only" a node CLI toolset, but it is already backed by
> elm at its core. In the coming days I will improve the elm code base with
> comments and better types and will probably provide it as an elm-package
> too.
>
> I would greatly appreciate your feedback. The readme also includes a list
> of advantages/disadvantages to the outlined approach, feel free to
> criticise these.
>
> Kind regards,
>
> Felix
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Systemic problem in Object Oriented languages

[John Orford]

I have minimised (almost 0% now) my use of this in JS, by using arrow
functions. Perhaps 'this' is a bad example, they're an arcane artifact...

Basically you're right, the guide isn't clear at best, wrong at worst : )

On Thu, 20 Jul 2017 at 10:52 Dave Ford  wrote:

> On Thu, Jul 20, 2017 at 4:14 AM, Peter Damoc  wrote:
>
>> "this" is associated with mutation. Elm is an immutable language.
>>
>
> I don't think that's true. I might be wrong, but I'm pretty sure that
> "this" has nothing specifically to do with mutation. I write immutable
> objects all day long in java and kotlin making use of "this" and mixing
> data and logic.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Systemic problem in Object Oriented languages

[John Orford]

It's ambiguous, I also imagine it means avoiding:

this.x = 123

But then again, why do you need 'this' in the first place? In Elm you can
access anything in scope in the module.

I suppose this is useful for accessing class stuff which isn't in your
immediate method scope... which again leads you down something like ideas
around local (object) mutable state...

Good question!

On Thu, 20 Jul 2017 at 10:15 Peter Damoc  wrote:

> "this" is associated with mutation. Elm is an immutable language.
>
> In theory, one could have immutable objects where data and logic are
> grouped together.
> The best expression I've seen so far is the FauxO system in Gary
> Bernhardt's Boundaries talk.
>
> Something like this would constitute a non-trivial expansion of the
> language and, as far as I can understand it, there are other priorities.
>
>
> On Thu, Jul 20, 2017 at 10:55 AM, Dave Ford  wrote:
>
>> There is a line from the docs that I am trying to understand: "Elm
>> encourages a strict separation of data and logic, and the ability to say
>> this is primarily used to break this separation. This is a systemic
>> problem in Object Oriented languages that Elm is purposely avoiding."
>>
>> What is the systemic problem being reference? Is it the [lack of] "separation
>> of data and logic" or "the ability to say this"?
>>
>> I have been programming in Java (an OO language) for a long time. I can
>> name dozens of systemic problems in the language. But the ability to say
>> "this" is not one of them. Nor is it the commingling of data and logic.
>>
>> Please help me to understand what the author is talking about.
>>
>> Thanks.
>>
>> Side note: "this" *is* a problem in JavaScript. But not in OO generally.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Moving on

[John Orford]

My 2c on above...

1) web components - once they're a standard they will be a must.

Perhaps they feel like a necessity now (I am sold) but they're still in a
flux, browsers support bits and pieces, some things haven't been finalised
yet.

Angular / Reacts / Vue's ad hoc implementations for their own
implementations are fine, but you get bitten when they have breaking
updates (Ng 1 -> 2 etc...).

Best to stick with the W3C when it appears.

2) Community / priority setting / BDFL

Elm is unique, it doesn't try to do everything well. Evan obviously has his
priorities and other things go by the way side. This is a strategy, and
this is how Elm will be effective.

It's right there on the home page:

> A delightful language for reliable webapps

>From my POV, Elm is almost success already, in that it has a goal, clearly
advertises it and is almost there. Roll on 1.0!

3) JS interop

This will evolve, but see above, the constraint is that Elm remains
reliable...

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Moving on

[John Orford]

ll. That's laudable. (I'm the sort of caveman that
> prefers C to C++.) But for the ecosystem, if I look at other successful
> languages, it feels like Evan needs to make clear where the boundary lies
> for what he wants absolute control over, needs to make a commitment to
> making the material inside that boundary as strong as possible, and needs
> to figure out how to be supportive of active development outside of that
> boundary. Those actions would allow people to make decisions based on facts
> rather than hopes and/or fears. It would allow more people to decide up
> front whether the Elm ecosystem is where they want to be and if it results
> in some people not coming in then it also results in fewer people leaving
> noisily or throwing around talk of forks to address issues that don't seem
> to be being addressed.
>
> Short of that, it would be great if the features called out on
> elm-lang.org got more attention. There are only four of them. Semantic
> versioning is essentially done and while JavaScript performance could
> probably be better, the benchmarks are doing well. But anytime the
> implementation can generate a runtime exception — other than stack
> overflows from halting problem issues — this is a failure of brand promise.
> And when people are banging their heads against JavaScript interop issues
> and leaving the ecosystem because of it, that makes the promises in that
> regard seem particularly hollow.
>
> People are worried and frustrated.
>
> Mark
>
> On Tue, Apr 25, 2017 at 7:17 PM, John Orford <john.orf...@gmail.com>
> wrote:
>
>> My 2c on above...
>>
>> 1) web components - once they're a standard they will be a must.
>>
>> Perhaps they feel like a necessity now (I am sold) but they're still in a
>> flux, browsers support bits and pieces, some things haven't been finalised
>> yet.
>>
>> Angular / Reacts / Vue's ad hoc implementations for their own
>> implementations are fine, but you get bitten when they have breaking
>> updates (Ng 1 -> 2 etc...).
>>
>> Best to stick with the W3C when it appears.
>>
>> 2) Community / priority setting / BDFL
>>
>> Elm is unique, it doesn't try to do everything well. Evan obviously has
>> his priorities and other things go by the way side. This is a strategy, and
>> this is how Elm will be effective.
>>
>> It's right there on the home page:
>>
>> > A delightful language for reliable webapps
>>
>> From my POV, Elm is almost success already, in that it has a goal,
>> clearly advertises it and is almost there. Roll on 1.0!
>>
>> 3) JS interop
>>
>> This will evolve, but see above, the constraint is that Elm remains
>> reliable...
>>
> --
>>
> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Moving on

[John Orford]

More info would be nice - just purely out of curiosity. If you have written
about this elsewhere, pls pt this out. Thanks.

On Mon, 24 Apr 2017 at 15:58 Juan Ibiapina  wrote:

> Good to know I'm not the only one with this feeling!
>
> On Mon, Apr 24, 2017 at 3:45 PM, Duane Johnson 
> wrote:
>
>> Hi all,
>>
>> I've decided to move on from Elm. I've only been successful in 1 of 3
>> projects. I'm now in a role where I need to make an important decision
>> regarding the transition of a codebase from Angular to something else, and
>> I don't feel like I can responsibly recommend Elm as the replacement. So I
>> need to focus my time and effort elsewhere.
>>
>> If someone could please remove me as a moderator of elm-discuss it would
>> be appreciated.
>>
>> If anyone is interested in taking the `canadaduane/typed-svg` project
>> over, I'd be happy to help transition it to willing hands.
>>
>> Thanks,
>> Duane Johnson
>> aka canadaduane
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Juan
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Announcement: (yet another) elm-gamepad

[John Orford]

nice one - I never heard about this spec before - v interesting!

On Tue, 8 Aug 2017 at 11:07 Francesco Orsenigo 
wrote:

> http://package.elm-lang.org/packages/xarvh/elm-gamepad/latest
>
> Gamepads cannot be implemented in pure Elm so I published a package and,
> in the docs, I tell the user "hey you need to manually add a port, you can
> find the code in the port/ directory".
>
> I hope this is an acceptable compromise between keeping all of Elm's
> guarantees and enabling people to share unsafe code.
> Regardless, I tried to keep the JS code at the absolute minimum and do all
> the real work in Elm.
>
> Other library features:
> * Recognises and supports W3C "standard gamepad" out of the box
> * Allows full button remapping
> * Includes function for serialising and deserialising button maps
> * Includes the TEA functions and types for bare button remapping tool
> * Has tests
> * Keeps its implementation away from the API
> * Works even on MS Edge ^_^
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] New guidelines for posting on Elm-discuss

[John Orford]

I love your work Noah and appreciate the sentiment.

But... I think elm-discuss is quite nice.

I haven't seen anything egregious, and rather free form discussion rather
than pointing people to the rule book every once in a while.

>From my POV almost everyone comes with the right attitude here.



On Fri 5. May 2017 at 03:33, Noah Hall  wrote:

> Hi folks,
>
> We've come up with some new rules for posting on elm-discuss. You can see
> them here
> .
> The goal is to have a healthier, happier mailing list, with more people
> feeling like they want to take part.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] New guidelines for posting on Elm-discuss

[John Orford]

I remember reading that post from Overmind and thinking it v odd.

Maybe I am blind or have rose coloured glasses.

Unsure whether Noah's rule book will help or hinder. But good that he cares.
On Sat 6. May 2017 at 09:01, Mark Marlow  wrote:

> John,
>
> I tend to agree that the discourse isn't a problem. However, one can't
> help but notice that there is a perception of hostility in this community,
> e.g.
>
> https://elixirforum.com/t/front-end-development-options-2017/3832/2
>
> The standard you walk past is the standard you accept, and we all need to
> take ownership of the community we're a part of.
>
> Noah, thanks for pulling this together and hope this is a first step in
> improving our community.
>
> M
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Moving on

[John Orford]

This thread is really good imho.

Uncomfortable? Perhaps. But everyone here has good intentions.

>From my POV Elm ain't your usual throw-things-at-the-wall and see what
sticks open source project, which is what makes it very very special.

And therefore perhaps the community and our BDFL need to communicate
better(?)
On Mon 1. May 2017 at 02:33, Mark Hamburg  wrote:

> On Apr 30, 2017, at 8:43 AM, Max Goldstein 
> wrote:
>
> Fourth, web components were briefly mentioned. Richard gave a talk on
> these  last year and it
> seems like everything you need already works.
>
>
> Specifically, on this, no. The virtual DOM API does not make the sort of
> specific commitments one would need in order to know that a web component
> with its own state would not get accidentally destroyed and recreated
> rather than preserved. The code that works today just happens to work
> because the virtual DOM implementation just happens to do certain things
> that just happen to work out right. An example of the sort of guarantee
> that would resolve this would be "keyed nodes always preserved keyed child
> identity on updates provided you don't assign the same key to multiple
> children". That comes with caveats about what won't work and you have to
> make sure the path is stable all the way up the DOM and not just at the
> component, but if you obey the rules, it promises that something will work
> and keep working. Html.Keyed makes no such guarantee and as I recall when I
> last looked at the code it didn't look like the implementation would be
> likely to support such a guarantee.
>
> On the broader issue, Elm is free code and it does what it does and being
> free, people have no right to ask for anything more. But similarly people
> need to figure out whether the benefit they are getting is valuable enough
> to stick around v some of the other options that have been bandied about on
> this thread such as moving to other languages or forking Elm (thereby
> essentially creating another language). The talk here does not in general
> seem focused on going elsewhere but rather on what sort of changes in
> process and policy would quell the concerns. Remember that this thread
> started with an engaged community member leaving because using Elm had lead
> him to more failures than successes. People ought to ask "is that likely to
> be the case for me as well" and the community ought to ask "how might we
> fix the things that resulted in those failures?" You are right that this
> code is being made available free by Evan (or by NoRedInk since they are
> funding his work) and as such, it's his call. But similarly, it is a call
> for everyone using Elm as to whether it is still working out or whether
> they would be better off placing their bets elsewhere.
>
> Mark
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] The Elm Discourse is Ready

[John Orford]

Great work!

On Fri, 1 Dec 2017 at 16:30 Brian Hicks  wrote:

> Hey all,
>
> The Elm Discourse is now live at https://discourse.elm-lang.org. Hosting
> has been graciously provided by discourse.org. You can log in with your
> existing Google or GitHub accounts, or an email and password of your choice.
>
> As I mentioned earlier this week, we intend to replace Google Groups with
> Discourse if everything shakes out OK. There are more details on the site:
> https://discourse.elm-lang.org/t/transition-plan-from-google-groups/20/3.
> To summarize: we'd appreciate if you could take new threads to Discourse so
> we can give it a solid run. We will likely not be able to migrate existing
> discussions, but we will retain this list in read-only mode so that
> existing discussions will not be lost. We hope existing discussions can
> continue and finish up over here so that those threads are not separated
> and hard to join later.
>
> We're going to try an experiment around discussion categories. Right now,
> we have these:
>
> 1. Learn
> 2. Request Feedback
> 3. Show and Tell
>
> The idea is to select your intention for writing the post and things
> should sort themselves out automatically. People get what they need, and we
> all communicate in a healthy way. There's a thread on the forum where we
> hashed out the design decisions for these categories. If you get stuck on
> which category a post belongs in, feel free to contact me privately however
> makes sense to you and I'll help you out. :)
>
> Thanks, and see you there.
> Brian
>
> P.S. It's completely possible to maintain an email-only interface if you
> are so inclined. Once you sign up, go to your settings (click your picture
> in the top right, then the gear icon.) From there, select "Emails" and then
> "Enable mailing list mode." That said, the web interface is much nicer than
> it is here; give it a try.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: ELM = JAVASCRIPT REINVENTED (PART 1)

[John Orford]

I think Elm is a very opinionated language - which lends itself to love &
hate : ) Which is a good thing - languages in which you can do anything and
everything are guey slimey things...

On Tue, 24 Oct 2017 at 18:36 Charles Scalfani  wrote:

> Back in the day when Java was all the rage, I used to ask 2 interview
> questions of developers:
>
>
>1. What do you love about Java?
>2. What do you hate about Java?
>
> I never cared what the answer was to #1. It turns out that they simply
> listed all of the things that people who promoted Java mentioned,
> write-once-run-anywhere, etc.
>
> It was #2 that I was really interested in. Many developers couldn't think
> of a single thing. That told me that they didn't know Java. At the time, I
> could've talked for an hour about all the things that were wrong with Java
> (and still are). Why? Because I really knew the language. And familiarity
> breeds contempt.
>
> This article feels like the answer to #1 by someone who really doesn't
> know the language yet or at least hasn't built anything real or large with
> it.
>
> Don't get me wrong I love Elm but it's not perfect (no language is).
>
> I'd hope that your articles include the good, bad and the ugly. By doing
> so, you will help more people understand if Elm is right for them in a
> balanced way.
>
>
>
> On Monday, October 23, 2017 at 11:02:11 AM UTC-7,
> tfr...@imaginarycloud.com wrote:
>>
>>
>> Hi,
>>
>> I'm a developer and founder of an agency specialised in digital product
>> development.
>>
>> This summer we've decided to do some experimentation with Elm and we'll
>> be summarising the findings in a series of two blogposts.
>>
>> Here is the first one. Comments are welcome.
>>
>> https://www.imaginarycloud.com/blog/elm-javascript-reinvented-1-overview/
>>
>> Best,
>>   TF
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: ELM = JAVASCRIPT REINVENTED (PART 1)

[John Orford]

that's v true - perhaps programmers are are too prone to idealism... but
then again, it's a perk of the job ; )

On Wed, 25 Oct 2017 at 12:14 Peter Damoc <pda...@gmail.com> wrote:

> Reality is prickly-goo and gooey-prickles
> <https://www.youtube.com/watch?v=D4vHnM8WPvU>.
>
> Elm sins by seeing reality too much from a prickly point of view.
> You can call this opinionated but if it is taken to an extreme, you get
> the symptoms typical to a prickly system, the main one being the stifling
> of creativity.
> Creative people are gooey and they don't thrive in an environment that is
> too prickly.
>
> Also, businesses need gooey stuff because they deal with reality not with
> some abstract world of ideas.
>
>
> On Wed, Oct 25, 2017 at 12:19 PM, John Orford <john.orf...@gmail.com>
> wrote:
>
>> I think Elm is a very opinionated language - which lends itself to love &
>> hate : ) Which is a good thing - languages in which you can do anything and
>> everything are guey slimey things...
>>
>> On Tue, 24 Oct 2017 at 18:36 Charles Scalfani <cscalf...@gmail.com>
>> wrote:
>>
>>> Back in the day when Java was all the rage, I used to ask 2 interview
>>> questions of developers:
>>>
>>>
>>>1. What do you love about Java?
>>>2. What do you hate about Java?
>>>
>>> I never cared what the answer was to #1. It turns out that they simply
>>> listed all of the things that people who promoted Java mentioned,
>>> write-once-run-anywhere, etc.
>>>
>>> It was #2 that I was really interested in. Many developers couldn't
>>> think of a single thing. That told me that they didn't know Java. At the
>>> time, I could've talked for an hour about all the things that were wrong
>>> with Java (and still are). Why? Because I really knew the language. And
>>> familiarity breeds contempt.
>>>
>>> This article feels like the answer to #1 by someone who really doesn't
>>> know the language yet or at least hasn't built anything real or large with
>>> it.
>>>
>>> Don't get me wrong I love Elm but it's not perfect (no language is).
>>>
>>> I'd hope that your articles include the good, bad and the ugly. By doing
>>> so, you will help more people understand if Elm is right for them in a
>>> balanced way.
>>>
>>>
>>>
>>> On Monday, October 23, 2017 at 11:02:11 AM UTC-7,
>>> tfr...@imaginarycloud.com wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I'm a developer and founder of an agency specialised in digital product
>>>> development.
>>>>
>>>> This summer we've decided to do some experimentation with Elm and we'll
>>>> be summarising the findings in a series of two blogposts.
>>>>
>>>> Here is the first one. Comments are welcome.
>>>>
>>>>
>>>> https://www.imaginarycloud.com/blog/elm-javascript-reinvented-1-overview/
>>>>
>>>> Best,
>>>>   TF
>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to elm-discuss+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.