[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 28/04/13 10:31, Gordon Henderson wrote:
>
> At the risk of simply repeating xkcd...
>
> http://xkcd.com/927/
Love it.
Anyone want to volunteer some languages to die.
I'll offer up these to start with....
PHP -> just learn Perl.
C -> you've had C++ for 30 years, really you can carry on much the same
if you really have to.
csh -> Just stop it.
M4 -> No idea - but it made sendmail config files as easy as writing
assembler macros, and I don't think it improves the readability of
autoconf. Maybe it just needs to be fenced into only being used for
assembly language macro creation.
Having pondered Lex/Flex & Yacc/Bison a few times, I think I can safely
say if there aren't better tools for compiler creation it is time
someone made some (I'm pretty sure there are, but a lot of the books
refer back to these inspite of that).
Makefile (?)
Not sure on this, I suspect it may me that you can "write bad makefiles
in any language", and even where they are used I rarely have to look at
them these days except to check flags were passed appropriately etc.
Then again if we had to automate it all perhaps it was too hard in the
first place.
They started of looking like:
---------- snip -----------------
edit : main.o kbd.o command.o
cc -o edit main.o kbd.o command.o
main.o : main.c defs.h
cc -c main.c
kbd.o : kbd.c defs.h command.h
cc -c kbd.c
command.o : command.c defs.h command.h
cc -c command.c
clean :
rm edit main.o kbd.o command.o
------------- snip--------------------
Which is fine although possibly a little non-descriptive, anyone who
knows what a compiler does, and the compiler command syntax can grasp it
instantly.
And these days they look like this:
---------snip---------------
...
am__nobase_list = $(am__nobase_strip_setup); \
for p in $$list; do echo "$$p $$p"; done | \
sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
$(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
if (++n[$$2] == $(am__install_max)) \
{ print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
END { for (dir in files) print dir, files[dir] }'
am__base_list = \
sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
...
---------snip---------------
Anyone want to bet there isn't an exploitable security flaw in there? No
you can't have 30 minutes to answer.
Although maybe if I added "awk" and "sed" to the list, and said even if
they are better than Perl for some things they aren't better enough to
justify the cognitive overhead.
Those who started in the 1960s and even myself, have had years to become
familiar with this stuff (or in some cases just loathe it - moi?), but
anyone coming afresh will throws their hands up in horror and recreate
it in Python or some such, and then the next generation faced with 50
years of Python tool creation, and people still using all the above will
throw their hands up in horror and get their IBM Watson2 instance to
sort it out for them.
It is even hard to lose a lot of this, because it is easier to take sed,
M4 or awk to a new platform and then at some low critical mass you get
all of the software packaged in the GNU style, than rewrite all the
current packaging and compiling stuff. So even if we all agree never to
create any new bits, we'll still have the overhead of maintaining it all
for decades. Roll on the AI programmers, it'll be so much easier to
recode it all at Watson style speeds of comprehension.
--
The Mailing List for the Devon & Cornwall LUG
http://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/listfaq