Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sylph: the programming language I want

eev.ee

Post reply on HN
Print view View original

31–40 of 119 posts

Re: Sylph: the programming language I want

#31

Post by sparkie »

octatoan wrote: post #18

I kind of like languages that require "a complete upheaval of [one's] mental model of the universe". :)

I think it's necessary to look for such alternative approaches when the ones we're using are resulting in ~5 bugs per 1k lines of code on average, frequent security issues, crashes, race conditions, etc. Plus the hundreds of man hours spent fixing these problems.

With technology coming more and more into our lives, such that our lives will depend upon it behaving as was intended, we're really going to reach a point where we've got to say enough is enough. The languages (and approaches to development) we're using are not fit for purpose anymore.

Re: Sylph: the programming language I want

#32

Post by brudgers »

deckiedan wrote: post #23

A lot of syntax / spacing / etc. problems would go away if we stopped using completely plain text as the medium for programming languages. Or rather, if we extended plain text, or got our editors to understand the languages a bit more thoroughly than just highlighting keywords and giving us autocompletion or whatever. This has been explored a bit by michaelw and others ( http://www.foldr.org/~michaelw/emacs/ ) for li…

Lisp programs are data for the reader ~ in contrast to text for a lexer as is typical in other language families. So long as AST's are in the pipeline from source to execution, the options are lexing [or its equivalent] or writing an AST directly.

Re: Sylph: the programming language I want

#33

Post by [deleted] »

agumonkey wrote: post #16
seanmcdirmid wrote: post #5

Earlier quoted context omitted.

The computer is really quite proficient at inferring block structure from indentation, and if you use a modern editor this structure is manipulated rather effortlessly. The main problem with indent oriented languages is that not everyone is or wants to use a modern editor. Then there are LISPers who think braces everywhere are a swell idea.

The only thing superior to Sexps is Forth. Mechanical syntax forever.

[deleted]

Re: Sylph: the programming language I want

#34

Post by zak_mc_kracken »

okasaki wrote: post #3

>If your language has braces, then you are indenting for the sake of humans (because humans are good at noticing alignment and edges), and bracing for the sake of computers. That’s double the effort for something as mundane as where a block ends. If they get out of sync, then your code naturally breaks in a way that’s very difficult for you to detect. No, I use braces for the computer, and the computer automatically…

You're using a double standard, here: if the computer is good at indenting brace based languages, then it is equally good at indenting languages without braces just based on the grammar.

Re: Sylph: the programming language I want

#35

Post by falcolas »

TazeTSchnitzel wrote: post #22
gnuvince wrote: post #14

Earlier quoted context omitted.

I like writing compilers, how do languages like Haskell and Python handle blocks-by-indentation? I figure you have some sort of INDENT token, but how do you know its width? Also, in specifying the grammar, with explicitly delimited blocks you just say `block := OPEN stmt_list CLOSE`. What about with indentation?

I think they specify "INDENT foo DEDENT" and the lexer tracks indentation and issues INDENT/DEDENT as appropriate.

This is correct. A bit of state (an indentation width stack) in the lexer creates the block boundaries as clearly for the interpreter as normal braces does.

Any problems in parsing are typically only encountered by stateless parsers.

Re: Sylph: the programming language I want

#36

Post by falcolas »

geocar wrote: post #13
seanmcdirmid wrote: post #5

Earlier quoted context omitted.

The computer is really quite proficient at inferring block structure from indentation, and if you use a modern editor this structure is manipulated rather effortlessly. The main problem with indent oriented languages is that not everyone is or wants to use a modern editor. Then there are LISPers who think braces everywhere are a swell idea.

> The computer is really quite proficient at inferring block structure from indentation, and if you use a modern editor this structure is manipulated rather effortlessly. Nonsense. Try pasting a block of Python into Hacker News and you get something that starts off like this: import os import random def do_something(x): if x: fd = os.open(x) and only gets worse. A language with braces/semicolons has no such problem;…

It's only problematic because the comment grammar used on HN for non-code folds consecutive whitespace down to one space. Ironically, this was done to work around those who feel that text documents should be hard-wrapped at ~70 characters. If the grammar did not apply this folding, then it would be happy to preserve the structure.

If I were designing a language, its compatibility with naive commenting systems (or catering to users who refuse to use code blocks provided by most modern commenting systems) would be pretty low on my list.

Whitespace, even disregarding indentation, is already very significant to a number of modern languages. Why, then, is this particular form of significance bad?

Re: Sylph: the programming language I want

#37

Post by brudgers »

seanmcdirmid wrote: post #5
okasaki wrote: post #3

>If your language has braces, then you are indenting for the sake of humans (because humans are good at noticing alignment and edges), and bracing for the sake of computers. That’s double the effort for something as mundane as where a block ends. If they get out of sync, then your code naturally breaks in a way that’s very difficult for you to detect. No, I use braces for the computer, and the computer automatically…

The computer is really quite proficient at inferring block structure from indentation, and if you use a modern editor this structure is manipulated rather effortlessly. The main problem with indent oriented languages is that not everyone is or wants to use a modern editor. Then there are LISPers who think braces everywhere are a swell idea.

A token is a token. PEPpy Python's four spaces are isomorphic to Lisp's left banana and C++'s curly brace. An ASCII would be just as well with a lexer.

White space has significance for humans. The road to the Turing tarpit is paved with human intentions. Describing computation mathematically is a solved problem. Expressing it clearly for and by humans, not so much.

Re: Sylph: the programming language I want

#38

Post by falcolas »

brudgers wrote: post #30

This reminds me of reading a typical zoning ordinance: more an historical sack of bandaid reactions to specific but unrelated past problems than a positive program generating a bounded creative domain. Addressing gripes is not evaluating tradeoffs. Successful languages start with a clear idea of what problem they want to solve, creating coherency at a high level. Values are ranked and might be nice is distinguished f…

It actually reminds me of a first draft mind dump. From here, some aggressive refactoring could turn this into a very nice language specification.

Brain-dumps are valuable for discussion and as a first step. From there, we just need to follow our normal programming routines: Write, refactor, test, repeat.

Re: Sylph: the programming language I want

#39

Post by vertex-four »

geocar wrote: post #24
vertex-four wrote: post #17

Earlier quoted context omitted.

> A language with braces/semicolons has no such problem; it is easier to communicate with others If someone posts more than two lines of practically any curly-brace language as one line, it's illegible. Yes, you can pull it into an editor and fix it automatically, but it's a huge waste of time that is best fixed by simply posting the code properly in the first place.

> any curly-brace language as one line, it's illegible. You might not be able to read it, but others can, so it is by definition not illegible. "Indention language", on the other hand, has actually lost its meaning and therefore is illegible. > it's a huge waste of time that is best fixed by simply posting the code properly in the first place Helping others is never a waste of time, but telling people thy are too stu…

> Helping others is never a waste of time, but telling people thy are too stupid to ask for help correctly is cruel.

Asking others politely to help you help them is not cruel in any way. If you allow a community to become a place where people can ask questions without putting any effort at all in themselves, you end up with all the people who can actually help leaving, and your community being full of people who will only ever put in the bare minimum of effort.

Re: Sylph: the programming language I want

#40

Post by dochtman »

gnuvince wrote: post #14
okasaki wrote: post #3

>If your language has braces, then you are indenting for the sake of humans (because humans are good at noticing alignment and edges), and bracing for the sake of computers. That’s double the effort for something as mundane as where a block ends. If they get out of sync, then your code naturally breaks in a way that’s very difficult for you to detect. No, I use braces for the computer, and the computer automatically…

I like writing compilers, how do languages like Haskell and Python handle blocks-by-indentation? I figure you have some sort of INDENT token, but how do you know its width? Also, in specifying the grammar, with explicitly delimited blocks you just say `block := OPEN stmt_list CLOSE`. What about with indentation?

I have one (probably quite naive) implementation here:

https://github.com/djc/runa/blob/master/runac/parser.py#L54

(Runa uses tabs for indentation, not spaces, but it's basically the same thing.) Whitespace at the start of a line is a separate token, then I add a thin layer of processing that turns a change of indentation level (i.e. count chars in the token contents) into INDENT or DEDENT tokens.

Post reply on HN