Episode #125 of the Stack Overflow podcast is here. We talk Tilde Club and mechanical keyboards. Listen now

Hot answers tagged

6

Two months late, but I will try to answer nevertheless. ;-) Since your rand already makes sure the numbers will be valid indices for your fruits, you don't have to use so many if cases. The rest looks OK to me, but I made some annotations in the source. import Random import Mouse -- Sometimes empty lines can improve readability. data Fruit = Apple | ...


4

Here are a few things I'd recommend changing: There's no need to store the sum of a and b. You can always compute it in the view with a + b. This simplifies the update function a lot. You can match Foo A and Foo B in update instead of a nested case. Optionally, you can destructure model into {a, b} in view. I don't have any opinion on this. Either way is ...


4

I like your code a lot more than the original! It is definitely cleaner and more obvious than the first example you gave. However, there still seems to be a process you’re repeating — get value from array, pattern match on it, update array — that you can still factor out. (The original code is guilty of this, too.) I tried to rewrite your function in a ...


3

I think the general consensus is to avoid functions in Msg constructors when possible. The one certain thing that will break is the Msg history import/export of the Elm debugger, since functions cannot be serialized. Evan included this comment in his Sortable Tables example: One of the core rules of The Elm Architecture is never put functions in your ...


3

From the functional point of view what you're doing is a bit odd as you always create a link and try to load an image, even for non-existing users. You should better query the GitHub API and change your model to something like: type alias Model = { username : String -- this is the string typed in the input box , user : Maybe User -- this is the parsed ...


3

This review comes with the caveat that I've spent a few days in total on Elm so far... Take anything I say with a pinch of salt. Firstly, some style things. posX: Int -> Int -> Int posX i n = round (33 + (15 * cos (6.28 * (toFloat(i) / toFloat(n))))) Why so many brackets? You can cut it down to this very easily posX i n = round (33 + 15 * cos (...


2

Why don't you just use the exponentiation (^) operator? Using that you can omit the recursion at all: powers : Int -> Int -> Result String (List Int) powers base limit = if base < 0 then Err "negative base" else let size = floor (logBase (toFloat base) (toFloat limit)) in Ok (List.map (\i -> base ^ i) (List.range ...


2

I didn't know there was an Elm language - your posting introduced me to it. resultComputedByAnonymousFunction = (\a b -> a + b) 4 5 When reading from a whiteboard, one has to be able to pronounce things. Apparently the correct pronunciation here would involve "lambda a b". I found this explanation a little surprising. And I suppose ( \ a b ... would ...


2

Since you're already keeping track of the <input>'s value in your model, it would be cleaner to use that as the value in your view, too. view : Model -> Html Msg view model = div [] [ div [] (List.map viewMessage model.messages) , input [ onInput Input, value model.value ] [] , button [ onClick Send ] [ text "Send" ] ...


2

I would split out the each of the style definitions into a function of their own. For instance: -- VIEW mainDivStyles : Html.Attribute Msg mainDivStyles = style [ ( "display", "flex" ) , ( "justify-content", "center" ) , ( "align-items", "center" ) , ( "flex-direction", "column" ) ] formInputStyles : Html....


1

I know little to nothing about Elm, but speaking of PHP your code is awfully duplicated. Sometimes it duplicates itself, either across different files or in the same file and also it duplicates the functionality already exists in PHP. For example, PHP can log errors for you, and not a single line of code have to be written for that. Processing input $...


Only top voted, non community-wiki answers of a minimum length are eligible