
Three Things I Wish I Knew When I Started Designing Languages - matt_d
https://www.infoq.com/presentations/language-design-process
======
jfengel
The semantics of negation is like security: there's an urge to ignore it at
the beginning because it's not the use case you have in mind, but it turns out
that it's absolutely fundamental to everything. You have to build it in from
the beginning; you can't layer it on afterwards.

Different negation semantics put you in different computability classes. And
there's a tension: you want more powerful semantics, but they take longer to
run. Full first-order logic is great, but it's also exponential time to
evaluate. (Also, the semantics of negation for FOL are easy to explain but not
actually very similar to what you expect negation to mean in real life,
leading to unexpected semantics.)

------
asplake
“He summarises by saying the only good reason to design a programming language
(I assume he means a radically novel language) is to shape your understanding
of the problem. No regrets of being the only user of his first language,
Datalist, because the point is that it shaped all his later thought in his
research.”

I don’t design languages but I speak and write (iterating between different
forms) for much the same reason. Thoughts made concrete in some way are much
easier to manipulate. Programming can be much the same.

~~~
Klathmon
This is also why I'll often not ask important questions in meetings and will
instead ask them in a chat message or email.

Not only does the act of writing it out make me ask a better question (and
there are times I answer the question myself before sending it!), but the
answers are often much better when written down. (Not to mention the
additional benefits like easier searchability)

~~~
lugg
Discussion is cheap. If it is on topic, saying something stupid quickly and
then rolling back the conversation is a far more efficient use of your time.

You do need to pick your audience.

Some people really struggle with this style of conversation. The rapid
depreciation/substitution of facts can be a tad tiring.

But for those that can take it, this is essentially the same as writing things
down but it's faster and has the added benefit of at least one other person
"checking your math" as you go.

~~~
Klathmon
Don't get me wrong, a realtime discussion is extremely important in many
cases. When brainstorming or talking through bugs or building something
collaboratively, it doesn't get any better than an in-person or video meeting.

But when it comes to more complicated details, one-off questions, important
decisions, or bringing the "results" of an investigation to a group, text is
just better a lot of the time.

I can't count the number of times that a decision was made verbally in a
meeting only to find that half the meeting misunderstood the decision or can't
remember details about it the next day. Or going to discuss a complex
bug/problem and having to spend a significant amount of time talking about the
"setup" to the problem rather than the problem itself.

It's those cases where spending 5 minutes writing the question up and letting
people read and understand it before jumping into a meeting, or even something
as simple as following up a meeting with a written summary of the important
points made can be very powerful.

~~~
joshmarlow
> I can't count the number of times that a decision was made verbally in a
> meeting only to find that half the meeting misunderstood the decision or
> can't remember details about it the next day.

I've had the same experience, but I tend to follow a hybrid approach; bring up
everything you can think of in the meeting, then immediately following up with
an emailed recap of what was agreed upon. It helps make the verbal decisions
explicit and iron out additional details.

------
sshine
> Jeff Ullman's claim that encapsulation and declarativity are in tension

Can someone provide an elaboration on this, or link to this claim?

~~~
mjburgess
SELECT name FROM users;

Users.getName();

The above is "encapsulated" meaning that you need to have done the extra work
to write "getName". Encapsulation is a bad solution to a worse problem
(changing state).

If you hide information you have to do extra work to get it out. This "extra
work" is in tension with a declarative approach which uses general verbs
across domains, requiring therefore, these domains expose their data.

~~~
fnord123
>This "extra work" is in tension with a declarative approach

No it isn't. They work complementary to each other. If User is an interface
then retrieving the name could be a call to a db, read from a file, read in
memory, http GET request, it doesn't matter. The declarative component here
does not care how the request is fulfilled as long as the interface is
respected.

~~~
0815test
The problem is that encapsulation makes it hard to specify reasonable
constraints. For example, a "getter" might come with a constraint that "x =
myobj.GetX(); myobj.SetX(x);" should not change the observable behavior of
myobj. Or that "myobj2.ConstructFromXY(myobj.GetX(), myobj.GetY());" should
result in a "myobj2" that's in some ways indistinguishable from "myobj". With
a "declarative" approach, these constraints are implied in the system itself.

------
dang
Url changed from [http://lambda-the-ultimate.org/node/5569](http://lambda-the-
ultimate.org/node/5569), which points to this.

~~~
chalst
The virtue of the LtU link is that it gave a brief outline of the talk.

