Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The naked truth about writing a programming language (2014)

digitalmars.com

Post reply on HN
Print view View original

71–80 of 212 posts

Re: The naked truth about writing a programming language (2014)

#71

Post by matheusmoreira »

WalterBright wrote: post #37
matheusmoreira wrote: post #31

Is it true that optimization follows the 80/20 rule? What are some common performance issues that new languages and their implementations face? Are there common optimization techniques that can be applied in order to make the new language competitive with existing ones? For example, I know that it's generally better to compile programs into a linear code structure such as bytecode instead of interpreting a tree struc…

Optimizing code is a book-length topic just for an introduction. It's also true that knowing how optimizers work can feed back into improving the language design. For example, `const` in C++ doesn't mean the data is immutable - it can change with any assignment through a pointer. No optimizations assuming immutability will work. That's why D has an `immutable` qualifier, giving the optimizer to do optimizations assum…

> That's why D has an `immutable` qualifier, giving the optimizer to do optimizations assuming it does not change.

Which optimizations are enabled by immutable data? I can think of constant folding. Is the data statically allocated in a read-only page?

> For a famous example, Fortran assumes two arrays never overlap. In C/C++ they can. This is the source of a persistent gap in performance between Fortran and C/C++.

What sort of optimizations does this assumption enable? Does it allow the compiler to freely reorder or parallelize the code?

C assumes that pointers to different types are never equal. This is incompatible with common systems programming concepts such as type punning. Even something simple like reinterpreting some data structure as an array of uint8_t can make the optimizer introduce bugs into the code. Notably, the Linux kernel is compiled with strict aliasing disabled:

https://lkml.org/lkml/2003/2/26/158

https://lkml.org/lkml/2009/1/12/369

Re: The naked truth about writing a programming language (2014)

#72

Post by WalterBright »

mhh__ wrote: post #52
Rochus wrote: post #45

Earlier quoted context omitted.

What is your opinion about self-hosting (i.e. writing the parser/compiler in its own language)? Is that really desirable, or even necessary, or just a gimmik (I know what Wirth says, wonder what you think)?

(Not Walter but) Self-hosting in a compiler should be done wherever possible - if we ignore that if the compiler self-hosts it becomes it's own test suite (writing tests is good but it's quite difficult to find weird behavioural bugs using unittests if the tests only test one thing at a time) - it makes it so much easier to work on the compiler (For example, the main D compiler can build itself in a second or two on…

Yes on all points. I'll add that I invented D because D was the language I wanted to write code in. The D compiler was originally written in C-with-Classes, and it became increasingly irritating for me to have to be working in that language rather than D. Thankfully, the DMD compiler is now 100% in D and I've been slowly refactoring the code into much more pleasing forms.

Re: The naked truth about writing a programming language (2014)

#74

Post by Animats »

kohtatsu wrote: post #67
Animats wrote: post #54

That's a good set of questions for 2014. Questions that have become important more recently include: - Imperative? Functional? Some mixture of both? Mixtures of the two tend to have syntax problems. - Concurrency primitives. The cool kids want "async" now. Mostly to handle a huge number of slow web clients from one server process. Alternatively, there are "green threads", which Go calls "goroutines". All this stuff i…

Just wanted to say thank you for all the contributions you add. It's always a pleasant surprise to scroll back up and see your username on a comment I just delved into.

Well, I blew it yesterday, not knowing that Python really does do a > b > c expressions as a special case.

Re: The naked truth about writing a programming language (2014)

#75

Post by renox »

Animats wrote: post #54

That's a good set of questions for 2014. Questions that have become important more recently include: - Imperative? Functional? Some mixture of both? Mixtures of the two tend to have syntax problems. - Concurrency primitives. The cool kids want "async" now. Mostly to handle a huge number of slow web clients from one server process. Alternatively, there are "green threads", which Go calls "goroutines". All this stuff i…

I`m not so sure about ownership, sure it's nice to be able to brag no GC and being memory safe, but this has a huge complexity cost.. IMHO adding to the compiler a GC/ASan for the debug mode (to detect double free, use after free, leaks) is a valid option.

Re: The naked truth about writing a programming language (2014)

#76

Post by pbiggar »

tomp wrote: post #47
pbiggar wrote: post #24

This advice is quite good for certain types of programming language, if you look at the world the same was as he does. We're implementing Dark from a completely different worldview, and from that vantage point, a lot of these aren't exactly wrong, but different. > Syntax matters The approach we took with Dark is that there isn't a syntax, per se, in that there isn't a parser. There's certainly a textual view of Dark…

> The approach we took with Dark is that there isn't a syntax, per se, in that there isn't a parser. Can you explain how that works? Unless Dark is a purely visual programming language (in which case I'd say that there is "syntax", it's just a bit more abstract, and in any case, it seems that visual languages haven't really caught up as an idea), I find that hard to believe.

Sure. You can see it in action at http://darklang.com/launch/demo-video (also, we've gone through our waiting list, so we're pretty much adding new folks who sign up immediately, if you want to try it out).

The main idea is that you when you make a change (let's say, you type a key in the editor), that change happens directly on the AST (the internal set of objects that represent the program). So for example, if you're seeing:

    let x = 5
    x + 2
we represent that internally as `Let ("x", Int 5, BinOp ("+", Var "x", Int 2))`

In a normal programming environment, you type up text, and the parser converts it to the internal representation. With Dark, we always keep everything in the internal representation. That means, if it isn't a "syntactically" valid program, you can't create it in the first place.

In practice, this means that if you type, for example, `z` in the middle of `let`, in a traditional language you'd get an error like `lzet is not a valid token` and in Dark, the `z` just wouldn't appear (nothing would happen). So it's not possible to get a syntactically invalid program.

The overall idea with Dark is that programs are always live (and also safe). So to make that be true, we need to ensure that you don't spend a period of time in a state where we can't understand your program (such as when the syntax is invalid).

Re: The naked truth about writing a programming language (2014)

#77

Post by DonaldFisk »

WalterBright wrote: post #33
didibus wrote: post #8

After learning s-expression based syntax, I am just baffled why we even bother with anything else. When you play around with different Lisps, the syntax is always the same, the language differences becomes the semantics only. Other languages put too much emphasis on the syntax in my opinion. And while I understand the "popularity" appeal. I've almost never seen someone learning the s-expression syntax and afterwards…

This reminds me of the debates in college (late 1970's) of RPN calculators vs Infix calculators. RPN's big advantage was reduced number of keystrokes, which is important with a calculator. But when dealing with formulas where you can actually type with a keyboard the number of keystrokes is not important, readability is much more important, and infix wins. > I've almost never seen someone learning the s-expression sy…

It's whatever you're used to, but using sexprs means you don't need to write parsers because you have the read function. In Lisp, it's important to give the user access to the parse tree.

Since the S-expression syntax for Lisp was chosen, there have been at least three documented attempts to replace it: Lisp 2, CGOL, and Dylan. Lisp 2 syntax wasn't implemented and was only ever used in textbooks, and CGOL and Dylan were never popular and are no longer used. All Lisps today use S-expressions (but Clojure has [] and {} as well as ()), as do some Prologs, as well as a few other languages such as CLIPS. Readability is taken care of by the prettyprinter.

For arithmetic expressions, I agree infix is easier to read because that's what maths uses. For complex formulae, I wrote a Lisp macro which accepts infix notation and I'm sure other Lispers have done likewise.

Re: The naked truth about writing a programming language (2014)

#78

Post by massysett »

zzo38computer wrote: post #41
chubot wrote: post #9

Earlier quoted context omitted.

The two top answers are in conflict. The second answer with 43 points is closer to right: There are hardly any real-world programming languages that are context-free in any meaning of the word. The first answer with 41 points is totally wrong: The set of programs that are syntactically correct is context-free for almost all languages ----- A better source is this whole series by Trevor Jim, which has nice ways of rel…

Is Haskell context-free if you don't use the indentation layout mode? Haskell does support using braces and semicolons too. However, this is not true of Python (as far as I know).

In theory Haskell supports braces and semicolons but in practice nobody uses them, leading to bugs like this one:

https://github.com/haskell/haddock/issues/12

Re: The naked truth about writing a programming language (2014)

#79

Post by DonaldFisk »

chrisseaton wrote: post #20
didibus wrote: post #8

After learning s-expression based syntax, I am just baffled why we even bother with anything else. When you play around with different Lisps, the syntax is always the same, the language differences becomes the semantics only. Other languages put too much emphasis on the syntax in my opinion. And while I understand the "popularity" appeal. I've almost never seen someone learning the s-expression syntax and afterwards…

> I've almost never seen someone learning the s-expression syntax and afterwards not liking it. I don't particularly like s-expression syntax - I think s-expressions suit the computer at the expense of the programmer, which I think is backwards. I think they're verbose and noisy and that obscures the meaning I want to see in the text as a person. Yes they're easier to parse, but I want to make my life easier, not the…

You might argue that s-expression syntax is "worse is better" but I'd argue that more complex syntaxes are "accidental complexity." You need a parser, you need a more complex prettyprinter.

Without s-expressions you also lose programmer access to the parse tree.

For the usual arithmetic operators I've never had any problem, but I was once caught out when programming in C by getting the precedence of > wrong (at least to me, it's counterintuitive), and it took a few hours to find the bug, because my code looked correct. Had I just parenthesized everything, that bug wouldn't have happened.

Re: The naked truth about writing a programming language (2014)

#80

Post by MauranKilom »

WalterBright wrote: post #37
matheusmoreira wrote: post #31

Is it true that optimization follows the 80/20 rule? What are some common performance issues that new languages and their implementations face? Are there common optimization techniques that can be applied in order to make the new language competitive with existing ones? For example, I know that it's generally better to compile programs into a linear code structure such as bytecode instead of interpreting a tree struc…

Optimizing code is a book-length topic just for an introduction. It's also true that knowing how optimizers work can feed back into improving the language design. For example, `const` in C++ doesn't mean the data is immutable - it can change with any assignment through a pointer. No optimizations assuming immutability will work. That's why D has an `immutable` qualifier, giving the optimizer to do optimizations assum…

> For example, `const` in C++ doesn't mean the data is immutable - it can change with any assignment through a pointer.

In C++, an object declared as `const` cannot be changed by assignment through a pointer. Maybe you are thinking of const references?

For example, a `const int x = 10;` cannot be changed. Neither through `const_cast` nor through pointers nor anything else - it's UB in every case.

Post reply on HN