sedachv · HackerTrans

قبل 4 سنواتdiscuss

_Test Driven Development: By Example_ certainly had the highest ratio of dumb unnecessary jokes to contrived unconvincing examples of any programming book I have read. My copy of TAOCP volume 3 doesn't even begin to compare. Clearly Knuth was doing something wrong.

sedachv

قبل 4 سنواتdiscuss

You just copy-and-paste the relevant input-output and there is your test. There isn't a need for any extra tools when using the REPL to come up with regression tests (obviously a REPL cannot be used to do TDD).

sedachv

قبل 4 سنواتdiscuss

TDD use would be a lot different if people actually bothered to read the entirety of Kent Beck's _Test Driven Development: By Example_. It's a lot to ask, because it is such a terribly written book, but there is one particular sentence where Beck gives it away:

> This has happened to me several times while writing this book. I would get the code a bit twisted. “But I have to finish the book. The children are starving, and the bill collectors are pounding on the door.”

Instead of realizing that Kent Beck stretched out an article-sized idea into an entire book, because he makes his money writing vague books on vague "methodology" that are really advertising brochures for his corporate training seminars, people actually took the thing seriously and legitimately believed that you (yes, you) should write all code that way.

So a technique that is sometimes useful for refactoring and sometimes useful for writing new code got cargo-culted into a no-exceptions-this-is-how-you-must-do-all-your-work Law by people that don't really understand what they are doing anymore or why. Don't let the TDD zealots ruin TDD.

sedachv

قبل 8 سنواتdiscuss

> Raising graph analysis to the level of linear algebra is brilliant.

Adjacency matrices is how graph problems were handled by APL programmers in the 1980s, mostly because there was no alternative before nested arrays. At the time, there was not a lot of vectorized hardware, and main memory sizes were too small for many problems, so the adjacency matrix representation was more of a problem than a good solution. It's really the advances in vectorized hardware and main memory sizes that have made this technique practical for large graphs.

sedachv

قبل 9 سنواتdiscuss

Good point. I always have to set whatever GPS I am trying to use to fixed scale (no auto-zoom) map view with "north is up" before things feel right.

sedachv

قبل 9 سنواتdiscuss

> I can't imagine why you wouldn't want navigational assistance.

Here is why I look up directions in advance in almost all situations:

* GPS is a distraction to maintaining awareness while driving, motorcycling, and bicycling.

* Navigational assistance does not help you when walking, taking public transit or taxis. Using GPS while driving prevents you from learning the layout of the place you are in which transfers to navigational competence for these other modes of transportation.

* You miss fun roads when following GPS navigation.

* GPS navigation is useless when planning long bicycle and motorcycle tours. I pick waypoints and routes between them in advance.

* GPS will route you into sketchy situations (like to phantom bridges) that you could have predicted by looking at a map.

* GPS does not take weather conditions into account when routing. People have gotten into floods (easy to see when looking at rivers and topo on a map in advance), stuck in snow, and have even died in the desert: http://www.sacbee.com/entertainment/living/travel/article257...

I do not know very many competent drivers who rely on GPS navigation. I see plenty of "GPS zombies" obliviously plowing through intersections and ignoring crosswalks every day.

The most use I get out of having a GPS dash unit is on trails and off-roading in my truck or motorcycle, where there is usually no signage for forest roads and trails.

sedachv

قبل 12 سنةdiscuss

Exactly. You have to drop hooks into the lexer from the parser, and by the time you're done you end up with just as much code. Only it's slower than a recursive-descent parser would be, and a lot of the time parsing speed really matters because it shows up as user-visible latency.

sedachv

قبل 12 سنةdiscuss

Flex does not work fine, that's why you need the lexer hack: https://en.wikipedia.org/wiki/The_lexer_hack

Non-working (no lexer hack) Flex and Bison specification for C99: https://gist.github.com/codebrainz/2933703 653 lines

Hand-written recursive-descent C parser and pre-processor (something not handled by Lex/Yacc) that produces executable Common Lisp code: https://github.com/vsedach/Vacietis/blob/master/compiler/rea... 935 lines

sedachv

قبل 12 سنةdiscuss

Yes. This is the reason it is way easier to hand-build a parser for C than try to use any kind of parser generator.

sedachv

قبل 16 سنةdiscuss

"JavaScript already has gotos in the form of labels and break."

Actually, no, it doesn't. I don't know anything about JavaScript.

sedachv

قبل 16 سنةdiscuss

"You're right. Scheme implementations usually have unboxed fixnums and other types. However Scheme systems do not usually support user defined unboxed objects, like C#, C and ML do."

That's because Scheme has to support type safety for arbitrary code loaded at run-time. Exactly like JavaScript has to do when the web browser GETs a script. Exactly what any of the other proposed ILs would have to do as well.

"I agree, I did mean tail calls. Tail calls may not be so good for programming with, but they are good for compiling to, because you can easily encode your control structures like while, for, until, state machines and more exotic forms of looping to them. You can also compile (parts of) code in continuation passing style without blowing the stack, which is hard to do efficiently if you don't have tail calls.

The reverse is not true, you cannot easily express tail calls on top of the usual control structures like while. This is why Scala and Clojure still don't have support for tail calls."

A better argument can be made for gotos than tail calls in this case. JavaScript already has gotos in the form of labels and break.

Tail call faking doesn't always have to have a trampoline overhead cost. Take a look at Scheme2JS for how they do it (http://www-sop.inria.fr/indes/scheme2js/)

"I'm not arguing that Java is better than Javascript for programming in. It's just a better target for compilers."

JavaScript provides run-time types and extensive reflection and introspection facilities. This makes it relatively straightforward to write something like Parenscript. OTOH trying to compile even a static subset of Common Lisp to C or Java is pretty complicated.

"Do you have any arguments to back up why ML would not be a better IL than JS?"

Your original statement was: "I challenge you to find a language that would have been a worse choice than Javascript." Given the state of ML implementations in 1995, I think it would have been a worse choice.

"It seems to me that you are arguing that these languages are not better than JS for programming in, but that is not what I claimed."

And you seriously think people would have first run out and built compilers from other languages to the "hypothetical better than JavaScript" language rather than use the latter directly? Because that's not what actually happened.

sedachv

قبل 16 سنةdiscuss

"- Scheme: this would have been a much better choice, because it supports integers and has a compact object representation instead of representing everything with hash tables. Bad point: all objects are boxed (like in JS). Good point: tail calls are handy when compiling all kinds of control structures."

The boxing part is untrue. Even on 32-bit systems (that have word-aligned addressing, which all current 32-bit systems do), you can get 6 arbitrary type tags by using up the three least significant bits of a pointer (6 and not 8 because you use up two of the possible tag values for even/odd immediate integers (fixnums)).

Tail calls are overrated, maybe you're thinking about continuations? Those would have been truly terrible - you get all the downsides of concurrency with no benefits. One of the reasons arbitrary crap JS code runs as well as it does is because there's no possibility of concurrency. The browser event-loop model is a good one.

"- Java: As an IL to compile down to this would have been better than Javascript. Good points on top of Scheme: unboxed primitive types, static typing means fewer runtime checks."

Don't forget: getting sued by Oracle.

Java blows in every way compared to JavaScript. If Netscape had put Java instead of JS into Navigator the web would be a very different place today, because no one would have used it [Java].

"ML: excellent choice: has both unboxed primitives and tail calls."

In 1995? Give me a break, or a time machine.

comments