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

121–130 of 212 posts

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

#121

Post by DonaldFisk »

bear8642 wrote: post #118
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…

>important predecessors Don't know enough about it but feel missing Simula from your list

It was a descendant of Algol 60. It was the first object oriented language but Smalltalk is different from any language which preceded it in the way it handles object orientation.

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

#122

Post by klipt »

nonbirithm wrote: post #101
Dylan16807 wrote: post #97

Earlier quoted context omitted.

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.

Ruby has a nice convention where impure functions like those have a "!" appended to the name. For example String#gsub takes immutable string arguments and returns a new string, but String#gsub! operates on a String instance and mutates it. I guess if you write a new programming language, it would be nice to establish that convention early on, when it's still possible to be done.

That convention may have originated with Scheme, which has non mutating 'let' vs mutating 'set!'

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

#123

Post by Dylan16807 »

uryga wrote: post #112
Dylan16807 wrote: post #97

Earlier quoted context omitted.

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.

> That is not the right name to use for returning an element without side effects 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. it's all a matter of expectations and language conventions – e.g. in Haskell, `replace`, `reverse`, `insert` etc. would all be pure functions and no one would…

> 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 sense to do neither. Why would you make a modified version of an immutable variable, then immediately throw it into the void? 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.

Also, 'pop' works on unordered data structures too, which makes it fit even less since it's now "pick some arbitrary element".

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

#124

Post by gautamcgoel »

WalterBright wrote: post #13

Author here. AMA!

Hi Walter, I've been thinking for a few years that it might be fun to fork the C toolchain and create a modernized version of C which is 80% backwards compatible with standard C but fixes the most egregious issues of C. Do you think this is a worthwhile project?

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

#125

Post by ken »

zzo38computer wrote: post #56

In some programming languages, e.g. TeX, Forth, PostScript, etc you cannot really syntax highlight the program without executing it. However, syntax highlighting is a feature that I can do without, and I don't think those programming languages are bad. In some programming languages, such as C and Free Hero Mesh, you can read the sequence of tokens despite there are macros, which you need not parse to find where the t…

> In some programming languages, e.g. TeX, Forth, PostScript, etc you cannot really syntax highlight the program without executing it.

Technically true. In practice, however, I've run into way more issues with syntax highlighters in overly-complex fixed languages than I have with simpler-but-programmable languages.

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

#126

Post by tandr »

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?

I cannot comment on mobile (brave) - text box expands, and reply button disappers

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

#127

Post by rgbrenner »

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

You have a grammar... you're just enforcing the rules when data is entered. The same as if my editor stopped accepting input if I miss typed a line until it was fixed.. or if I was required to select one of it's autocomplete suggestions.

let x = 5

"hi " ++ name

DB::set{}

Are you saying these lines from the video are not consistent throughout? Like in one part I'll type "x = 5" to assign 5 to x, but somewhere else I'll have to type "5 # x" to do the same? Like just random syntax everywhere?

If not, then you have a grammar. You should document it and treat it as such.

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

#128

Post by didibus »

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…

Do you mean precedence or infix?

The choice of infix vs prefix vs postfix is semantic. What s-expression syntax imposes is to have everything balanced between brackets. For example, nothing prevents an S-expression based language to allow:

(2 + 3)

The only thing is there are no precedence rules, you must have parenthesis always:

((3 * 2) + 5)

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

#129

Post by didibus »

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…

> I'm a counterexample. Sorry :-)

Haha, fair enough, I did say "almost" ;)

That said, I should have specified, that spent enough time. Like there is a certain amount of time needed to get your brain to really adapt, and generally it's after that period that I've rarely seen anyone not like it. But I admit this might suffer from selection bias, the only people who stick with it long enough for their brain to adapt might be the people who like it.

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

#130

Post by a9h74j »

WalterBright wrote: post #73
mrlonglong wrote: post #39

Zortech C was fabulous, wrote a disk editor in it many moons ago. Kudos!

Thanks for the kind words! Zortech was indeed a great compiler for its time.

Years ago IIRC you put out a request for original Zortech C++ disks and packaging, if anyone had some. I was sorry that I had just disposed of mine six months earlier. .. That was my one-and-only C++ in the early 90's, and I am still programming in D. Sorry I couldn't help!
Post reply on HN