Have you tried F# or OCaml? I would argue that programming in Python is much harder than it is in F#. It is for me.

I tried F# seriously for a few days and the tooling was so annoying to set up it made me crave going back to pip and virtualenvs

I guess if you're a .NET developer that may be a non-issue, but I literally couldn't get all but the simplest examples to work and just gave up even though I loved the language and its design overall

How recent was this?

If not recent, steps would be:

* Download and install .NET 7 SDK (very easy on basically any platform): https://dotnet.microsoft.com/en-us/download

* Already, you have F#. You can run `dotnet fsi` to enter F# Interactive (FSI), the F# REPL. Or you can create a new solution and project with the dotnet CLI: https://learn.microsoft.com/en-us/dotnet/fsharp/get-started/.... Once you have tests, you can just use `dotnet test` and it will find and run all tests.

* You can also just download VS Code and install the Polyglot Notebooks extension to write F# code in a notebook. All you need is the .NET SDK, VS Code, and the Polyglot Notebooks extension. https://marketplace.visualstudio.com/items?itemName=ms-dotne...

* Either in an F# script (.fsx file), FSI (ran by `dotnet fsi` again), or in a notebook, you can install NuGet dependencies by just writing

    #r "nuget: <package name>"

https://learn.microsoft.com/en-us/dotnet/fsharp/tools/fsharp...

I'm confused about the tooling being bad. Python doesn't have any management like solutions and projects like F# and .NET has. Visual Studio on Windows and macOS are good, there's JetBrains Rider, and also VS Code with Ionide for IDEs. I've never had issues with the tooling with F#. That cannot be said for Pip, in my experience.

> the tooling was so annoying to set up it made me crave going back to pip and virtualenvs

Damn, if you wanted to go back to pip and virtual envs, then that's really saying something about how bad the tooling is, because pip and virtualenv are the bane of my existence when writing Python. Give me cargo or even npm and I'd be happy.

Something I like about boring Java: I hardly ever think about the dependencies management tool.

Java is even worse to be honest, you basically need an IDE for it, so much that VSCode literally ships a build with Java preconfigured.

https://code.visualstudio.com/docs/languages/java#_install-v...

You need an IDE for any language honestly. And I don't see that as a negative.

I have never used an IDE for any language. Some languages make it very easy to set up. Python, Haskell, Rust, Node are extraordinarily straightforwards with basic CLI tooling. others like C++ are more complicated, but the compilers and tooling are extensively documented.

Every company I've worked at has extensive setups regardless of the language. Even supposedly "simple" languages like Python will benefit from IDEs, and it shows. It's especially the case when programs become larger and more complex.

Static types mean some languages benefit from IDEs more than others. Code completion is not very meaningful without types unless you use some machine learning magic.

The nice thing about Typescript is that it was basically designed as an IDE language. It has just enough typing to make the IDE useful and let's you ignore the typing well enough when you need to. It isn't a safe language, just toolable.

I was specifically thinking of dependencies management. VSCode/IDE is kinda out of scope here.

I find the InteliJ product are good IDE. I use VSCode for node stuff and it's fine.

As daily driver, I personally use vim and build with maven. It's boring, nothing ever happen. I need 2 binary and one edit to my $PATH. Once in a while I do use IntelJi, to explore new codebase.

Gradle, Maven etc are also a pain, especially when compared to cargo or other all-in-one package management and build tools.

* * *

It couldn't possibly be that VSCode ships with a build for a language that is enormously popular preconfigured instead?

So? Lots of languages work well with VSCode that aren't TypeScript.

My point is that the REASON VSCode ships with java support is NOT that Java "needs" it.

But I think you knew that.

F# tooling is not bad actually. In fact it is much easier to have project level dependencies unlike python where dependencies are system wide or virtual environment wide. I just think OP is unfamiliar with the kind of tooling that DotNet has and got deterred by that. I'm a python developer who have tried F# casually and adding a dependency is as easy as copy pasting a line of command from the nuget repository online

F# was one of the languages I was thinking about with I wrote my comment. :)

Very strange. When I write F# code, it almost directly mimics the problem statement. For example, I have implemented a fair amount of The Ray Tracer Challenge in F#, and it feels like I'm literally just writing down the description and tests from the book and have working code.

Do you have a particular example of Python that you feel it shows off its pseudocode abilities? Because one can write F# almost identically to Python, so I just can't imagine Python being superior given that it lacks several domain modeling tools that F# has (records and discriminated unions).

Speaking as a python dev with some experience in F# , one maybe minor point is the unfamiliar function call syntax that could throw off programmers not familiar with curried functions. Most other languages have parenthesis for function calls, so it can be a bit jarring to have a sequence of strings and not know whether the result is a function or a value. Furthermore some experienced F# devs love making custom symbols, which can also obfuscate the code

> so it can be a bit jarring to have a sequence of strings and not know whether the result is a function or a value

I think that the nice thing about F# is it is always a value. Function evaluation and currying can be taught fairly readily, especially given that once you get it, there's no gotchas.

> Furthermore some experienced F# devs love making custom symbols, which can also obfuscate the code

I agree that is painful when it occurs, but that style should absolutely be de-recommended and is so by Don Syme. I haven't really encountered it much in my personal development though (or I have avoided it).

My way of explaining this is that we have a part of our brains which is intended to handle and recognize grammar. If we offload some of the work to it, it feels easier to deal with code. Even though what we are actually doing is certainly harder.

The tradeoff of this kind of grammar is that metaprogramming becomes harder because by the act of making some of the structure into special grammar, it becomes harder to metaprogram.

> You basically get into a situation where you need to be able to read and comprehend math-like lines of code. Which doesn’t seem to mesh well with the structure of nature language.

"The Art of Doing Science and Engineering" has a few paragraphs about this. He points out that language has some intentional redundancy, because humans are unreliable and require it. But programming language designers are often skilled in logic, and prefer that to verbose "human" communication.

The language referenced is APL, but it made me think of functional languages which have a lot of custom infix operators, etc.

> But programming language designers are often skilled in logic, and prefer that to verbose "human" communication.

Reminds me of a thing my dad quoted about the problem with Newtonian Notation. AKA dot notation or fly spec notion. Because with it a fly can do differential math. As a result people use different notation usually.

That said redundancy allows for both readability by humans and better resync by parsers when there are errors. And it's easier to code gen and auto refactor code.