enricopolanski

def removeCoin():
	coinlist = ["a", "b", "c", "d"]
	while True:
		print("\nThe list of coins you're currently tracking is: \n" + "\n".join(coinlist) + "\n")
		yes_or_no = input("Do you want to remove a coin from the list? (Y/N):").upper()
		
		if yes_or_no == "Y":
			try:
				coinlist.remove(input("Which coin do you want to remove?").upper())
				print("\nThe list of coins you're currently tracking is: \n" + "\n".join(coinlist) + "\n")

enricopolanski

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

module.exports = (mypath) => {
    var inputFile = fs.readFileSync(mypath, "utf8");

    var $ = cheerio.load(inputFile, {xmlMode:true});

    // defines the selector

enricopolanski

While attempting to explain JavaScript's reduce method on arrays, conceptually, I came up with the following - hopefully it's helpful; happy to tweak it if anyone has suggestions.

Intro

JavaScript Arrays have lots of built in methods on their prototype. Some of them mutate - ie, they change the underlying array in-place. Luckily, most of them do not - they instead return an entirely distinct array. Since arrays are conceptually a contiguous list of items, it helps code clarity and maintainability a lot to be able to operate on them in a "functional" way. (I'll also insist on referring to an array as a "list" - although in some languages, List is a native data type, in JS and this post, I'm referring to the concept. Everywhere I use the word "list" you can assume I'm talking about a JS Array) This means, to perform a single operation on the list as a whole ("atomically"), and to return a new list - thus making it much simpler to think about both the old list and the new one, what they contain, and

enricopolanski

Questa non è farina del mio sacco, io ho solo copia incollato la discussione. Kudos to Giulio Canti

@vncz ho un consiglio su come procedere a strutturare un programma funzionale, con me ha funzionato bene, vediamo se funziona anche per te

In linea teorica e generale procedo così

• dominio
• firma del programma
• firme delle operazioni di base

enricopolanski

A 4-Bit Virtual Machine implemented in TypeScript's type system. Capable of running a sample 'FizzBuzz' program.

Syntax emits zero JavaScript.

type RESULT = VM<
  [
    ["push", N_1],         // 1
    ["push", False],       // 2
 ["peek", _], // 3

enricopolanski

Table of Contents

• Resolving promises
• Working with the Browser
• Working with Locators
• Working with Elements
• Jasmine expect and matchers

Protractor Cheatsheet

enricopolanski

On hiring Haskellers

Recently I noticed the number of the same two questions being asked again and again on different Haskell resources. The questions were “How to get a Haskell job” and “Why is it so hard to find Haskellers?” Although these two are coming from the opposite sides of the hiring process, the answer is really just one. There is a single reason, a single core problem that causes difficulties of hiring and being hired in the Haskell community, and we should clearly articulate this problem if we want to increase the Haskell adoption.

We all know that there are many people wishing to get a Haskell job. And a visible increase of Haskell jobs looks like there should be a high demand for Haskellers. The Haskell community has also grown like crazy past years. But still, why is it so difficult to hire and to be hired? Why can’t companies just hire any single person who demonstrates a deep knowledge of Haskell in blog posts, in chats, on forums, and in talks? And why do Haskell companies avoid hirin

enricopolanski

// when T is any|unknown, Y is returned, otherwise N
type IsAnyUnknown<T, Y, N> = unknown extends T ? Y : N;
  
// when T is never, Y is returned, otherwise N
type IsNever<T, Y = true, N = false> = [T] extends [never] ? Y : N;

// empty object
type EmptyObject = { [key: string]: never };