未加星标

Rant on Reduction

字体大小 | |
[数据库(综合) 所属分类 数据库(综合) | 发布者 店小二03 | 时间 2017 | 作者 红领巾 ] 0人收藏点击收藏

Tl; Dr:

There is too little code reuse in software, particularly at the community level Examples of useless duplication (not-dry) include manyprogramming languages, package managers, data-stores, tools Thiscommunity duplicationmeansengineers have to learn different interfaces to nearly identicalsystems and reduces interoperability of tools

1. Why is there more than one unix/linux package manager?Do we really need a package manager with the same commands but renamed for every programming languages? Do we really need a distinct package manager for each distro?

Nobody seems to admit it, but php, Ruby, python, and javascript are the same language , with a little sugar added here or there and different libraries. I’m okay if not everybody wants to use curly braces but would rather indent for typing, but I’m not okay with every library for every functionality (date parsing, database connectivity, html parsing, regex, etc) being rewritten as a distinct library for every language when those languages have almost no significant differences.

This leads to a scenario where “learning a language” is more about learning the library than anything else (e.g. “How do timezones work again in PHP?”)

2. MongoDB never should have existed . MongoDB should be a storage engine. The concept of a datastore that adapts its schema on-the-fly and drops relations for speed is okay, but there’s no reason the entire database has to be reinvented to allow this. There’s no reason the entire query syntax has to be reinvented. There’s no reason the security policy has to be reinvented and all the DB drivers. There’s no reason all the tools to get visibility (sql pro) and backup the database need to be reinvented. Plus, if it were just a storage engine, migrating tables to InnoDB would be easier.

The same point holds for cassandra (which is basically mysql with sharding built in), elastic search, and even kafka (basically just log part of mysql without columns).For example, a kafka topic could be seen as a table with the columns: offset, value. Remember storage engines can process different variations on SQL to handle any special functionality as-needed.

3. Overly-specialized technologies should not exist. People seem to love interview questions about job queues.All job queues should be built on top of a SQL backend so that engineers get the normal benefits

engineers know how to diagnose the system if it fails because it’s a common one (e.g. performance issues, permissions) engineers can always query the system to see what’s happening because it’s using a standardized query language engineers can modify the system if necessary because it provides visibility into its workings engineers can use existing backup, replication, and other technologies to store/distribute the queue (giving interoperability) The effects of creating new systems: Senior Engineers are all set back years relative to junior ones (bad for senior engineers, good for junior engineers) The ecosystem is set back as a whole (all tools, libraries that interact with the old technology are rebuilt for the new one) The company is placed in a precarious position because it now only has junior engineers in the given technology The company runs the risk of being saddled with a technology that will be dropped (e.g. couchdb, backbone) and will require a rewrite back to a standard technology or be perceived as behind-the-time. Engineers spend so much time memorizing different bad interfaces to new technologies (how their config files work, gotchas and bugs, how their performance scales, how to understand their logs) that the ability for them to progress gets undone. It’s a treadmill effect engineers have to run (keep learning new technologies) just to stay in place. The exceptions:

There are a few exceptions I can think of when a complete rebuild from scratch was an improvement. One would beGit. In a few months, one of the most prominent software geniuses of our era invented a source-control system so superior to everything else that it has been adopted universally in a few years, despite the intimidating interface.

The times a rebuild is justified seem to bewhen many of these criteria apply:

You’re a known and well-respected name that people trust so much they may standardize on you for convenience (e.g. Linus Thorvalds, Google) The existing systems are all awful in fundamental ways, not simple in simple-patchable ways (e.g. UI) You can make your system backward compatible (C++ allows assembler, Scala allows Java) and thus can reuse existing knowledge and tools You’re so smart and not-average that your system isn’t going to have the myriad of unanticipated flaws that most software systems you want to replace will. For example, angular, backbone, nosql, are all community fails. Your system is already built-in or easily-integrated with existing systems (e.g. JSON being interpretable in all browsers automatically)

本文数据库(综合)相关术语:系统安全软件

主题: JavaMongoDBSQLInnoDBGitPHPRubyScalaC++Python
分页:12
转载请注明
本文标题:Rant on Reduction
本站链接:http://www.codesec.net/view/522252.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 数据库(综合) | 评论(0) | 阅读(70)