The naked truth about writing a programming language (2014) • Hacker News Board

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

#91

Post by zzo38computer » Sun, May 03, 2020, 12:16 AM UTC

massysett wrote: post #78

zzo38computer wrote: post #41

Earlier quoted context omitted.

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

I do use braces and semicolons when programming in Haskell, and I have encountered that bug before, and I hope that they will fix it (although it still seems to be unfixed after six years, but a few people clearly do care, even if others don't care).

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

#92

Post by WalterBright » Sun, May 03, 2020, 12:30 AM UTC

matheusmoreira wrote: post #71

WalterBright wrote: post #37

Earlier quoted context omitted.

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++. W…

> Which optimizations are enabled by immutable data?

    int test(immutable(int)* p, int* q) {
      foo(*p);
      *q = 4;
      foo(*p); // don't have to reload *p
    }

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

#93

Post by WalterBright » Sun, May 03, 2020, 12:31 AM UTC

MauranKilom wrote: post #80

WalterBright wrote: post #37

Earlier quoted context omitted.

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.

pointer to const int

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

#94

Post by robocat » Sun, May 03, 2020, 12:44 AM UTC

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…

Aside: this is the most amazing optimisation information I have seen: https://www.youtube.com/watch?v=r-TLSBdHe1A

Unfortunate that it is a video...

Summary: Modern CPUs have so many hidden causes of performance variation, that you require special tools to actually measure small performance gains. He finds an amazing but unobvious speed up in SQLite using the causal analysis tool they developed. And a surprising difference between -O2 and -O3 implying overfitting.

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

#95

Post by lioeters » Sun, May 03, 2020, 12:45 AM UTC

DonaldFisk wrote: post #64

You might be doing this as a learning exercise, in which case it doesn't need to be particularly innovative, and writing another Lisp or Forth implementation is fine. In fact, I'd recommend beginning along those lines, followed by developing several different new languages, probably domain-specific ones. Your first attempts probably won't be worth keeping. (I haven't kept the object oriented Prolog I wrote about 25 y…

> I have to write an IDE as well as the language

This part caught my attention. I've developed a few small languages over the years, with somewhat boring syntax in Lisp or Algol family. The one that has the most longevity (~7 years) and traction (estimated few thousand users) is an XML-based (!) domain-specific language. Frankly it's verbose and kind of ugly, but apparently easy to learn due to its regular, minimal syntax - a little like Lisp, if parentheses were brackets. It's also "declarative", a bit like SQL, in that the users describe the result, and magic happens internally to make it so.

More recently, I've been working on a tree-structured editor for users to visually build programs/templates. Developing it has been insightful - I'm realizing that this development environment should have been there from the beginning, as a fundamental part of the language's design and user experience.

All syntactic constructs, keywords, patterns, defined variables, functions, etc., can be made available to the user, with auto-complete, suggest, lists of choices. Rather than the user having to remember commands and type them in text, the environment can let them select, compose, and build. Ideally, it can ensure that a program never has a syntax error (conversely, that it makes it impossible to write/build such a program).

Another aspect I've come to appreciate is instant feedback. Any kind of live preview, or automatic build/test, makes a big improvement in the flow of programming and thought process. It becomes like shaping clay.

In an article about Smalltalk, I read how its integrated environment is indistinguishable from the language itself. In my daily work too, I spend most of my time in an editor with language servers for syntax highlight, autosuggest, linting, and other smart features, as well as integration with terminal, Git, remote edit with SSH.. Typing in text is still the fastest way for me to express myself, but the environment is constantly supporting it - it understands what I'm writing (often more than I'm aware), showing me what I need to know to build with minimal effort.

What I like is a programmable development environment, especially one which is built on itself.

Well, this has been a ramble without a point. It's an endlessly fascinating subject, and perhaps it's only natural that a programmer finds delight in creating one's own language. There's something pure and philosophical about it, like working with the very material of thought.

---

A little list of links related to building interactive software visually:

https://airtable.com/

https://bubble.io

https://www.memberstack.io/

https://webflow.com/

https://zapier.com/

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

#96

Post by somewhereoutth » Sun, May 03, 2020, 12:54 AM UTC

abecedarius wrote: post #89

somewhereoutth wrote: post #69

Earlier quoted context omitted.

Possibly an alternative - but operating at the term level as predicates - if you consider 'type' to be a total function dividing your term space into 'of the type' and 'not of the type'. Church numerals: 0 = (^Nat (\f \x x)) 1 = (^Nat (\f \x (f x))) The ^Nat is the decoration, and can be recovered with a special predicate function ?Nat. So: (?Nat (^Nat (\f \x x))) =>Beta (^Bool (\x \y x)) *i.e. true* For this to work…

It sounds like the trademarks in https://blog.acolyer.org/2016/10/19/protection-in-programmin... -- is that right?

Kind of - but more about dynamic dispatch / overloaded function name resolution than protection per se.

Furthermore, the decorations work at the lowest possible level, and are bound up with the extended beta reduction (there is also an unwrap operator with associated reduction rules).

Of course, any computation can be modelled in the standard lambda calculus, without needing to hack the reduction, but I believe that this extension is in some sense non-trivial as it would require the LC to first implement the LC terms and usual beta reduction within itself, before then implementing the additional terms and redux.

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

#97

Post by Dylan16807 » Sun, May 03, 2020, 12:56 AM UTC

macintux wrote: post #87

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…

> Mixtures of the two tend to have syntax problems. My gripe isn’t the syntax, it’s the lack of guarantees/constraints. When I’m working in a language with immutable data structures, I know what to expect. A language like Python with some added functional sugar is much harder for me because I make stupid assumptions. Spent a half hour once chasing down a bug just because I was carelessly assuming list.pop() didn’t al…

You make a good point in general, but I'd be upset if a function called 'pop' didn't mutate anything. That is not the right name to use for returning an element without side effects.

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

#98

Post by ModernMech » Sun, May 03, 2020, 1:07 AM UTC

Rochus wrote: post #45

WalterBright wrote: post #13

Author here. AMA!

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

I think it depends on the language. If you're writing a language that is targeted toward systems programming, yeah, it's probably a good idea to write a compiler in it. But what about languages that are targeted differently? Should people be writing parsers/compilers in CSS or SQL? Probably not a top priority there.

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

#99

Post by macintux » Sun, May 03, 2020, 1:12 AM UTC

Dylan16807 wrote: post #97

macintux wrote: post #87

Earlier quoted context omitted.

> Mixtures of the two tend to have syntax problems. My gripe isn’t the syntax, it’s the lack of guarantees/constraints. When I’m working in a language with immutable data structures, I know what to expect. A language like Python with some added functional sugar is much harder for me because I make stupid assumptions. Spent a half hour once chasing down a bug just because I was carelessly assuming list.pop() didn’t al…

You make a good point in general, but I'd be upset if a function called 'pop' didn't mutate anything. That is not the right name to use for returning an element without side effects.

Like I said, it was stupid. I’d spent a few years working with Erlang and hadn’t yet made the mental switch.

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

#100

Post by kyllo » Sun, May 03, 2020, 1:17 AM UTC

billconan wrote: post #2

I want to implement a toy programming language, but I have questions regarding the following in that article: > Context free grammars. What this really means is the code should be parseable without having to look things up in a symbol table. C++ is famously not a context free grammar. A context free grammar, besides making things a lot simpler, means that IDEs can do syntax highlighting without integrating in most of…

Context-free has nothing to do with symbol tables, it just means that in the grammar, the left-hand side of a production rule can only have a single non-terminal symbol, which can always be replaced by the expression on the right-hand side, without ambiguity.

Language features are an orthogonal issue--you can implement any language feature with a CFG, but you just can't reuse the same keyword or operator to have different meanings in different grammatical contexts.

A classic example is that in C++ it is impossible to know whether Generally language designers don't choose to implement a context-sensitive grammar on purpose because they desire some feature that requires it; they strive for a context-free grammar, but end up with a handful of special cases that require context-sensitive parsing because of either convenience or legacy reasons.

Popular programming languages nearly all use custom parsers written in other (or the same) Turing-complete programming languages, so it's not "harder" to parse the context-sensitive rules, it only poses a problem if you want to use a parser generator to implement parsing for a CSG.