Nyetan

That is definitely very interesting! Writing a parser/compiler for 'x' language tends to be a component of many interesting projects, and that's definitely a good start -- thanks :)

I've always wanted to write something like regular expressions for lists of objects. So, for example the example of writing a parser, one could use a regex to match chars to tokens, then write another that gathers tokens into blocks and etc. Essentially, bottom-up parsing without resorting to parser generators that take over everything. A similar tool would be interesting for querying trees directly.

My impression of Elm was that it's trying to create a platform for real-time interaction (e.g. games, UIs, etc.) that happens to target the browser. There's a constant undercurrent of practicality in the community: for example, new language features are regarded suspiciously, and modifications to existing behaviour are only made when they reduce the burden of complexity to the programmer. Obviously it's a language that has yet to hit 1.0 so there are occasionally large swings in its design, but apparently they've become more stable as of late (I'm only picked it up ~1 month ago).

The only unpractical part I'd noticed was its perspective on reusing components, as seen in this overview under 'Nesting' [1]. That bit of explicit routing aside, may I ask what dissuaded you from using the language seriously?

[1]: https://gist.github.com/evancz/2b2ba366cae1887fe621#nesting

Mildly off-topic, but does anyone else find it odd when people wonder what the function of a naturally evolved object is? I mean, you could ask that of a module in some code or a part in a car, but the moving bits in organisms came about through an unguided process, so don't they just do things (some of them well)?

Could you point an interested reader towards some stats :) ? I wanted to pick up Frege for a hobby project some weekend soon and would love to read more about the JVM up-and-comers.

Behold, the problem net neutrality has searched for: Bell Mobility circa 2013 [1]. For $5, you could buy either 10 hours of Bell Mobile TV™ or ~1.5 hours of Netflix (not including your subscription) [2]. Assumptions below. The story has a happy ending, in that the Canadian equivalent of the FCC wound up forcing them to change their pricing after four or five years [3]. Whoo. What's a few million dollars between friends.

Make up your own mind as to whether you want this to be your future.

Assumptions:

1 Mbit/s video streams

Data purchased in 5GB ($35) chunks. Note that, if purchased in 500 MB chunks, one can watch 15 minutes of Netflix, which is laughable and therefore not presented due to shock value.

[1]: https://web.archive.org/web/20121220034331/http://www.bell.c...?

[2]: https://web.archive.org/web/20130102055752/http://www.bell.c...

[3]:http://www.theglobeandmail.com/report-on-business/bell-denie...

Intersection ARC, Lifetimes:

* Not having to worry about trivial memory/resource allocations

ARC - Lifetimes:

* Can blow up hilariously with refcount cycles

* Incurs a runtime overhead

Lifetimes - ARC:

* For the subset of allocation patterns it handles, it does so with zero runtime overhead (i.e. invalid programs do not compile, invalid = leaks memory)

* Use extends beyond just memory allocation/deallocation (see the concurrency docs [1] for example) (note that Mozilla wrote Rust to help write Servo [2], their prototype highly-parallel browser engine, so this use case was a target from the getgo)

* Cannot encode all data structures a GC can (hence why reference counting is part of the stdlib [3])

[1]: https://doc.rust-lang.org/book/concurrency.html

[2]: https://github.com/servo/servo

[3]: https://doc.rust-lang.org/alloc/rc/

They're referring to a tracing JIT[1], I believe.

[1]:https://en.wikipedia.org/wiki/Tracing_just-in-time_compilati...

Unfortunately, as you're keenly aware, the software development industry has a tendency to attempt to reinvent itself every few years. It might stop eventually.

For the specific problem of python, consider using 2to3.py to catch most problems (it'll fix up minor API changes and the like). It might help :)

Although being pessimistic about technology is my pass time, I'd imagine that breaking backwards compatibility is not done for business purposes. Two points of data on that line of reasoning: 1. C has a number of active, popular compilers (gcc, clang and msvcc, but I haven't kept up) which keeps maintainers from individually removing _too_ much functionality -- it's typically a poor business decision to remove compatibility bullet points from your product. Python (excluding pypy since it makes the typically poor business decision to remove compatibility bullet points) and F# are single-major implementation languages, giving them a fair bit more freedom to experiment. 2. Off the top of my head, Java and C# have compatibility going back many, many years. Considering that they've huge corporate backers that would have a lot of incentive to deprecate functionality continuously, that seems a good counterexample. A point could be made regarding feature addition rather than subtraction, but similarly that applies to C++ ...

It's starting to come together :) I'll keep an eye on your repo; I'm still curious about various specifics that will likely be elaborated upon in time.

It was more of a rhetorical question, with the remaining literalness directed at the OP :) but yeah, those are fantastic examples! The Berlin Brandenburg [1] was what came to mind immediately, but you're absolutely right that history is like to be littered with other dead developments.

[1]: http://www.bloomberg.com/news/features/2015-07-23/how-berlin...

1. Aah, makes sense.

2. The similarity with openshift is due to their Marketplace [1], but it pretty much ends there. Sandstorm as well for much the same reason (easy deployments of premade services).

3. Mmhm, makes sense.

As for documentation changes, please highlight what improvements your product makes to the status quo! The 'DEEP for Developers' section tells me that it adds abstraction on top of AWS' model services, but beyond that, I don't see any improvement to working on the bare metal, so to speak. Like, Sandstorm [2] (sorry, just heard about them so they're on my mind right now) says that they handle authentication themselves. That's wonderful; I hate reimplementing auth for every project! Or even PyPy [3]: I _could_ use CPython, but their product runs faster and uses less memory. Why should I bother to learn DEEP and add another level of dependency to a project?

[1]: https://marketplace.openshift.com

[2]: https://sandstorm.io/#developers

[3]: http://pypy.org/

Actually, that's an excellent point -- how do buildings/bridges/etc. actually get built? I mean, laugh if you will, but can you not think of any examples of construction projects that straight up ran out of money and had to halt? Or that became enormous money and time sinks, inching their way but never-quite-making it to completion?

As I understand it (still pretty new to the industry), we're supposed to give realistic estimates for a product's completion, considering that 1. requirements are always incomplete and 2. unexpected complications will always arise. 'Done' is a moving target, and part of its estimation is ensuring the product is deliverable at every stage (with varying degrees of completeness), regardless of whether how many times everything goes pear shaped.

Zero offense intended; the following are my honest-to-goodness impressions of your product.

1. I have no idea what it is. DIY (presumably) microservices? And, there's a way to use AWS without servers (is this a reference to Lambda?) The title of your product is 'Digital Enterprise End-to-end Platform', which looks impressive but on further inspection appears meaningless.

2. Reading further into your github page and looking at the DEEP marketplace, I think you're selling software-as-a-service deployments? Something like Sandstorm or Openshift, I'd imagine.

3. Aah, okay, so you're making an abstraction layer on top of AWS -- but it doesn't seem like that permits any portability between cloud platforms. Is the only benefit to using your system easy deployment onto Amazon's product?

Seeing this run through an equivalent of the deep dream visualizer could be really interesting -- what _are_ people looking for in thumbnails? I'm having difficulty imagining what features would even be relevant in such a situation.

Not sure if I'm reading this right but per the NCHS (via the CDC)[1][2][3], in 2013, for people aged 15-24, ~6500 died relating to motor vehicle injuries whereas ~6000 died relating to firearms (although ~2000 of those were suicides -- not sure how that factors in, but it's probably important). Anyways, it seems like an awful lot of people kill themselves with guns, so perhaps we should just consider it a binary: if something is lethal, treat it with all the care you can muster.

Edit: drat, and the site you can use to get more stats: http://webappa.cdc.gov/sasweb/ncipc/leadcaus10_us.html

[1]: http://tinyurl.com/qfqn5oz

[2]: http://tinyurl.com/on9lyfc

[3]: http://tinyurl.com/ov5je39

Fair enough, I suppose. Still, I'll miss reading the occasional post outlining Linus' outbursts on the kernel mailing lists when that day comes.

Aah, brilliant -- and they even have a book :D thanks for the recommendation!

This brings up a point that's been nagging at me for a while: does making a community more inclusive necessarily mean making it less distinctive? GenderDetector (formerly SexMachine [1]) is another example of this process, wherein what was formerly considered within the norm of politeness is now sufficiently far outside to cause outcry. I'm curious what other people think -- this has been on my mind for a while, and although I like parts of the predicted conclusion (more people for me to share my hobby with!) others frighten me (genericization to the point of losing meaningful cultural identity).

[1] https://github.com/bmuller/gender_detector/pull/14

I certainly could (and actually hadn't thought of doing that; the hype was really getting to me)! Part of the difficulty is in fixing the setup process, though, as over the years this system seems to have accrued a fair amount of -- shall we say -- character. Jumping in and fixing it up to the point of making environment setup a short, portable and error-free process (such as (1) pull a vm image (2) feed it a commit hash to build, test and deploy) would optimistically take weeks. This drove my desire to short circuit the entire affair and stick it all into a VM. That's what I was alluding to vis. proper solutions :)

Bother you for a little advice? I'm working at a mid-sized tech company and am evaluating Docker for CI, testing and limited, internal deployment usages.

The services in question are built with a hodge-podge of shell scripts and build tools, so getting them all to compile locally is a challenge, let alone deploying them. My hope was that containerizing the builds would isolate any configuration problems, and that containerizing the deployed services would cut down on outages by permitting trivial rollbacks (say, by snapshotting all the service containers before each deploy and merely restoring them should a deployment fail). Of course, all of the above could be fixed by traditional means (e.g. rewriting the build system with a single, standard tool; streamlining the deployment process, etc.), but it seemed like Docker could solve 80% of the problems while easing the implementation of the proper solutions down the line.

Considering the above, do you still think Docker's a poor fit for business that aren't building hosting systems? Oh, and any nuggets of wisdom you could throw to a newcomer to the industry? :)