Live data from Hacker News

The naked truth about writing a programming language (2014)

digitalmars.com

61–70 of 212 posts

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

#61

Earlier quoted context omitted.

The implementation of D has a lexer that is independent of the parser, and a parser that is independent of the rest of the implementation. I have resisted enhancement proposals that would put holes in those walls.

could you give an example for > Any programming language that is massively adopted is context free? I want to have an intuition on what is context free and what is not. Is D context free? I mean I want to make a useful language, is being context free practical?

D is context free in that the parser does not require semantic analysis in order to complete its parse.

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

#62
post #35

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…

Linear encoding is better than interpreting a tree because accessing adjacent elements in arrays is faster than chasing pointers. Poor performance depends on what your language does. What's poor performance for SQL will be different than for JS. Features which don't have efficient implementations will be slow. If the language encourages use of inefficient features, then it will generally be slower. The easiest optimi…

> Linear encoding is better than interpreting a tree because accessing adjacent elements in arrays is faster than chasing pointers.

Yes. From this we can derive some general optimization principles: reduce indirection, increase data locality.

Are there any others?

> Poor performance depends on what your language does. What's poor performance for SQL will be different than for JS.

Let's consider modern dynamic languages like Javascript and Python. What performance problems did these languages face? Which optimizations had the biggest impact on code execution performance? Which optimizations were the easiest to understand and implement?

For example, I know Javascript virtual machines will automatically create hidden classes for objects. This allows the data to be accessed by constant offsets rather than lookups.

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

#63

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…

An Ownership/Borrowing system like the one Rust uses? Rust is sadly not (yet) able to use its stricter rules about ownership and aliasing for optimization, because the LLVM backend has been shown to have a number of bugs that prevent such optimizations. Sadly, I'm not that knowledgeable on optimization. Do you expect that such optimizations would make most programs significantly faster or is it more of a special case…

> Do you expect that such optimizations would make most programs significantly faster or is it more of a special case that would not improve the performance of most programs?

I don't know because I have no personal experience with such. What I have to go on is the Fortran vs C/C++ experience I mentioned.

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

#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 years ago, but I do regularly use a small Prolog I recently wrote in Lisp.)

The languages at the roots of all programming languages are Fortran, Lisp, Cobol, Algol60, APL, Snobol, Forth, Prolog, OPS5, SASL, Smalltalk, Prograph. (If I've missed any out, or any of the above have important predecessors, please let me know.) A new language is unlikely to be radically different from any of those languages or their descendants - of those I listed, the most recent is from the mid 1980s. Within the descendants, which is your favourite? Can you make big improvements to it? If so, make them. Otherwise, can you improve another language so that it becomes your favourite?

One heuristic I've found useful: the right design choices at the start might be unknown, but when I need make them, they're obvious to me, and often a particular choice leads to other equally obvious choices. If the choice isn't obvious, I've probably done something wrong.

My own preference is for pure rather than hybrid languages with simple regular syntaxes (i.e. one idea expressed well), and very strong static typing.

My favourite language is Common Lisp or rather a subset of it. I have trouble thinking of ways to make it significantly better. But I also like the idea of dataflow (a few decades ago I knew some of those working on experimental dataflow hardware), and graphical programming seems to be the right approach to dataflow. Prograph was the closest existing language to what I wanted. It's isn't pure dataflow, it's dynamically typed, it's object oriented (so, unless it's Smalltalk it's hybrid), and entering programs in it involves too many mouse gestures and keystrokes. So I'm implementing a new language which corrects those deficiencies. It's been particularly difficult because I have to write an IDE as well as the language, and there aren't any textbooks I can rely on for help.

I'll have succeeded if I use the new language more often than I do Lisp, and if along the way I get a few more papers (two so far) and some academic interest, so much the better. I don't expect a wide user base. If that was important to me, it would have C syntax and I'd try to get corporate backing. Your criterion for success might differ from mine.

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

#65

Earlier quoted context omitted.

This point in the article is pretty weird (the rest is good). I don't think IDEs do a lot of parsing to do syntax highlighting, isn't it all just regex matching to identify the types of tokens? I'd be interested in real-world examples of IDEs doing something more complex to achieve syntax highlighting. And conversely, examples of imperfect syntax highlighting of C++ due to the undecidability of its input language. I…

> I don't think IDEs do a lot of parsing to do syntax highlighting, isn't it all just regex matching to identify the types of tokens? IntelliJ highlights variables etc. differently if they're unused and can highlight different identifiers in different colors. Not sure about other current IDEs. That said I never felt like I needed such features, normal syntax highlighting does the job pretty well for me.

IntelliJ has context-aware autocomplete. Type this.field.get and it will show methods and fields starting with get for whatever type field is. There's a lot of context needed to make that happen.

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

#66

Earlier quoted context omitted.

My opinion is that Jonathan Blow is an amazing developer and he should be joining us on D! It's been a while since I reviewed the language, and I'd have to re-review it to say anything sane here. But one thing stuck out at me. In D, the support for Compile Time Function Execution (CTFE) is very extensive, and opens the door to a lot of incredible metaprogramming abilities. Jai has this too, but has extended it to all…

Other languages (such as python) have install-time code execution. When you pip install a library, the library can run arbitrary code and of course has access to anything and everything via the python interpreter. The only thing protecting you is faith in pypi. How is compile-time code execution any different?

> How is compile-time code execution any different?

I don't know the Python ecosystem and so can only speculate. PIP install is not compiling the code, it's an installation program. Installing anything that can be executed is potentially dangerous, but I imagine PIP install only installs from a trusted source.

But I'm not going to restrict D to compile only source code from a trusted source.

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

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

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

#68

Earlier quoted context omitted.

My opinion is that Jonathan Blow is an amazing developer and he should be joining us on D! It's been a while since I reviewed the language, and I'd have to re-review it to say anything sane here. But one thing stuck out at me. In D, the support for Compile Time Function Execution (CTFE) is very extensive, and opens the door to a lot of incredible metaprogramming abilities. Jai has this too, but has extended it to all…

I assume most people run the code they compile on the very machine they compile it on, so how does preventing compile-time system calls help stop malware?

It means that the D compiler itself is not the doorway for the malware.

Cross-compiling is a common practice, too.

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

#69
post #59

I am currently developing a language, though more as a research project than anything practical. Apologies for jumping on this post, but it is a good opportunity to organize and set out my thoughts (and possibly someone might find it interesting): Essentially the language is a pure functional language that takes the untyped lambda calculus and adds decoration terms as first class citizens in the calculus. These terms…

From your description it sounds like these decorators are an alternative to type annotations? Mind showing how these decorators look and work? I'm also building a language, and always interested in seeing novel features like these :).

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 the inner part must be reduced first. It does seem to be consistent with Normal order reduction - the Y combinator etc work as expected.

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

#70
post #9
post #6

Earlier quoted context omitted.

https://stackoverflow.com/questions/898489/what-programming-... Most languages have context-free syntax, which is what the article refers too. There really is no reason to sacrifice that. Even modern PHP recognises the value of having a parse tree independent of an entire compiler. Context-free semantics is an entirely different matter, and I'm not even sure what it'd mean...

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…

what is context free language anyway? context free grammar had a clear definition in parsing, not sure i understand how that can be extended to languages.
Post reply on HN