70 karma · joined July 18, 2014
I think I've listen to asianometry (YT channel) talk about this too, but I am unable to find any clip now where he explicitly talks about interference lithography...
I found my solution superior in several ways:
- I can force an autoreload just by saving a file (no file changes needed to force an md5 diff)
- exec() doesn't suffer from the side effects of not restarting the python interpreter, clean start every time :)
- it is also quite portable and doesn't require extra dependencies like inotify/fswatch/etc. </ul>
I have seen several comments like this on this thread suggesting people are contagious during the incubation phase. Do you have a source for this? AFAIK this has not yet been confirmed, other than perhaps a few anecdotal cases.
function main () {
# all code goes here
}
mainBut startup time increases an order of magnitude once you start importing 'requests' and other common packages.
Perhaps an option to turn imports lazy...
Because "return values" in bash are implemented by echoing (printing to stdout):
return=$(my_function arg1)
I believe OP has the point that echoing friendly-parsable output is a way of implementing "data-structures" in shells. result=$(my_function arg1)
result_a=$(echo "$result" | grep A)
result_b=$(echo "$result" | grep B)At work I usually go by looking for quick solutions for the very specific problems I encounter, e.g. disable echo on a terminal, send data through a socket, ...
And what I sometimes do over the weekend is to go over the problems I had and try to learn from the subject in a more generic way. e.g. learn TTY inner workings by reading the source code of python's pty.py standard library module, read the socket's documentation and understand all available socket operations, or watch some conference talk on the subject over youtube ...
This second consolidation phase has proven very useful to me. Not only because of discovering interesting gems hidden in standard libraries and other references, but also to be able to anticipate and solve really weird/low-level bugs that otherwise would have been very difficult to approach.
The main practical drawback, I would say, is that locks may suffer from the mutual exclusion problem; where you have contention, starvation and deadlocking. Also your ability to parallelize operations over shared state quickly vanishes as the number of threads grow...
Each variable can only be updated by a single and unique thread. If another thread (or actor) wants to modify it, it has to send a modification request messages to that one thread to do the job.
That's quite a difference!
Edit: Java threading model is fine for limited amounts of concurrency. Complexity escalates quickly with highly concurrent applications; the actor model makes reasoning about those programs far easier.