681 karma · joined September 26, 2013
Nice documentary about it: https://www.youtube.com/watch?v=NdZxI3nFVJs
Some of paper lasted for hundreds of years. How much of information didn't survive during that time period?
Information on s3 might not last for hundreds of years, but AFAIK the Voyager satellite didn't ship the information about our specie on paper.
You actually have to cut a tree to make a notepad. I hope in 100 years people will look at the "paper age" as we do see the era when people carving information in stones.
Why paper is worse:
* you cannot easily edit/alter information that has been already created
* it is hard to replicate and distribute
* version control is non existent (except book keeping)
* due to the replication problem and accessibility the information on it is not durable (at least not as durable as s3)
* collaboration is hard and not possible over the long distance
* security it terrible (even with all the stamps and hand signatures)
I know that paper might sound tempting sometimes, but I blame the schooling system which enforces kids to use it. We are trained to use paper first that's why it might seems easier. To learn how not to use paper (I don't use it at all for over 3 years) is really hard, it requires to change the workflows, mindset and attitude towards the information. But at the end of the day, it is really worth it.
The most compelling evidence for the holocaust being a lie is the fact there were survivors, period.
https://www.stormfront.org/forum/t553062/?postcount=6#post62...
No words can express the look of my face while reading this.
2. They should describe the purpose of the code in general not the quirks in the code
3. The exception rule is when the code can't be self-explanatory. Hacks are undesirable, but in real life you have implement them sometimes anyway - then comments are necessary
4. Docstrings in everything are wrong, the code itself is a documentation.
Type annotations in py3 might change that, but lets be honest - py3 is still far from broad adoption.
I know how hard and time consuming it is to build backend properly and firebase looks like a big shortcut.
Do you know some applied design patterns in swift for quick firebase replacement?
* type annotation + awesome tool for analysing code (dialyzer)
* immutability, list cannot become a dict out of nowhere
* great support for concurrency
* concept of application (OTP) gives out ability to run many loosely coupled apps on one VM. I believe "microservices" is the buzzword that matches the concept.
* distribution by design.
* great monitoring tools
* I could go on... really.
* Packaging is horrible
* Releasing python code is a non-standarised nightmare. Every solution has it's own flaws
* Big and complex projects in python are really hard to reason about
* Poor support for concurrency (fixed in py3)
Don't get me wrong, python is really cool as a proof-of-concept scripting language. But for mature and complex stuff, I'd recommend something with type checking and better support for release process.
I have to use ECS for caching (I am not happy about it)
Builds might fail due to the custom docker version/compilation
You can mock docker, but people are using it in one way or another and you should support it properly.
I think, no one gets this right. What's missing here: for software startups, hardware (servers) should be the main cost of running the business. Increasing load due to the growing user base is a very nice to have problem.
The bigger the company, the smaller the feeling of doing something 'real'. Just my experience.
Meltdown by T. Woods (cool guy, Austrian Economy)
The Witcher by A. Sapkowski (Fantasy, but It reads well only in polish language)
That's why a pasted http://www.slideshare.net/BrianTroutwine1/erlang-lfe-elixir-... - slide 96 (I can't find a direct link). Elixir sits above golang but way below Java or C++. Maintainers are doing pretty good work at simplifying things as language matures - for example merging Dicts and Maps together.
> I wouldn't personally call it a big pile.
Touche.
Hard to grasps at first - later it is a huge benefit.