> You always feel like you are trying to trick the system into doing something it was not designed for.

This is one of the hallmarks of human civilization.

Your hands were designed for throwing a stone at the eye of a mammoth. But you can play the violin with them! Yes; it is totally awkward and anti-natural for your hands, obviously not their intended purpose... but so beautiful!

I would disagree. You can play the violin firstly because the violin was designed so that it could produce beautiful sounds under _human_hands_. This way, not another.

It seems you are actually in agreement with the underlying argument. Humans were able to use their body, originally developed for hunting large prey, to design, build and play violins.

> Your hands were designed for throwing a stone at the eye of a mammoth.

No, they weren't designed at all.

And utility in fine as well as gross manipulation of the type you describe is clearly part of what they were selected (not designed) for.

> But you can play the violin with them

Violins, unlike human hands, were designed, and specifically for people with human hands to use. They aren't just something existing outside of humans in nature that hands happen to work with.

So, it's not at all surprising that they can be used with human hands.

> This is one of the hallmarks of human civilization.

This is one of the hallmarks of evolution.

How do you think wings evolved? By repurposing an appendage that was already had a purpose other than flight.

We didn’t evolve to play instruments though, we adapted and created them to suit our existing physical form

Our hands were not designed, and they have no “intended purpose”. We have hands because throughout the extremely long line of evolutionary adaptations the individuals that had them ended up surviving and procreating, and so we ended up having them.

This is not true of a violin, which is of cause the product of intelligent design and is designed to fit our hands, no Awkwardness intended. Though naturally there are constraints dictated by the physics of the sound generation.

Nope, we use stones because we can lift and throw it with our hands, not the other way around.

I see what you're saying, but the violin was designed for human hands.

Nothing in nature was necessarily "designed"

I'd go so far to say that linguistically nature is the antithesis of artificial (made by hands).

Avoiding silly theological tropes, evolution is often mistakenly referred to as a designer when it's just an emergent property of competing, replicating agents. People don't normally bother with precision though, so we are where we are.

I always like to see it the other way around, it eliminates entities that are not a good fit, and the remainder is what drives adaptation. Of course, people could argue that's just like Michelangelo [1], and we're back at 'designed'.

[1] “The sculpture is already complete within the marble block, before I start my work. It is already there, I just have to chisel away the superfluous material.”

> it eliminates entities

But evolution doesn't eliminate entities. Low fitness entities are eliminated by hunger, or predators, or lower reproductive rates.

The marble on the other hand is eliminated by Michelangelo.

There's a linguistic confusion where because evolution is a noun, we think we can treat it as a subject. But in the person/place/thing/idea delineation, it is an idea.

Not only does it not design, not only does it not eliminate: "it" doesn't do anything!

Of course 'evolution' is not an actor, it's just the overall pattern we give a name to. And the pattern we observe is that low fitness entities are eliminated. That plus variation yields adaptation.

Well, yeah.

The process of evolution is more than just the elimination of unfit specimens. That suggests that a tiger is just a tiger, and the only kind of evolution that can occur in the tiger is for it to become a better (faster, stronger) tiger. But in fact there was a time when carnivores didn't even exist, and then some random genetic flux produced an animal that was inclined to start eating other animals and a new ecological niche was discovered. Evolution is therefore a creative process of adaptation and specialization under constantly changing circumstances.

> That suggests that a tiger is just a tiger,

Not at all. Everything can come from variation (mutation, cross over) + elimination of the worst. It's just that 'worst' is not a global minimum. Are we as humans superior to animals in strength, agility, speed, etc? Not at all. But some distant ancestor had some bigger brain, and that gave it all the edge it needed compared to weak and dumber siblings that were eaten, while our ancestor hid on a tree.

When some animal mutated to be able to eat meat in addition to plants, it had some advantage and was less likely to be eliminated when food got scarce. That's all you need to eventually arrive at something tiger-like.

That said, some animals seem to have reached a local maximum: sharks haven't changed in millions of years, cockroaches seem pretty successful, too.

But there's nothing 'creative' about it.

In my interpretation entities != organisms

Entities could be alleles, genes, or gene products

If you consider a "design" to result from a process where someone sketches out a plan, builds it, and it works first time. I've designed a lot of systems, and it is clearly an iterative process. Balancing tradeoffs, figuring out the essentials, build prototypes, test, etc. If you are patient and diligent a solution emerges. That sounds a lot like evolution, so in my mind everything in nature has been designed by the collective intelligence of an iterative process that rewards useful optimizations.

I think that's a reasonable perspective to take, although I would argue that there is no clear goal in evolution besides survival and reproduction

The nice thing about a goal, is that one goal begets other sub-goals.

Or rather, a goal begets a strategy, and a strategy begets sub-goals. Beautifully at some point these sub-goals start being optimized for. A few steps of this is how I believe humans went from the sub goal "Survive, eat, reproduce" to "Make art, understand life, explore the world".

The cool thing is that I think this extends beyond humans to tools. Because at some point humans had a sub-goal of "hit thing hard" they made a hammer. And this hammer has a goal (or a purpose) which is "hit things hard". This purpose can be traced back, through human sub-goals, to the final goal of evolution: "reproduce".

Note that I am not saying that the point of a hammer is to produce more hammer. But the point of a hammer is (very indirectly) to allow a human to reproduce.

Interestingly there is a weird game of telephone that can happen, where the sub-goals are imperfect for achieving the final goal. I would argue that this is (part of) why humans can be truly selfless. Take a soldier going to a battle he considers unwinnable but going out of a sense of duty / fear of ridicule. This will not help him reproduce, since the battle is unwinnable it will not help his progeny reproduce either. From the 'ultimate' goal, this is an irrational step. But there are sub-goals at play. Things like "be honorable", "do your duty".

This idea that a sub-goal can subvert the 'ultimate' goal is very beautiful to me. It means that evolution is not some tyranny that sets our purpose in life. Instead evolution brought 'purpose' into the world. And then some stochastic process put you and me on into the universe with some, vaguely related, sense of purpose. But we have our own purpose. Sure our purpose was 'created by' the ultimate purpose of evolution. But our purpose is not subordinate to the ultimate purpose of evolution. A human life can have so much more value that just "continue the genetic line and have children". I find that freeing.

There is no plan in evolution. That's the point. It's a reactionary phenomenon. If it had a plan, it would be a proactive phenomenon. Evolution is happenstance.

Design has a goal, evolution has not.

Proponents of the anthropic principal disagree. Nevertheless, it's irrelevant to this thread.

No, its definitely relevant. Hands were not designed with any specific function in mind. There was not evolutionary pressure to "throw rocks at the eye of a mammoth"

Did orangutans evolve hands to throw rocks at mammoths? No, they did not

The parent comment is making ridiculous claims without evidence

https://www.worldatlas.com/articles/what-do-orangutans-eat.h...

You've smoothly shot right past solid ground (evolution doesn't design things) to a fairly wild claim (rock-throwing apes didn't experience evolutionary pressure to get better at throwing rocks).

Orangutans aren't humans, so what are you saying, apes which don't throw rocks to kill their prey don't... throw rocks to kill their prey?

Perhaps my example is poor, but it shows that hands are not coupled to predation

I'm specifically talking about the evolution of hands, humans are not the only organism with hands.

The poster didn't say "hands", they said "your hands".

Your human hands, which co-evolved with throwing things, we have abundant paleontological evidence of this and you may read as many papers on the subject as you would care to.

Got links to any of those papers?

Are you vegan? Just curious.

No, but I'm not sure what that has to do with the topic at hand

Also unsure how that's an appropriate response to a request for citations?

This seems accurate to me.

Like complex brains are evolutionarily fit because they can solve lots of disparate problems, hands are evolutionarily fit because they can do lots of disparate things.

Of course, we do also then design violins for our specific dexterity.

I think you're assigning too much weight to the word itself. In informal settings, or even quasi-formal ones, it's not uncommon to use "designed" when we don't mean "literally designed".

The use of "design" in the context of the structure and capability of human bodies means precisely "literally designed" to many religious people, including many readers of HN.

So I don't think it's out of place for the GP to address this.

Thank you. This was exactly the point of my comment. While some readers interpret the word lightly, there are many who use it literally in the context of biology with a reference to creationism. There is no evidence for creationism

> Proponents of the anthropic principal disagree. Nevertheless, it's irrelevant to this thread.

The anthropic principle does not imply designed, it implies suited for.

Sculpted like a riverbed.

My main issue with LaTex is that you can't take a perfectly correct piece of markup, insert it into a container like a table, and expect it to work.

LaTeX makes it difficult to compose stuff. Even HTML did this better.

Not to mention that when it fails to compile, at least in Overleaf you get an error log that is hopelessly useless and the only thing you can do is just remove your changes until it works again.

LaTeX is a cool idea, but the implementation? Absolutely horrid.

There are two big challenges: One is that TeX, the underlying executable behind LaTeX, is pushed to its limits¹ to run. The macro expansion paradigm behind LaTeX made sense in 1982 but there are a lot of decisions underlying the executable and TeX-the-language that were dictated by the computing technology of the 1970s (forget Unicode, standard ASCII wasn’t universally available when Knuth wrote TeX).

The other problem was the questionable decision by the LaTeX core team to, rather than release LaTeX3, they instead decided to evolve LaTeX2e which means that they are encumbered by backwards compatibility issues.

The noisy output from LaTeX is also not so great. One of the things I’m doing with finl is (a) assuming that there won’t be an attempt to fix errors mid-run (one of those 1982-era decisions that no longer makes sense) so a comprehensive list of errors can be presented to the user (or revealed programmatically) and (2) Adding indications in the output (which can be disabled) of errors in the input. I’m debating between errors being PDF annotations so users would click on an error or warning icon in the PDF to see the message and indication of where the issue was found, or just making it a big blot of overprinting (so many times on tex.stackexchange there are so many issues where a user—usually on Overleaf—ignored the error messages being output.

⸻

1. Actually beyond its limits. LaTeX will no longer run on a Knuth TeX executable but requires eTeX extensions to run.

> errors being PDF annotations so users would click on an error or warning icon in the PDF to see the message and indication of where the issue was found

This would be by far the best approach, no?

I haven’t seen any updates to your “finl is not LaTeX” page in a while. I’m glad to hear you’re still working on the project.

I should have an update when the next crate is ready for publication—I ended up writing some Unicode handling stuff because unicode-segmentation didn’t offer the interface I needed while unicode_categories is outdated and has a flawed implementation (my replacement code is 10x faster by my benchmarks). I need to do some additional work to verify that my segmentation algorithm is at least comparable in speed to unicode-segmentation and fix that if it’s not and I’ll have a 1.0 release of finl_unicode ready probably in the next month.

Yes! Plain python is almost always crystal clear and self explanatory. But "idiomatic python" which people seem to compete to be "more idiomatic than thou" is none of these things. It's actually a barrier to learning the language.

Idiomatic python is slow. Trying to convert everything into the mini-DSL that a C implemented library can understand is oftentimes considerably faster.

In case of most ordinary datasets it simply doesn’t matter in practice. Even comenius logo would be adequately fast.

> almost always crystal clear and self explanatory

and slow. Most of the time the idiomatic pandas answer takes advantage of its vectorization capabilities while plain python would require nested loops.

This is one of the advantages of languages with optimizing compilers. In Python, there's a tradeoff between clarity and performance. But in C++ for example, your for-loop is just as fast as any library's for-loop.

Edit: My assumption is that many Python libraries are written in C for performance, but maybe that's not the case.

>But in C++ for example, your for-loop is just as fast as any library's for-loop.

This is most definitely not true. Even stuff like subtle aliasing guarantees can make code run an order of magnitude faster or slower.

Another example is the order in which you access memory. To multiply two matrices, in one you move by row and in the other you move by columns. One makes the cache happy and the other unhappy, so it's faster to transpose one of them (the correct one, I never remember) and them "multiply" them. We notice this in Fortran with -O2, but the difference disappears in Fortran with -O3, so the compiler is doing some magic.

In case of these libraries it is mostly the case of painstaking optimizations in low level code. No common language has sufficiently smart auto-vectorization to reliably convert for loops in most cases to SIMD instructions - so no, your average C++ for loop wouldn’t be that much faster, unless you spend a lot of time optimizing it for the specific task.

Except that your C loop can be WRITTEN slower than some library’s loop.

Someone pointed out to me recently as you say, the idiomatic python sometimes seems like more of a barrier. It takes more time to parse and grok, for their human brain, a for loop with a zip having multiple interables vs nested for loops. I've been thinking about this. So take, a list comprehension, supposedly better than a for loop at times. The canted take would be that list comprehensions are said in a way of what a human wants, the for loop is more how to do it, and the former is better ipso facto. And I think I've come to appreciate this difference and preference.

My conclusion is that I rather like the opinionated take of python. It might take a liiiiittle bit of a learning curve, but you do come to appreciate the zen of choices they've arrived at after a few decades of going at it.

Worth pointing out that list comprehensions aren't just a stylistic preference or syntactic sugar, they're significantly better performance than the equivalent for loops.

> There is never a keyword that does what you want

Clearly you haven't seen https://github.com/mscroggs/realhats

> I always find this a bit sad, because it seems to take away the idea that programming is about assembling composable parts

[OT] Concerning "programming is about assembling composable parts": I always find both sad and ridiculous when self-proclaimed software developers bash Unix because they are not able to appreciate its philosophy.

It would help Unix’s case if the glue between the parts wouldn’t be byte streams and some very crude int result code, signals, etc.

A monolith can be just as composable if not more, with a much “stronger glue” in the form of language-mandated guarantees. Also, sometimes doing multiple things well is the better direction — IPC is additional complexity and essential complexity can’t be decomposed.

Unix has gotten pretty far using just text and return codes. But there's no need to be dogmatic about it I guess, it could be nice to pass objects around, rather than text, like Powershell does. Although, their implementation seems quite verbose.

I think to really use something like that, I'd want a well-defined ordering for the fields and the ability to also do something like

variable.1

in addition to

variable.someLongFieldName

This could result in less than obvious scripts, but a shell language also needs to be compact, for interactive usage.

In Unix space we use text, almost exclusively. This byte stream thing is a windows/java bs thing.

When contributing to uutils (the coreutils written in Rust), one of the bigger pain points with cross platform support is the way that in Unix, everything, including arguments, is just bytes, while on Windows, arguments are semi-opaque text strings. E.g., the -t option in sort, join, etc. takes an arbitrary byte (other than null, which is supported via \0), so you can sort, join, etc. binary inputs. However, the -t option will not let you use a multi-byte character, even valid Unicode characters like é, which, if Unix actually used text for everything, you would expect it to. Meanwhile, on Windows, uutils still doesn't support non-ASCII byte values for -t, because Windows doesn't provide a way to represent those.