7 ms·

It's rather unbelievable to me that people find ML syntax unfamiliar and off-putting. It makes no sense, and I have always found it disappointing that both Rust

• ghqst 4y ago
  It's a matter of personal preference, and there's a lot more people who are familiar with C-style syntax. A good amount of those people also dislike Python, in fact.
• tooltower 4y ago
  Familiarity. The preferred syntax is the one that incurs the least cognitive load. Which in turn depends on what they are already familiar with.
• dom96 4y ago
  It makes perfect sense. Most programmers learn to program on a C-like, Basic-like or Python-like language. Not ML-like. What's familiar is what's easiest to adopt.
  • bmitc 4y ago
    But those languages weren't familiar to begin with. It's like people are saying programmers can only learn to program one time.
    • acheron 4y ago
      Given how much effort has been spent in shoving Javascript into places it doesn't belong solely so that programmers don't have to learn something else, that seems to be more true than not.
    • satvikpendem 4y ago
      No, but that's what most people learned, so most people will continue to favor more C-like languages than languages that are not C-like. If you want people to favor ML-like languages, you'd have to start off teaching them ML first (which some colleges do). Industry-wise as well, C-like langs have network effects through the past 30 years, especially in JS land which is a lot of the professional software engineering work done these days.
      • kilgnad 4y ago
        This is incorrect. People are born with an innate biological bias towards C like syntax OVER ML syntax or even FP syntax. It's easy to prove this fact with some natural example outside of programming. Let's say I have several tasks I need you to do. If I wanted to present those tasks to you in written form, what would those tasks look like? They would look like a series of procedures. Any human would present imperative instructions to you WITHOUT being taught anything beforehand. Nobody is going to put those tasks into a single run on sentence because that's less intuitive to us. Additionally if I want you to repeat a task I'm not going to write something self referential. I just say repeat this task four times or something. We communicate this way through language and through writing, so OF COURSE c like syntax is more natural. (for those who didn't pick up on it, I'm referring to function composition and recursion respectively in the examples I just gave.) You got it backwards. The industry teaches C-like syntax because that syntax is naturally more intuitive. This is despite the fact that in the long run FP-syntax is overall better.
        • satvikpendem 4y ago
          Sure, I'll agree with that. Imperative code is simply more natural for people.
        • bmitc 4y ago
          > People are born with an innate biological bias towards C like syntax OVER ML syntax or even FP syntax. Are there some studies that back that up? My wife took the How to Code course on edX, and the use of Racket was a non-issue. The use of it was quite literally transparent. The issue is that humans react to something foreign with huge amounts of bias. So if I person has any introduction at all to some form of a C-type of language, it seems to shut down all forms of curiosity, generally speaking. I honestly wonder if that has been studied. I was first taught C, Python, and Java, and was totally uninterested in programming. Once I found functional-first and visual dataflow languages, I was hooked. I'm generally curious what C and Python people think when they learn something like Prolog? Do they exclaim "this isn't hard enough?".
    • wpietri 4y ago
      They can only learn to program the first time one time. After that, everything is relative to their first language. So learning cost becomes a function of the distance between old languages and the new one. Moreover, the gain in going from zero programming languages to one is huge. You can make things! Going from one to two is small in comparison. You can make things, but hopefully somewhat better. So the ROI on learning a very different language isn't great for most. And that's when the technology adoption curve comes in handy: https://en.wikipedia.org/wiki/Technology_adoption_life_cycle https://en.wikipedia.org/wiki/Technology_adoption_life_cycle For any technology, some people will like the novelty and will be risk tolerant, so they'll pick it up for fun. Others will be seeking some strong benefit; if the technology provides that they'll adopt it too. If that happens, another chunk of people will pick it up as the coming thing. But circa half of people adopt the new thing only when it becomes dominant or when they're forced to by circumstance. Max Planck said, “A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it.” And that's often shortened as "science proceeds one funeral at a time." Software's not quite that bad, but it's certainly heading in that direction.
    • anon291 4y ago
      If you change the order of language introduction, people's preferred languages and paradigms change, based on my experience TA'ing in undergrad. Our program started off with python, but immediately introduced lisp and prolog right after. The output was CS grads who were more varied in their language choices.
• kayodelycaon 4y ago
  This is my really high level and poorly explained thoughts on this. I have enormous trouble reading functional programming languages. Python gets away significant whitespace by reading like pseudo code and is fairly clean. It uses words rather than symbols. C syntax provides visual structure using brackets. It seems to keep things readable, you get the option of using symbols or significant whitespace for scope. Functional languages have a tendency to do both. Lisp’s syntax is defined by replacing syntax with parentheses. 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. It’s kind of like abstraction in programming. Some people kind of get it. Some people really get it. And other people need to consider a different career. I think there are just too good programmers who don’t work well with functional programming to say it’s a problem with lack of familiarity. I think it could be a fundamental lack of talent.
  • bmitc 4y ago
    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.
    • kayodelycaon 4y ago
      F# was one of the languages I was thinking about with I wrote my comment. :)
      • bmitc 4y ago
        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).
• satvikpendem 4y ago
  I learned OCaml in college and I would not liken it to Python at all. Python is very easy to grasp since it's basically pseudocode, but OCaml, for example, is based entirely on recursive constructs (yes, imperative versions exist but only as a last resort). It's an entirely different way of thinking. The syntax therefore also looks unfamiliar, coming from `for` loops in Python.
  • hayley-patton 4y ago
    Whose pseudocode? I have not once written pseudocode that looks like Python, though apparently this is odd. In high school pseudocode was BASIC with structured control flow. I tend towards pseudo-SML for scribbling things; once got in trouble for using "language specific constructs" like map() for university work. They weren't a fan of APL for adjacency matrix munging either, though that's how I went through that part of the course. In either case pseudocode is just ignoring the unpretty parts of any language, and it can hardly be said any language is more like pseudocode.
    • satvikpendem 4y ago
      > I have not once written pseudocode that looks like Python, though apparently this is odd. Well, looks like you're an outlier. Most people I know who write pseudocode don't use filters, folds, maps or APL like constructs either, even though I totally would when writing the actual code. They write it in a Python-like format with for-loops and if-statements.
  • bmitc 4y ago
    F# can be written nearly identically to Python if one so desires.
• heavyset_go 4y ago
  > People seem to love Python syntax. Python's syntax is just yet another C-like syntax that goes back to ALGOL. People love it because it's familiar, it's not doing anything special.
• nsonha 4y ago
  Yes I find this point unconvincing too. I do not think elm is intimidating, lots of FE devs jumped on its bandwagon and it’s considered easy to learn. If it’s true that it is, the syntax seems like the last thing people would find intimidating about elm, or haskell. The intimidating part would be the programming model. Reason basically started with that premise that syntax is a problem to solve and we saw how successful it turns out.
• kilgnad 4y ago
  It's very easy to see why. People naturally are drawn to procedures rather then formulas. When given a task of several things to do, that task is naturally given and expected in a list of procedures. Nothing needs to be explained here. People intuit this naturally. A list of things to do is grammar we all universally understand. But ML syntax and FP? Who composes all the procedures into a single run on sentence? And to top it all off it's some sort of functional grammar that's highly divergent from a list of procedures? That's essentially FP and ML. This initial barrier is what prevents people from adopting FP. People who say it's because C like syntax is the default syntax taught in schools are missing the point. C like syntax is MORE intuitive and THAT is why it is taught in schools. That is not to say C like syntax is better then FP. I prefer FP, but I'd be lying to myself if I said it was naturally intuitive.
  • anon291 4y ago
    Luckily, the vast majority of FP languages operate on lists of procedures combined together with the `.` operator. Similar to how C composes things with the `;` and many pythonic languages compose with the newline operator. Realistically, most FP programmers program ML-like languages (Haskell and Elm included) in an imperative manner. It's an extremely straightforward translation, and in Haskell it's basically syntactically identical due to do notation.
    • kilgnad 4y ago
      I'm not talking about tricky stuff like do syntax monads. I'm talking about FP at it's core. The '.' compose operator is not procedures. In haskell it does something completely different. >Realistically, most FP programmers program ML-like languages (Haskell and Elm included) in an imperative manner. It's an extremely straightforward translation, and in Haskell it's basically syntactically identical due to do notation. No Elm doesn't do any tricky stuff. So elm is not imperative Haskell can look imperative with do notation. That's about it. I mean you can put put elements of your equation on different lines but it's still not imperative. 1 + 2 + 3 I mean ..yeah... if you want to call that (1 + 2 + 3) imperative, be my guest. But obviously that's not what I'm talking about.
• lolinder 4y ago
  I honestly think that ML is too consistent and regular. Natural languages inevitably build in a lot of redundancy that can seem irrational but that serves a very important purpose in decreasing confusion and increasing the rate of comprehension. The redundancy makes the language harder to describe, but it reduces cognitive load once you've learned it because it's easier to distinguish between different elements, even in less-than-ideal conditions. I think this is where both Lisp and ML fall short and why they consistently lose to the more convoluted syntaxes: what seems like a flaw is actually an important feature that makes comprehension easier. Sure, you can go overboard (looking at you, Perl), but the irregularities present in C-style languages are valuable extra information channels that increase cognitive bandwidth.
• yellowapple 4y ago
  > People seem to love Python syntax. I sure don't. I'll take explicitly-delimited blocks over having to slap a ruler to my screen to know what scope I'm in any day. It's a prime example of why form over function is a horrible tradeoff. I use Python in spite of how much I hate its syntax (and myriad other aspects of it) because it's often the path of least resistance. > ML syntax is just more regular, consistent, and typed. My sample size is "Elm and Haskell", and of that sample size, my impression is the precise opposite. I encountered enough cases of whitespace that shouldn't have mattered but does anyway that it put me entirely off both languages. Lisp? Tcl? Forth? Now those are regular and consistent (though admittedly rarely typed).
  • mixmastamyk 4y ago
    Editor indentation guides have been a thing for a decade or two.
    • yellowapple 4y ago
      That's cold comfort when I need to make some quick fix in nano or vi on some remote server somewhere.
      • mixmastamyk 4y ago
        A practice to avoid. Cattle, not pets. Not to mention, well factored functions/methods shouldn't be so large they are hard to manage. Never had trouble with terminal editors either, but I keep things simple.
        • yellowapple 4y ago
          If only all of us were so fortunate to live with you in such a utopia where servers are perfectly fungible and automation scripts are written by competent software engineers :)
          • mixmastamyk 4y ago
• ezrast 4y ago
  A few of the things I hate about ML syntax: * Infix semicolons instead of paired delimiters to denote code blocks. These cause shift-reduce errors and make indentation unintuitive. * Implicit currying turning what should be obvious argument count errors into type errors on unrelated lines. * Implicit currying making parameter order overly significant. This drives languages to introduce infix pipe operators with unintuitive precedence and to bikeshed forward vs backward piping. This could all be done away with by having a dedicated partial application syntax. * Postfix, of all things, for type constructors. Except for the ones that are, sigh, infix again. * Inscrutable type signatures on higher-order functions, largely as a result of the above and of the convention of single-letter type variables.
  • michaelcampbell 4y ago
    I don't hate ML or its syntax, but this feels like a reasonable set of irritations to me. I may need to introspect a bit more.
• oneplane 4y ago
  ML Syntax seems to be made for machines, not for the average human mind. Parsing language that is 'too unnatural' is a bit of a strain when compared to something that looks like average grammar if you squint at it, so it doesn't surprise me at all. It's also a bit in the realm of scientific/academic programming vs. real-world bulk programming where it's mostly just CRUD, mapping and business rules. It's all still important if that's how money is made, but as far as I can tell, most programming isn't really all that involved with 'quality languages' and more about feature output from a backlog. If you can do that for cheap with a fresh can of Python developers and some extra EC2 instances on AWS, that's an easy choice vs. someone who might want to do it in Lisp instead for example.
• kerkeslager 4y ago
  It's not worse. It's just not better in any significant way. So if you're new to this language, and the first thing it makes you learn is this new syntax which isn't better in any significant way, learning that language immediately feels like you're wasting your time learning something that isn't better in any significant way. Of course, if you started with ML syntax, you'd feel the same way learning a language with C syntax. But if you're introducing a new language, it makes sense to target the language the most people are already familiar with. Maybe your language does really bring some real syntax improvements, but it's a silly hill to die on, because syntax just isn't very important. If syntax changes are all your language brings to the table, your language really isn't worth learning. And if your language brings more important ideas to the table, then it would be a shame for people to never make it to those ideas because they got bored learning unimportant syntax ideas.
  • vlovich123 4y ago
    > if you started with ML syntax, you'd feel the same way learning a language with C syntax. I always wonder this but I’ve always found Lisp syntax to be a lot more intimidating and less readable for whatever reason. I should give it a fair shot one of these days.
    • trenchgun 4y ago
      Lisp syntax is unreadable because there is not much syntax. Functions, macros, variables are all in a mix of gazillion parentheses. ML syntax is really clean.
    • kazinator 4y ago
      Lisp syntax is about the vocab. Because the grouping (what expression is child of what other expression, and at which position: third child, fifth child, ... is clear). If you don't know what the word means, like what is foobly in (foobly ((x 3)) (blorch x)), and don't yet have the intuition to make an accurate guess, you are screwed if you don't look it up. The meaning of everything inside (foobly ...) could depend on the definition of foobly. foobly could be in the language itself, or some extension in the language implementation, or it could be defined in the code base. Newcomers to some kind of Lisp get confronted with identifiers that they haven't seen anywhere.