HackerTrans
TopNewTrendsCommentsPastAskShowJobs

Banana699

no profile record

comments

Banana699
·il y a 4 ans·discuss
'Patriarchy' is just a dumb conspiracy-theoritic ideological framework for viewing society that starts with "women are victims" and back-propagates that to whatever beliefs and assertions needed to make it true. HN is mostly non-political compared to other Social Media forums in my experience, but if it's skeptic against that dumb conspiracy theory, then that's Good News.

>I don't know what the cause of the weirdness is though.

Might I suggest that you're reacting favorably to young men earning less and having the deck stacked against them even more and more, calling it the 'dismantling of the patriarchy'? perhaps that is making people a little bit weird?
Banana699
·il y a 4 ans·discuss
Banana699
·il y a 4 ans·discuss
>If I can include this functional pearl "A play on regular expression"

For anyone intereted :

https://xfido.com/pdf/regexp-play.pdf
Banana699
·il y a 5 ans·discuss
It's a very common misconception that readability is a tradeoff against performance.

The true underpinnings of readability is language malleability, nothing more and nothing less. The whole "dynamic languages are automatically more readable" impression is a misleading consequence of the much more general claim "Malleable languages are more readable", with a malleability = dynamicism substitution.

Malleability is key because readability is really just languages being as close as possible to the problems they are used to solve. This means one of two things

  1)Either the language come preequipped with the concepts and semantics of the problem domain built into their fabric, this is the DSL approach (this will always fail if you aspire to be a "general purpose language", you simply can't hope to match the sheer number of contexts people want to use your language in. One radical conclusion is to abandon the "general purpose language" myth absolutely, and just make all application development language-building, and focus on building the tools to make language building easy.),

  2)Or you make the language malleable and stretchy enough that a tiny handful of the rare programmer-domainExperts breed can construct the whole domain inside the langauge, _with_ _the_ _language_ (no transpiler, preprocessor, etc..., this would require the rare programmer-expert to be an even rarer programmer-expert-languageHacker), then cover up all the low level machinery with syntactic elements that mirror the domain vocabulary. 
That's it. Any langauge that allows you to do the above is a malleable language. Any malleable language is a candidate for being a readable langauge (and a horribly unreadable langauge, if you gave in to irresponsible abstractions). Dynamic languages are malleable because they give you extremely powerful hooks into their semantics, they are very... well, dynamic. The details differ, the two poster childs are python and ruby, they have a grab bag of features that range from operator overloading in python, free form syntax in ruby, and extreme dynamic dispatch and resolution rules in both. The last feature is a common theme in all dynamic languages, and it happens to be a performance killer.

But you absolutely don't have to be dynamic to be malleable, lisps have been doing it since forever, and though lisps are traditionally dynamic, it's macros that make them stretchy, not dynamicism. And there are loads of other mechanims that can make a language malleable without making it unpredictable. It can be as simple as scala allowing unicode in it's source, and as complicated as haskell making lazy evaluation the default and now control structures are just a library. Any abstraction with a "meta" flavor, with hooks extending into the language environment and doing various things depending on how you wield them, makes the language more malleable.

Malleablity is allowing the language's source to take different shapes and semantics according to the whimes of the programmer, performance comes from massaging the source till it fits comfortably into machine semantics without much runtime shenanigans. They are absolutely not in tension, making the code do everything at runtime is just the easy way out.
Banana699
·il y a 5 ans·discuss
The book "Understanding Computation: From Simple Machines to Impossible Programs" by Tom Stuart was/is my Theory Of Computation Nirvana experience.

Its motives is the same as NandToTetris: to make any programming-literate person comfortable with the rough outlines of the theory of computation and its main lore and results. The author uses Ruby as an interactive "Illustration language", a notation to describe concepts that happens to be executable. It's the same way I noticed the authors of "Structure and Ineterpetation of Computer Programs" use scheme or the way Niklaus Wirth sometimes uses Pascal in his educational writings. There is a small tutorial chapter in the beginning that crash-courses you through all what you need to understand in Ruby to read the book.

The structure is a bit different, the book isn't project-based like ECS, and there is no natural hierarchy to the theory of computation (except maybe the famous state_machines ==( push_down_automatons ==( turing_machines, and the book does introduce those topics in the natural order) that would make the book feel more bottom up. There is no exercises or nudges towards exploration and tinkering so you need to come equipped with your own. I stopped trying to digest it in one reading and designated it as one of those books you come back over and over again to fully absorb its nourishment.

But the main motivation of the book is strikingly similar to that of ECS: to take a complex and jargon-heavy several-years study topic and distill the most essential lines and edges so that a minimally-educated person motivated enough to understand could mostly understand. Some parts felt rushed and weren't meant to be digested in full details (when he was e.g. discussing a "zoo" of other computational systems that feels superficially different or less powerful than turing machines but are equivalent nonetheless, he was fairly hand-waivy), but the book is so great you will feel guilt dwelling on its shortcomings.