

Free your technical aesthetic from the 2010s - jdale27
http://www.storytotell.org/essays/74-response.html

======
danieldk
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...](http://enfranchisedmind.com/blog/posts/what-good-is-a-cs-degree/)

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.

~~~
oconnor0
Are you arguing that RDBMS can handle all of the data, performance, and
scalability requirements as well as a kv store while also in BCNF?

~~~
dxbydt
There's no real argument cause these are orthogonal concerns.

In general, you'll have a bunch of concerns. 1\. BCNF 2\. ACID 3\. Performance
4\. Scalability 5\. Ease of implementation

Before noSQL, you'd prioritize in that exact order. Post noSQL, the order has
precisely reversed. There used to be pricey Oracle consultants ( and Sybase
consultants & DB2 consultants & so on....data architects of all stripes).
They'd come in, study your data in some depth & figure out which attributes
were single-valued, which ones were multivalued, which bunch went into which
tables, who the primary keys & foreign keys were, what the typical views would
look like, what joins would that involve & could you do away with some of
those joins....hell, even the typical interview questions for a fresh grad
having absolutely nothing to do with databases would still involve Outer Join,
Inner Join, difference between the two, here take the Employee spreadsheet and
the Company spreadsheet and decompose into tables upto 3.5NF, list all the
keys & tell me how many joins you'd need for a view that lists all employees
in Accounts making over 70k between the age of 35 and 45 in Illinois. All of
the above is pure relational logic. Its completely tech-agnostic. You don't
even need an actual database to answer any of that. Nowadays, the questions
are more along the lines of - How do you deploy MongoDB ? Great, you're hired,
cause Mongo will handle the scalability & performance & if it doesn't we'll
just add another node....imo, this is a vacuous line of thought.

------
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.

~~~
pnathan
Yeah, when a native app crashes, it just dies.

Whereas, generally with Common Lisp, I can trap the condition, fix the
problem, and keep running.

I know what languages I'd consider starting grounds for 100% uptime systems
(not 5 9s), and languages that segfault and die as part of their usual crash
hangling are not among them.

(Erlang, Lisp, and Smalltalk would be my shortlist)

~~~
bonzoesc
Picking nits here, but (limited) crashing (by design) is exactly why Erlang's
failure handling is solid. It's like an automotive crumple zone for your
application.

~~~
william42
An Erlang crash is of an Erlang process, which is a tiny green-thread with
shared-nothing. That's very different from a C program segfaulting.

~~~
bonzoesc
Not if your application is a bunch of small C programs that monitor each other
a la DJB.

------
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.

~~~
jamieb
And then, 30 years later, came Siri and IBM's Watson...

Winograd talks about three different metaphors for HCI: conversation,
manipulation and locomotion. In the 70's he gave up on conversation for
manipulation, and was right do to so, but with modern computing power and
databases, conversation is coming back as a relevant model.

------
stralep
What I like about UNIX: Everything is a file.

Except of processes.

And sockets.

And XWindows.

~~~
gaius
/proc and /dev/tcp

[http://tldp.org/LDP/Linux-Filesystem-
Hierarchy/html/proc.htm...](http://tldp.org/LDP/Linux-Filesystem-
Hierarchy/html/proc.html)

[http://www.linuxjournal.com/content/more-using-bashs-
built-d...](http://www.linuxjournal.com/content/more-using-bashs-built-devtcp-
file-tcpip)

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

~~~
stralep
I agree, but this should have been from the start, or at least from UNIX-
Internet marriage. My point was little tongue-in-cheek, but I believe that
during the years UNIX has got things that are not truly with their initial
idea. Or little more interfaces than necessary.

------
gfodor
relevant talk by Alan Kay:

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

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

~~~
sp332
Why do you say that? The content or the style?

------
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?

