possibilistic

  > Does nature tend to create forms which 
  > are easily detected by relatively simple 
  > neural networks?

Poison markings and mimicry, for sure. Furthermore, large swaths of plant life in various spectra. reply

Thanks for raising this point. It's absolutely correct, and I agree with both of you.

It still irks me when biases are so general and aimed at an entire set of people. I know I do the same internally for some populations or interest groups, but it still makes me mad when I see it done by others on the basis of race, gender, sexual preference, etc. I'm probably guilty at some level too sometimes... :/

I never played this game, but back in HS/college I recognized that it brought one of the largest shares of traffic to my video game strategy guide wiki. The RO guide underwent constant maintenence by fans, and was subject to extreme organic growth despite no manual intervention on my part. The level of curation, attention to detail, and the extent to which it was taken was fascinating--and I didn't initiate any of it.

I was always impressed by the Ragnarok community.

Sadly, memory of those days was marred when a trusted friend that was running sysops hijacked my domain name account and stole the site from under me when I was overseas. But it was a good lesson in never trusting anyone and not to under any circumstance reuse passwords. (Granted, I swear Godaddy's password reset was an idempotent no-op back then... My account changes never seemed to persist.)

Are you sure that reverse mapping is universal?

I was going to go for a few anecdotal examples of people I would decidedly consider as counter-evidence to your claim: the Dalai Lama, Mahatma Ghandi, Martin Luther King, Mother Teresa, ...

Then I realized that you're probably right. :(

Reading anecdotes like this makes me so disappointed in my gender. Why do some people marginalize other groups so eagerly?

I see so much "bro culture" in our field, and it feels inescapable. Every time I experience it, I literally cringe. I'm not even a party to being singled out; I can't imagine what it must be like to have this garbage directed at you.

The sad thing is, I used to be picked on and ostracized by these types of people. This was one of those things I assumed I was going to be getting away from back in high school by choosing computing. I thought "nerds" didn't do shit like this.

Apparently not.

I just want to wake up in the decade this is no longer an issue. That must be nice.

(Note: Posted as self-reply because original comment was too long)

I picture a website kind of like Github, or perhaps a language package index like npm's. Except this website is concerned with classification instead of code. You would see the following kinds of downloads:

  * Highly optimized, performant, pre-trained classifier models. 
    Perhaps numbering in the thousands if the site were popular. 
    You'd see a wide variety of classifiers: general ones,
    specific things like "dog breeds" and "celebrities" and "car types".

  * Common library code capable of running the models against user data.
    Available in a variety of languages. The model classifier format would 
    have to be generic enough that it can run under libraries in any 
    environment. 

There might also be downloads directed at supporting researchers. Stuff like:

  * Well put-together training data sets

  * Human-curated annotations, categorizations, ontologies, etc. 
    available as metadata that can be paired with the training sets in any 
    way desired. Not all of it may be useful for any given classifier. 

Do you know if there is already an existing "standard format" for encoding or serializing pre-trained models for the purpose of sharing and exchanging them? There are likely a few algorithm-specific serialization formats for persisting internal graphs and weights and so forth. But some of these results are left trapped entirety within the confines of the internal data structures of a particular implementation...

In any case, I'm not aware of the existence of one universal format encoding all the things. Because why would there be? What would be "standard" about it? The algorithm space is rather wide and different algorithms encode different things, so there wouldn't even be cross-cutting similarities to take advantage of. It would be like inventing a file format for "text files and PNG images and fonts together!". Arbitrary, pointless. An absurd idea.

Assume it's not pointless, though; start forming a picture of a universal data format or scheme for encoding and sharing all the possible training results irrespective of the source algorithm that produced them or the one that is required to produce the results. We can't just encode the "training result" because we've already demonstrated the complete and utter uselessness. Instead, the universal scheme would have to encode at least three things: a "language descriptor" written as an abstract machine language whose task is creating a bridge between the computer-generated "training result" and the predetermined "classification result" when a user input is provided.

    descriptor(input, perception encoding) => classification result 

Apart from the user input, everything else is encoded into our data serialization format. The "descriptor" would ordinarily have been some C or MatLab (or whatever) code. It's the part that would have told us "this picture is of a KITTEN" or "this text was written by STEPHEN KING" given all the other inputs. Now it is an encoding of an abstract circuit, state machine, or some other language grammar. Notice also how this has become entirely self-hosting.

If there other other arguments, then,

    descriptor(input, A, B, C..., perception encoding) => classification result

Where metadata concerning the purpose, names, types, ranges, and defaults for `A, B, C...` are also encoded in the data format. Classification types, ranges, etc. must also be encoded,

    classification result ∈ (class P, Q, R...)

Instead of being compiled to a reduced representation and inlined into the body of the "descriptor", they could be provided as a parameter, adding a further degree of indirection. I won't show any further notation.

To quickly summarize again: The language descriptor performs the task of parsing the model, then accepting an arbitrary input (a classification set, possible parameters, and the subject material), and ultimately yielding production of an output.

By now you've likely noticed that all of this mess isn't technically different than stuffing the executable of the classifier program itself into the serialization of the training results. You'd be correct, of course. It might seem arbitrary here, but I think I'll demonstrate a few nifty results later on. Besides, I'm not really suggesting they be contained in the same file.

To make use of these abstractions, there would need to be some client libraries (C++, Java, Python, etc.) provided that make it trivially easy to load and evaluate any of the classifiers from your own code. Since we went to the trouble of encoding the aforementioned "language descriptor" as an abstract grammar, the whole classifier (training and all) can be hosted and run from anywhere there is a client library provided, essentially making the classifier available from any language. What's more is the client libraries would not require constant updates to support new algorithm variations--it's baked into the data format, so we get the capability for free simply by swapping files.

           import pyclassifier 

           #include <classification>

           etc...


           classifier = classifiers.standardSvm()


           classifier = classifiers.load("my_novel_algorithm")


           classifier = classifiers.load("clustering_doe_et_al_09")

Another cool thing we could do is define shared sets of "classification results". Instead of defining classes and categories and whatnot on a situation-to-situation basis, perhaps we could draw from a global pool of concepts and ideas pulled from the world. We can impart stable names to as many different things and concepts as possible: classes like "CAR", "PERSON", "BOY", "DOG", "TANK", etc. -- all designed to be globally unique and robust identifiers that can continue to evolve over time without breaking our classifier algorithms. A side benefit is that all classifiers would begin to speak the same shared language. (Granted, not all classification outputs would be amenable to this. Some would. Photo seem like a great use case.)

Now, If we were to build that category database as an ontology database instead... Perhaps you could begin to semantically infer things?

          {Dexter's Lab} implies {Cartoon}

          Might we infer the person who uploaded it is a 90's kid? 

Or for a more graph topology-based, semantic kind of result,

         {Velociraptor} implies {Dinosaur}
                        implies {Predator}
                        implies {Extinct Animals}
                        implies {Seen on film} {Jurassic Park}

         Coincident occurrence with

         {Person}, -> 
         {Man}, -> 
         {Sam Neill} 

         {Sam Neill} was {Seen on film} {Jurassic Park}

         We can probably be sure that you're looking at a still from {Jurassic Park} at this point.

I'm not claiming searching the graph like that would be efficient, of course. But if you've got ontological overlap that is cheap to check, it might be fun...

The classifier ontology would be versioned, but probably very slow moving in terms of changes. It might be impractical to package the entire database with an app. With ontologies, you can plug in subsets and wire them to other ones later on,

          "AKC-STANDARD-DOG-BREEDS_CLASSES-1.0.1"

          "CARTOONS-OF-THE-90S-0.1.0"

The pre-trained classifier data can be versioned. Say that someone else did all the work of training it to recognize Bob Ross paintings or whatever.

          classifier = new Classifier("algorithm").forModel("BOB-ROSS-PAINTINGS-0.1")

          classifier.classify(new Image("http://i.imgur.com..."));

Oops, someone forgot to include happy little trees. But we can fix that,

          // Happy Little Trees edition.

          classifier = new Classifier("algorithm").forModel("BOB-ROSS-PAINTINGS-1.0")  

          classifier.classify(new Image("http://i.imgur.com..."));

          Produces results:

             95% Bob Ross
             100% Happy Little Trees
             75% Happy Little Clouds

If this kind of tooling and ecosystem existed, do you even know how much fun I could have on Reddit?

But in all seriousness, think of the practicality of reusability. Downloading and running classifiers other people trained, from the language of your choice? That's powerful and empowering. It takes the tech out of the realm of "Google playtoy" and puts it in our collective hands.

Think of the kinds of novel apps that the Average Joe programmer could develop. And if this type of thing truly got the support of the image processing crowd, I can't fathom how much improvement we'd witness on a year-to-year basis.

Does anything like this exist in your field for researchers now? If so, could it be made to be usable by laymen? (Or does it already exist for general audiences? Am I living under a rock?)

If this kind of thing doesn't exist or isn't shared, what steps could be made toward making something like this a reality? Are there critical gating pieces that need to come together first in order to make all of it work? Or conversely, do you feel strongly that something like this just isn't feasible?

Possible complications on building an "open source" set of classifiers is the deep knowledge required to contribute. And what about patents? It's my understanding that universities like to patent research (eg. SIFT), and AFAIK there must be broad coverage of of this space by the universities. That would be a major setback.

Anyway, I've rambled on far too much. If anyone managed to read all of that, please forgive me for inundating you with such a crazy, ill-informed, and long-winded diatribe. I hope I made sense.

I hope I'm not too late to your thread to ask questions. I find your field absolutely fascinating, though I've never taken my interest further than basic undergrad image processing or simple machine learning. I wish I had more time to follow all of my interests.

Anyway, this one particular gray area has been bugging me, and I've been hoping to run into a researcher or someone that has the appropriate context to clarify it for me. It's not technical question, per se.--it's a set of questions that build up to an uncertainty related to model training, reuse, and sharing. (I hope I'm asking the relevant questions...) I don't expect answers to all of this as it would take way too much of anyone's time, but maybe you can pick a few key points and discuss. I'm also really dying to get feedback on the last part as to its feasibility.

1. Do computer vision / modeling researchers typically share common training and evaluation data sets, or is it mostly kept proprietary? If good data sets do exist out in the open, do they undergo continual improvement, or are they frozen? Are these training sets typically amenable to only one type of training--ie., black box, offline vs online, etc.? Does it take a lot of practice/skill to know how much to hold back for post-training evaluation? Do you have an estimate for how much time and effort is involved in manually annotating and curating these data sets?

2. Once an algorithm is developed, does a model get trained under different parameters? Does tweaking those parameters lead to vastly different results? Are there typically distinct optima for a given classification task, or can it vary? Does the training set have a big impact on the performance of the algorithm? Which is more important, the training data or the algorithm?

3. Once models undergo offline training, are they fast to run? Is there a typical runtime complexity, or do different types of models operate significantly differently under the hood (by principle or by computational complexity)? Can you run an extremely complicated and robust model with a ton of classification outputs in sub-millisecond time on commodity hardware?

4. Can trained models be packaged and redistributed as a kind of "open source"? Are there any obvious barriers preventing this, such as the existence (or proliferation) of patents in your field? Do computer vision researchers like to share their code / results? If it's not a common practice to share code, would a large number of researchers be downright opposed to having their (patentable) algorithms and (copyrightable?) models made available to others?

5. Are trained models too complicated for the layman to use and produce good, consistent results? (For our purposes, I would consider a layman to be someone with at least some understanding of basic computer science, including exposure to data structures, algorithms, and a little bit of mathematical ability. Perhaps none of this too deep.)

6. Highly related to the last question, would there be a lot of specialized knowledge required to tweak model input parameters? Would these parameters correlate to mathematical operations? Would there be any arcane and seemingly arbitrary weights to adjust that are deeply encoded into the model itself? (Not sure if I'm far left field here or not.)

I think what I'm ultimately hitting at is that it would be freaking awesome if there were a good set of robust pre-trained classifier models available for the layman programmer. Models that continually undergo development as improvements are made to training sets, algorithms, the literature--what have you. Please tell me if this kind of thing already exists.

Anyway, I feel like I'm about to go on a long-winded talk about a technology I've been imagining. It's something along the lines of a specification that allows for the broad spectrum sharing of reusable, generic, containerized ML and classifier training results with others. In the world I envision, you would share trained models and import them just as you would code libraries.

Let me reiterate: if this sort of thing happens to exist in the wild already, please point me to it! I can think of tons of uses. :)

Note: replied to my own comment because original text was too long.

Except we are computer scientists and there is no BNF grammar (or what have you) for the language. We all know we can do better than that. I'm just shocked this omission went for so long without anyone noticing--it's a big freaking deal.

Formalization of a grammar isn't "design by committee" (and in any case, this work in particular certainly was not). Formalization sets a logical, mathematical foundation for something that has thus far been a rather back-of-the-napkin, cowboy coded, cargo cult kind of thing. Could you name all the terminals before? I couldn't.

Markdown is implemented in hundreds of places (conservative guess). Discounting marked deviations and well-known dialects, it is a nontrivial task to ascertain whether a given Markdown implementation will produce the "correct output". What is correct output? Our ability to express or ascertain that is complicated by the fact that some rather archaic perl code [1] somehow holds the dubious distinction of being the de facto standard reference point for Markdown. Perhaps it was chosen as such on account of being the first mover, but probably its because nobody else had spoken up yet. (We're playing catch up now.)

"Implementation defines the standard" is a poor substitute for formality and is the result of intellectual laziness. (Hello PHP prior to HHVM.)

How did any of us effectively communicate what we thought correct meant? I feel a lot of our consensus was arrived at by enumerating all the examples and complex edge cases we could think of. (There's an idea that'll cover all the bases, yet it still maintains the niceties of being wonderfully concise!)

A formal grammar, as it turns out, is rather usually concise by nature (at least for the types of languages we care to design). To the attentive and deliberate thinker, a grammar's rules can be beautiful. A random mental walk through a complex repeating parse tree fills the mind all at once with intracate patterns and possibility. These are structures you can truly grok. With just pen and paper, or a standard text editor, you can easily define how the edges and vertices of an arbitrarily complex, infinite graph can connect. It's really kind of special, and definitely cerebral.

So now that we have a Markdown grammar to look to, libraries now have an easy model for attaining consensus agreement. Nobody is going to force anyone to change their current implementation or preference. If you like the one you've got, that's perfectly valid state to be in. If your only objection to the new formalization is because it was named the so-called "standard grammar," it's just a name. A silly old case of primate chest pounding, at that. Great ape problems.

Despite all the drama, this spec will probably not be the final end-all, be-all of 80 character wide expression. I can picture infinitely many such grammars, each one being just a little more absurdly named than its predecessor. Nothing is stopping you from forking "standard markdown" and calling it MarkyMark or something.

I still can't believe none of us ever noticed there wasn't a grammar for this. Especially given we communicated all of it through bloated Perl code shared from a zip file.

[1] https://github.com/rtomayko/shocco/blob/master/Markdown.pl

(Sorry for the non-canonical link; I'm on my phone. Google search results mention a downloadable on Gruber's site, but I could be wrong.)

I think the fitness landscape is too complicated to justify that kind of assessment. Even with the non-universal qualifier "usually". I think a more correct statement would be to replace "usually" with "can be", and mention the possibility of it also being disadventageous or disasterous. At this point the entire statement becomes somewhat meaningless, though. Maybe it should just be "too complex to assess without a study per-ecosystem; it depends".

I'm sure someone more familiar with the research can express all of this mathematically and and confirm of deny the existance of an overall, cross-cutting model. It may even be common knowledge in evo bio/ecology/etc.

All I can mention on my phone right now is "keystone species", "s curve", and "wolf/rabbit populations". (or was it elk?) anyway, the latter search term leads to info on cyclical and highly dynamic ecologies. Check it out.

Electric vehicles are huge here in Georgia. We have state tax breaks on the purchase of EVs that make the vehicles effectively free [1] for many commuters. Anecdotally, one of my coworkers just bought a leaf because of the tax credit.

Guess who wants to stop the state EV tax credit bill? Shouldn't come as a surprise that it's the same dealer lobby [2] mentioned in the Tesla article.

1. http://cleantechnica.com/2014/02/13/1-nissan-leaf-market-atl...

2. http://m.bizjournals.com/atlanta/blog/atlantech/2014/02/bill...

It wouldn't be a constant energy algorithm though, would it? For each successive optimization iteration, you would have to expend energy. Does that energy get put back with every rewind of the clock? If so, energy is also infinite.

I wonder what the time-energy-complexity trade-offs are?

As an aside, I would gladly pay someone to walk me through the math and physics sometime. (Any grad students in Atlanta are more than welcome to take me up on that offer... I might even try Skype.)

Which is what I said, right?

HTML 4 - vendors implemented the spec incongruently and failed in their own special ways. XHTML strict - standard parsing rules with strict failure mode. HTML 5 - standard parsing rules, suggested (but not required) rendering behavior for browser uniformity, and well-defined failure behavior.

You hit the nail on the head.

HTML5 got one thing right though: standardization of the DOM failure behavior. As an implementation detail of their design, they went with "sensible recovery" for failures over stricter failure modes.

In going with the WHATWG over the W3C, we ultimately chose "easy to author, (slow to evolve) living standard" over "strictly typed yet developer extensible". I was disappointed, but it's good for some parties I suppose. (It certainly keeps the browser vendors in charge of the core tech...)

The W3C over-engineered to a fault. They had a lot of the right ideas, but were too enamored by XML and RDF.

I'm speaking more in terms of the goals the markup dialects had, irrespective of the ultimate implementation. I think we can all agree that those suffered from misguided engineering choices (bloaty XML culture).

Responsive images could have been an XHTML module with a javascript implementation. The browser vendors could catch up and provide native implementations in their own time, but that would not postpone immediate usage.

If it were done right, anyone could have defined a markup module/schema with parsing rules and scripting. The evolution of those extensions would have been pretty damned fast due to forking, quick vetting/optimization, etc. It would have been well timed with the recent javascript renaissance, if it had happened. It might have meant browser vendor independence at the level of the developer.

HTML should really have been modular with an efficient, lightweight core spec. It should have also paid lots of attention to being semantic so that others could compete with Google on search. I am still curious if that's why Google got involved in the WHATWG. I'm rambling about things I don't know about though...

This all seems horrific. Why can't HTML be properly extended to support attribute arrays or dictionaries as values? Having a value encode a DSL is so messed up. This is yet more to parse...

HTML keeps getting pulled in so many directions. I wish XHTML had won. It was modular, pluggable, extensible, and semantic. The last bit might have eventually made entering the search space easy for new competitors, too.

How comfortable is it to live in Shenzen as an expat? I spent half a year in Changsha and Shanghai as an undergrad and absolutely fell in love with the country in ways I never did for Japan. I found that feeling odd since I spent years studying Japanese and ultimately wound up teaching English in Hokkaido for a year.

I'll probably spend another two or three years stateside with my family, but ultimately I am disdainful of American materialism. I can't come to grips with the price of rent, the long commutes, and the costs associated with living here. Maybe I'm just too frugal. I grew up an only child honestly having more than I needed, and as a consequence I don't want to accumulate anything material that is just superfluous. I'd love to live in a capsule hotel with just my laptop and bike. I suppose I'm getting way off topic...

My Mandarin is pretty bad as I only studied it off and on for six months or so. Do you see a late 20-something white software engineer as being capable of making a living in Shenzhen? Or is this a pipe dream? What recommendations could you make?

Considering the importance of not crashing, both literally and figuratively, I can understand the need for that heavy of a software process. Isn't this par for the course in high CMMI [1] [2] organizations? I don't really know much about this side of engineering, but I find it fascinating.

Thanks for sharing the anecdote with us. :)

[1] http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integ...

[2] http://boeing.mediaroom.com/2011-10-26-Boeing-Huntsville-Sit...

Thanks for posting this! I like hearing about internal tooling. Is there more on the query tagging? How do you guys bubble query annotations through the stack?

I don't know if you're at liberty to discuss further, but how has it been scaling a giant Rails app? Have there been any pushes to break it up into smaller components? Ie. fast moving stuff stays Rails, core infra moves to something statically typed?

Both solve entirely different classes of problem. There are functional overlaps for small problem domains, but as your infrastructure tries to do more, you may find a need to run several distinct lightweight services backed by a variety of datastores serving focused requests.

Many of you have already seen Kovacs' comparison of nosql stores. Just throw a SQL DBMS into the decision matrix. Consider how several might work together.

http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Fowler's microservice post is a decent introduction to the microservice architecture, which is more or less what I'm describing.

http://martinfowler.com/articles/microservices.html

Granted, this probably isn't how to get the MVP out the door. But once you grow, this architecture can prevent the formation of monoliths of pain.

So we'll be writing Javascript forever?

See my reply to sibling comment.

I feel like you're being that guy. Forgive me if I come across the same way.

Why link me to the Wikipedia article or insinuate I'm pulling this out of--to put it more politely--ex culo? Given my use of notation, one might assume I am at least a little familiar with how the thermodynamic entropy functions are mathematically derived.

To be pedantic for a bit, Entropy is an abstract mathematical state function useful for the prediction of thermodynamic systems. Much like the Gibbs and Helmholtz terms, entropy has no direct qualitative basis; there are many open-ended interpretations seeking to justify what it means, which is not unlike looking for God or faeries or what have you.

Mathematically speaking, I think you got your equality / definition wrong. Which energy function do you refer to? If you are still convinced about an error on my part, you can demonstrate in classical thermodynamics that,

    S = "the inverse of available energy to do anything"

Or stats thermo, if that's how you roll. (Mine isn't that great anymore, sadly.)

I don't mean to seem rude, but what am I looking at? Is this a content management system?

I don't like that definition.

I like to consider ∆S the result of a smoothing operation over energy differentials.

You can put work into a system to reestablish an energy differential. It just necessitates obtaining that other energy differential with which to do the work.

Biological abstraction is simply not a thing. You must understand that the fundamental difference between digital logic, software, etc. and biological systems, reaction mechanisms, signaling, and the like is not simply about sorting out how the different things are connected together. The biggest differentiating factor is by far is how deeply fundamental high-order nonlinear dynamics and complexity are within biological systems. The topology is an implementation detail and isn't want causes us problems.

Consider the nature of digital logic for algorithms of a low computational complexity. There might be a simple state machine, some kind of input, and one or more terminal states. Let's reduce this even further to the level of logic gates. NOT, AND, OR, and all the like are extremely simple and trivial to calculate. As far as the physical implementation of these goes, I have to admit that my knowledge of EE is fairly poor. I know there are some rather involved mathematics. AFAIK, however, the ultimate determinate of "on" or "off" state is a thresholding function. It's really not that bad of a problem.

Now let's consider one of the lowest possible levels of what we would consider to be a biochemical system: two chemicals involved in a reaction. For our sake, we would probably make it an acid and base problem, since acid-base chemistry is prevalent in biochem and it's quite easy at the freshman level.

http://en.wikipedia.org/wiki/Chemical_equilibrium

As you can see, the treatment is a little bit more complicated than Boolean algebra. There are terms for Gibbs free energy, chemical potential, activities, solubility potentials, etc. to consider for a system sitting in some glassware. I won't get into the details, but do make note of the math. Can you think of how to compute these quickly in silico or by hand? Probably not too hard.

We're just getting started though. Things get rather noisy as we start to consider more than a few chemicals. As we trend up towards approximating an in vivo system, we also have to developing a model for interaction. To do that, we have to understand each component. At both ends, we enter into the realm of statistical thermodynamics. Here you'll encounter much more complicated models and concepts such as canonical ensembles:

http://en.wikipedia.org/wiki/Grand_canonical_ensemble

You know can't simply consider aggregate systems as pairwise interactions or summations or any other trivial model. For one, there are too many incredibly localized chemistries within solution that produce rich behaviors. For example, here's a decent figure that presents a chemical transport process: http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2980713/figure/f...

All of the familiar, easy math typically involves equilibria, and equilibria systems are nice and easy systems to study. But to be alive is to not be at equilibrium--one facet of biology is to push against that state as long as possible. Nonequilibrium systems present further computational and modeling challenges for us. http://en.wikipedia.org/wiki/Boltzmann_equation

I've presented a bunch of math, and I'm not done yet. It's known that Metabolic pathways, the interplay interacting metabolites, happen to be NP-hard. Typical of graphs, fairly orthodox. The computational complexity of the topology isn't really isn't expressive enough to convey the beauty of a graph edges themselves--that they are in constant flux, connected through a chemical calculus. Chaotic, transient metastabilities that arise and collapse. Digital bits blink, but chemicals dance.

Do you know the breadth and depth of this machine? Here's a wonderfully illustrative map of the known metabolic pathways--at a glance it'll give you an instant perspective if you didn't already have context: http://www.cc.gatech.edu/~turk/bio_sim/articles/metabolic_pa... (When observing the forest, be careful not to forget what the trees actually represent. There is unfathomable complexity to be found in the small interactions.)

It probably dawns on you now that we're not going to live to see the answers. I've only really introduced metabolites here. Gene regulation, proteins... I never even mentioned the word "cell". That's far too much.

If it doesn't make sense why bioengineering is slow-paced, then I did a poor job at conveying how hard the problem space is. Yes, we can make certain gene products and achieve simple little results that still dazzle us. It's not quick, it's leagues away from what we want, and it's definitely not abstractly or generically portable. (I don't refer to the assays/methods.)

I suspect the only way to enter into the biological renaissance requires that we get better at everything else: math, low-level logic, algorithms. I imagine we'll have to find ingenious new ways of greatly contracting the problem space, reducing dimensionality, operating over compositions of subgraphs, etc. in order to deal with computing the complicated nonlinear dynamics at interaction level. Integration into an acceptable holistic model is mind-boggling. How to do this and get meaningful results, I have no idea. Whatever far future tools that might be effectively applied to this will appear to have bent the Matrix.

Thinking of today's "big data", I can't help but feel dwarfed at a truly astronomical scale. The depth of ignorance we'll eventually have to cross in order to solve the problems presented by a single cell... it puts everything into perspective.

Sorry for the long post. I hope I illustrated that the core tendencies of electrical engineering and computer science towards simplification and logic reduction are simply not very amenable to bioengineering. You can't simply tweak one thing or edit the binary. Everything touches everything, and you can't adjust the weights and levers without understanding the ultimate runtime behavior. You already know that line from Jurassic Park about the weather...

There is already an awful in lua.

http://awesome.naquadah.org/doc/api/

Felix looks really interesting, especially with regard to the first class functional aspects, how they implemented their stack, and the user extensible grammar. I might actually find myself distracted by this instead. :)

Got a way for me to contact you? I'll cc you with a github link if/when I get around to this. Would love early design feedback. Alternatively, you can email me from the info in my profile. No worries if not interested, of course.

I hear the "different C++ subsets" meme all the time. To the best of my knowledge, this is typically cited in relation to template generics, exceptions, multiple inheritance, and RAII being used incongruently. IIRC, Google chose not to use exceptions, but this might be unrelated. (ex-googlers I know have mentioned that Google doesn't care about C++ services terminating and having to be respawned)

Your comment kind of makes me question my understanding of the different subsets issue... Would you mind elaborating? I could really stand to understand this better. If you can't expand on it, thanks for giving me something to look into. :)

I've been using C++11, and I really like it. Together with RAII it seems entirely modern and reasonable.

Is there a list somewhere that describes what the "bad parts" (in the Crockford sense) of C++ are? Bad practices, bad feature interplay, etc.

I've been thinking of writing a little C++ transpiled language of a limited feature set to make prototyping certain things easy. It would try to follow the accepted best practice conventions. I imagine it to be Coffeescript-like, with no separate header files, support abbreviated syntax, syntax for managed pointers, etc. It would probably follow a rudimentary linking scheme.

It might be opinionated in ways that turn some people off: const vars and args by default, virtual methods by default, auto virtual dtors, and probably other "sensible" (in average usages) default patterns.

Finally, I would want to generate simple intuitive interfaces that are linkable to existing C++ headers.

Anyways, this would just be a side project for fun. I don't do C++ professionally. Just for robotics and lasers and hobby stuff. Any information on best practices and bad C++ usages would be awesome to have if I undertake this.