Date: Tue, 17 Oct 2017 23:52:01 +0200 From: Polytropon <freebsd@edvax.de> To: Warren Block <wblock@wonkity.com> Cc: "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: Scripting problem Message-ID: <20171017235201.c3c8bd3a.freebsd@edvax.de> In-Reply-To: <alpine.BSF.2.21.1710171426170.91992@wonkity.com> References: <7AB396F429EEB6890100F082@Pauls-MacBook-Pro.local> <VI1PR02MB1200B33C1F59A223B84E9153F6770@VI1PR02MB1200.eurprd02.prod.outlook.com> <8C8E7D66788801594EC0FC4C@Pauls-MacBook-Pro.local> <20171008100017.30ab5987.freebsd@edvax.de> <88D321A2CCD516AEF39DE8C3@Pauls-MacBook-Pro.local> <alpine.BSF.2.21.1710090615040.94613@wonkity.com> <1984508980.4145408.1507553196491@mail.yahoo.com> <alpine.BSF.2.21.1710111652460.80616@wonkity.com> <5D3BAA54-3229-4472-8A4D-A10D3F3F07D9@fjl.co.uk> <alpine.BSF.2.21.1710171426170.91992@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 17 Oct 2017 14:45:02 -0600 (MDT), Warren Block wrote:
> Writing a program is not that hard. Modifying one, especially one you
> didn't write, can be a lot harder. As maintenance can be, and most
> programs require ongoing maintenance.
A program is read many more times than it is written. ;-)
> Higher-level constructs make for less code, which generally makes it
> easier to see on a screen and understand. And when it's easier to
> understand, it's easier to maintain.
The downside is that if you follow the turtles all the way down,
you end in C, assembly, or any other low level programming language.
The "easy to understand" is true on the surface, and the price
often is a pyramid of dependencies.
> There have been some efforts to polish off the roughest C warts.
> Google and Apple have done this lately, although it looked to me like
> they kept the ugliest parts and polished around them.
The reason probably is that they had a certain understanding of
"backward compatibility", such as C constructs within Objective-C.
Other reasons might be to increase appeal to programmers who feel
happy in Java land. The success of a language (and often the
software creation and deployment ecosystem connected to it)
depends on programmers actually using that language. This often
is not in direct relation with language design and pitfalls
("What does == mean in Javascript?"). Even worse, it can be
influenced by marketing ("The consultant said that programmers
for C# are really cheap!"), or comparison to competitors
("The other big companies use C++, and they make big money
with it!").
The "framework of the week" illustrates the same core problem.
Sometimes they can be seen as the illness that understands
itself as the cure. ;-)
> The sad thing is that we have a bunch of high-quality open-source
> languages available for free, and people should be picking the language
> based on the problem domain.
Exactly. The "one size fits all" programming language hasn't been
invented yet, even though some folks claim it's Java. Maybe this
is because Java is the new COBOL... ;-)
> It's difficult to change mindspace to match radically different
> languages. But it often leads to clearer expressions of the algorithm.
> That makes it easier to debug and maintain. And it can also give the
> programmer different ways of looking at problems. That is valuable no
> matter which language you end up using.
Maybe this is just an exception, but I found that many programmers
who are "programming language polyglots" have no problem switching
mindsets along of switching languages - to work with the best tool
of the current problem domain, as you mentioned. On the other hand,
programmers who only know one language (and maybe another one that
is similar to the first one, like Java and C#, or Java and C++)
sometimes seem to lack a fundamental understanding of why there
are other languages and other paradigms, and why something they
acquired with hard work (like iteration from 1 to length of what-
ever) is not the best way to "do this and that with all elements
of the list" in every language they have to use. In my opinion,
this is one of the reasons for bad code: Bad habits, cargo cult,
"But I've always done it that way!", "But I've never done it
that way!" and similar excuses. Explosing that kind of programmer
to APL code will only result in a brain freeze, followed by a
loud ON ERROR RESUME NEXT. ;-)
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171017235201.c3c8bd3a.freebsd>