ddellacosta

I don't actually disagree but you could find similar criteria and write a similar piece for the vast majority of "professional" programming languages, including e.g. Python, JS, and C++, so this is kinda silly. "Computing is a pop culture" remains true, and the existence of this article in a magazine like Wired is a perfect example of that.

Heh I had a feeling that this was going to be Kirsten Dirksen before I clicked on it...great channel, lots of amazing projects to see there.

Heh good point. Coq comes to mind too...there was something else recently that sounded terrible in French..."Bitchat" maybe?

"It should almost never be the case that project names conflict"

My corollary to this is "You should never reach for a language you are not fluent in for a name. Especially, just stop it with using Japanese words to name stuff please ffs"

UX on the other hand...I hate it when sites hijack my key commands for moving backwards and forwards in my browser history. Please don't do this!

> If you know Ruby, there is essentially zero reason to learn Perl.

I don't think I ever thought about it but I think I have implicitly taken this to heart since I last was using Perl seriously. Almost every engineering org I've worked for in the last decade has had Ruby as a part of its stack for e.g. scripting or lambdas and it's what I reach for when I need to script something. And I've done Rails work in a few orgs too, which has few parallels in its niche even without considering Perl.

Although I suspect for most people Python is where they land if we're just talking about scripting or hacking something together...or anything (I hate it but it is what it is lol).

Given that Matz considers both Perl and Lisp an influence, what's your take on Ruby? If homoiconicity is something you care about it's probably dissatisfying, but it's got a lot of very functional aspects at the same time.

> That said, I still "think" in Perl regex to this very day. ;)

Yeah good point, if there's one thing from Perl that will live far longer than the language itself it's PCREs. I can't thank my experience with the language enough for my facility in crafting regexps.

I can't read this article due to the paywall, but here's my lukewarm take based on the title at least: "nobody" codes in Perl any more because the language lost a lot of mindshare in the transition from Perl 5 to Perl 6, a.k.a. Raku. And regardless it's always been a fairly idiosyncratic language in a lot of ways. Stuff like Ruby (which inherits DNA from Perl along with Lisp and Smalltalk), PHP (also takes some notes from Perl, perhaps more superficially), and Python ate a lot of its lunch.

It was the first language I wrote professionally and I always thought it was a lot of fun, but if I want to be humbled these days I reach for Haskell (like a lot of the Perl community it sounds like...).

EDIT: okay I read the article, thanks to welpo for the archive link. Yeah this is kind of a nostalgic piece so I think my original comment is still relevant. I do like Perl still, I will always have a spot in my heart for it. I appreciate especially how seriously Larry Wall tried to think about approaching things vis-a-vis linguistics even if I don't necessarily think that's the best approach for a language used by an engineering team these days.

I hope it sticks around in any case. It is truly unique.

now see how well they learn Ruby using only why's (poignant) Guide

> The second type definition is there only to make developers write it wrong.

Int32 is the type of the return value for the function (https://doc.flix.dev/functions.html), which is distinct information not implied by the type being passed in (Shape), so I dispute this characterization--the fact that this type is the same type as the parameter given to all of Shape's terms is specific to this example. Furthermore I suspect it would immediately be caught by the typechecker regardless.

While in a language like Haskell you could define this function without a type definition and its type would be inferred (vs. in Flix, see https://doc.flix.dev/functions.html?highlight=inference#func...), regardless I will almost always declare the type of top-level functions (or even non-top-level functions) for clarity when reading the code. I think this is useful and important information in any case.

> The Int32 or Int32, Int32 types are in the definition of Shape, so we can be DRY and spare us the chances to mismatch the types

I have to admit I don't see the distinction here in terms of DRYness--they are basically equivalent--or why the latter would somehow lead to mismatching the types--presumably if Flix has a typechecker this would be a non-issue.

I use Elixir now at work and I have used Haskell and PureScript personally and professionally, which both support analogs of both the case syntax and function-level pattern matching, and in my experience the case syntax is often the better choice even given the option to pattern match at the function level. Not that I'd complain about having both options in Flix, which would still be cool, but I don't think it's as big of a benefit as it may seem, especially when type checking is involved.

Gotcha, thank you both, I totally missed this

> Dont make the mistake of anthropomorphizing Mark Zuckerberg

Considering the rest of your comment it's not clear to me if "anthropomorphizing" really captures the meaning you intended, but regardless, I love this

See, you can even do quantum computing very naturally in Haskell.

I don't really get this take, at least wrt Haskell--I know less about the others. I don't disagree that it's not ideal, but I still would compare the combination of nix+cabal in Haskell favorably with anything I've used in Python, JS, Ruby, Clojure...and other ecosystems I'm forgetting. Python and JS in particular I've always found absolutely miserable to work with when it comes to dealing with dependencies. So I don't believe that this is why folks aren't choosing Haskell (I think it has a lot more to do with how different it is from most people's programming language experience, and how so much of the documentation is aimed at non-beginners).

In my opinion the existence of No true Scotsman posts like this arguing about random concepts is endemic to OOP and a symptom of the lack of formalization inherent in that approach. The GoF book just piles more confusing noise on top of it.

I soured on OOP decades ago exactly because I grew tired of reading dogmatic posts like this or bike-shedding how to do DI or whatever The Right Way with my colleagues. At the end of it I never ended up feeling like I'd ever grasped the core of what OOP actually is, because I don't think there's actually anything there. Maybe there are coherent threads that can tie together languages like Smalltalk, Eiffel, C++, Java, Self, Javascript, Python, Ruby, etc. etc. but I don't think it's a nebulous concept called "OOP," and I think there's more value in talking about how specific features can be used in these different languages on a case-by-case basis than trying to hone in on some coherent, generalized notion of "delegation in OOP."

To be fair the same could be said for FP, but at least with functional programming I can latch onto some core concepts and assert a coherent, formalize-able definition that makes sense across languages, to a greater or lesser extent (again, with debatable value given my last point in the paragraph above). "OOP" as a concept just makes me throw my hands up in the air.

After writing Clojure/CLJS for a decade professionally I think it's a toy language that is completely inappropriate for industrial use. But, at this point it's not worth my time to talk about it past that

Yeah I sent an application on a whim because I've spent a lot of time in FP land professionally and otherwise, I figured "what the heck, maybe they'll see value in that," and I was surprised to actually get a response but it was dismissive and borderline insulting..."there's nothing relevant here" talking about my resume is the thing I remember the most.

It was probably the first and only time I would have rather have been ghosted lol

Agreed. I disagree pretty vehemently with him wrt Blue Velvet but he's one of the few reviewers I trust(ed)

Yes this may be my favorite of his films, and I love pretty much everything he's done

I felt this comment so hard

> Yes, a type theory is a logic, but not a particularly good one.

Given the context of the original post, type theory at least has the benefit of actually existing in industrial languages in the form of a bunch of implemented and in-use type systems.

> It is limiting to have to under-approximate the mathematical universe via statically typed chunks before being able to talk about the objects in the universe, and the article just describes another instance of why that is problematic in practice.

>

> The alternative I propose is simpler than you would think, and definitely simpler than type theory, but it is also very new: http://abstractionlogic.com . And of course, it doesn't come with a fixed algorithm for type checking, but going forward and in the age of AI, I think that will turn out to be an advantage.

That's helpful in understanding where you're coming from, but now I'm even more perplexed--what you've linked to seems extremely theoretical. The closest to something my industrial programmer brain can grasp and read that I'd care about (in the context of the original post we're discussing) is https://obua.com/publications/automating-abstraction-logic/1..., which seems focused on theorem proving.

None of this is meant to suggest that I don't see the value in what you've linked to--it will take me some time to absorb, but I will take a closer look--but if you want to come into a discussion about a post like this one and criticize it, and more generally type systems, I think you'd be better off showing more directly how your approach can solve the same problem (or how it doesn't need to solve it, which it sounds like you're implying) in a way that doesn't take reading through a bunch of fairly abstract posts and papers or watching a five-part video series first. And if there's no actual implementation (that I can see at least) then don't expect me, an industrial programmer--like most folks on HN I would guess vs. e.g. lambda-the-ultimate or whatever--to consider it worthwhile past idle curiosity.

I see value in Valim's post because it identifies a problem with type systems that I understand and have encountered, and provides an incremental and pragmatic solution to that. It doesn't seem like you're offering a coherent, practical alternative, regardless of the validity of your arguments ("It is limiting to have to under-approximate the mathematical universe via statically typed chunks before being able to talk about the objects in the universe" makes intuitive sense to me in this context, at least).

This is great stuff! As a Haskell fan who uses Elixir (and Erlang) in my day job, I'm really looking forward to seeing how we can leverage more of the new set-theoretic type features showing up in Elixir. Revisions seem like something I've never really seen before in any of the type systems I've used, so I'm excited to see how it can be leveraged in a real production system. Thanks for the post.

> because you need to work around the limitations of type systems.

What limitations of type systems are you talking about?

> When you say "set-theoretic types", I hear, "get rid of types, just give me logic".

A type theory/type system is a logic, so I don't really understand this point. https://en.wikipedia.org/wiki/Type_theory#Logic

I appreciated this. Lots of solid advice and positive and pragmatic thinking here about aging in the context of being a programmer, and more generally too.

I'll take this opportunity to make a related pitch regarding back pain in particular, which can become more of a problem if you are sedentary as so many programmers are: if you have chronic back issues you owe it to yourself to at least check out Stuart McGill's Back Mechanic (https://www.backfitpro.com/books/back-mechanic-the-mcgill-me...). It's very much in line with this post; in particular the idea that you just have to deal with back pain as a fact of life is--for most people--not the case. Please take a look if you are struggling with back pain. The process he lays out takes work but it's based on solid research and experience and it has helped me tremendously.

> I agree with this, but I also don't think the strategies are mutually exclusive.

Yes I absolutely agree, and I should have said it. Thank you for making this point.

Emotional resiliency is not just about receiving negative stimuli and recovering from that. It's as much about knowing yourself well, knowing what kinds of situations or stimuli you should try to avoid or minimize, and knowing where and when you can best function to your full potential. So I very much agree with what you're saying.

For someone who suffers from anxiety like myself, and therefore empathizes well with the perspective in the article (i.e. an emotionally-charged event can have an impact on my productivity):

I think a better approach is to focus on becoming emotionally resilient so that things don't overwhelm so easily, or so it's possible to reset even given an emotional challenge. At least, that has been critical in my life to avoid spirals of self-recrimination or agonizing over things I can't affect or control.

> Haskell has an endemic problem where way too many development resources are put into fringe parts of GHC

There has been an incredible amount of work over the last decade put into all the things you mentioned, which it sounds like you're unfamiliar with. https://github.com/haskell/haskell-language-server in particular is a pleasure to use in my experience. Package management is far from perfect, but it's always being worked on and I'll take it over anything in Python or the Node.js ecosystems any day. Developer experience has improved a lot since I started using the language and this is an area that the community and leadership absolutely cares about--I'd be surprised if anyone spent time reading relevant discussions in https://github.com/ghc-proposals/ghc-proposals or https://discourse.haskell.org/ or etc. and agreed with you.

> Haskell has the worst support for records of all its peers. SML, OCaml, F# all have better records.

> Without good records it’s unreasonably hard to write large software projects.

> AFAIK it’s hard to retrofit ML-style structural subtyped records onto Haskell, because the type system is designed around that not being possible.

Haskell is not ML, and while Haskell records are weak they are not what is preventing people from writing big projects in Haskell. There is much more to the language than records. But I said this in my previous comment.

Nothing you've written resonates with me, and I've written Haskell and PureScript professionally as well as Java and JS along with a bunch of other languages that haven't been mentioned. I'm also actively working on an open source project in my spare time with thousands of lines of Haskell and PureScript code (https://github.com/ddellacosta/automation-service), not to mention a half dozen other random half-done projects and contributions I've made to other open source libraries and applications. What have you written in Haskell that has made you dislike it so much?

> Talk is cheap.

Yes it is.