881 karma · joined June 9, 2013
If you have an opinion or idea that isn't reproducible, verifiable or testable and the only thing you can do is "accept" it based on how good it sounds to your ears then it doesn't belong in science.
So please, leave that stuff out of science, it's our last barricade.
That's not how science works. If something is proven and reproducible via the scientific method, it must work(used to make verifiable predictions) whether you accept it or not.
Let's never forget https://en.wikipedia.org/wiki/Diederik_Stapel . His M.O. was to fabricate results that would be easy for his peers to accept.
And if we take into account all the dangerous pseudo-scientific hype around the gut(leaky gut, cleansings, etc) we should be twice as careful.
Right. Ok we have a problem with definitions. No this is obviously not normal syntax.
Unless we take it to mean "whatever new syntax python introduces is normal syntax, since it supports it!", which is tautological and not very useful.
I'm gonna say something, strictly so you can understand where I'm coming from, not to offend you.
You sound very young. And by "young", I mean so young to not remember that Python was always about "duck typing" and not about strict types. I still have books on my bookshelf that tried to dissuade you from using "issinstance(foo, sometype)". So no, it's not python or normal syntax.
Yes, Python now is safer than older Python. But I had 99 problems with Python and that wasn't one of them :(
You, speaking as if Python is progressing so fast while Go is standing still, feels disingenuous. Go fixed their dep/packaging woes in a few years, Python is not even close. Go is adding generics. Go becomes faster in almost every release.
Changing Python into something that doesn't resemble python, its values, or the reasons that people chose it in the first place doesn't make sense, nor does it make it "Python".
I don't want Python to become Haskell, Rust or Go. No one ever chose python for its typing system! Rather its lack of it.
Anyway, there's no accounting for taste and to each their own.
Cheers
I will leave this tidbit here:
i, found = 0, False # type: int, bool
In any case, I find these new "typing" features very awkward, overly verbose and not the reason that I chose python in the first place. If I am to write all this non-pythonic stuff to be 10x+ slower, less memory efficient, awful at concurrency and still not having solved the packaging/deployment situation... I will just use Go. Or any other language in that league, that offers so many more nowadays.
If you truly believe that a dynamic language like python can have type safety, then imagine what a language like Go can achieve.
Python already has deviated too much from where it started and mypy offers too little to justify the verbosity.
So I guess we'll see what the future holds for them.
It can't be faster. It can't consume less memory. It can't stay still.
So they add auxiliary features. No matter how much they downvote you, you're right.
For a new project it doesn't make sense to not use Go, or something similar, if you're going down that road.
Did I miss that part of history?
You don't need JS to "serve a socially useful purpose" most of the time, as well.
As I said, it seems we decided that everything needs to feel like an app.
95%(yes, I'm probably exaggerating) of the actual value of the today's websites could be plain documents with links to each other.
But try and suggest to anyone you're gonna have a company presence site(or anything for that matter) with no JS at all, and see where it gets you.
That sounds like saying "living is the leading cause of death".
I mean, I don't particularly like JS, but it seems like we decided long ago that plain documents and links won't cut it. Everything, apparently, needs to be a rich web application with huge images and a gazillion of ads.
Why is that Javascript's fault?
The people who designed these gems would probably be able to design good sites no matter what tools they had at their disposal.
I am just that crazy person that believes that default options should err on the safety/integrity/consistency side.
I also love abstractions, but abstractions can't change their underlying fundamental reality. So I would like to be the one who makes the compromises and I'd like those compromises to be explicit rather than implicit.
If you have constraints that can be enforced by the DB, you simply use the DB's constraints, because the DB guarantees they're gonna work 100% of the times and your data will be correct.
If they are more dynamic or require custom business logic... well you do it on the application layer. That's what everyone does.
I mean you can probably implement your own transactions, that doesn't mean that you should. And if you do, then just admit that there's no point in using an off-the-shelf RDBMS.
Deciding to implement constraints on the application/business layer is something that github can probably do, in the same vein that Facebook can create their own PHP compiler.
I just think that you can't use these examples as effective arguments on whether someone should use FKs or not. I guess whatever brute-force solutions these companies would apply, on any given problem, would probably work one way or the other.
Thanks for that tidbit, I have no XP with Rails, but I would never imagine they do something so atrocious.
If you want to have referential integrity there's no other choice. Otherwise you create tables that have no relation to each other. No one stops you from doing this, but then you probably don't want an RDBMS in the first place.
It's predicated on the fact that you don't use foreign keys. Now why would someone use MySQL without FKs... is beyond me, but I'm sure they have their reasons.
MySQL has this https://dev.mysql.com/doc/refman/5.6/en/innodb-online-ddl.ht... for Online Schema migration and
MariaDB has ALTER ONLINE https://mariadb.com/kb/en/library/alter-table/
They both work with triggers + ghost tables, so they don't need transactions.
And yes, in some sense, they do abstract this away for you, but then you just have different kind of problems. So your efforts just shift towards other difficulties presented by such technologies. But I digress :)
You said:
> Passing peer review is something used as a substitute for reproducibility
And what I'm saying is "No, it's not". Reproducibility of the results is the most important aspect of the scientific method, otherwise, as I said above: "what's the point really? We would resort to trust or belief in one's sayings."
1. Define a question
2. Gather information and resources (observe)
3. Form an explanatory hypothesis
4. Test the hypothesis by performing an experiment and collecting data in a reproducible manner
5. Analyze the data
6. Interpret the data and draw conclusions that serve as a starting point for new hypothesis
7. Publish results
8. Retest (frequently done by other scientists)
Emphasis on 4) and the "reproducible manner".
Otherwise what's the point really? We would resort to trust or belief in one's sayings.
Wow, pretty low bar for science. You can have peer review for the actual results and what they mean, as well as them being reproducible.
> The procedure (scientific method) that has lead to all the great stuff
I don't think you know what the scientific method is.
Empty statement that means nothing. SQL/RDBMS is backed by computer science and robust engineering examples that make the world spin. Alternatives are usually full of fanfare and false promises.
> I think AWS has already started that with Amazon Aurora.
Just in time when we were talking about fanfare. Spend 10-20 minutes searching on the Internets to see what actual experiences people have with it.
Its 3X write increase? Bollocks. Usually the performance is worse than when you administer your own DB(Postgresql/MySQL). You might(or not) see some read-performance increase, which... well everyone can scale on reads so I don't see the point.
I suspect it has other goodies pertaining to administration/provisioning, but performance/scaling is not one of them.
Okular(provided by KDE), for example, is blazingly fast. Or at least, I haven't noticed any slowness.
REST is still HTTP + more exotic verbs + headers + more serializing/encoding options. You can build a small library, specific for you project's needs in a matter of 3-5 days. And on top of that, you don't forfeit any possible future optimizations, which you most certainly will by choosing any ready made library.