sporto

/*
This script touches each elm file
And recopiles it, then stores the time taken
*/

const r = require("ramda")
const dir = "./src/Elm"
const fs = require("fs")
const childProcess = require('child_process')
const async = require('async')

sporto

/*
This script compares timestamp of elmi files
To try getting files that take a long time to compile
But this attempt has proven very useful
*/

var fs = require("fs")
var path = require("path")

var dir = "./elm-stuff/build-artifacts/0.18.0/Versent/stax/1.0.0/";

sporto

Register Element

First you will need document-register-element

yarn add document-register-element

Add script to register elements

sporto

Exceptions are surprising

Given something like this:

proc sub(): string {.raises: [OSError].} =
    raise newException(OSError, "OS")
	...

proc main() =

sporto

class DoSomething
	def self.build(dep:)
		->(user:) {
			self.new(dep: dep, user: user).call
		}
	end

	def initialize(dep:, user:)
		@dep = dep
		@user = user

sporto

{"lastUpload":"2019-07-01T05:02:52.543Z","extensionVersion":"v3.3.1"}

sporto

This is an example reusable element I made for our application https://github.com/sporto/elm-select

My current API is not great as it requires a lot of boilerplate to hook init, state, update and view.

But in summary this library requires:

• Some configuration
• App state: Some state that the application manages e.g. currently selected thing
• Hidden state: Some state that the component cares about, that can be hidden from the app

sporto

This is an example reusable element I made for our application https://github.com/sporto/elm-select

It is an input field with auto suggestions.

This element needs three pieces of state:

• List of things to search for
• Current selected thing
• And the query the user is typing (At the moment this is in "hidden" state)

sporto

https://twitter.com/markdalgleish/status/830557687779700736

Extreme is very vague. I assume you are comparing JS vs Elm / PureScipt.

You get a lot more than purity i.e. robust, speed of development, confidence.

You give up less than you say.

Convenience: Depends on what are you used to, Haskell, PS can be have a lot of 'convenience' after you learn them. Is just different type.

sporto

http://reasonablypolymorphic.com/blog/elm-is-wrong

Haskell dev writes some Elm, concludes that the language should be avoided. Writes an article about it.

JS developer then reads and thinks, oh Elm is bad, I better stick to JS then.

We just made a huge disservice to the programming community. That article might be right in several things (how the lack of Typeclasses hurts expressiveness), but it totally missed the point of Elm.

As an industry we want to move to more robust languages. Haskell has been around for many year, but we are still mostly using mediocre programming languages. Haskell is great but it has a huge learning curve, so people don't adopt it.