Skip to main content

The death of the drug deal is nigh

These type of discoveries in a subtle way describe the long game on why the idea of drug prohibition is as extinct as the dodo.

You won't have to traverse dark alley ways to buy impure product trafficked from far away lands. Instead you will sit in your basement bio lab with elemental components and code together the necessary little functionality that you wish to have your host of living beasties produce for you. From heroine to vanilla, oil to alcohol.... when every one can bio synthesize what ever they want from scratch ...what need for outside suppliers?

Drug dealing will go extinct  and in it's
place will spring up a wide industry where templates for production of all kinds of inebriating or mind dulling agents will emerge....the same way maker 3D files are shared online for use in 3D printers...or modeling files are shared for rendering CGI.

As people will be able to clandestinely supply their own drugs the risk of trying to buy them illegally doesn't have to be taken nor will there be a desire to deal as you would simply share your biobug blueprints with who ever asks so that they can create their own living factories of what ever wonder their little minds can code up.

Decriminalizing all manner of drugs today has seen strong positive results in all the places it has been tried without exception. The correct path is to enable people to get access to the vice of their addiction so long as it is safe and clean and then treat their addiction. It works for alcohol...it works for cigarettes and it will work for all the other drugs (even heroine!!) and beyond the fact that this is the best way to deal with the drug underworld is the fact that soon there will be no way to stop drug production at the grass roots level once people are coding and creating their own biobugs that can make them for them.

Comments

Popular posts from this blog

On the idea of "world wide mush" resulting from "open" development models

A recent article posted in the Wall Street Journal posits that the collectivization of various types of goods or services created by the internet is long term a damaging trend for human societies.

http://online.wsj.com/article/SB10001424052748703481004574646402192953052.html

I think that the author misses truths that have been in place that show that collectivization is not a process that started with the internet but has been with us since we started inventing things.

It seems that Mr. Lanier is not properly defining the contexts under which different problems can benefit or suffer from collectivization. He speaks in general terms of the loss of the potential for creators to extract profit from their work but misses that this is and was true of human civilization since we first picked up a rock to use as a crude hammer. New things make old things obsolete and people MUST adapt to what is displaced (be it a former human performance of that task or use of an older product) so as to main…

Engineers versus Programmers

I have found as more non formally trained people enter the coding space, the quality of code that results varies in an interesting way.

The formalities of learning to code in a structured course at University involve often strong focus on "correctness" and efficiency in the form of big O representations for the algorithms created.

Much less focus tends to be placed on what I'll call practical programming, which is the type of code that engineers (note I didn't use "programmers" on purpose) must learn to write.

Programmers are what Universities create, students that can take a defined development environment and within in write an algorithm for computing some sequence or traversing a tree or encoding and decoding a string. Efficiency and invariant rules are guiding development missions. Execution time for creating the solution is often a week or more depending on the professor and their style of teaching code and giving out problems. This type of coding is devo…

Live Coding Exercises: How NOT to hire potentially Brilliant Engineers.

I've intimated this view before but, I abhor "live coding" exercises for engineering interviews and will never have them as part of any interview process I conduct. They are simply unrealistic to real world engineering in every possible way, they only test familiarity (or luck) with a tiny subset of solution methods to a specif subset of problems...that you either "nail" or get spectacularly wrong depending on who is observing you.

They are mostly entirely unfair to the candidate on top of the pressure of having a gun under them while coding, only in the most extreme cases is coding under the gun and that's just competitions where the code is far from real world engineering related...so why test for general coding ability with such tests?? Stupid.

I posit, it is significantly more effective to see examples of a candidates finished working code in the form of a project or projects they've created. How long it took some one to get some uber algorithm work…