From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Yuri Khan Newsgroups: gmane.emacs.help Subject: Re: Check for redundancy Date: Sun, 28 Jun 2015 22:35:02 +0600 Message-ID: References: <87zj3mb4jf.fsf@mbork.pl> <87twttcpve.fsf@robertthorpeconsulting.com> <20150627131227.GB23450@tuxteam.de> <87d20glpqa.fsf@nl106-137-147.student.uu.se> <20150628110732.GA23656@tuxteam.de> <87twtrn86z.fsf@nl106-137-147.student.uu.se> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1435509342 16478 80.91.229.3 (28 Jun 2015 16:35:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Jun 2015 16:35:42 +0000 (UTC) To: "help-gnu-emacs@gnu.org" Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Jun 28 18:35:41 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 1Z9FYR-0008M5-Vk for geh-help-gnu-emacs@m.gmane.org; Sun, 28 Jun 2015 18:35:40 +0200 Original-Received: from localhost ([::1]:39449 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9FYR-0000EN-1x for geh-help-gnu-emacs@m.gmane.org; Sun, 28 Jun 2015 12:35:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35857) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9FYD-0000ED-Pd for help-gnu-emacs@gnu.org; Sun, 28 Jun 2015 12:35:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z9FYC-0002r9-FV for help-gnu-emacs@gnu.org; Sun, 28 Jun 2015 12:35:25 -0400 Original-Received: from mail-la0-x235.google.com ([2a00:1450:4010:c03::235]:34374) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9FYC-0002q5-70 for help-gnu-emacs@gnu.org; Sun, 28 Jun 2015 12:35:24 -0400 Original-Received: by lagx9 with SMTP id x9so101329030lag.1 for ; Sun, 28 Jun 2015 09:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type:content-transfer-encoding; bh=Gs/Mhalr5e2FK6jMDA+MqEWPiMUj3DpXzA1nCB4xJRU=; b=H34oMorEEfTrkAt9JgcFis4fFclw4gtBdxktnOSTT1roP+3YpJsGHu60SKcOGYKtBZ u0X9U+Lv0bfw4trCSLHLAf1HjStsJ8lxPEFSZ3agmy/xBNFzSVapUwVfUFfj8nj50rB/ mx4yWYm+xmlNUYMHtnwVPOeouKdNviunEMNmN0VZJJlG6lpVdWF90VToNrwlY3RqUO/b ozi6fg83Cb0X2KaC8ziChYc/rjSrPl435Os/J/QffYmxSXl9Mbu0QmUhzDqYKDq+vSCK cp0Qw5tfAs3OvN9djimmLljeIGmJX4GB6pEihGzz5KKwRbm8y4C0D91f8XEIbgUhQsDk 2Mrw== X-Received: by 10.152.21.168 with SMTP id w8mr10214652lae.22.1435509321706; Sun, 28 Jun 2015 09:35:21 -0700 (PDT) Original-Received: by 10.25.43.65 with HTTP; Sun, 28 Jun 2015 09:35:02 -0700 (PDT) In-Reply-To: <87twtrn86z.fsf@nl106-137-147.student.uu.se> X-Google-Sender-Auth: 1U0sBcMIQeNrIoQQlYiKyORatzM X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::235 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:105260 Archived-At: On Sun, Jun 28, 2015 at 9:50 PM, Emanuel Berg wrot= e: > writes: > > Indeed. For untyped languages, why put the types in > code where they aren't actually types anyway? And for > typed languages, why put them in code where they still > aren't types and even more, where they can indicate > the *incorrect* type as well? There are still reasons to use Hungarian notation, because even the most strongly typed languages in common use are not strongly typed enough. (Haskell is or can be persuaded to be, but my employer is not ready to embrace Haskell.) 1: Every time I have to work with two or more coordinate systems that use the same axis names (typically X and Y). E.g. a mathematical plane and pixel coordinates relative to a window and/or a monitor and/or a workspace. Eventually I start naming variables starting with =E2=80=9Cwx, w= y=E2=80=9D for window, =E2=80=9Csx, sy=E2=80=9D for screen, etc. 2: Strings in different encodings. E.g. the Python (2.7) web framework I use gives me Unicode strings, then I want to map them to filenames and thus have to encode them to UTF-8, and later I need to send an urlencoded header to the web server. Pretty soon Unicode strings get the u_ prefix, UTF-8 strings get u8_, filenames from the user-provided zip file (that are labeled in the zip file directory as cp437, but actually are windows-1251 in most of my cases, but I can=E2=80=99t rely on that and have to implement a heuristic) get yet another prefix. 3: Local and UTC times, if you are unfortunate to have to deal with them. 4: Measurements that are in neither SI nor common use units. (A routing algorithm I used to work with had a parameter expressing the estimated pedestrian speed. It typically had a value of 56. The unit? Centimeters per second, of course. The common speed unit is km/h here.) Without carefully labeling each affected variable, after a month of not touching the codebase, it becomes impossible to make modifications without breaking anything. Note that this isn=E2=80=99t the Systems Hungarian many people are used to, which encodes the actual type. It=E2=80=99s Applications Hungarian, where variables that have the same physical type get different prefixes after their conceptual type.