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

81–90 of 212 posts

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

#81

Post by MauranKilom »

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…

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

Consider this code:

  void foo(int* data, const int& count)
  {
    for (int i = 0; i
The compiler has to account for the possibility of `count` being inside of `data`. It has to reload `count` from memory at every iteration. This also prevents e.g. auto-vecorization:

Compare https://godbolt.org/z/sNRKv4 vs https://godbolt.org/z/iJq5yn.

Similar story if you manipulate data with multiple arrays in play: Unless the compiler knows (via `restrict`, type-based alias analysis or just seeing the definition) that two objects are non-overlapping, it has to correctly handle the worst case. See also this related discussion: https://news.ycombinator.com/item?id=20800076

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

#83

Post by pfdietz »

A reason for simple parsing is to make the toolchain for the language easier. And in particular, you don't want a preprocessor. Try to parse your program into an AST? You can't in C/C++ in general -- you can only parse it for a particular set of preprocessor defines, which will leave out large chunks that were deleted during preprocessing.

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

#84

Post by Silhouette »

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?

If nothing else, deep immutability means you can pass around a reference to data instead of the data itself but still treat it as having value semantics. This can be a huge saving with large data structures, sharing data across threads, etc.

C++ programs are full of functions taking const references to things instead of the things themselves because C++ programmers have to do this optimisation (or some equivalent) manually to get the same performance boost, because the language doesn't prevent all possible cases of aliasing that would make automatically applying that transformation safe.

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

#85

Post by saagarjha »

jakear wrote: post #50

Off topic: Annoying that this is totally unreadable even at 300% zoom on an iPhone 11 Pro. I feel like a set of people refuse to learn proper HTML/CSS as some sort of statement, not realizing their laziness renders their work unavailable to the visually disabled. HN behaves similarly poorly.

What's wrong with Hacker News?

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

#86

Post by pfdietz »

amelius wrote: post #12
daenz wrote: post #10

Earlier quoted context omitted.

It's simple, but it's fundamentally reductionist. You can ease the cognitive load by making certain programming structures first-class citizens in the language.

Yes but now you have to worry about parentheses and at what nesting level certain constructs should live.

An adequate editor with autoindent and paren matching solves those problems completely.

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

#87

Post by macintux »

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 alter the list.

Now I keep a Python shell running all the time so I can see whether various functions have side effects.

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

#88

Post by saagarjha »

pbiggar wrote: post #76
tomp wrote: post #47

Earlier quoted context omitted.

> 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'…

That sounds…potentially confusing? Correct me if I'm wrong, but it just continues to run the last version of the program without errors, but it won't tell you if the current version is syntactically invalid?

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

#89

Post by abecedarius »

somewhereoutth wrote: post #69
tpush wrote: post #59

Earlier quoted context omitted.

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…

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

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

#90

Post by jakear »

saagarjha wrote: post #85
jakear wrote: post #50

Off topic: Annoying that this is totally unreadable even at 300% zoom on an iPhone 11 Pro. I feel like a set of people refuse to learn proper HTML/CSS as some sort of statement, not realizing their laziness renders their work unavailable to the visually disabled. HN behaves similarly poorly.

What's wrong with Hacker News?

it doesn't respect iOS font size, and you can't alter the zoom to make the text actually bigger. It zooms the entire page rather than just the text, so the text doesn't re-flow. It's pretty much equivalent to just pinching to zoom, when it should be adjusting the font size.
Post reply on HN