Free your technical aesthetic from the 2010s

[microtonal]

It's true that most natural languages cannot be parsed with a CFG, but he gives the wrong example. In fact, the language of the grammar that he describes can perfectly be generated by a CFG. E.g. for a rule such as:

  sentence --> noun_phrase(Num), verb_phrase(Num).

You could create the CFG equivalent:

  sentence --> noun_phrase_sg, verb_phrase_sg.
  sentence --> noun_phrase_pl, verb_phrase_pl.

It sure is a drag, but this is how many CFG grammars/parsers work. Of course, it's generally agreed upon that DCGs generalize better even when used with grammars that can be described with a CFG.

Most natural languages are not context-free, but he gives the wrong example. To provide a more convincing example - in Dutch you can construct phrases like:

dat ik Marie Jan de dozen zie helpen inpakken (lit: that I Marie Jan the boxes see helping packing)

The NPs and the verbs correspond in the following manner: ik - zie, Marie - helpen, Jan - Inpakken. Or, more formally, the structure is: np_a np_b np_c np_x v_a v_b v_c. Of course, this highly resembles a COPY language, which cannot be expressed using a CFG, but (obviously!) can be expressed using a DCG:

  s(L) --> w(L), w(L)
  w([a|Rst]) --> [a], w(Rst).
  w([b|Rst]) --> [b], w(Rst).
  w([]) --> []

(This grammar parses/generates a string of zero or more a's and b's, followed by exactly the same string.)

[shadowsun7]

"Those who don't understand UNIX are doomed to reinvent it, poorly."

--Henry Spencer

Which can then be turned into:

"Programmers who do not understand history are doomed to reimplement it - poorly" - http://enfranchisedmind.com/blog/posts/what-good-is-a-cs-deg...

I thought both of them were good sayings to keep in mind, while reading the above post.

[batista]

On the other hand, those that understand UNIX all too well, are doomed to recreate and use it ad infinitum, in lieu of creating something better.

At least the ACTUAL developers of UNIX created Plan 9, they didn't put their hands up and said "this is how you do things, no improvements can be made".

For example, when I see the lame "it's how it was always done", arguments against a sane FS hierarchy like the one gobolinux attempts at, I want to tear my hair off.

[dkarl]

It's strange that we live in such a bifurcated world, that on the one hand we have astronomical demands for a certain class of program, but for the kinds of programs we use day-to-day, they're shockingly procedural.

Programmers, by virtue of being a little bit understanding and forgiving of computers' nature, can enjoy software that frustrates the hell out of normal people.

It gets pounded into us over and over again that normal people are the right standard to build software to, but once in a while we should allow ourselves to enjoy something like the blocks program, even if it would never pass an A/B test against a blank screen.

[TeMPOraL]

"Cocoa doesn't have this. C# doesn't have this. Nothing else has this."

Lisp has this. It has probably invented this.

[arethuza]

Sounds like Lisp image files and .Net dump files:

http://stackoverflow.com/questions/480083/lisp-image

http://msdn.microsoft.com/en-us/library/d5zhxt22.aspx

[stevencorona]

You had me until the NoSQL rant. I see what you're saying, but modern data stores such as Cassandra, Riak, Mongo, Redis etc. are solving different problems and, IMO, it's ignorant to say that they are simply reinventing the wheel. There is life beyond RDBMS and ACID.

[dxbydt]

In graduate school, I was taught RDBMS & ACID by a Math Professor with a Math PhD, who later got a CS PhD, & personally interacted with Date & Codd. My key takeaways from that experience were:

1. There's a very stringent one-to-one mapping between RDBMS & relational logic. To put it another way, BCNF is not a matter of taste. Its a matter of adhering to the rules. If two dozen data architects are given the same many to many relation, and asked to take it through 1NF to 2NF to 3NF to BCNF and then stop, every single one of them will have the exact same answer. And this is because normalization is an extremely formal process => formal in the mathematical sense of the word. Two sets that have a given many-many relation will decompose to the exact same subsets because the mathematics of BCNF is unambiguous. This is incredibly powerful => Because there's a wrong answer! So if you hire a data architect & the guy gives you a BCNF & you crosscheck that BCNF with a more reliable architect, you are checking if the answers agree objectively. Its just straight math, not a matter of subjective taste as to which should be the primary key & which should be the foreign key & how the transtive dependence works out. 2. With objects in the mix, the relationship is already on creaky foundation. ORMs have an impedance mismatch because the relationships captured by notions of inheritance, polymorphisms, mixin traits - these don't have an exact mapping onto the set-theoretic notions captured by BCNF. Morover, there is a matter of subjective taste. You might design your UML differently from me & you might have valid reasons to do so. So while your BCNF exactly matches mine , your object model won't. 3. With kv stores, your relations are even more mathematically fuzzy. You are storing entire multi-valued objects and your rows have variable number of columns & at times you are dealing with completely denormalized structure. The math simply doesn't apply at these levels, and people tasked with populating a NOSQL structure will come up with wildly differing solutions that are completely unsound from a mathematical standpoint, but will nevertheless perform ( upto a certain threshold ) simply because machines have gotten faster & network latency issues aren't holding them back.

I see more & more firms pick #3 because of trends( latest & greatest), lack of expertise to do #1 properly, or because of some false sense that scalability will bite them in the ass if they do #1 instead of #3, but primarily because #3 is EASY and #1 is hard. Its nice to not worry about normal forms & just have a multi-column row which grows & shrinks...but is it sound ? Am not sure.

[etrain]

I have serious problems with the relational data model, but I do think he raises a good point. This relational stuff has REALLY strong fundamentals and is battle tested. There are a lot of people out there shouting 'scalability!' without understanding the roots of their problems. Is a fully distributed persistent k/v store what's needed for many applications? Certainly. But that doesn't mean we should throw out the relational model for every application.

[rbanffy]

Indeed, there is, but it feels oddly familiar, for those raised in the ancient era of ISAM, IMS and Total, to once again need to worry about consistency.

NoSQL databases (and not all of them are hierarchical) solve problems Codd wouldn't dream of having, but that doesn't mean they solve every current problem. I've seen people abusing them in horrible ways.

[franklovecchio]

There is definitely a learning curve associated with proper NoSQL data-modeling (and slightly different for each of the above stated DBs), but a place for both relational and non exists, as they each solve different problems! (NoSQL being really good at time-series data)

[weavejester]

The author seems to have the attitude of "I don't understand why people do X, therefore people who do X are morons."

[taybenlor]

"instead of reading an exception trace, you get to load the actual moment the exception was triggered into your local debugger and pick up from there as if it just happened locally!"

I want this.

[Negitivefrags]

You already have it!

This is what our good old friend the core dump is for. Load the core dump in GDB and there you are.

I'd argue that on windows it's even easier. You can create a symbol server to store all the debugging info (the PDB files) and the debugger can download the correct symbols for that particular compiled version.

The PDB format supports having an arbitrary commands added to procure each source file. You can connect this up to your version control system so that not only do you have the stack and symbols, you can actually browse around the source code of whatever version of the code actually crashed just as if it had crashed locally.

On linux you have to work out a system for archiving your symbols and getting them for the correct version of your software yourself, but the effort is certainly worth it.

We have a system to generate HTML reports each day by grouping crash dumps by the functions near the top of the stack (if the top 5 functions are the same, it's considered the same crash), so each day we can see what the most important crash is.

[nitrogen]

You could do it with C++ by enabling core dumps and wrapping any "throw" statements (or altering the constructor for the exception classes you want to monitor) with an operation that dumps the core. There's also the "gcore" utility I discovered while researching this comment.

[wazoox]

Aaaah, SHRDLU, fond memories. When I was 7 around 1977 I had a wonderful magazine on robots (I still have it somewhere), and it had a long chapter on SHRDLU, and an interview with its programmer Terry Winograd. This was the first time I was captivated by computers, programming and pure unadulterated geekery.

[msutherl]

After SHRDLU, Winograd denounce AI as hogwash and was instrumental in starting what we now know of as interface design/HCI.

[gfodor]

relevant talk by Alan Kay:

http://tele-task.de/archive/video/flash/14029/

[webnrrd2k]

I've had a lot of the same thoughts, although in a much simpler form. So, of course, I think the talk is brilliant. Thanks for posting it.

I found it especially relevant how he illustrated thinking in terms of imprinting and erosion. I've been thinking about my personality, and how I think about things, in different, but oddly similar terms.

I also agree that personal computing is, to a large extent, re-inventing the past. The best quote I heard on that, as best I can recall, is "The PC recapitulates the mainframe", which is borrowed from Biology's "Ontogeny Recapitulates Phylogeny".

[wseymour]

I love the content of that presentation as well as the fact that the presenter was clearly as high as a kite.

[stralep]

What I like about UNIX: Everything is a file.

Except of processes.

And sockets.

And XWindows.

[etrain]

You missed the point. This is why he talks about Plan 9. In Plan 9, everything IS a file. Including sockets, and windows, and processes. Several of these features have made their way back into linux.

[gaius]

/proc and /dev/tcp

http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/proc.htm...

http://www.linuxjournal.com/content/more-using-bashs-built-d...

X is just a protocol, you can happily think about X apps in terms of processes and sockets.

[bergie]

As far as I can understand, this was exactly the problem that Plan9 tried to fix. UNIX had started from the concept of "everything is a file", but then as new things got added, those didn't follow the philosophy. Plan9 was an attempt at a fresh start where such non-UNIXisms could be moved back to files.

[gurkendoktor]

One reinvention of remote debugging at the source of an exception is this, in Ruby:

https://github.com/Mon-Ouie/pry-remote

Now, if I only had the same thing for Cocoa Touch - after all, both languages are supposed to inherit from Smalltalk.

[SonicSoul]

speaking of aesthetic, this post has huge fonts, and a horizontal scroll. luckily there's readibility: http://rdd.me/ycoese07

[angersock]

I'm not sure if you noticed, but readability here seemed to drop some headers and also render the special font sections (code snippets, etc.) in skinnier and less legible text.

The scrollbar seems due to the conversation with the computer about the blocks--barring that, nothing else is offpage.

Really?