From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: Check for redundancy Date: Thu, 25 Jun 2015 01:31:12 +0200 Message-ID: <87381gk7jz.fsf@nl106-137-147.student.uu.se> References: <558A7875.4050905@easy-emacs.de> <24a1b328-82a8-44ff-8f8d-1425ab89ab67@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1435188810 28997 80.91.229.3 (24 Jun 2015 23:33:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Jun 2015 23:33:30 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Jun 25 01:33:21 2015 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z7uAT-00035c-0a for geh-help-gnu-emacs@m.gmane.org; Thu, 25 Jun 2015 01:33:21 +0200 Original-Received: from localhost ([::1]:53342 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7uAS-0006sR-CI for geh-help-gnu-emacs@m.gmane.org; Wed, 24 Jun 2015 19:33:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37960) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7u9u-0006Pk-Kl for help-gnu-emacs@gnu.org; Wed, 24 Jun 2015 19:32:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7u9r-00042X-Fj for help-gnu-emacs@gnu.org; Wed, 24 Jun 2015 19:32:46 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:35344) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7u9r-000422-A0 for help-gnu-emacs@gnu.org; Wed, 24 Jun 2015 19:32:43 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Z7u9k-0002UX-Jn for help-gnu-emacs@gnu.org; Thu, 25 Jun 2015 01:32:36 +0200 Original-Received: from nl106-137-246.student.uu.se ([130.243.137.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Jun 2015 01:32:36 +0200 Original-Received: from embe8573 by nl106-137-246.student.uu.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Jun 2015 01:32:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: help-gnu-emacs@gnu.org Original-Lines: 55 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: nl106-137-246.student.uu.se Mail-Copies-To: never User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) Cancel-Lock: sha1:+bhe62P+91fcq93wuTRqk07BVjs= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:105130 Archived-At: Stefan Monnier writes: >> The term is not specific to programming: expressing >> things which have been expressed already. > > Obviously, Drew knows that. The issue is that if you > want to check for redundancy in code, it's > presumably by doing it with another piece of code. > That other piece of code will have to encode > formally what you mean by redundancy, so to be able > to write it, you'll need to describe formally what > you mean by redundancy. And that's pretty damn hard > for the usual interesting cases of redundancy. Yeah, this is extremely difficult to accomplish at any level and to get it to be actually useful in practice is close to impossible. And it is not needed. > Of course, you could also use machine-learning to > define "redundancy" by way of a set of examples used > to train your machine-learning code. Not sure how > well it would work, nor how to make it work well. I dare say the AI methods will *never* be able to do this! The only method that might work is to have a compiler do relentless super-optimization over and over. Then, when done, tho having different codes, some functions will have produced the same sequence of machine instructions - then, you could delete one of them, sound and safe. No - the much better way is: 1) Write and read code every day. You will learn to identify what isn't needed. 2) Don't be afraid of doing stuff and having stuff around. Your computer isn't a garage that can fill up with junk. There is no harm in having a couple of defuns and shell functions lying around, mostly up to no good, some of them doing (almost) the same thing as their neighbor. This is not a situation to be worried about. It is not a bloated system or a system that will run slower. Instead of thinking you "have" to merge them into one thing that does everything "the right way" think what other functions you *don't* have and that you would like, and focus on those. -- underground experts united http://user.it.uu.se/~embe8573