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

41–50 of 119 posts

Re: Sylph: the programming language I want

#41

Post by falcolas »

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…

> it is by definition not illegible

illegible, adjective: not clear enough to read.

Says nothing about "others being able to read". A doctor's handwriting can be illegible to everyone but the doctor, and not be a contradiction to the definition of illegible.

> Helping others is never a waste of time

If someone cares so little as to paste unformatted code on a forum which provides simple tools to display formatted code, how much value can you really put in their ability to provide quality code? How is requiring someone else decipher something you didn't care enough to post correctly not ultimately a waste of everyone's time?

Re: Sylph: the programming language I want

#42

Post by falcolas »

DanWaterworth wrote: post #25
ahoge wrote: post #19

The inference example is actually a good illustration for why you want to add types to a function's signature. As the author mentioned, a machine can look at how the arguments are used and make some educated guesses. The big problem is that humans have to do the same. That's why I like optional types à la Dart. Not only do they help with static analysis, they also act as documentation. With a good editor, this docume…

> a machine can look at how the arguments are used and make some educated guesses. The big problem is that humans have to do the same. Why? Just get the machine to do it. It's like when you see programmers doing arithmetic in their heads. "You're sitting in front of a glorified calculator!"

> Just get the machine to do it.

Exactly. Many people already use IDEs, or programs which provide auto-completion or hinting of the types a function accepts when writing out a function name - the type does not need to be explicitly written for the machine to identify the type of the function.

Re: Sylph: the programming language I want

#43

Post by zak_mc_kracken »

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

> Try pasting a block of Python into Hacker News and you get something that starts off like this:

You're talking about a web site that seems to have been written by web developers who don't know Javascript exists.

Any Python parser will be able to format your snippet correctly.

Re: Sylph: the programming language I want

#44

Post by mindslight »

zak_mc_kracken wrote: post #34
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.

Not at all. In this case, by 'languages without braces' we mean languages where indentation is part of the grammar. Python's grammar includes explicit INDENT/DEDENT tokens. It is impossible to reindent this mangled python:

    if z:
    print 'a'
    print 'b'

Re: Sylph: the programming language I want

#45

Post by zak_mc_kracken »

> it’s sometimes asked why len in Python is a function, rather than a method. The answer is that of course it is a method, called __len__. The real answer is that Python pointedly and deliberately does not reserve any method

That's some comical post rationalization.

The reason why len is a function is because it was in Python before Python started receiving OO features.

As a result, Python is a crazy hodge podge of imperative, OO and functional semantics where you never know if you should be calling `o.foo()` or `foo(o)` unless you've been writing Python since the late 90s.

Re: Sylph: the programming language I want

#47

Post by the_af »

ahoge wrote: post #19

The inference example is actually a good illustration for why you want to add types to a function's signature. As the author mentioned, a machine can look at how the arguments are used and make some educated guesses. The big problem is that humans have to do the same. That's why I like optional types à la Dart. Not only do they help with static analysis, they also act as documentation. With a good editor, this docume…

> With a good editor, this documentation is right at your fingertips. When you type a function's name, a call-tip will remind you of the expected arguments. If you've added type annotations, the types will be there, too.

Without type annotations, the types will be there too for a language with type inference. The editor just has to ask the language implementation "hey, what is the type for this function?" and show the result back to the programmer.

Re: Sylph: the programming language I want

#48

Post by one-more-minute »

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…

This really assumes that syntax is a purely superficial thing, but in reality syntax reflects the underlying semantics of the language as well.

For example, a typical C program (sequence of imperative statements) displayed with lisp syntax will look awful, yes, but so will a typical lisp program (deeply nested expressions) rendered with C syntax.

Getting rid of text doesn't change the fundamental issues: Languages would still have different semantics (and thus suit different/custom representations) and it wouldn't make any more sense to mix-and-match than it does now.

Re: Sylph: the programming language I want

#49

Post by geocar »

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

Earlier quoted context omitted.

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

"Help you help them" however is only necessary in the python example because data is lost. The indention doesn't mean anything to C programmers, and thus I need no help from them to help them.

Re: Sylph: the programming language I want

#50

Post by sparkie »

masklinn wrote: post #29
marcosdumay wrote: post #11

Earlier quoted context omitted.

What's effortless is putting begin and end of blocks symbols only where they matter. Haskell is particularly guilty of creating several different indenting possibilities, and does require constant intervention. Python is less bad, but still requires more effort than C for example.

Er… you know Haskell's syntax is defined as braces-and-semicolons right? And the braceless-and-semicolons-free syntax is the addition of a few layout rules[0] for human convenience. [0] https://www.haskell.org/onlinereport/syntax-iso.html#sect9.3

The problem is the addition of "a few layout rules" turns the context-free syntax of the language into a context-sensitive one. For example, if you were to write a parser using just the information from the link you've posted, you can enter a scenario where the same piece of code pasted in two different places in a code base mean two different things.

Case in point: putting if _ then _ else on separate lines is fine, but inside a do-notation it causes problems because the layout stage inserts semicolons between the parts, and the production rules listed at the bottom of the page do not include optional semicolons in the "if" alternation. You need to indent the then/else to overcome it. This problem is fixed with a hack[0], which fortunately has no side-effects for the rest of the language, but it just shows that throwing together ad-hoc rules for parsing code, rather than well understood theory like LR parsing, is inviting room for problems.

With CFG subsets like LR/LL, every production rule in these grammars is also a valid LR/LL grammar - in other words, it's not only the entire grammar of a language that is context-free, but all the parts are too. An indentation-sensitive language is only context-free when looked at for the entire language grammar, but the individual production rules of are context-sensitive. You can't just copy and paste some code into the syntax without providing this context (by means of manually indenting the code).

[0]:https://ghc.haskell.org/trac/haskell-prime/wiki/DoAndIfThenE...

Post reply on HN