There are a few HDL complexity factors that are defined in that paper: size nesting control flow information flow hierarchy locality regularity modularity coupling (of modules or instances) concurrency timing
nesting and information flow can to coupled to 1) nesting of words in factor, ie how far removed a word is from the primitives that make up the system 2) how many shuffle words there are
constraining the available operations makes it easier for humans to wrap their heads around what programs do. This is not a panacea, as anyone who has had to struggle with an overly complex regular expression can attest
True!
A language that resembles a Unix-style command line pipeline with a predetermined list of operators, for instance, can guarantee the resource usage of the individual operations it supplies—and thus of the entire program
or a stack-based language with a stack depth of 1, which if I'm not mistaken is equivalent to the power of a FSM, since each command would be the state transitions, poping and pushing states from the stack.
I've written tree traversals, sorts and parsers in such restricted languages - the result is always a lot of comments and at least one level of unnecessary indirection
the parsers need to consider which type of grammar its parsing. however only unrestricted grammars actually need a turing machine?
inheritance
check out class keyword in ES6
true && say("it is true") || say("it is not true")
some languages, such as C and javascript have a ternary operator
a > b ? "a is bigger" : "a is smaller";
if else then
should include case/switch statements, then add pattern-matching under functional programming
// javascript
should explain what comments are
In programming languages, when we talk about syntactical differences, we are mainly talking about superficial differences in how a programming language structures itself
this sentence could use some work
In mathematical logic,falseimpliestrue
that was unexpected
This book has video lectures at MIT opencourseware
GivensystemsAandB, we say thatA≤Bif, wheneverxis connected toyinA, thenxisconnected toyinB
but in this example, there is no x connected to y in A. However the statement was conditional:
if x is connected to y in A, then x is connected to y in B
Alice’s connectivity observation will not be compositionalwith respect to the operation of system joining
so now just because we are now joining new edges/sub-graphs to this graph, we will no longer be able to make statements of whether edge A is connected to edge B?
the less structure ispreserved by our observation of a system, the more “surprises” occur when we observeits operations
because we as humans expect the similarities to remain, but as the structure disappears, we can make incorrect assumptions, being side-blinded by the differences.
Gaining access to consistent and accurate data streams—and applying statistical analysis to that data in an appropriate manner—is difficult.
related to business analytics?
in a Six Sigma approach, but the idea or change in question goes through rigorous analysis and data testing first
how well can one predict the impact of an innovation beforehand, without beta-testing or introducing it into the market?
reduces processing time, opportunities for errors, and overall costs
removing waste, also reduces maintenance cost. Something Chuck Moore definitively mentioned more than once.
caller moods
for example lead to variations.
One anecdote is doctors being more lax with prescriptions right after lunch, and more stringy right before lunch.
Every process contains inherent variation
couldn't agree more, and if variation can allow for errors, then variation should be reduced
An organization that completely adopts a Six Sigma methodology never stops improving
what if you're working with a specification that is fixed? I suppose the implementation can be improved, and all the human processes surrounding the software as well...
The value stream is the sequence of all items, events, and people required to produce an end result
not just processes, but rather sources of value, such as resources & human capital
Sometimes, organizations have to consider the expense of an improvement
opportunity cost: we are losing this much, but to improve it would cost that much
The success of the idea is weighed after implementation;
keyword here is after
implement strategies that are based on measurement and metrics.
good! SMARTR
the yo-yo problem
ie scrolling too much (up and down, like a yo-yo)
Another issue with inheritance is that subclasses must be defined in code, which means that program users cannot add new subclasses at runtime
the underlying issue here is probably the tight coupling of data and code. users very rarely need to edit code, especially at runtime. On the other hand, users need to manipulate data all the time.
Inheritance is contrasted with object composition, where one object contains another object (or objects of one class contain objects of another class); see composition over inheritance
composition is a good idea
The relationships of objects or classes through inheritance give rise to a directed graph
yup...
Inheritance allows programmers to create classes that are built upon existing classes,[1] to specify a new implementation while maintaining the same behaviors
why would you want several implementations of the same exact same behavior unless for optimization purposes? and even that should be left to compilers for the most part
hierarchy of classes
now we need to be aware of the entire structure of a classes hierarchy; its parents, grandparents, siblings & cousins.
inheritance breaks encapsulation
makes sense
According to Allen Holub, the main problem with implementation inheritance is that it introduces unnecessary coupling
true! do not add anymore complexity that is inherent in the problem-space
Void-safe capability
comparison to maybe type?
Thus, an executable file can be compiled to either include or exclude any level of contract
this is because they're essentially assertions, not dependent types (which would be just type-checked at compile time)
Eiffel does not permit any assignment into attributes of objects
only through the use of setters, which enforce invariants
all Eiffel attributes are "protected", and "setters" are needed for client objects to modify values. An upshot of this is that "setters" can, and normally do, implement the invariants
enforce the invariants
Eiffel's control structures are strict in enforcing structured programming: every block has exactly one entry and exactly one exit
really good for decreasing cyclomatic complexity
Eiffel has five basic executable instructions: assignment, object creation, routine call, condition, and iteration
x = Object.new()
and if-else + loops
available under either an open source or a commercial license
dual license?
all at the same level
no nesting, this probably reduces cyclomatic complexity
In contrast to most curly bracket programming languages, Eiffel makes a clear distinction between expressions and instructions
expressions and statements?
Simple Concurrent Object-Oriented Programming (SCOOP)
how does it compare to actor-model?
Inheritance, including multiple inheritance, renaming, redefinition, "select", non-conforming inheritance, and other mechanisms intended to make inheritance safe.
sounds complicated
class serves as the basic unit of decomposition
class-based instead of prototype based?
Under Eiffel's design, a software text should be able to reproduce its design documentation from the text itself
literate programming?