Live data from Hacker News

Sylph: the programming language I want

eev.ee

81–90 of 119 posts

Re: Sylph: the programming language I want

#81

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

Iverson's design of APL was well thought out to the degree he won a Turing award. His lecture Notation as a Tool of Thought lays out some of his thinking:

http://www.jsoftware.com/papers/tot.htm

Three decades after first conception, Iverson developed the language J using only ASCII characters and based on what he learned over roughly two decades of APL's deployment in the field. IMO, J is worth looking at because it may change the way a person looks at programming languages and their design.

http://www.jsoftware.com/

Re: Sylph: the programming language I want

#82

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

[deleted]

Re: Sylph: the programming language I want

#83
post #79

Earlier quoted context omitted.

Well have the machine annotate the code then.

What the machine annotates and what the programmer wants to read are two very different things, for we often condense some long, confusing type signatures into things we can talk about - for example, a lens. type Lens s t a b = forall f. Functor f => (a -> f b) -> s -> f t If we want to compose several of these, for example, with our regular function composition operator, then we check the resulting type - it's not w…

If you follow the train of this thread, you're now arguing against type inference by sighting an example from the canonical type-inferred language.

Re: Sylph: the programming language I want

#84
post #79

Earlier quoted context omitted.

What the machine annotates and what the programmer wants to read are two very different things, for we often condense some long, confusing type signatures into things we can talk about - for example, a lens. type Lens s t a b = forall f. Functor f => (a -> f b) -> s -> f t If we want to compose several of these, for example, with our regular function composition operator, then we check the resulting type - it's not w…

If you follow the train of this thread, you're now arguing against type inference by sighting an example from the canonical type-inferred language.

I'm not arguing against type inference, I'm arguing against omitting type signatures.

Re: Sylph: the programming language I want

#85
post #75

Earlier quoted context omitted.

"modern base API", what does that mean?

I meant "language standard library" (I updated the text). C/C++/Object-C/PHP have short functions with names like strlen , strstr , etc. Java/C#/JavaScript have .length() and things like System.out.println() / Console.Write() . Ideally, I would like a middle ground. The Java/C# standard library is too verbose and the C standard functions are a bit cryptic. It's great one can use different programming styles in JavaSc…

My own point of view is biased, admittedly, but I couldn't stop thinking that Common Lisp was relevant for each item in your list.

Of course, much isn't built-in, but this is not as bad as it sounds: concurrent channels are not part of the language specification, but you can install the "calispel" or "cl-actors" libraries that gives you what looks like primitive constructs.

Regarding "modern" languages, I like this quote from the author of pgloader: "I switched from Python to Lisp because I wanted a modern language" (also transcribed as: "[...] in searching for a modern programming language the best candidate I found was actually Common Lisp."; see http://tapoueh.org/blog/2014/05/14-pgloader-got-faster.html)

Re: Sylph: the programming language I want

#86
This is a great bag of "Hum, these things irritate me, let's do better". Couple critiques come to mind:

- too Rust/Python focused - the author needs more rounding of PL experience. I would suggest spending some more time with Haskell/ML and then some time with Common Lisp/Scheme. Reread the Programing Languages survey textbooks from college.

- not really enough familiarity with the theoretical side of PL. A metric ton of work has been done in academia, some of the listed problems have been solved, and at the worst, will give the author a nice way to go to sleep at night. This kind of relates to the previous point.

The concept of Locality I think is an important one and a real take-away from this essay. You want to be able to ensure that your code is meaningful locally without bouncing around half a dozen modules and inheritance trees just for basic understanding.

Re: Sylph: the programming language I want

#87

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…

Sure - not all syntax is superficial. But a goodly proportion of it is, I suspect.

That's why I kind of was trying to aim towards saying you /COULDN'T/ have a universal language syntax translator - but for a (new?) language, you could create (possibly) different interfaces to the central logic and structure of the code to suit different preferences.

Sort of how we have different skins and fonts and so on now.

Re: Sylph: the programming language I want

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

> Why? Just get the machine to do it.

I meant the writing stage, not the checking stage.

Imagine you don't know which type to pass. So, you'd have to pass something (null or whatever) in order to generate an error which gives you a clue.

That doesn't sound very convenient.

Well, the machine could check which types match that fingerprint, which might work okayish if the list isn't too long, but it won't tell you anything about the writer's intend.

Is a list of doubles, a list of ints, a Float32x4List, or a Float64x2List really the same thing?

What if it's actually meant to be used with something else which also supports the [] operator and whose items support the + operator.

Static analysis might not be able to tell you because it doesn't know all packages in existence. That package might not have been referenced, because that's not required to use a type from that package.

How does the generated documentation look like? It takes one argument "foo" which is something which has a "bar" field and a "baz" method? I'd rather have a concrete type there. "int x". Done.

What if you optimize the function a bit and now the fingerprint doesn't match one or more types anymore. Was this a breaking change?

Your intention didn't change. You always had one particular type in mind.

Re: Sylph: the programming language I want

#89
This bothered me a lot:

> I seem to have a knack for trying to write things in Rust that rely on intertangled references and mutability: first a game, then a UI library…

First of all, a UI library is EXACTLY the kind of thing I want you running through Rust and having a long, drawn out fight over mutability. Every UI we currently have absolutely sucks in a multi-threaded context. I want the compiler to make you think long and hard that maybe, just maybe your ideas about how to architect a GUI library are very broken and that you have to restart from a clean slate.

As for a game, do you really have that much mutable state, or are you just conditioned to use mutable state by default? Games do have lots of mutable state, but games also have lots of bugs due to multi-threading that being forced to analyze mutable state exposes.

Re: Sylph: the programming language I want

#90
post #13

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

[Note: if you add two spaces at the beginning of each line, it will look like code: import os import random def do_something(x): if x: fd = os.open(x) Note2: If one line with two spaces is too long, it will mess the whole thread, so if you ever want to quote use italics instead of spaces.]

Sorry about being pedantic.

PEPpy Python should have four spaces at each level of indentation...not two.

Now I feel better

Post reply on HN