Rahul Goma Phulore missingfaktor
| // 3D Dom viewer, copy-paste this into your console to visualise the DOM as a stack of solid blocks. | |
| // You can also minify and save it as a bookmarklet (https://www.freecodecamp.org/news/what-are-bookmarklets/) | |
| (() => { | |
| const SHOW_SIDES = false; // color sides of DOM nodes? | |
| const COLOR_SURFACE = true; // color tops of DOM nodes? | |
| const COLOR_RANDOM = false; // randomise color? | |
| const COLOR_HUE = 190; // hue in HSL (https://hslpicker.com) | |
| const MAX_ROTATION = 180; // set to 360 to rotate all the way round | |
| const THICKNESS = 20; // thickness of layers | |
| const DISTANCE = 10000; // ¯\\_(ツ)_/¯ |
This document describes the general outcome we want for users as well as a few ideas on how we should do this. It shouldn't be considered prescriptive or precise though; if we come up with better ideas along the way, we should do them instead!
Users should be able to run something like the following:
$ sbt new typelevel/serverless.g8 --branch aws/http
The idea behind program analysis is simple, right? You just want to know stuff about your program before it runs, usually because you don't want unexpected problems to arise (those are better in movies.) Then why looking at Wikipedia gives you headaches? Just so many approaches, tools, languages 🤯
In this article I would like to give a glimpse of an overarching approach to program analysis, based on ideas from abstract interpretation. My goal is not to pinpoint a specific technique, but rather show how they have common core concepts, the differences being due mostly to algorithmic challenges. In other words, static analysis have a shared goal, but it's a challenge to make them precise and performant.
Code is meant to be executed by a computer. Take the following very simple function:
fun cantulupe(x) = {
Fibers are an abstraction over sequential computation, similar to threads but at a higher level. There are two ways to think about this model: by example, and abstractly from first principles. We'll start with the example.
(credit here is very much due to Fabio Labella, whose incredible Scala World talk describes these ideas far better than I can)
Consider the following three functions
Lately I have been busy reading some new books on Domain Driven Design (DDD) and software architecture -- including a short yet eye-opening one in Python and a great one in F#. At the same time, it seems that more people in the Functional Programming world are looking at more formal approaches to modelling -- some examples here. This has brought some thought from the background of my brain about how we should model, organize, and architect software using the lessons we've learnt from functional programming.
Before moving on, let me be clear about this being just a dump of some thoughts, not always well-defined, definite
| Introduction | |
| ============ | |
| Industry statistics as a whole have failed to improve much since 1968, when software engineering and | |
| scientific management were introduced as means for resolving the "software crisis". Unfortunately | |
| abandoned projects, cost/time overruns, and bloated, buggy software still dominate the landscape. | |
| In spite of the efforts to mitigate this situation --like XP, agile, software craftsmanship or DDD-- the | |
| reality is that a usual software project stack involves an increasingly larger number of programming | |
| languages, DSLs, frameworks, systems, tools, techniques and processes, so it is a fact that the |
Zebu https://github.com/modernserf/zebu
Constraints - Crista Lopes tagide.com/blog/research/constraints
Little Languages - Jon Bentley staff.um.edu.mt/afra1/seminar/little-languages.pdf
Purpose-Built Languages - Mike Shapiro
In Haskell, if you want to create a hierarchy of types (and there will be needs at times), you use an encoding like below:
data CustomerCreatedAction = CustomerCreatedAction { ...stuff... }
data JourneyRunnerAction = JourneyRunnerAction { ...stuff... }
data Action = AC CustomerCreatedAction
| AJ JourneyRunnerAction