261–270 of 502 posts
For the last 2.5 years I've been doing RPG - both the newer free form and older fixed. I can imagine I'll be doing it a lot more within the next year also. A lot of people give it hate, but it's a pretty simple language after you use it a lot. It's possible I will start to write C++ also.
assembly apl (k4) forth (bootloader) snobol (spitbol) C (small subset) sh (Almquist-like) sed (not GNU) nawk (do not use added functions such as strftime) execlineb
what in the world do you still write in snobol / spitbol? I haven't heard anyone even mention that language since 1983.
I do scientific computing in academia. Secretly, it's just fortran all the way down, and LaTeX for document preparation. Piled on top of that is a fair amount of matlab, simulink, and python.
You know, modern Fortran isn't awful. Fortran 77 code however, is frighteningly ugly to look at.
Earlier quoted context omitted.
Ever benchmark it against Lua? But yea a whole lot more people use Perl.
Lua feels awkward to me when used as a standalone scripting language. When embedded into a C host applications, it is really nice, though. There is also a port of Lua 5.2 to Go, which has a slighty confusing API (to me, at least), but the documentation makes up for that.
Perl 5, of course! It's an awesome language and both the language and the ecosystem is getting better and better all the time
Earlier quoted context omitted.
not deployed on apple: http://inteng.fnal.gov/Integrated_Eng/irm/irmsoftware/IRMSof...
Fascinating! And you keep old Macs around to run the toolchain on?
https://github.com/ksherlock/mpw
Here's the end of a Makefile, very unix-like:
APPL = ${TYPE}${NAME}
DATA = DATA${NAME}
OBJS = ${NAME}.p.o
LIBS = ../WordSum.asm.o ../LASysLib.a.o ../PasLib.o
LANG = C
MPWC = /usr/local/bin/mpw
AS = Asm
AFLAGS =
CC = SC
CFLAGS = -mc68020 -mc68881 -b2 -Opt all
PC = Pascal
PFLAGS = -mc68020 -mc68881
LD = Link
LDFLAGS = -w -t LApp -c MPWX -m MAIN -sg ${NAME}
# Link -w -t TEXT -c RWG1 -rt CODE -m HELPLOOP -sg HELPLOOP
CFMFLAGS =
# CFM = ${MPW:/mpw=/cfm}
# CFM = /usr/local/bin/cfm
CFM = cfm
# TFTPFLAGS = -vt
TFTPFLAGS =
# TFTP = ${MPW:/mpw=/tftptool}
# TFTP = /usr/local/bin/tftptool
TFTP = tftptool
.SUFFIXES : .p.o .p .c.o .c .asm.o .asm
.phoney : all clean install
all : ${APPL} ${DATA}
.asm.asm.o :
${MPWC} $(MPWFLAGS) $(AS) $(AFLAGS) $mult.asm
mult : mult.asm.o
$(MPWC) $(MPWFLAGS) $(LD) $(LDFLAGS) $- sh (I really don't use bash features in scripting) - awk - perl - sed, if that counts as language. It's funny that a course that I took in university almost 29 years ago, for learning the use of Unix scripting tools, is one of the most useful learning experiences in my daily work today - even if my job is not really a programmer. But very often I see colleagues (project managers, architects etc) struggle with proce…
Any suggestions for a bash scripting tutorial to help me better connect the dots? Over the years I've learned some nifty one-liners, but I'm not really familiar enough with the patterns and art of of command-line thinking to solve my own problems in bash. Most of the bash resources I've found online are just loosely organized collections of magic spells. I'd really like to get better at it though.
Classic Shell Scripting Arnold Robbins, Nelson H.F. Beebe
Recommend it to anyone with a basic understanding and a will to learn more. It also really doubles as a rich information resource. Cannot recommend it enough if books are your thing.
assembly apl (k4) forth (bootloader) snobol (spitbol) C (small subset) sh (Almquist-like) sed (not GNU) nawk (do not use added functions such as strftime) execlineb
what in the world do you still write in snobol / spitbol? I haven't heard anyone even mention that language since 1983.
- sh (I really don't use bash features in scripting) - awk - perl - sed, if that counts as language. It's funny that a course that I took in university almost 29 years ago, for learning the use of Unix scripting tools, is one of the most useful learning experiences in my daily work today - even if my job is not really a programmer. But very often I see colleagues (project managers, architects etc) struggle with proce…
Any suggestions for a bash scripting tutorial to help me better connect the dots? Over the years I've learned some nifty one-liners, but I'm not really familiar enough with the patterns and art of of command-line thinking to solve my own problems in bash. Most of the bash resources I've found online are just loosely organized collections of magic spells. I'd really like to get better at it though.
It's helpful to learn some more about bash, and there's some good stuff in there. But shell scripts above a few dozen lines tops are a bad idea, and even those "few dozen" lines need a surprising amount of armoring with "set -e" and such.
I don't think this is because bash is bad. I've come to the conclusion that there's a fundamental tension between interactive use and safe programmatic use, and anything really good at the one is not going to be good at the other. In particular, interactive users more-or-less want the shell to accept inputs that are a bit sloppy, because they can interactively recover from the vast bulk of misinterpretations immediately, whereas a program becomes very risky with the same level of sloppiness because it will quite likely just keep going, doing very bad crazy stuff. (Which is why all my shell scripts tend to start with "set -e", which amounts to "If you get confused... STOP, instead of trashing an arbitrary amount of state.")
And again let me emphasize #1. By splitting my world up into interactive use and programmatic use, I've made my peace with shell, and I don't hate it or anything. I use a lot of the features interactively. For instance, I do a lot of little loops on the command line. Often I'll build them up with some "echo"s done to make sure that it's about to do what I think it will do. There's a lot of great ways to save time in interactive bash (or zsh or whatever), and the best part is, in interactive use you can be as crazy efficient as you want and there are no software engineering implications. Writing bash scripts with every crazy sophisticated trick in the books starts raising software engineering issues fast, and worst of all, some of them are quite invisible ("what if you run this in a directory with a file with a space in it? a newline? a file called '-rf'?"), to say nothing of whether the next person working on the script will know what all the fancy operations do. And I've got a decent-sized collection of 5-line bash scripts lying around doing various things. I just don't let them get much longer.
One of the most useful things to do is just load up an index in your head of what bash can do, then know you can look it up if you ever want it.
(Substitute your choice of shell for bash throughout.)