4 ms·

> But there are many career programmers who would rather say: > Print 1 to 10, as a comma-separated list. No, I would not. Don't make assumptions on behalf of

> But there are many career programmers who would rather say: > Print 1 to 10, as a comma-separated list. No, I would not. Don't make assumptions on behalf of others.

thiht 8y ago
It says "many", not "every". But even then, I'm not convinced that "many" programmers would rather write the latter.
stefanve 8y ago
There are many career mathematicians who would rather say: " add two to four and multiply the sum with three". Natural language mathematics (arithmetics)
- thepratt 8y ago
  What I'm contesting is the assumption of the majority. There may be a small sub-set of programmers who will prefer the example, but until Avail's usage/interest is wide-spread such an assumption has no validity.
  - ljw1001 8y ago
    "Many" doesn't mean "the majority" any more than it means "every".
- markvangulik 8y ago
  Right, and that’s why Avail is nothing like that. Kind of the opposite when it gets down to it... Cheesy, closed languages like C forgot that exponentiation was even a thing, or complex numbers. If you shift over to using C++’s “clevernesses”, you still don’t get exponentiation, because the traditional caret symbol is already used for exclusive-or, which has no sensible ASCII punctuation. As for someone’s distant comment that Lisp has been used to create languages for years... sure, if the language you wanted was parenthesized lists with keywords inside the left parenthesis. Which is just Lisp with a few more operations and macros. Yuck.
  - deleted 8y ago
    [deleted]
  - lispm 8y ago
    A few languages implemented in Lisp: C, Pascal, Ada, Prolog, Python, JavaScript, Fortran, Haskell, ML, ... none of that had parenthesized lists...
    - kazinator 8y ago
      All those and SHRDLU. https://news.ycombinator.com/item?id=17156049 https://news.ycombinator.com/item?id=17156049
      - markvangulik 8y ago
        “Implemented in” is the key. If you want, say, a C compiler written in Lisp, you end up writing a compiler. If you want a Haskell compiler written in Lisp, you write another compiler. If you want Avail to include all of C, you define C language capability in an Avail module and subtract the rest. Then your C program is also an Avail program, so you have the same tool chain you had with core Avail (still lacking, but getting there), you have dynamic optimizing compilation to JVM (and eventually native, perhaps), and you have a program that not only interoperates with programs written in other dialects, but allows direct connection between them. Like if you want Avail exceptions with your C code, you import exceptions and just use them. You don’t build them over and over again for each language. And if you want to support closures in your C, you’d probably just remove the limitation that treated the closures of Avail as contextless C functions. Similarly for backtracking, universal serialization, and sensible module dependencies (maybe call it #import, versus the horrible textual #include mess of C). And finally, if you want your existing vanilla C code to be able to call “out” efficiently to some FORTRAN or Python code, you no longer have an impedance mismatch. Define those dialects as Avail, and you’ll have real garbage collection, multiplexed lightweight threads (fibers), dynamic optimization, and objects and functions that are reasonably compatible between these dialects.
        deleted 8y ago
- deleted 8y ago
  [deleted]

> But there are many career programmers who would rather say: > Print 1 to 10, as a comma-separated list. No, I would not. Don't make assumptions on behalf of others.

thiht 8y ago

It says "many", not "every". But even then, I'm not convinced that "many" programmers would rather write the latter.

stefanve 8y ago

There are many career mathematicians who would rather say: " add two to four and multiply the sum with three". Natural language mathematics (arithmetics)

thepratt 8y ago
What I'm contesting is the assumption of the majority. There may be a small sub-set of programmers who will prefer the example, but until Avail's usage/interest is wide-spread such an assumption has no validity.
- ljw1001 8y ago
  "Many" doesn't mean "the majority" any more than it means "every".
markvangulik 8y ago
Right, and that’s why Avail is nothing like that. Kind of the opposite when it gets down to it... Cheesy, closed languages like C forgot that exponentiation was even a thing, or complex numbers. If you shift over to using C++’s “clevernesses”, you still don’t get exponentiation, because the traditional caret symbol is already used for exclusive-or, which has no sensible ASCII punctuation. As for someone’s distant comment that Lisp has been used to create languages for years... sure, if the language you wanted was parenthesized lists with keywords inside the left parenthesis. Which is just Lisp with a few more operations and macros. Yuck.
- deleted 8y ago
  [deleted]
- lispm 8y ago
  A few languages implemented in Lisp: C, Pascal, Ada, Prolog, Python, JavaScript, Fortran, Haskell, ML, ... none of that had parenthesized lists...
  - kazinator 8y ago
    All those and SHRDLU. https://news.ycombinator.com/item?id=17156049 https://news.ycombinator.com/item?id=17156049
    - markvangulik 8y ago
      “Implemented in” is the key. If you want, say, a C compiler written in Lisp, you end up writing a compiler. If you want a Haskell compiler written in Lisp, you write another compiler. If you want Avail to include all of C, you define C language capability in an Avail module and subtract the rest. Then your C program is also an Avail program, so you have the same tool chain you had with core Avail (still lacking, but getting there), you have dynamic optimizing compilation to JVM (and eventually native, perhaps), and you have a program that not only interoperates with programs written in other dialects, but allows direct connection between them. Like if you want Avail exceptions with your C code, you import exceptions and just use them. You don’t build them over and over again for each language. And if you want to support closures in your C, you’d probably just remove the limitation that treated the closures of Avail as contextless C functions. Similarly for backtracking, universal serialization, and sensible module dependencies (maybe call it #import, versus the horrible textual #include mess of C). And finally, if you want your existing vanilla C code to be able to call “out” efficiently to some FORTRAN or Python code, you no longer have an impedance mismatch. Define those dialects as Avail, and you’ll have real garbage collection, multiplexed lightweight threads (fibers), dynamic optimization, and objects and functions that are reasonably compatible between these dialects.
      - deleted 8y ago
deleted 8y ago
[deleted]