hooya · HackerTrans

We gleefully exclaimed "Arab Spring" when social media destabilized other countries. It's come home to roost. Spring has sprung, bitches.

hooya

7 lat temudiscuss

check out: https://en.wikipedia.org/wiki/Formal_methods

I ran into loop invariants in my CS undergrad where they were teaching "formal logic" to prove correctness of programs. At the time, it was a bit above my head and i struggled with it. i'm just beginning to understand what it was that we were studying at the time. cool stuff. wish i could go back and re-learn that stuff. Also google TLA+ - there's a book on it by Leslie Lamport.

hooya

8 lat temudiscuss

i have an anecdote that you might find interesting..

many moons ago when i was an undergrad, there was this one class that i hated. i got practically nothing out of it. and the reason was that the professor had prepared all the course material in powerpoint. every damn proof, every single block of code.. everything. he would come in and read the deck, line by line in the class. i can trace my hatred of powerpoint to that single class. i remember thinking "i can read damnit. if you're going to read the powerpoint back to me, why don't you email that to me and i can read it on my own. i am not a toddler that needs to be read to by an adult".

prepare ahead of time - by all means. plan the coursework, the lecture. but whatever you do, don't read your prepared material to the class.

incidentally, i was also taking a class on public speaking at the same time. and near the end of the semester we each had to give a speech as our final "project". and one gent stood out - Sean (don't remember his last name) - he put up one poster and gave a 20 minute speech that i remember to this day after some 20 years or so. he didn't "read down" to us with a wall of prepared material.

since then i have sat through countless presentations/meetings. i can recall any presentation as vividly as i remember Seans'.

P.S.: Sean, if you find this, you convinced me that day that BMWs are the ultimate driving machines.

hooya

8 lat temudiscuss

I use it for almost everything. Take ETL type tasks. It's almost impossible to remember where I downloaded certain data files six months after initially creating a project. I put that into the Makefile. Everything I do on the command line, I put into a Makefile. That way, 6 months later when I need to download new data, do some transformation on that data and load it into the database, 'make' re-traces my steps from 6 months ago. Broadly, my ETL makefiles look like this:

all: data.loaded data2.loaded

data.csv: wget 'some url'

%.sql: %.csv sed/awk/custom-python-script $< > $@

%.loaded: %.sql psql < $< && touch $@

hooya

10 lat temudiscuss

> I grew up with a machine which booted into a BASIC interpreter

ZX Spectrum by any chance?

hooya

12 lat temudiscuss

If you've been able to keep up with others solely with the know-how you've picked up on your own in terms of software development, then great; my advice: take as many non-CS classes as possible. After you graduate, you'll spend all of your time in CS - constantly learning. But you'll rarely get a chance to learn anything else. College is where you do it.

Really, I see college as a way to learn how to learn. You've done that with CS, it seems. Now learn how to learn in other areas. You'll probably never get another chance.

During college I hated having to take any non CS class. In hindsight, I'm really glad I had to.

hooya

12 lat temudiscuss

> To begin with you have to have a single target for each file produced.

Try this next time (only the pertinent lines are included):

  SOURCES=$(wildcard $(SRCDIR)/*.erl)
  OBJECTS=$(addprefix $(OBJDIR)/, $(notdir $(SOURCES:.erl=.beam)))
  DEPS = $(addprefix $(DEPDIR)/, $(notdir $(SOURCES:.erl=.Pbeam))) $(addprefix $(DEPDIR)/, $(notdir $(TEMPLATES:.dtl=.Pbeam)))

  -include $(DEPS)

  # define a suffix rule for .erl -> .beam
  $(OBJDIR)/%.beam: $(SRCDIR)/%.erl | $(OBJDIR)
	$(ERLC) $(ERLCFLAGS) -o $(OBJDIR) $<

  #see this: http://www.gnu.org/software/make/manual/html_node/Pattern-Match.html
  $(DEPDIR)/%.Pbeam: $(SRCDIR)/%.erl | $(DEPDIR)
  	$(ERLC) -MF $@ -MT $(OBJDIR)/$*.beam $(ERLCFLAGS) $<

  #the | pipe operator, defining an order only prerequisite. Meaning
  #that the $(OBJDIR) target should be existent (instead of more recent)
  #in order to build the current target
  $(OBJECTS): | $(OBJDIR)

  $(OBJDIR):
  	test -d $(OBJDIR) || mkdir $(OBJDIR)

  $(DEPDIR):
  	test -d $(DEPDIR) || mkdir $(DEPDIR)

I've been using a makefile about 40 lines long and I've never needed to update the makefile as i've added source files. Same makefile (with minor tweaks) works across Erlang, C++, ErlyDTL and other compile-time templates and what have you. Also does automagic dependencies very nicely.

> Generating all the targets to get around this is a nightmare that results in unreadable debug messages and horribly unpredictable call paths.

If you think of Makefiles as a series of call paths, you're going to have a bad time. It's a dependency graph. You define rules for going from one node to the next and let Make figure out how to walk the graph.

comments