Hacker News new | comments | show | ask | jobs | submit | mhd's comments login

So you don't even build dynamic queries in the stored procedures themselves (e.g. with string concatenations and EXECUTE)?

That's where I usually get fed up with stored procedures, as pseudo-ADA ain't a nice language for list and string manipulation. I'd rather do that in a language better suited, and that quickly leads to query builders…


Wasn't that why Michael Abrash was hired by id way back when?

I do wonder how "Gopher5" would look like.

Actually, some papers written about crossbows seriously doubt that the penetrating power was that much better -- if at all. The poundage certainly was, but it had to be -- crossbow arms are short and the arrow doesn't travel as long, thus less time is available to transfer energy.

And "large populace" makes it sound like they just handed out crossbows to peasant levies, instead of them being very highly paid mercenaries. I mean, I can hand a bill or halberd to a peasant, too, but that didn't stop the Swiss from getting hired by most of Europe...

-----


Hmm. I'd be interested in seeing your source for that. Yes, the power imparted to the arrow is the integral of the poundage supplied by the bow or prod, over the distance that it is propelling the arrow, and that distance is shorter on a crossbow than a longbow. But you can have a much higher poundage and still be usable with a crossbow; you have two arms to draw together, and are supporting none of the draw weight while aiming. I've seen the analysis of draw weights of longbows on the Mary Rose; do you know where there are sources for that of crossbows?

And yeah, sorry, I didn't mean to make it sound like they were just handing out longbows. Longbows do require significantly more training. In part, the tradeoff for longbows is that you have cheaper weapons but need to put more into training the archers.

-----


Payne-Gallwey's "The Book of the Crossbow" is at least in the same category as the paper's cited "Great Warbow". At one point he tests a 15th century siege crossbow with a draw weight of 1200 lbs, which is probably close to the upper limit (and requires a heavy cranequin). IIRC the Mary Rose longbows were about 150 lbs.

But that's a steel bow, which is stiffer than wood, and the draw length is pretty small.

W.F. Paterson published a test that compared a 70 lbs bow with a 740 lbs crossbow, and the initial velocity was about the same.

Now how that equates to actual damage is another issue, and I haven't seen a really good test about that. One major factor that one has to consider is that damage varies with range, too. So what might look comparable at close range might be completely different at far range. (I think the Genoese were out-ranged by the English at Crecy.)

-----


You need some pretty specific muscles for bowmanship, which don't really equate to a bodybuilder's physique. That goes both way, I wouldn't be sure whether Arnie in his best days could draw a 150 lbs bow, and I'm dead certain that Daffyd Longbowman didn't look like a candidate for Mr. Universe.

But you still had some pretty healthy specimens, which brings to mind one important factor that's often forgotten: It's not like archers were suddenly useless when they couldn't fire their bows anymore. They were decently well armed and armored, and if you're swarmed by guys with mauls (and possibly deep in mud), your fancy chain & plate doesn't really help you all that much.

-----


The wreck of the Mary Rose has provided numerous well preserved skeletons of well trained longbowmen, and sailors (for comparison) and allowed studies of the effect upon their body. http://www.bbc.co.uk/news/uk-wales-17309665 - they found a significant difference in the lower arm bones of archers and non-archers.

-----


Very interesting. I see that asymmetry is one of the indicators: "In fact, on one of the skeletons we have looked at, the surface area of the joint between the lower arm and elbow is 48% larger than on the joint on the other arm."

I believe there was a lot of arm-and-hand labor in being a sailor, but without the bias that archery creates.

-----


The intro still assumes that the battles won by the English in the Hundred Years War were due the longbow (alone), which AFAIK is quite debatable (at least outside of England, where Agincourt is a bit of a national myth, even more than e.g. the Black Legend).

And never mind instability, the French also weren't as geographically isolated as the English and thus it was easier to hire mercenaries. Genoese crossbowman being a particular example.

The penetrative ability of the longbow is also greatly exaggerated, citing a book that did some pretty shoddy testing (flat sheets of poor quality metal used as targets, but hardened bodkins as penetrators, 10m distance, no padding).

-----


Exactly. The longbow alone doesn't win anything. It has to be used in the right situation, preferably on defensive terrain, on a hill, with dismounted knights protecting the longbowmen.

Dismounted knights was a no-go for the French nobility, who loved their glorious cavalry charge. If you're going to charge, the longbow is a lot less useful. And in battles where the French charge succeeded (because the English lacked a good defensive position, for example), the French were a lot more likely to win.

-----


France won the Hundred Years War.

-----


My bad, of course I meant the famous English victories, changed the post to reflect that.

-----


Doesn't exactly help the case for the longbow.

-----


One of the major precedents to Doom's level design was probably Dungeons & Dragons. IIRC, the id Software guys were pretty heavy players and people like Sandy Peterson and Jennell Jaquays were working for id.

-----


It's an Algol-based language. I never quite got what people "got wrong" with Perl code. Yes, I've seen bad examples, but those would've looked pretty much the same in C, Pascal or Python (deep nesting, bad names, overuse of regexps).

Back in the days one argument was using "grep" or "map" instead of explicit for-loops, but in this day of functional programming, that would seem a weird criticism.

Is it the type glyphs? ($%@)

References are a bit unnecessary, yes.

-----


Yes, it's the type glyphs. (For me, at least.) Back when I was a DBA writing database back-up scripts in Perl, I could never remember how to dereference a value in an array or hash properly. (It reminded me of my problem with pointer notation syntax in C). When I first saw Python, I thought "Wow, it's like Perl, but without the confusing notation." I rewrote the scripts in Python and never looked back.

-----


> I could never remember how to dereference a value in an array or hash properly.

I too struggled with that and came to hate it.

Perl 6 directly addressed this and some related problems.

First, sigils are now invariant - they're just a part of the name that signals which of the three data structure types a particular variable is. Second, there's no need for a `->` dereferencing op.

  my @array = 1,2,3; # `@` sigil means indexable var
  say @array[1]; # prints 2
It might be interesting to look at an example. Perhaps you could share an example of code in Python that illustrates some data structuring code that would be confusing in Perl 5 syntax, I'll try show what the Perl 6 equivalent would be, and we can see if Perl 6 really does clean this part of the language up.

-----


Nested arrays are a pain on the arse in Python. Do I use extend or append? Then strings are treated as character arrays. I far preferred Perl's approach where you would reference or dereference variables instead.

-----


If an article starts with basically "Because Uncle Bob said so", cum grano salis doesn't even cover my mindset when reading the rest of it.

Function size has been a pretty peculiar fetish. Even when viewed on the mythological 80x24 remote terminal, the initial function doesn't seem to be that hard to understand, and spreading it out between some function with lackluster naming doesn't really improve it all that much ("Computer science has two hard problems: cache invalidation, naming things and off by one errors").

Literate programming or the rather esoteric "refinements" at least had the advantage of being able to use proper sentences to describe the functional component and with the former you even had the option of being able to look at the code in both forms.

Having said that: As I'm not a Swift programmer (ba-doom-tish), is this all the language has that approaches Design By Contract?

-----


> If an article starts with basically "Because Uncle Bob said so", cum grano salis doesn't even cover my mindset

Uncle Bob is a recognised expert in the area. So no, his opinions on SRP should not just be dismissed out of hand.

-----


It's a bit like learning a language, you'd need some almost immediate application to make it past the first steps of a book or course (and/or make that gained knowledge stick). And while it's easy enough to travel to some country where they speak a language you just learned, that's often harder when it comes to mathematics and IT.

3D maths and game development worked out somewhat in the past (I forgot most of it though, and as that was the DOS days it wasn't really more than high school level geometry). But I doubt that I could find enough real noticeable application for e.g. category theory.

(Just being the basis for something often isn't enough. You don't need to know much about physics to hop on a trampoline.)

-----


I was going to say, a lot of the Math I learned in High School and then never applied to anything I re-learned more recently when I started mucking around with computer graphics and game dev (especially trig, matrices, vector math, etc.)

I'd love it if people had suggestions for other engaging ways to apply math while programming!

-----


I highly recommend Jeremy Kun's blog - Math and Programming (http://jeremykun.com/). His posts are always awesome.

-----

More

Applications are open for YC Summer 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: