Ana Luiza Portello Bastos anabastos

Por: Paulo Torrens
Originalmente portado no facebook em 2014-03-08

#["LÓGICA DE PROGRAMAÇÃO" É BOBAGEM, e explicarei porquê.]

Se preparem que o texto é longo.

Várias vezes chegam novatos aqui perguntando como começar, e a galera diz "estuda lógica primeiro, depois vai pra linguagem X". Vivo dizendo que é bobagem. Ontem, em particular, falei isso, e vieram várias pessoas por inbox me perguntar porquê (e uma pra me xingar, achando que falei por arrogância).

Pra facilitar, eu vou escrever uma boa explicação de porquê "lógica de programação" é furada, doa a quem doer, e postar na APDA e no fórum da EnergyLabs (para futuras referências, porque esse assunto vai voltar, ctz).

MOOCs

Self paced

How to Code - Systematic Program Design

Non self paced

Emacs packages, features, files, layers, extensions, auto-loading, require, provide, use-package… All these terms getting you confused? Let’s clear up a few things.

Files

Emacs files contains code that can be evaluated. When evaluated, the functions, macros and modes defined in that file become available to the current Emacs session. Henceforth, this will be termed as loading a file.

One major problem is to ensure that all the correct files are loaded, and in the

	const
	composeN = (...fs) => x =>
	fs.reduceRight((x, f) => f(x), x)

	, map = f => xs =>
	xs.map(f)

	, reduce = f => xs =>
	xs.reduce(f)

	The question was asked why I (as a programmer who prefers dynamic languages) don't consider static types "worth it". Here
	is a short list of what I would need from a type system for it to be truely useful to me:

	1) Full type inference. I would really prefer to be able to write:

	(defn concat-names [person]
	(assoc person :full-name (str (:first-name person)
	(:second-name person))))

	And have the compiler know that whatever type required and produced from this function was acceptible as long as the


	// example of what this code would produce => http://worms.io/pocDeclarative

	const makePlayer = () => {
	return {
	initial: {
	size: [50, 50],
	position: [10, 10],
	physics: true
	},

	const I = x => x
	const K = x => y => x
	const A = f => x => f (x)
	const T = x => f => f (x)
	const W = f => x => f (x) (x)
	const C = f => y => x => f (x) (y)
	const B = f => g => x => f (g (x))
	const S = f => g => x => f (x) (g (x))
	const S_ = f => g => x => f (g (x)) (x)
	const S2 = f => g => h => x => f (g (x)) (h (x))

	/eslint-env es6 /

	// Inspired by the paper "A tutorial on the universality and
	// expressiveness of fold" by Graham Hutton (available at
	// http://www.cs.nott.ac.uk/~gmh/fold.pdf), implementing some generic
	// list handling functions in JavaScript in terms of `fold`.

	// Personally I had an enlightnening moment when I realised the
	// beautiful interplay of cons lists and foldr during the FP101x
	// Haskell course. JavaScript's syntax doesn't make this very apparent

	/**
	* LL(1) parser. Building parsing table, part 1: First and Follow sets.
	*
	* NOTICE: see full implementation in the Syntax tool, here:
	* https://github.com/DmitrySoshnikov/syntax/blob/master/src/sets-generator.js
	*
	* by Dmitry Soshnikov <[email protected]>
	* MIT Style License
	*
	* An LL(1)-parser is a top-down, fast predictive non-recursive parser,

	/* eslint-disable new-cap */

	/**
	* Lens types.
	* ===========
	*
	* a * b = {fst: a, snd: b}
	* a + b = {index: Boolean, value: a \| b}
	*
	* Iso s t a b = forall (~>) . Profunctor (~>) => (a ~> b) -> (s ~> t)