Nice to see a fellow ebook hoarder here. I always get that magpie impulse to download any book that looks or sounds interesting, even though I may never read them.
It ended up kind of weird, but it was fun writing it. The organizer should suggest what programs to use for word counting, since different programs slightly give different counts. I used vim to write but used google docs to check word count and spellings.
Location: SE Asia
Remote: Yes, preferably
Willing to relocate: Depends
Technologies: C#, Golang, Typescript/Javascript, PHP, Python, Zig, Git, SQL
Résumé/CV: On request
Email: nwnoiiFnujsw:p}| (hint: shift the ASCII char by its negated index)
I'm primarily looking for contract work (short-term or long-term) for any brown field projects that needs general maintenance work such as refactoring, optimizing, fixing or identifying a root cause of a bug or vulnerability. I can fill the niche areas where LLMs are prohibited, have failed or would otherwise do it terribly/expensively.
In addition to the technologies listed above, I can also work with any unfamiliar, obscure or poorly documented codebase/tech-stack, provided the time to study or train is accounted for and is part of the compensation.
I like to think he was amused by the student's audacity and decided that yes, he was being unfair in this particular case. I know not everyone would be so fair-minded, but I like to think that this guy would be.
Guess it depends how big the university class is. If it's less than 30 students I can see him remembering their face and knowing which person in the list it might be, if there are 50/70/over 100 students enrolled, good luck. It's not like there's a picture of each student's face on the exam booklet or anything.
Huh, that's strange, where did all comments to this post go? I remember seeing three, then a few more the day after. Were they bots? They seemed legit recommendations, like the Pricing Money book.
Dungeon Meshi is a good well-rounded recommendation even for those who aren't particularly into anime. I'd personally add to that list:
- Clevatess
- Kusuriya no Hitorigoto
- Tongari Boushi no Atelier
- Sousou no Frieren
- Yuusha-kei ni Shosu
- Shoushimin Series
- Chi. Chikyuu no Undou ni Tsuite
With my recommendation criteria being: good (or decent budget) art/animation, good story and characters, and nothing too "weird" in it for the general population.
Off-topic rant for dandadan:
One of the main character Takakura is initially portrayed as being obsessed with aliens and UFOs, to the point it affects his social life. But the morning after their actual encounter with paranormal, the dude literally can't think about anything but pussy. I couldn't get past what a grifting poseur the protagonist was and I dropped the anime after that. Petty reason, but I'll probably change my mind and retry again in the future. Or not.
I just don't like them
That is what I dont get I have used many different languages. and often is not the syntax that I dont like . I may dislike the semantics. the runtime. the tooling. but syntax. really how. It.s like. I hate Greek alphabet. even though this is a weird comparison . alphabet is a flat bag of arbitrary symbols with no structural role. so disliking it sounds incoherent by construction. I just cant ever get over .sexpressions hate. in such a way like. What are you even talking about. Theres practically zero syntax in Lisp.
I can only think of the word disingenuous when I can see someone outright refusing the possible downsides of s-expressions (you probably meant zero syntax since it's still possible to have syntatic s-expressions.).
I never said s-expressions have no downsides, I merely tried to explain why I think people hate them. They do have downsides - diffing and merging and complex macros are good examples - but calling Lisp code outright "unreadable" is equally disingenuous. There are trade-offs, but they are not without benefits, and often the benefits do outweigh the cons. It's just sad that people choose to completely ignore them simply because they have visceral reaction to the unfamiliar visual structure.
You didn't say it directly, but it's implied from what all you said in this thread, just as no one in this thread said "outright unreadable". Up until now, there's no acknowledgement of the downsides and you refuse to even understand the dissenting point of view. If you truly do acknowledge the downsides, you would (try to) understand why people "hate" it. But no, "people are too incoherent to not like the beautiful perfection of s-expressions" as the lines in between would say.
Look, it is very simple. Compare it to natural languages. Unfamiliarity with a language may evoke aversion and even hatred, yet anyone who reaches fluency in a foreign language just "magically" stops hating it. The language becomes a pragmatic tool to use, that's all. Some may argue, saying something like: "well, my friend who knows Russian says he hates it". You dig a little further and you discover that the friend hates Russian now because they were born in Ukraine, and before 2014 they had no issues with it. Turns out they don't really hate the language, do they? They don't hate phonology, morphology, syntax - they "hate" the culture, the idioms, the orthogonal stuff, right?
Save the time and resources spent on learning (let's for the sake of the argument imagine we get it for free), there are zero downsides to reaching fluency in a foreign language. Zero. Sure, one still may prefer reading Tolstoy, Bulgakov and Dostoevsky in English, even though they'd probably agree - to unveil the full gamut of emotions, it needs to be read in Russian, simply because there are tons of interesting twists of phrases that are just inconceivable to be translated precisely. Same can be said about English - James Joyce's puns and phonetic play just don't port well; Beckett's rhythmic English is delicate; Carroll's wordplay and Victorian logic-games in "Alice" are extremely English-specific.
Alas, learning a natural language to fluency may take a lifetime. That's why we don't go around screaming "Learn Spanish if you want to understand Borges, Márquez and Cortázar!". Yet at the same time, nobody in the right mind would ever join a discussion only to say "I hate Spanish, it's weird and hard to read".
And just like there are no downsides to acquiring a natural language (once again, let's say you get it free - ignore the time cost), there are really no big drawbacks to getting fluency in Lisp. It is universally better to know it (even if you don't use it every day) than not knowing it at all. Lisp teaches you that most syntax is noise. Once you internalize that, you write better code in any language because you're not cargo-culting idioms - you understand why they exist.
I'm not saying Lisp is universally better than the alternatives. I'm just saying that it has tremendous value, and the "haters" are just missing it out.
And just like I won't ever trust anyone claiming they dislike a language despite enormous fluency, I just can't see how anyone would know Lisp and yet just hate it. I stand by my words; the bias and hatred come from misunderstanding. I understand why programmers may dislike a specific PL - but Lisp is not a single programming language. It's an idea, the idea that influenced pretty much every single PL being used in the industry today. Like I dunno, how could anyone hate recursion, or closures, or pattern matching, or parametric polymorphism - these are just ideas, specific tools to use in specific context and situation. The only reason I see someone may hate them is because they have not gained sufficient understanding for how they work.
Assuming any such comparison is valid is purely speculative. There are significant differences.
> anyone who reaches fluency in a foreign language just "magically" stops hating it.
Not true (plenty of people learn Mandarin and regret doing so), and even if it were true it could just be survivorship bias - of course people who hate a language are less likely to become fluent in it.
> Turns out they don't really hate the language, do they? They don't hate phonology, morphology, syntax - they "hate" the culture, the idioms, the orthogonal stuff, right?
No, sometimes people really do hate the language.
> nobody in the right mind would ever join a discussion only to say "I hate Spanish, it's weird and hard to read".
That might not be a productive thing to say in a discussion, but that doesn't mean it can't be true.
> Like I dunno, how could anyone hate recursion, or closures, or pattern matching, or parametric polymorphism - these are just ideas, specific tools to use in specific context and situation.
Plenty of people hate any or all of those things. I'd say it's reasonable to hate a tool that tends to have bad consequences - e.g. a language feature that makes code superficially easier to write but hard to refactor or debug.
> Plenty of people hate any or all of those things.
Oh come on. You're flummoxed about things that are not controversial. You don't have to listen to some rando HN commenter like me - there isn't a line-up of renowned CS figures or prominent programmers who ever harshly criticized Lisp to absolute rejection, even Dijkstra. People expect him to have bashed Lisp, but he actually praised it (and not once): "Lisp has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts." And there's a long line of well-known names from Alan Kay to Steele, Matz and Goetz, etc. who publicly said great things about the grand idea of Lisp. That is all well-documented and known. This isn't some "recorded history of the past", it's still going on - Clojure-like languages for different runtimes popping up every few months. Lisp isn't BASIC, Fortran or COBOL, yet some people waste so much energy to prove to themselves that it's somehow "wrong" or has "bad consequences", while Apple, Cisco, Netflix, Walmart, CircleCI, Nubank and many others have successfully built and maintained large projects. All the while so many "opposing" ideas quietly died over the years - Ada's intended universal dominance; anti-GC dogma; Algol 68 complexity-heavy direction (though Algol's good ideas lived on); rigid, ceremony-heavy, anti-interactive approaches consistently faded, while the dynamic/interactive/symbolic cluster that Lisp has pioneered keeps getting re-adopted.
What serious programmer ever ignores Lisp influence or importance? I suppose an ignorant one. I get it, plenty of serious programmers acknowledge the influence and still rationally choose not to use it, but outright rejecting the idea because it doesn't "visually appeal to them" - that is some naivete.
Whatever. You free to hold any beliefs - my actual, pragmatic, lived experience says otherwise.
> there's a long line of well-known names from Alan Kay to Steele, Matz and Goetz, etc. who publicly said great things about the grand idea of Lisp.
About the ideas, yes, helped by being such an early language that it can lay claim to being the originator of a great many things. About the syntax, rather fewer.
> Apple, Cisco, Netflix, Walmart, CircleCI, Nubank and many others have successfully built and maintained large projects
There are a great many success stories and just as many failure stories. 60+ years on, Lisp continues to exist but remains niche.
> rigid, ceremony-heavy, anti-interactive approaches consistently faded, while the dynamic/interactive/symbolic cluster that Lisp has pioneered keeps getting re-adopted.
Yes and no; the pendulum swings but the oscillations get smaller. At this point the programming world has pretty much converged on present-but-lightweight typing with inference and optional annotations, for example; there are no new serious pure dynamic languages being made, and all major dynamic languages are putting huge effort into retrofitting typing. Long edit-deploy-test cycles aren't coming back but nor is live-editing your production system.
> What serious programmer ever ignores Lisp influence or importance?
That's quite a different thing from saying that it's pleasant or even good. Every serious critic acknowledges that e.g. David Foster Wallace was influential and important, but many openly hate actually reading his work.
> actual, pragmatic, lived experience
Hardly. You've built this a whole edifice of beliefs that wouldn't withstand 5 minutes outside the Lisp bubble.
I would say, with a striped-shirt and not a glove in my hand, that the person you were fighting with gets the score, and wins by technicality. I suggest you take the bench first and review your comments and reflect with a wet towel on your head.
Having reviewed as instructed, I stand by everything I said here. Let's review the action replay.
I began by noting that TS has literals and set theoretic types, and that this makes sense for a post-facto type system bolted on top of a dynamic language. Jaen showed up to inform me that TS has literals and set theoretic types, implying he hadn't read my post.
I noted that typed string literals are not generally considered desirable within strictly typed environments. "Parse, don't validate", etc. Jaen seemed to follow this up by aggressively trying to prove that TS is somehow "better" than Haskell. His arguments comprised the fact that TS has literals and set theoretic types (again, yes, this was is in my initial post), and a mixture of personal insults and just straight up nonsense (I wasn't the one to bring Zod into a discussion of type systems... ). At that point I did have a little fun with things, since it had become clear Jaen was not a constructive or good faith interlocutor.
Jaen's central misapprehensions seem to be that (a) I don't understand literals and set theoretic types, despite this whole thread being in reply to a post where I give examples of them in TS; and (b) that I care which type system is "better".
As I repeated a number of times above, TS' type system makes sense for a type system bolted onto a dynamic language. It's extremely useful when the underlying language has oodles of untyped structs flying every which way. Conversely, Haskell's type system makes sense within a holistic strictly typed environment. Structural typing would be a gaping hole in Haskell's strict type safety, which is kind of Haskell's whole thing. Neither system is better, each has its use. Different strokes for different folks.
I don't usually put much stock in upvotes, but I do note I seem to have the edge there. Seems that our esteemed panel of armchair referees respectfully dissent from your narrative, nvlled. :)
You seem to be aggressively misreading what I said, stuck in your own "world" and instead of asking for clarifying questions, making unfounded assumptions.
> I began by noting that TS has literals and set theoretic types
Can you please quote me exactly the part of your original comment that implies that literal types are structural and have subtyping? Because that is what I said. If you did imply that, well, excuse me for helping you by clarifying then.
> aggressively trying to prove that TS is somehow "better" than Haskell
Sorry, what? Refer to the first line of this comment. Just saying that some type system features are extensions or harder to use in Haskell says nothing about the superiority of TS. This is completely your imagination.
> I wasn't the one to bring Zod into a discussion of type systems...
Not sure why this is even relevant, but this was a direct reply to: "...language like TS, which is not type safe at runtime, and which will happily ingest an unexpected value, silently coerce it in all sorts of fun and wacky ways"
Zod (just a random library) is a direct counter-example to that. There may be better counter-examples. One just needs a proof of existence - it doesn't have to be good.
I then had to repeat that I am also talking about static types because of: "...exhaustive runtime schema for your zero-first non-empty integer array example...". TS can both enforce that as a type (which you never presented for Haskell) and as a value. (nominally typed solutions quickly run into ergonomic problems like phantom types not being composable across library boundaries - eg. refinement types, which are even safer by nature, are structural!)
In any case, I'd estimate 99% of people using TS don't encounter any type safety issues caused by the design of TS. Haskell has `unsafeCoerce` too, just a bit wordier than in TS.
If wanting to talk about real unsoundness, one would mention something like bivariance (see also: linked comment), but even then almost all of that is entirely irrelevant in most practical software engineering.
> (a) I don't understand literals and set theoretic types, despite this whole thread being in reply to a post where I give examples of them in TS; and (b) that I care which type system is "better".
Huh, what? Again, I'm thinking none of that. Again, you imply you know better what I'm thinking...
> Structural typing would be a gaping hole in Haskell's strict type safety
I mean, yeah, let me just repeat OCaml and Scala here, both also famously type safe languages... Why make an argument when there's two immediate counterexamples that were already mentioned?
> but I do note I seem to have the edge there
This pretty much sums up the difference in attitude, I'm not here to score internet points in an argument.
I just wanted to comment on why the world is not black and white and even technically flawed languages like TS have something to learn from.
I disagree with a lot of what you said, but I don't feel authorative enough to say you're wrong.
> Which is really not that many places, it's a fast but rather niche optimization. There's not a whole lot of scenarios where lots of temporary memory is needed for one well defined scope.
Arena allocators are not niche optimizations, or not something picked first for optimization. Contrary to what you said, arenas are useful for temporary allocations with poorly defined intermediate scope or lifetime (think functions directly or indirectly called by the arena owner). If the scope is local and well-defined, a regular allocator or even a fixed buffer would do just fine.
> Zig's lack of ownership
Zig doesn't have explicit annotations for it, but the concept of ownership and lifetime doesn't go away. It's not enforced by the compiler, which is an intentional tradeoff to let the programmer have more control and freedom. When you use languages with manual memory management, it's expected that you are capable of designing sensible programs in such a way that ownership and lifetimes are tractable and are part of the program design, rather than something to workaround to please the compiler.
> Zig doesn't have explicit annotations for it, but the concept of ownership and lifetime doesn't go away. It's not enforced by the compiler, which is an intentional tradeoff to let the programmer have more control and freedom.
Right, it's exactly like C, and we kinda all know how that worked out in practice already...
Hence why I called Zig a "love letter to C". If all you want is C with a dash of zest, that's Zig. If you want a modern language that has learned from the many hard lessons the industry has dealt with over the years... well, Zig ain't it. Which is a perfectly fine thing for Zig to be, it doesn't have to be a good general purpose language. We have plenty of those already from Rust to Go to Java/C#/Kotlin to etc...
> arenas are useful for temporary allocations with poorly defined intermediate scope or lifetime (think functions directly or indirectly called by the arena owner).
Arenas are not good for that because the arena as a whole has to outlive all of those poorly defined scopes & lifetimes, which is hard to do. Especially if you later go add on something like an retry-with-backoff or asynchronous metrics/tracing or caching or whatever. Then suddenly you're either fighting use-after-frees or doing deep-copying of data.
> Right, it's exactly like C, and we kinda all know how that worked out in practice already...
Production operating systems have been written in C, along the with the countless tooling, libraries and game engines (which you said are a poor fit for manual memory management) that modern systems depend on. I say it worked out it pretty well.
And zig did learn from the hard lessons from the industry and fixes a lot of problems with C. It also has a lot of affordances that makes it more than suitable for general purpose use.
> Arenas are not good for that because the arena as a whole has to outlive all of those poorly defined scopes & lifetimes, which is hard to do.
I don't what else to tell you, arenas outliving temporary allocations is exactly what it is made for, they go poof as soon as the arena owner is done. That's not hard, it makes it easier if anything. To give concrete examples, arenas are used on HTTP requests that are clean up in one go as soon as the request is done. They are also used on (possibly deep) recursive functions that are cleaned up as soon as the root function returns. Of course, you don't store arena-allocated memory elsewhere that outlives the arena, that would be dumb.
That's why you have to be consciously aware of the ownership and lifetimes that a piece of memory has. Ownership and lifetimes are just one part of the API contract of a function or module. You break it, that's on you. Having a compiler help with ownership model would be nice, but it's a not substitute for having a good mental model of your programs. It's not that different from the tradeoff of a having a less strict type system. Not every sanity check can or has to be performed at compile time. Zig also has debug allocators that catches a lot of memory mismanagement during testing. Hard to debug double-frees, use-after-frees and other things are a symptom of poor cavalier YOLO programming.
That all said, I do agree that manual memory management is really hard to do if you are used to just sweeping gigabytes of memory under rug, hoping the GC vacuum cleaner slurps it afterwards. It takes a mindset and a set of practice. But once you internalized it, it becomes second nature.
(Not to sound like a zig fanboy, I do think it's still rough around the edge and there are a lot of things I don't like. But manual memory management is not that big of a problem).
> written in C [..] tooling and game engines (which you said are a poor fit for manual memory management)
Game engines moved to C++ over 20 years ago.
Most major compilers are also in C++, including GCC (it switched over a decade ago). Which means the two largest C compilers are themselves not written in C. They have un-bootstrapped.
> That all said, I do agree that manual memory management is really hard to do if you are used to just sweeping gigabytes of memory under rug, hoping the GC vacuum cleaner slurps it afterwards. It takes a mindset and a set of practice. But once you internalized it, it becomes second nature.
Sorry, but no, you cannot internalize this. Nobody can. Once a program grows past some point, purely manual memory management & "git gud" are simply not practical. The amount of evidence against this is beyond any doubt.
Zig's emphasis on cross compilation seems like it's a better fit for embedded than anything else, which is where things shouldn't realistically grow to be huge projects, but with how coding efficiency (or lack thereof) works today along with microcontrollers getting ever more powerful... who knows.
Ever heard of tribalism and echo chambers? Wrongness being a function of number of dissidents is a terrible heuristic, in contrast to determining the lies and falsehood based on the soundness of the argument or logic.
Also, when a population group is large enough (e.g. entire world), it's quite likely a crazily-held belief is shared by other people, or people who would at least nod in agreement.
