Comment by andrewstuart

They only seem obvious to you because you are used to them.

Quite the opposite to you, Rust is obvious to me because I'm used to low-level programming and careful memory management, where JS is more than often very surprising.

Another example: I wrote a Lisp-like language in my company for mathematicians to develop constraint systems; now this purely functional, bastard Lisp feels like a second nature to them, whereas they could barely put three lines of Java together to save their lives.

Does not mean that I'm more or less right than you are; just that just like human languages, no PL or paradigms are ‶naturally obvious″, we are just more or less used to them.

How does the quote go again, someone can learn Lisp in a week, except if they know C then it will take three weeks? I'm sure I've got the quote completely wrong (maybe it was about Forth?), but the essence is there: if you're learning a programming language it may take longer if you're already used to a programming language with different semantics compared to getting into it from scratch.

Also Raku is the most obvious language because it inherited the "it" variable ($_) from Perl, and "it" is unbeatable for writing obvious code (read a line, uppercase it, replace all numbers in it with dollar signs, and print it out again).

That's very subjective. Of the languages you mention JavaScript, C++ and Zig are not obvious to me at all – I usually find myself on Stackoverflow looking for answers when trying to write even the simplest things in them.

Janet on the other hand felt instantly familiar after reading the language introduction. It has all the usual imperative constructs from C-family languages – for, while, if – but also extremely expressive macros like `loop` and `as->` that are more common in the world of lisps, and `partial`/`comp` from the functional paradigm. For such a small language Janet really covers a lot of bases.

Functions/macros are often called exactly what I expected them to be, which has allowed me to figure out how to do most things by simply guessing in the REPL. If I need to figure out the details I can use the `doc` function (or Ctrl-g in REPL), and the docs work perfectly even for what would be keywords in non-lisp languages. It has been a really pleasant experience that I haven't really had with other languages, aside from maybe Julia which also has very intuitive syntax and function naming conventions.

I used to work at a US EMR company, not as a programmer though. They use a terrible language called M or MUMPS. New hires would spend their first month or so literally in a classroom with an instructor and homework to learn the language (and other company specific things).

Now I'm not recommending you use an unusual language, but I think most companies don't spend enough time on boarding new hires and expecting professional development happen on the employees time.

If I am going to use a tool every day for a couple years I want the best tool, not the easiest tool to learn how to use.

Functional programming it's quite obvious, actually: there's data, there's transformations, there's data again. Sometimes there's side effects. Doesn't math work that way? I'm no expert on it, but the key for me was understanding that usually, in functional languages, you actually write _less_ functions, and most of the application behavior is expressed through static data.

I remember the first time I encountered a C-like for loop, and felt as a most alien thing: until this day I still feel it's an unnatural construct, a third of it abstracted from the application logic, the other two halves low-level requisites. And of course, watching that classic video of Rich Hickey destroying Java's HTTPServletRequest class just once made it clear, at least for me, that OOP's stance to redefine every data input and output into its own understanding of the universe isn't the obvious approach at all.

> Python, javascript, they’re not perfect but they’re pretty obvious.

It’s really strange to call JavaScript obvious… strange implicit conversions, broken equality operator, strange variable scoping… I still have no clear idea what the `this` keyword does in the majority of circumstances…

That depends on what you are used to.

I was mostly used to C and Perl when I was young, and Python made a lot of sense.

I would not say that javascript was more obvious to me than rust was when I started to use them.

A lot of people seem to be hung up on borrow checker, but if you are used to low level C, you had to keep track of that with comments on functions and conventions anyway (and you had to keep it in your head).

The thing that I had to get used the most of in rust is using more functional style of programming, but since I liked python comprehensions and collections, It want such a long jump as it otherwise might be.

Does someone with no programming experience at all say the same?

Have also seen cases where people with background in Physics, Mathematics found functional programming more obvious. Obvious is relative.

Even for people with programming experience - once I got hang of Haskell, learning and using Scala professionally became more "obvious" for me.

There's probably a distinction to be made between being obvious and having no surprises. I agree Python is relatively obvious, and I write a lot of small python scripts for data analysis because if I can figure out what I want to do, doing it in python is usually very simple. But for larger programs I care less about obvious, and more about no unpleasant surprises. Once the amount of code grows larger than I can hold in my head at once, I really want the language to help me avoid footguns. Python mostly isn't great for this due to its type system (with a few exceptions such as its big integer support avoiding most integer overflow surprises).

It probably isn't a popular opinion, but I actually think C++ does a fairly good job of this, so long as you're disciplined in how you use it. That discipline is not necessarily obvious, but I've acquired it over 30+ years, and now I find that I almost never have memory safety issues (I do use sanitisers here, but they rarely show up anything). Perhaps more importantly, C++'s fairly strong typing means I'm generally pretty confident refactoring code as requirements change without getting unpleasant surprises. Sure, C++ could do better in many ways, but it is pretty good at avoiding many of the unpleasant surprises I care about, at least for single-threaded code.

Pattern matching and referential transparency are much more "obvious" or "natural" (meaning closer to the way we humans think) than javascript and its idiosyncrasies (think that even something like `x = x+1` in imperative languages is an infamous tripping point for beginners). C++ is definitely anything but obvious.

obvious is too subjective here, what is not obvious in FP ? is it the terminology ? or the accumulated culture (monads and such) ? because FP at its core is pretty much very obvious. Functions from domain to domain, that's it.

I somewhat agree with this, note that Janet is not very functional, when I briefly used it I never used a single recursive function. It's meant to be used more in an imperative way.

For you Janet is obvious or non obvious?

[dead]

[dead]