heretoo
https://gist.github.com/antirez/6ca04dd191bdb82aad9fb241013e...
My gut is telling me erlang might have tackled this.
Actually, Kent Beck, who coined the term TDD, has the following to say in his book "Test Driven Development":
"In Test-Driven Development, we Write new code only if an automated test has failed"
This implies that in TDD the test is written first.
Regardless of any definition, test-first and test-last are just two ends of a scale we can use.
Side-effects in imports are, in my opinion, unnecessary, losing some of the benefits of static analysis, running with different parameters during tests, compiling to native code (if those tools exist), slowing things down, and more.
Libraries could have an initializer function and the problem would go away.
Where "cross your fingers" is equivalent to the "warrant canary has not been revoked" when encryption is involved.
50,000 serious injuries in one year seems considerable.
Noone agrees on the definition of any of these, and they have changed over the years. Wikipedia says they are the same https://en.wikipedia.org/wiki/Programmer
> Maybe try a hallucinagen
Is there strong evidence to support this is necessary? Which great computer programmers attribute their abilities to this?
By leaky, I assume you are refering to the interop with the host platform. Overall, this seems like a benefit, simply for having access to many more libraries than would otherwise exist in Clojure(script).
> Clojure brings all the XML pain of Java dependencies
Do you mean pom.xml?
> better VM
The JVM seems extremely powerful with regards to performance and memory management, with 20+ years of backwards compatibility (mostly), and improvements still being made with GC and JIT.
I don't think it is the building, so much as the burying that needs more work, so that we know what libraries do or don't need tombstones.
To the best of my knowledge, Onyx and Cortex were both backed by companies which either needed to move onto more successful products, or in the case of Cortex, they closed up shop. It might be better to look at libraries that have stronger community support.
Onyx is an amazing library but it competes with other libraries like KafkaStreams which has community buy in, and commercial support if needed.
Cortex might be replaced with mxnet which got clojure bindings sometime in the last couple of years (see gigasquid). (Although libpython might make this redundant -- assuming language purity isn't a blocker to being pragmatic).
Others will have better examples, but here are some simple ones that are well maintained, but lets not forget that the java ecosystem is also available:
clojure clojurescript core.async mxnet integrant
Its good to remember that what might be considered "rot" in some ecosystems, is just a sign of maturity and of a library being finished. Many older libraries with no commits in years function as is, as documented.
Vigilantes make their own choices, but professionals are judged by their reputation. As I've said elsewhere, I challenge anyone, especially professionals, to tweet "I will delete your data if you don't secure it" and to add it to your resume/CV as a strength.
For completeness, would you mind answering, "what bad comes of it?"
If this were true, then a typed system couldn't exist on top of machine code and random access memory, because the existing components (i.e. CPU + random access memory) have no knowledge of the types you are speaking of.
I think the assumption is false. Types can be shoehorned onto untyped data.
To put a spin on it, maximally low-level within it's particular domain, perhaps, sitting on top of the transistors below them, sitting on top of quantum physics.
Thinking a bit further, an abstraction appears to be the mapping in both directions between two domains. That being said, the two domains themselves, are independent, and don't appear to be the abstraction.
The verb "abstract" would mean we are mapping from one domain to the other.
I think "homomorphism" is the mathematical term for what I'm describing.
What's my point? We can always go lower. :)
In a threatening situation, you solve the short term problem in order to have an opportunity to think long term, which will help to prevent these problems subsequently.
If we were talking chess, you wouldn't ignore the immediate moves of your opponent, because their idea of how the game should be played doesn't fit with your long term desire of how you want the game to turn out.
Not really an argument for saying an implementation isn't possible.