Jump to content

Wikipedia:Articles for deletion/Comparison of ABAP and Java

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Pcap (talk | contribs) at 14:32, 26 August 2009 (delete). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Comparison of ABAP and Java (edit | talk | history | protect | delete | links | watch | logs | views) (delete) – (View log)
(Find sources: Google (books · news · scholar · free images · WP refs· FENS · JSTOR · TWL)

Synthesis with no meaningful refs. These 2 languages are not closely related enough to be sensibly considered comparable; they're from completely different generations. One is a proprietary COBOL-like language used to script a server, the other is a modern, fairly open C-based language. Cybercobra (talk) 23:50, 14 August 2009 (UTC)[reply]


Relisted to generate a more thorough discussion so consensus may be reached.
Please add new comments below this notice. Thanks, JForget 23:44, 20 August 2009 (UTC)[reply]
  • Delete per WP:NOR. Stifle (talk) 22:13, 22 August 2009 (UTC)[reply]
  • Delete Wikipedia is no source of advices to migrate from one computer language to another. --Kgfleischmann (talk) 03:54, 26 August 2009 (UTC)[reply]
  • Delete. It would be okay to have this article if it actually cited various sources that were themselves non-trivial comparisons. But this is not the case. The only source that remotely comes close to that is this wiki entry (the most recent version of which has been vandalized, by the way). All I see there is a table comparing how many bits some data types have; the other source is a comparison of whitespace usage, again an entry on the same wiki entry. Not enough to base an article on even if they weren't sourced to another wiki... The entire series of "Comparison of ... " needs scrutinizing, and many articles there should probably be killed with fire, but I don't feel very deletionist this year... Pcap ping 14:32, 26 August 2009 (UTC)[reply]