Venting thread

[alice]

This thing is something I know, too. In my youth, I was skinny; now (at 53) I am not fat, but not particularly thin either (my BMI hovers around 25).

Bizarrely, this is exactly true in every respect about both myself and a good friend, except that I don't know the BMI for either of us.

[alice]

On a totally different note: does anybody else hate the Rust compiler? It's the least forgiving compiler I've ever met, even more so than the Scala one, and while I know it's for entirely admirable reasons, it's still far from a joy to use.

Alternatively, I've gone soft from doing too much Ruby and Python; YMMV.

[Travis B.]

On a totally different note: does anybody else hate the Rust compiler? It's the least forgiving compiler I've ever met, even more so than the Scala one, and while I know it's for entirely admirable reasons, it's still far from a joy to use.

Alternatively, I've gone soft from doing too much Ruby and Python; YMMV.

I have heard that the whole "borrowing" logic is a major pain in Rust (I have never used Rust by the way), but just because a compiler is not forgiving is not necessarily a problem. Take GHC for instance - getting code to compile under GHC Haskell is a pain, but once it actually compiles there is a good chance that it actually works.

[bradrn]

On a totally different note: does anybody else hate the Rust compiler? It's the least forgiving compiler I've ever met, even more so than the Scala one, and while I know it's for entirely admirable reasons, it's still far from a joy to use.

Alternatively, I've gone soft from doing too much Ruby and Python; YMMV.

I think it all depends on your attitude to programming. If you prize correctness, Rust and Haskell are perfect. If you value dynamicity instead, you’ll hate them.

[alice]

On a totally different note: does anybody else hate the Rust compiler? It's the least forgiving compiler I've ever met, even more so than the Scala one, and while I know it's for entirely admirable reasons, it's still far from a joy to use.

Alternatively, I've gone soft from doing too much Ruby and Python; YMMV.

I think it all depends on your attitude to programming. If you prize correctness, Rust and Haskell are perfect. If you value dynamicity instead, you’ll hate them.

That's a very good observation. In my experience I've encountered numerous situations where there's too much of one and not enough of the other, and I don't think any programming language has yet to strike the best balance. Hence my (futile) attempts at creating my own.

[bradrn]

On a totally different note: does anybody else hate the Rust compiler? It's the least forgiving compiler I've ever met, even more so than the Scala one, and while I know it's for entirely admirable reasons, it's still far from a joy to use.

Alternatively, I've gone soft from doing too much Ruby and Python; YMMV.

I think it all depends on your attitude to programming. If you prize correctness, Rust and Haskell are perfect. If you value dynamicity instead, you’ll hate them.

That's a very good observation. In my experience I've encountered numerous situations where there's too much of one and not enough of the other, and I don't think any programming language has yet to strike the best balance. Hence my (futile) attempts at creating my own.

Problem is, ‘the best balance’ is personal — I feel mildly uncomfortable with anything less safe than Haskell. I do have some ideas as to what might be a sensible middle ground which would satisfy most people, but it’s hard to know whether it would actually work well in practice or not. (And given the history of PL design, then answer is probably ‘not’.)

[Travis B.]

To me the ideal "big" language would be a strict-evaluated variation upon Haskell - strict-evaluated to avoid many of the memory issues that plague Haskell. (Even Simon Peyton Jones has stated that if he could redesign Haskell from scratch he'd make it strict-evaluated.)

[alice]

Problem is, ‘the best balance’ is personal — I feel mildly uncomfortable with anything less safe than Haskell. I do have some ideas as to what might be a sensible middle ground which would satisfy most people, but it’s hard to know whether it would actually work well in practice or not. (And given the history of PL design, then answer is probably ‘not’.)

And therein lies the nub of the gist, the root of the problem, the heart of the matter, nay, even the crux of the debate. Some programmers feel uncomfortably restricted with anything resembling any hint of type-checking, others consider anything other than the strictest possible type-checking to be akin to a serious and catastrophic moral breakdown. Don't you love humanity?

[Raphael]

Some programmers feel uncomfortably restricted with anything resembling any hint of type-checking, others consider anything other than the strictest possible type-checking to be akin to a serious and catastrophic moral breakdown. Don't you love humanity?

Oh, I suspect that humanity would probably be even worse if everyone always had the same attitudes towards everything.

[Zju]

On a totally different note: does anybody else hate the Rust compiler? It's the least forgiving compiler I've ever met, even more so than the Scala one, and while I know it's for entirely admirable reasons, it's still far from a joy to use.

Alternatively, I've gone soft from doing too much Ruby and Python; YMMV.

g++ says hi

[rotting bones]

Currently, the most usable language might be Q. It's multi-paradigm with functional programming and array processing. Its syntax is incredibly compact (a descendant of APL). The only book on Machine Learning with a functional language that I know of uses it: https://www.fun-q.net/ (Let me know if one exists for Haskell. I only know of articles like this: https://mmhaskell.com/machine-learning) Too bad the free license only lasts for 12 months.

My ideal language would of course infer types in a general effect system of stacking linear transformations. All mutations will be encoded as monads. Since I'm not sure how to create this myself, I'm thinking of a sci-fi novel about it.

[bradrn]

Currently, the most usable language might be Q. It's multi-paradigm with functional programming and array processing. Its syntax is incredibly compact (a descendant of APL).

Q compact? It’s the least compact array language I know of. K is better, though personally I prefer J and its rank system.

My ideal language would of course infer types in a general effect system of stacking linear transformations.

Could you elaborate please? I can’t see how linear transformations are related to effect systems.

[foxcatdog]

The pre vomit limbo is the worst the feeling like you are going to vomit plus the anticipation of another night where getting to bed is difficult is extremely annoying. I throught i was past this problem by now but it happened last night and possibly this night.

[rotting bones]

Q compact? It’s the least compact array language I know of. K is better, though personally I prefer J and its rank system.

"{$[x=0;1;x*.z.s[x-1]]}"

- Wikipedia

Could you elaborate please? I can’t see how linear transformations are related to effect systems.

I once read a paper about demonstrating the correctness of deep learning architectures by proving theorems on its tensor operations. In linear algebra, every tensor is a function, and tensor multiplication is function application. In my fantasy, we'd separate the categories of effects multiplying various classes of tensors can have. The code will refuse to compile if the operation is semantically invalid even if it can be carried out mechanically.

[bradrn]

Q compact? It’s the least compact array language I know of. K is better, though personally I prefer J and its rank system.

"{$[x=0;1;x*.z.s[x-1]]}"

- Wikipedia

OK, so you’re basically talking about the subset of Q which is similar to K.

Could you elaborate please? I can’t see how linear transformations are related to effect systems.

I once read a paper about demonstrating the correctness of deep learning architectures by proving theorems on its tensor operations. In linear algebra, every tensor is a function, and tensor multiplication is function application. In my fantasy, we'd separate the categories of effects multiplying various classes of tensors can have. The code will refuse to compile if the operation is semantically invalid even if it can be carried out mechanically.

That makes more sense, although from the sound of it I doubt that effects per se are the right abstraction here. Don’t know enough about tensor algebra to say anything more, though.

[alice]

deleted; it was entirely pointless.

[bradrn]

Minor rant: I hope you're not saying that computer programming, and software engineering in general, should be inaccessible to those without the proper theoretical mathematical background.

No, we’re saying precisely that it should be accessible to those without a mathematical background.

[alice]

something I have since deleted, as you can see

No, we’re saying precisely that it should be accessible to those without a mathematical background.

And I have forgotten how to keep several very similar things separate in my mind at the same time. Please ignore my minor rant in future.

[rotting bones]

OK, so you’re basically talking about the subset of Q which is similar to K.

Q is K with some macros and stuff to make it more readable in certain domains. IIRC in databases, for example. If you don't believe that Q is commonly used with the concise notation, check out this tutorial: https://youtube.com/playlist?list=PLypX ... iTqJZmVsqm

That makes more sense, although from the sound of it I doubt that effects per se are the right abstraction here. Don’t know enough about tensor algebra to say anything more, though.

I don't know what your objection is. Eg. There are tensors that select specific elements of other tensors they are applied to: https://youtu.be/1wPEB2XDMJo (this link is an IIRC) Wouldn't it be appropriate to represent these with an effect system?

[bradrn]

That makes more sense, although from the sound of it I doubt that effects per se are the right abstraction here. Don’t know enough about tensor algebra to say anything more, though.

I don't know what your objection is.

My objection is simply that from the sound of it, effects feel like the wrong approach to me. It’s little more than an intuition at the moment, based on the fact that tensors don’t in general represent side-effecting computations, which is what effect systems are best for.