Point taken. I forgot that brackets are not shifted on my keyboard.
They do require worse acrobatics than a shift key on a German keyboard, though - one of the Alt keys is special and needed to trigger them, if memory serves.
Well, that's another argument for everyone to use an English layout for coding, I suppose.
It's such a lot of effort to make a language like this. I don't get why they don't just put in like 2% more effort and add syntax that makes it less awful for humans. Nobody really wants to write `[* 5 5]` do they?
[fn square [x] [* x x]]
Could very easily be
fn square(x) = x * x;
Or something like that, which is much more readable.
Also
> Hindley-Milner inference eliminates type annotations.
I think it's pretty widely agreed at this point that global type inference is a bad idea. The downsides outweigh the upsides. Specifically: much worse errors & much less readable code.
I do. The advantage being that if you suddenly realize that you want to do super-duper-multiplication instead of regular multiplication, you can just change the name instead of having to rewrite the entire expression. And honestly, having a few random functions be called differently from others feels gross.
There’s no use arguing. As the ancient Lisp proverb says, when the programmer is ready, the parens will disappear. Until then, you’re just wasting your breath.
No because the syntax is so awful. Programming languages are consumed by machines but written by humans. You need to find a middle ground that works for both. That's (one of the reasons) why we don't all program in assembly any more.
Lisp and similar are just "hey it's really easy to write a parser if we just make all programmers write the AST directly!". Cool if the goal of your language is a really simple parser. Not so cool if you want to make it pleasant to read for humans.
I've never used a Lisp either, but I get the impression that "forcing you to write the AST" is sort of the secret sauce. That is, if your source code is basically an AST to begin with, then transforming that AST programmatically (i.e. macros) is much more ergonomic. So you do, which means that Lisp ends up operating at a higher level of abstraction than most languages because you can basically create DSL on the fly for whatever you're doing.
That's my impression, at least. Like I said, I've never actually used a Lisp. Maybe I'm put off by the smug superiority of so many Lisp people who presume that using Lisp makes them better at programming, smarter, and probably morally superior to me.
This view is false because what is hard to parse for machines also presents difficulty for humans.
We deal with most languages (Lisp family and not) via indentation, to indicate the major organization, so that there isn't a lot left to parse in a line of code, (unless someone wants to be "that" programmer).
As someone who writes a lot of Scheme, I agree that the math syntax is not good. There have been proposals to add infix expressions (https://srfi.schemers.org/srfi-105/) but nobody seems to want them, or can agree on specifics.
However, code that is mostly function calls is fine for me, since those would have parentheses anyways in C++/Rust/whatever. In that case it makes the language more regular, which is nice for writing macros.
Earlier last year, I "quietly" introduced an infix support macro into TXR Lisp.
I devised a well-crafted macro expansion hooking mechanism (public, documented) in support of it.
It works by creating a lexical contour in which infix expressions are recognized without being delimited in any way (no curly brace read syntax translating to a special representation or anything), and transformed to ordinary Lisp.
A translation of the FFT routine from Numerical Recipes in C appears among the infix test cases:
The entire body is wrapped in the (ifx ...) macro and then inside it you can do things like (while (x < 2) ...).
In completing this work, I have introduced an innovation to operator precedence parsing, the "Precedence Demotion Rule" which allows certain kinds of expressions to be written intuitively without parentheses.
Why? It's pretty useful for connecting with recruiters in my experience, and I don't think anyone can actually do anything just because they have a connection with you.
I do ignore the connections from random students though tbf.
Connecting with recruiters is mostly a waste of time, and generally anyone can just fake being a recruiter. Once someone has a connection with you they can see your extended network, they know where you work, they find out all information you have shared with on your profile, &c. The recruiter may be using you to connect with someone else. You also start to consume their content since you are connected. Better to let them follow you and then when it's time to reach out to offer you a job/send an in-mail.
Generally speaking, unless you operate at an elite level or at an elite institution, you're not getting a ton of worthwhile cold intros from recruiters.
> Connecting with recruiters is mostly a waste of time
Probably depends on the field but this definitely isn't always true. I've got my last two jobs through recruiters, and speaking to colleagues a lot of them do too.
> they can see your extended network, they know where you work, they find out all information you have shared with on your profile
This is public anyway though? Isn't that the point of LinkedIn?
> You also start to consume their content since you are connected.
I don't because I don't read LinkedIn. I pretty much only use it to get jobs. Although I have actually started posting technical stuff I've done there because people actually read it (I guess other people do read LinkedIn tbf!)
> Generally speaking, unless you operate at an elite level or at an elite institution, you're not getting a ton of worthwhile cold intros from recruiters.
I'm definitely not elite level and I would say ~20% of the jobs I get from LinkedIn recruiters are of interest. That's pretty good! Almost all of them are at least relevant to my field (silicon verification). Sometimes I get stuff about mechanical engineering validation, or software jobs that aren't relevant but that's pretty rare. It must depend on the field. Maybe the country too?
> This is public anyway though? Isn't that the point of LinkedIn?
You can limit this. I don't think it's necessarily the point of LinkedIn - i.e. for others to connect with you and then have full visibility into all of the details of everyone you know and whatever you have on your profile. It's a bit naive to assume that operating in this manner doesn't make you a prime target for scammers, social engineers, hackers, &c., or even worse - solicitors.
> My experience is different
Yea, everyone has different experiences. I'm just describing how the platform generally works, as a matter of fact.
Are they going to have an exception for waterproof phones? Seems like it would be challenging to implement replaceable batteries while maintaining waterproofing. Are there any waterproof phones on the market with removable batteries?
Why? You can use an o-ring around the seal and screws to press it together. Even simpler: a water bottle like you might bring to the gym or while hiking is water proof, without needing glue. It is a solved problem. But the solution adds tens of eurocents to the cost of the phone, so the manufacturers won't do it unless they are forced to.
AI is not yet at the point where non-developers could use it to build useful apps. I've tried. It gave me a good start that saved me a ton of time setting things up but the result was buggy and had a lot of bad code, so I still had to read and understand it all and fix the issues.
> What if you want a library that isn't available in every distro? Or a specific version of a library?
Then your wrapper builds a native package for that first. After all it is building a native package for your application next, why would it be unable to also build a package for that library?
> I don't think anyone follows your "rule" because it would be such a mess.
Everyone offering distro repos is building packages like that, and that's a lot of projects.
The problem of libraries not being packaged is solved by distro-agnostic packaging systems. Why do you think everyone uses PyPI, Cargo, Go modules, NPM, etc. instead of this insane "package your app and all of its dependencies for every distro" idea? Pure lunacy.
It is not difficult to package for the most important distro (the others usually import from them). Those distro-agnostic packaging systems are popular because they basically have no quality control at all, so it is basically no effort to package for them, just register a github repository somewhere. But this is also why they are full of garbage and have severe supply chain issues.
> But this is also why they are full of garbage and have severe supply chain issues.
I don't think the solution to supply chain problems is "just make supplying things so shitty and annoying that nobody will bother". Not a good one anyway.
reply