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

181–190 of 212 posts

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

#181

Post by pbiggar »

WalterBright wrote: post #153
pbiggar wrote: post #76

Earlier quoted context omitted.

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 means, if it isn't a "syntactically" valid program, you can't create it in the first place. It's an interesting idea. I don't know if it would work for me, though. I don't write code as a stepwise refinement of a valid program, I massage the text gradually into a valid program. This is especially true when refactoring.

Yeah, I think a bunch of people work like that. We've had the feedback that some people have had to change their workflow to work well with Dark.

People generally use what we call "trace-driven development", where they make a HTTP request to the code they're editing (typically, people are making APIs or backends to JS apps), and then they always have "live values" of what they're working on (similar to a REPL, or to running unit tests on a loop, but instantly).

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

#182

Post by dkersten »

uryga wrote: post #164
Dylan16807 wrote: post #123

Earlier quoted context omitted.

> how do you feel about `str.replace`? i'd say that that name implies side-effects too, but everybody's used to the fact that [in python] strings are immutable, so it's no big deal. In that case it's returning a modified string, at least. 'pop' and 'replace' both create modifications to the item you feed in. You can return the modified version, or you can mutate it in place, or you can do both. But it makes zero sens…

> So as long as 'pop' is returning the element from the list/map/set/whatever, and nothing else, it is the wrong verb for immutable structures. right, but would anyone really write a functional `pop` like that? that's just `last`. any sensible functional `pop` would return a tuple: (x, new_xs) = pop(xs) so i'm not sure i understand what the problem is tbh. we might be in violent agreement... and re: unordered contain…

In clojure, pop returns the input with the item removed (so popping a vector returns a vector with the last element removed). To return the actual element, you use a different function (peek, or last).

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

#183

Post by uryga »

Dylan16807 wrote: post #177
uryga wrote: post #164

Earlier quoted context omitted.

> So as long as 'pop' is returning the element from the list/map/set/whatever, and nothing else, it is the wrong verb for immutable structures. right, but would anyone really write a functional `pop` like that? that's just `last`. any sensible functional `pop` would return a tuple: (x, new_xs) = pop(xs) so i'm not sure i understand what the problem is tbh. we might be in violent agreement... and re: unordered contain…

> so i'm not sure i understand what the problem is tbh. we might be in violent agreement... A two-return pop like that is a little weird, but still basically reasonable. But a one-return pop is a misleading term for immutable data structures. Use list[-1] or last(list) or something. When I say I'd be upset at pop not mutating a list, I'm talking about a one-return pop specifically. > and re: unordered containers, i'd…

so we agree about single-return-pop – it just wouldn't be very useful. what i tried to say is that it's a bit of a strawman – single-return-pop is pretty obviously useless, so no one would design a pure API like that. so there's no point arguing against it :)

if you want `pop`-like semantics, but also want your operations to be pure, tuples are the only real way to do it. for a real example, see this Haskell implementation of stacks: https://hackage.haskell.org/package/Stack-0.4.0/docs/Data-St...

its `pop` has this signature:

  stackPop :: Stack a -> Maybe (Stack a, a)
(with a `Maybe` thrown in to account for popping an empty stack)

---

another alternative that works well in some cases is algebraic datatypes and pattern matching:

  result = case myList of
    [] -> "whoops, empty"
    (x : rest) -> (
      "the first element is " ++ (show x) ++
      ", and the rest of the list is: " ++ (show rest)
which is pretty similar to

  try:
    x = myList.pop(0)
    result = "the first element is " + str(x) + " and the rest is " + str(myList)
  except IndexError:
    result = "whoops, empty"
so that way you can take your structure apart bit by bit like you would with `pop()`. if your container is unordered, you could convert it to a list first.

---

and if wrangling tuples and passing the "state" around like that gets annoying, Haskell has the `State` monad, essentially a wrapper around functions `SomeState -> (X, SomeState)` that eliminates the state-passing boilerplate

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

#184

Post by dnautics »

zzo38computer wrote: post #58
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 would say possibly to use a different programming language for GPU than CPU. I like the idea of Checkout (see [0]) for GPU programming, although unfortunately it is not implemented and the preprocessor is not yet invented. (The trigonometric functions are also missing. They should probably have at least sine, cosine, and arctangent, since these functions seem like useful to me when doing graphics.) [0] http://esola…

Julia has done a fair job of mapping high level mathematical primitives to the GPU (though I disagree with their approach)

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

#185

Post by uryga »

dkersten wrote: post #182
uryga wrote: post #164

Earlier quoted context omitted.

> So as long as 'pop' is returning the element from the list/map/set/whatever, and nothing else, it is the wrong verb for immutable structures. right, but would anyone really write a functional `pop` like that? that's just `last`. any sensible functional `pop` would return a tuple: (x, new_xs) = pop(xs) so i'm not sure i understand what the problem is tbh. we might be in violent agreement... and re: unordered contain…

In clojure, pop returns the input with the item removed (so popping a vector returns a vector with the last element removed). To return the actual element, you use a different function (peek, or last).

that's `init` in Haskell, and in this case i'd agree with the OP - i'm used to `pop` letting you actually access the last element, so i'd prefer a different name.

also, doing it that way will require traversing the structure twice, something that's often not free with functional data structures, whereas a tuple-pop does it in one go. similar to how you'd rather split a list at an index and get back two lists rather than do a `take n` and `drop n` separately

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

#186

Post by bogomipz »

>"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."

Could someone elaborate on why C++ is not a "not a context free grammar"? Also how does C++ deal with this fact?

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

#187

Post by barrkel »

matheusmoreira wrote: post #62
barrkel wrote: post #35

Earlier quoted context omitted.

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

You're sticking your toe in a very big lake, and this isn't the right forum to meaningfully talk about it.

(I don't mean this in any way negatively, but your two posts have a distinct whiff of Help Vampire - https://meta.stackexchange.com/questions/19665/the-help-vamp... - just a tiny chunk of information, and a naive question where you'd need years to properly survey the knowledge. It's a big topic and you need to be goal directed to get anywhere IMO.)

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

#188

Post by wool_gather »

uryga wrote: post #183
Dylan16807 wrote: post #177

Earlier quoted context omitted.

> so i'm not sure i understand what the problem is tbh. we might be in violent agreement... A two-return pop like that is a little weird, but still basically reasonable. But a one-return pop is a misleading term for immutable data structures. Use list[-1] or last(list) or something. When I say I'd be upset at pop not mutating a list, I'm talking about a one-return pop specifically. > and re: unordered containers, i'd…

so we agree about single-return-pop – it just wouldn't be very useful. what i tried to say is that it's a bit of a strawman – single-return-pop is pretty obviously useless, so no one would design a pure API like that. so there's no point arguing against it :) if you want `pop`-like semantics, but also want your operations to be pure, tuples are the only real way to do it. for a real example, see this Haskell implemen…

Curious; why `Maybe (Stack a, a)` rather than `(Stack a, Maybe a)`? The returned stack would be empty like the input.

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

#189

Post by uryga »

wool_gather wrote: post #188
uryga wrote: post #183

Earlier quoted context omitted.

so we agree about single-return-pop – it just wouldn't be very useful. what i tried to say is that it's a bit of a strawman – single-return-pop is pretty obviously useless, so no one would design a pure API like that. so there's no point arguing against it :) if you want `pop`-like semantics, but also want your operations to be pure, tuples are the only real way to do it. for a real example, see this Haskell implemen…

Curious; why `Maybe (Stack a, a)` rather than `(Stack a, Maybe a)`? The returned stack would be empty like the input.

i guess it's "making illegal states unrepresentable" – with `(Stack a, Maybe a)` you allow an implementation that does

  stackPop [1,2,3,4] == ([1,2,3], Nothing)
which doesn't make sense - `Nothing` is only supposed to happen when the stack is empty, i.e. `([1,2,3], Nothing)` should be impossible. and if `([], Nothing)` is the only "error state", why not just use a `Nothing` for the whole thing instead? and then you can sleep soundly, knowing your pattern-matches are exhaustive :)

ergonomically, it's nicer to to test for failure; and you can do "railway-oriented programming", either doing something with the result or quickly bailing out.

all that said, there's probably cases where `(Stack a, Maybe a)` is more ergonomic... so you know, this isn't dogma

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

#190

Post by WalterBright »

loicd wrote: post #154
WalterBright wrote: post #13

Author here. AMA!

Although the explanation of what you mean by "context-free grammars" is clear, it seems to me that you should be using "unambiguous grammars" instead. An ambiguous context-free grammar is not going to facilitate the job of an IDE. I also think you are mistaken about the C++ grammar not being context-free. The problem is that it is ambiguous. I could be wrong here since I have not kept up with the C++ standards. So ca…

The ones where the `template` keyword had to be added to make the template function bodies parse-able.
Post reply on HN