Remove deprecated readtable/writetable

[bkamins]

In order to clean up the code base I would remove as much as possible form deprecated.jl in the after the next release.

This is related to my thinking that when we release DataFrames.jl version 1.0 it should not contain deprecated functionality.

I am raising this as an issue, because I think that if we go this way it would be also good to indicate in release notes of 0.X what deprecated functionality will be removed in 0.(X+1) - not as a guarantee, but in cases we know it.

In particular - what would you say to remove after the next release readtable/writetable and related functions?

CC @nalimilan

[quinnj]

Are we or anyone else aware of any features/issues with using CSV.jl vs. readtable/writetable? The one thing I can think of outstanding is the Parsers.jl performance issue w/ full precision floats, but otherwise, I think CSV.jl has come a long way since we originally deprecated readtable.

[nalimilan]

I'd rather keep these until we are completely sure all issues in CSV.jl are fixed. We've got reports about performance issues very recently for example.

In general my thinking is that deprecations which do not block improving things should be kept for as long as they don't require additional work on our side. Deprecated code living in deprecated.jl is really cheap to keep -- except when it consists in duplicating methods which need to be kept in sync with the main code (like for SubDataFrame indexing). People are likely to bump into old answers in forums which use deprecated functions, and it's good that the message points them to the new way of doing it.

[davidanthoff]

Those functions could also be moved into a separate package? Just to keep them around?

[nalimilan]

Anybody is free to copy them to a separate package, but that would take a bit of work which would better be spent fixing the remaining issues in existing CSV packages. We already have too many of them!

[KwatMDPhD]

CSV.jl has too many issues now. These functions are very useful. Deprecating them is probably not a wise idea.

[quinnj]

@KwatME, can you share what issues you have with CSV.jl? As far as I know, it has more features and better performance than almost any other csv library, including other languages. We're also very committed to making it work for all use cases, so please share and I'm sure we can make it work.

[KwatMDPhD]

Thanks :)