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

51–60 of 119 posts

Re: Sylph: the programming language I want

#51

Post by nine_k »

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

Note that the interface between the machine and the human is one of the slowest. Being able to learn things about numbers, or about code, without touching the keyboard / mouse is important.

Re: Sylph: the programming language I want

#52

Post by brudgers »

falcolas wrote: post #38
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.

I hated sounding negative on the article. It represents a lot of admirable effort. My point is that the effort is not directed in a particularly constructive direction in regard to creating a new programming language.

There's a clear goal when writing a language that is both a floor wax and a desert topping. On the other hand, all writing a language with the goal of being neither floor wax nor desert topping just gets us a floor topping and a dessert wax. There's no problem solved. Griping isn't brainstorming.

Brainstorming is structured. Productive brainstorming is constrained by reality. By which I mean that brainstorming about something like type inference acknowledges that type inference is subject to the Halting problem and that dynamic typing as in Python does not entail type inference.

Starting with Assembly, all higher level programming languages are DSL's over machine code. Things I hate is not a domain that leads to insight or a coherent minimum language. Python's core was addressing pedagogical problems such as beginners learning to format code well. Google's Closure compiler addresses the problem of JavaScript performance. Rust is intended to address client server programming. For each there is something that can be measured objectively and improved.

Don't misunderstand me, there's nothing wrong with writing a programming language as a learning exercise or to scratch one's own itch or solve the world's problems. But it is an engineering design exercise not a poem. The facts of computation make it so.

Re: Sylph: the programming language I want

#53

Post by sparkie »

one-more-minute wrote: post #48
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 wo…

Different semantics can be approached by several different methods though - one can simulate an interpreter for a "guest" language in a host language - or the languages can provide an FFI for interoperability. While we have various means to combine the two different semantics of a language, we have no means to combine their syntax without encountering ambiguity problems. This is why storing code in a structured format rather than plain text could be so valuable, because it would enable us to mix and match languages in whatever way we wanted - rather than resorting to putting code inside strings, loading up new files, or complicating the syntax of our language to provide the expressivity we would like (eg, LINQ).

Diekmann and Tratt have a theory of Language Boxes[0][1] which provide the groundwork for achieving this kind of editing. They enable language quotation without the need for introducing per-language delimiters, the need to quote code in strings, and the need for escaping characters when hosting one language inside another. The editor is aware of where the language boundaries occur because they are specified by the programmer. The semantics of hosting one language in another are left up to the programmer to specify.

[0]:http://lukasdiekmann.com/pubs/diekmann_tratt__parsing_compos...

[1]:http://soft-dev.org/pubs/html/diekmann_tratt__eco_a_language...

Re: Sylph: the programming language I want

#54

Post by TheOtherHobbes »

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 was tried. It was called APL.

http://en.wikipedia.org/wiki/APL_%28programming_language%29

It was very, very clever.

It was so clever hardly anyone understood it, and it's (mostly) forgotten.

Having said that - I kind of agree. It seems like most languages are attempts to:

1. Create a human-readable text-based representation of symbolic logic.

2. Chunk the symbolic logic in (hopefully) useful ways.

3. Cross-correlate symbolic levels, so at one extreme you have actual bytes in physical memory, at the other you have arbitrarily complex symbolic data structures.

4. Build simple error checking into the language so it's impossible to write obvious nonsense. (This includes, but isn't limited to, all type systems.)

5. Constrain the operations that are possible for similar reasons. ('State' etc.)

This is all more or less taken for granted. I'm not sure it should be. Basically it's a bottom-up approach to language design - reduce operations to binary algebra, add constraints.

But top-down languages like Prolog and (kind of...) Erlang try to do interesting, powerful, things, and have at least a few features that Just Work.

So I think the top-down approach is underexplored. There's a sweet spot between top-down simplicity, expressiveness with minimal cognitive load, and processing efficiency.

It's unlikely current syntax conventions are close to it.

I think most people know that languages are different points on various trade-off scales, so there will never be one single best language.

But more variety might not be a bad thing.

Re: Sylph: the programming language I want

#55

Post by vertex-four »

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

Earlier quoted context omitted.

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

> The indention doesn't mean anything to C programmers

So you could read and debug a 5000-line program written all on one line without reformatting it?

Re: Sylph: the programming language I want

#56

Post by sparkie »

falcolas wrote: post #38
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.

We should add another stage into that routine: research.

It's no good looking at problems that other people have solved (or proven that they can't be), when we could be looking at new ways to approach problems instead. For example, we'd know that "statically inferred duck typing" is already well researched. It's called structural typing.

Re: Sylph: the programming language I want

#57

Post by DanWaterworth »

nine_k wrote: post #51
DanWaterworth wrote: post #25

Earlier quoted context omitted.

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

Note that the interface between the machine and the human is one of the slowest. Being able to learn things about numbers, or about code, without touching the keyboard / mouse is important.

Well have the machine annotate the code then.

Re: Sylph: the programming language I want

#58

Post by krylon »

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

> It's like when you see programmers doing arithmetic in their heads. "You're sitting in front of a glorified calculator!"

At the company where I work, most engineers have real, actual calculators on their desks. I think I even saw a slide rule once. So they sit there, sometimes, doing arithmetic on their calculators and then type the results into an Excel spreadsheet.

Re: Sylph: the programming language I want

#59

Post by geocar »

vertex-four wrote: post #55
geocar wrote: post #49

Earlier quoted context omitted.

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

> The indention doesn't mean anything to C programmers So you could read and debug a 5000-line program written all on one line without reformatting it?

What does "5000 lines all on one line" mean?

If it fits on a page I don't have trouble reading it. Line breaks tend to make it harder to fit on a page and not easier.

Example:

http://www.nsl.com/papers/origins.htm

Re: Sylph: the programming language I want

#60

Post by adrusi »

mindslight wrote: post #44
zak_mc_kracken wrote: post #34

Earlier quoted context omitted.

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'

Why would it be improperly indented in the first place? How is removing the indentation any different from removing braces?

Sure, when you paste code somewhere that expects prose (Facebook status updates, for example), it will consolidate consecutive whitespace and thereby remove the indentation, but you shouldn't be pasting code into a place like that anyway, because no matter what you do it'll be unreadable, and most people aren't going to be interested enough to put it into their editor to autoformat.

Post reply on HN