alphaalpha101

>But that feels like the debate about Illegal Immigrants. One side says "what part of illegal don't you understand" and the other responds with "hey, these are good humans."

Is there any country other than the USA where pretending immigration laws don't exist is a mainstream political viewpoint? Serious question here.

But the escapes aren't actually standardised to particular values, as far as I remember. The terminfo database exists for a reason. Assuming every terminal is 'xterm' is an awful idea.

I actually really like Vimscript. It has features that many popular languages lack or have only recently got, like destructuring

    let [file, line, col] = split("hello.c:39:10", ":")

This is the sort of feature I just assumed it didn't have, because few enough real programming languages have it.

The main issue I think is that there are lots of different contexts where you can put vimscript, and different bits of vimscript are legal in those contexts, or at least seem to be.

You can prove it, but you can also prove that a C++ programme has no memory safety bugs. And there are a lot of languages where you don't have to, where it's simply impossible to get memory safety bugs (assuming the runtime is safe).

For nontrivial libraries that use a lot of unsafe, it really is very difficult to know that all the uses of unsafe don't interact in some way to create unsafety. The scoped lock that had a problem in Rust 1.0 (or just before it?) is an example.

You can force callers to maintain your invariants in C++ too, simply by using some basic safety. Yes people can still do things that are obviously visually unsafe in code and undefined, but that's not a serious issue.

I still think Rust is better here. Don't get me wrong. But it's very hyped as 'safe and fast' when it just isn't safe.

It doesn't matter that it's 'kind of unusual', even though I contend that it isn't. Even if, for the sake of argument, we assume that it is, that doesn't change my point.

My point is that the whole point of Rust is supposedly that it

>is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.

except that when you look at any of the examples of code that really would benefit from the compiler's help, the compiler just throws its hands in the air and goes 'it's all up to you now'.

The problem is that Rust doesn't let you make a single assumption and let the compiler prove the safety of the code using that assumption. It just has a valve that you can hit that removes all guarantees.

If you could say 'this code is safe assuming that this FFI function doesn't exhibit undefined behaviour, please check that for me' or write a proof that says 'this actually is safe, because this pointer can only ever point into this valid memory or this valid memory, and this is why' then the compiler would still be useful.

Whether 'this work' (which is not just creating data structures, but anything that the compiler doesn't understand, which is much broader than just creating data structures) is unusual or not, IMO the whole appeal of Rust is that it makes doing that work easy. But it doesn't.

Rust just doesn't seem worth it, doesn't seem worth rewriting whole ecosystems of code. It doesn't give any actual safety.

Rust doesn't ensure memory safety or safe concurrency. It ensures memory safety - including data race safety, just one part of safe concurrency - assuming you never use any unsafe code and that the standard library is free of bugs. I'm happy to assume the standard library is free of memory safety bugs, because you have to trust something.

But I'm not happy trusting that dependencies aren't using unsafe code, and I'm not happy claiming that Rust ensures safety, when it ensures safety only if you assume that unsafe blocks aren't unsafe.

The problem is that you can't check unsafe blocks locally. Checking that each individual unsafe block doesn't have undefined behaviour requires checking the entire programme.

It's better than nothing, without a doubt, but it isn't safe.

I don't want to write nt(a=1, b=2). That's ugly. I want to write (a=1, b=2).

Being able to implement it without changing the syntax is irrelevant to the users of the language, mostly. It's an implementation concern. I've always felt that being a little harder to implement isn't a point against a feature, if it's good for users, because even a small improvement for users is usually much less effort in total than even a large implementation effort.

Not necessarily. There is no actual reason that you couldn't be required to prove to the compiler that your code is safe.

That proof might be parameterised by a proof that some external FFI function was safe, which you might not be able to actually prove and have to assume, but then you would have your assumptions well-documented.

As it is, you have to justify the safety of your unsafe blocks to other programmers using comments, which kind of sucks.

Still better than every other fast language in this area though so I can't complain much.

It's also really no better than C. Or at least no better than C++.

This is my main issue with Rust. It doesn't seem to really solve the right problem. I feel like it solves the easy problems that I already know how to solve easily, but as soon as I get to something that really, truly feels like I want it, the best solution is unsafe.

A complicated circular linked data structure is exactly where I want the language to be screaming at me if I make a silly error. But Rust doesn't even consider memory leaks to be errors...

> Either way (or both) would be implemented in C for speed. It would allow named tuples to be created without having to describe them up front, as is done now. But it would also remove one of the principles that guided the design of named tuples, as Tim Peters said:

> > How do you propose that the resulting object T know that T.x is 1. T.y is 0, and T.z doesn't make sense? Declaring a namedtuple up front allows the _class_ to know that all of its instances map attribute "x" to index 0 and attribute "y" to index 1. The instances know nothing about that on their own, and consume no more memory than a plain tuple. If your `ntuple()` returns an object implementing its own mapping, it loses a primary advantage (0 memory overhead) of namedtuples. Post-decree, Ethan Furman moved the discussion to python-ideas and suggested looking at his aenum module as a possible source for a new named tuple. But that implementation uses metaclasses, which could lead to problems when subclassing as Van Rossum pointed out.

> Jim Jewett's suggestion to make named tuples simply be a view into a dictionary ran aground on too many incompatibilities with the existing implementation. Python dictionaries are now ordered by default and are optimized for speed, so they might be a reasonable choice, Jewett said. As Greg Ewing and others noted, though, that would lose many of the attributes that are valued for named tuples, including low memory overhead, access by index, and being a subclass of tuple.

> Rodolà revived his proposal for named tuples without a declaration, but there are a number of problems with that approach. One of the main stumbling blocks is the type of these on-the-fly named tuples—effectively each one created would have its own type even if it had the same names in the same order. That is wasteful of memory, as is having each instance know about the mapping from indexes to names; the current implementation puts that in the class, which can be reused. There might be ways to cache these on-the-fly named tuple types to avoid some of the wasted memory, however. Those problems and concern that it would be abused led Van Rossum to declare the "bare" syntax (e.g. (x=1, y=0)) proposal as dead.

From what I've read, v8's implementation of objects in Javascript goes basically like this: when you call a constructor function and assign properties to your object, it makes up struct types and ties the object to that type or something.

Like this:

    function Point2D(x, y) {
        this.x = x;
        this.y = y;
    }
    let p = new Point2D(1.0, 2.0)

initially you'll have an empty object, which will be an empty struct. 'this.x = x' will change the type to the 'X' struct, and 'this.y = y' will change the type to the 'XY' struct. If you do this again with another object, they'll share these underlying structs.

Now this is perhaps easier with a JIT, and perhaps not. But it bears thinking about. Why not just make it so that (x: 1, y: 0) - which would be the best syntax IMO as it fills out the {set, dict; tuple, ???} square - creates an object that shares its class with every other namedtuple that has exactly the x and y properties in exactly that order?

It really frustrates me when I read 'Those problems and concern that it would be abused led Van Rossum to declare the "bare" syntax (e.g. (x=1, y=0)) proposal as dead.' I mean come on, I know it's a different environment in Python than in V8, but seriously this is a solved problem. Those problems? Those problems are a solved problem that a solution was already proposed for in the thread. Just do that.

>He elaborated on the ordering problem by giving an example of a named tuple that stored the attributes of elementary particles (e.g. flavor, spin, charge) which do not have an automatic ordering. That argument seemed to resonate with several thread participants.

I don't want to be too harsh, but this is nonsensical rubbish. Dictionaries preserve order in Python. This ship sailed a long time ago. Namedtuples also already preserve order. Tuples preserve order. Lists preserve order. Dictionaries preserve order.

What doesn't preserve order? Like, I get that it's not strictly defined that dictionaries preserve order, but they do, and people do rely on that, and so it's never going to actually be changed.

>This is exactly why I scream at relational databases. If you can't tell the difference between a set and a list, and especially if you want to store a list in a set-based paradigm, you are going to have ALL SORTS of grief ...

Unrelated but I found this comment funny. This guy has heard of an index, right?

My PC is powered, I think, entirely by hydroelectric power stations. Almost all of New Zealand's power is.

And if you don't think being an entrepreneur/startup founder/businessman is the pinnacle of human achievement? What then?

>The worst PhD productivity advice is to work long hours. This advice is shared by successful people in Academia, so it should be good advice, shouldn’t it?

Is it though? Because I've never heard this ever. I've heard over and over again to avoid working long hours. It always annoys me when articles start off on premises like these that I just don't think are true.

They aren't really REPLs.

>Your argument is the equivalent of saying notepad isn't a text editor because you can't edit multiple lines at once or highlight syntax.

No it's the equivalent of saying that not even programme that can possibly, technically edit a text file is a text editor.

Python's shell thing is not a REPL.

I don't understand how these coins have value. Surely things only have value if they:

1) have some scarcity, and 2) have some useful purpose.

I can see how these coins get scarcity, but what is their useful purpose? What can I do with FacebookKillerCoin or TwitterKillerCoin or EAGamesKillerCoin? If they're just essentially 'gift card currency' and the company will buy them off me in exchange for their products, why use a blockchain in the first place? Just call them loyalty points or whatever.

> Just to keep things in perspective, all I'm saying is that "the ability to write multiplication naturally" comes at a cost. I'm aware of Haskell/ML-like syntax for curried functions, but it is at odds with juxtaposition for multiplication.

But it doesn't. I've already explained why it's not an issue: they associate the same way (so it's not a parse-time issue), and they're never ambiguous (the type of the LHS is a function in one case and a number in the other case, and functions and numbers are never the same, so it's never an issue).

>Recall, I said "tends not to". My point was that the notation of mathematics is set up to prefer the case of functions returning values.

Functions are values...

>I meant 3f(x) to mean 3*f(x). I believe you'd want to be able to write 3f(x) since you should be able to have the "ability to write multiplication naturally," in your words.

    3 (f x)

>But sin can be represented as a power series and cos can be substituted in with cos^n meaning iterating cos n times. This may or may not be reasonable; I don't think it is "obvious."

I think it's pretty obviously unreasonable. In any reasonable language:

    sin : Number -> Number
    cos : Number -> Number

So 'sin cos' is going to be a type error: "type mismatch, expected type 'Number' in argument to 'sin', got 'cos: Number -> Number'.

>If you do it naively, the complexity will be exponential

Hindley-Milner type inference is doubly exponential already but is still widely used. If people never actually use extremely nested expressions in real code that require this sort of disambiguation then it will probably be completely fine.

>That's altering the syntax for function application by allowing f x to mean f(x), which is fine but changing the rules. If we do go with that, then "a b c" should be "Apply a (Apply b c)" because of the associativity of application --- traditional math tends not to have functions which return functions.

That's the standard way of writing function application in functional programming languages.

And in those languages,

    f a b c
    ==
    (((f a) b) c)
    

because they're curried: a function of 2 arguments (f: a -> b -> c) is a function f from type a to type (b -> c).

And mathematics definitely has functions that return functions. For example, any function where the codomain is a space of sequences is technically a function that returns functions, as a sequence in X is a function from the natural numbers to X.

>There is an ambiguity which comes up when you allow both f x and f(x) syntax, which is you cannot tell the difference between f(x,y) and f((x,y)) if your language has tuples. (One solution: make tuples be like Mathematica's Sequence, thus establishing the associativity of Cartesian products once and for all.)

You don't need to tell the difference. If you have a curried function, then you write 'f x y' which isn't the same as 'f (x y)' (which is like the C-style 'f(x(y))'. If you have a non-curried function, then 'multiple arguments' are just a tuple, at least that's how it works in ML.

A function that takes a tuple and a function with multiple arguments are equivalent. That's related to the fact that ((A AND B) IMPLIES C) is equivalent to (A IMPLIES (B IMPLIES C)).

>A gotcha is that you can't write f(x)(y) if your function does return a function, since this will parse as f(x y). You would need to write (f(x))(y) instead. (If you insist the associativity rule should be the other way, then 3f(x) would be (3f)x, which is possibly ok, and sin cos x would be (sin(cos))(x).)

sin cos x is okay notation in mathematics because sin can't take cos as an argument, so it obviously has to mean 'sin(cos x)' and not 'sin(cos)(x)'. But when dealing with computers, I would far rather just write sin (cos x) which is how people write it in Haskell/ML/Lisp.

Not sure if you mean existential quantification or just the number 3 in '3f(x)' but as I said, I don't think that it's a good idea to support 'x f' as meaning '(lambda (a) (* 3 (f a)))' or '(a => 3 * f(a))' or '\a -> 3 * (f a)' or whatever your preferred function notation is for that scaling operation.

It seems so insane to me that we have a company that is spending billions of dollars per year to break the law all over the world by undercutting while making a loss to corner markets, that is breaking labour laws all over the world, is a horribly toxic place to work, and this is just... okay and fine?

Why is this a thing? Imagine all the useful things those billions could do. Feeding and housing all the homeless people in the USA, for example.

When I first encountered material implication I thought it was just stupid. False implies anything? Everything implies true? That's not what implies means, there must be some sort of relevancy, surely?

The block for me was treating material implication as if it defined what 'if' meant in natural language. But it doesn't. 'If I am a turtle then the president of the United States is Hillary Clinton' isn't a statement about a relationship between whether or not I'm a turtle and who is the POTUS. It's a formal sentence. It's like a regular expression or something. It has no real meaning, it's just symbols. It's just 'Q Y C' or '$ ~ F' or 'A -> B' in a formal language. We give semantics to those symbols by assigning a truth value to 'A -> B' as a function of the truth values we assign to the symbols A and B.

It seems silly if we substitute A for something clearly false and B is substituted for something also false and clearly unrelated, but that's because when you read the statement above it looks like natural language, and it is natural language, but logic isn't about natural language. It's about formal language.

If you write it as 'I am a turtle -> Clinton is the POTUS' then it becomes a bit more clearly just 'arbitrary false thing -> arbitrary thing'.

If you try to divorce the concept of material implication from the natural language construct of 'if..then..' then you shouldn't have a problem.

Remember, material implication is truth-functional, which means that the truth value of 'A -> B' is just a function of the truth values of A and B (namely that it's true unless A is false and B is true), not whether they're related or relevant to each other.

>That syntax doesn't work along with using parentheses for function application unless you do something like making the parser context-sensitive (so function followed by '(' means application but value followed by '(' means multiplication) or treat whitespace as significant (so "f(x+1)" is application but "f (x+1)" is multiplication). This is why Mathematica does Sin[22] instead of Sin(22).

I'm not so sure that's true? You can just parse 'a b c d e' as

    Apply (Apply (Apply (Apply a b) c) d) e)

and then you can just say that Apply is overloaded to mean multiplication for numbers, just like + is overloaded to mean concatenation for strings in most languages, but addition for numbers. It doesn't actually change the parsing, your parsing doesn't become context-sensitive. 'Apply x y' would mean multiplication if the arguments are numbers and application if the left argument is a function.

Even if you allow multiplication of functions by scalars (which you probably shouldn't, IMO) you can easily say that 'x f' means 'x times f' while 'f x' means 'f applied to x'.

>I know you can type superscripts, subscripts, fractions, etc. using shortcuts. If you meant "as you type it" as in Mathematica will reformat what you type in more traditional notation as you type it, then I am wondering where you can enable that.

Well you can write :alpha: and it will make it an actual alpha character, you can write superscripts and it will superscript them, it will make fractions readable, etc. It will turn -> into a unicode right arrow, that sort of thing.

If you want to be literal about it then sure, it just means read-eval-print loop. But I think that's akin to saying that a functional programming language is a language that has functions in it.

EDIT: To be clear, what I'm saying is that when people say 'I really love using Common Lisp because it has a REPL' they aren't saying 'I really love using Common Lisp because it has a prompt I can write raw strings of code into that executes that code and has no other features'. That's not a lovable feature.

People love Lisp REPLs because there's much more to them than that. In Lisp, the REPL is more like GDB than it is like Python's REPL.

Not really sure why the reaction to my comments here is so viscerally negative. Very few terms that we use are wholly literal. REPL isn't literal either.

Yeah that was pretty worthless as a comment.

This line is a straw man. I'm sure code like that exists, but it's hardly the best we can do. The proposed system is good enough that you don't have to compare it against a straw man for it to look good and useful.

    force = 6.67*10^-11*mass_1*mass_2/radius^2

Firstly, we can write it like this

    force = 6.67*10^-11 * m1 * m2 / radius^2

And what language doesn't support this?

    force = 6.67e-11 * m1 * m2 / radius^2

Andalso what about an abstraction, and the ability to write multiplication naturally?

    -- a.k.a. G
    -- nobody really knows why this is so different from what relativity predicts
    const GRAVITATIONAL_CONSTANT = 6.67e-11

    fun gravitationalAttraction(m1, m2, radius) =
      GRAVITATIONAL_CONSTANT m1 m2 / radius^2

    val force = gravitationalAttraction(mass1, mass2, radius)

Now we actually know what it's calculating and why, and what that tiny number is. Would it be better if rendered as a large fraction? Absolutely. But I think it is less necessary if you write code like this well.

The suggested system is good but not novel. Rendering maths as you type it has been there in Mathematica, etc. forever.

Well maybe. I think the implication there is 'I would pay a subscription to use this service if I had to, and would prefer that than an ad-supported service'. I don't think it's 'I would pay money for no reason rather than using an ad blocker'.

They aren't really REPLs. A REPL isn't just a prompt that you can put code into.

>My point is, I don't think a lot of you are being totally honest when you say you'd be willing to pay if the site removed advertising.

Well why would I do it if I don't have to?

I'm happy to pay for Netflix because there are no ads and it's just a better more convenient product than torrenting is.

Isn't it still undefined behaviour to do so, though?

I think the difference is that Rust and Go projects seem to be posted to HackerNews (and upvoted!) much more than Python and C++ projects are, despite there being way more of the latter.

Maybe you shouldn't choose to have such a terrible healthcare system then.