Hello, I just wanted to point out that if I had not read comments here and had not looked for a second example linked to "Job", I would not have realized there were dots under the first example. You may want to make them more visible ^^;
Ante: A low-level functional language
91–100 of 226 posts
Re: Ante: A low-level functional language
#92Earlier quoted context omitted.
I have heard that if you count { and ( as parens, a Java program for example has just as many parens as. lisp one. A lisp paren can do both jobs: expression and scopes.
> A lisp paren can do both jobs: expression and scopes. Using different symbols for different purposes makes sense, it helps humans to parse correctly faster.
Sure, why care about splitting algorithms into functions and naming them appropriately when you can just write it all in a 3k line function.
Re: Ante: A low-level functional language
#93Interesting, well have to see how it develops in the future. Although, I normally dislike languages without {}, but I suppose that is just preference.
I hate having to press Shift to get braces. Let's use square brackets which require no modifier key.
Re: Ante: A low-level functional language
#94Earlier quoted context omitted.
I've heard this argument before, but this isn't true. In shell, f x y z, x y z are all augments to f. Doesn't matter if f takes one argument, all are passed to the function. With many functional languages this gets very confusing. IE what ie what does `f f x` do? In shell I know for sure. In the example f f x, it might be easy to parse. But in f x y z, any of x y z might be functions.
Most functional languages parse a b c d e f as a(b, c, d, e, f), it does not matter what b, c, d, e, f are. Do you know any language where this is different?
OCaml and Haskell parse `a b c d e f` as `((((a b) c) d) e) f`.
Re: Ante: A low-level functional language
#95Functional is always at odds with low level programming because of heap allocation. You can't control it because of immutability. Just a simple map operation does a heap allocation. How does Ante avoid this problem and give the user control of the heap?
The mechanism should be made clear in the introduction as browsing the documentation doesn't make it clear to me.
Re: Ante: A low-level functional language
#96Earlier quoted context omitted.
Most functional languages parse a b c d e f as a(b, c, d, e, f), it does not matter what b, c, d, e, f are. Do you know any language where this is different?
I thought more languages did this but at least nix and ocaml do not actually behave like I thought. In Ruby however it is a bit more ugly def f x x + 1 end puts f f 1 > 3
I don't understand your objection, what output would you like to see instead?
Re: Ante: A low-level functional language
#97The syntax looks a little funky to me but it's still quite interesting. Is there a reason why you would make fn(1) and fn 1 equivalent? For me personally it makes readability worse and looks strange when chaining functions like in their last example on their landing page. On mobile horizontal scrolling through the code snippets will trigger switching to the next snippet on my phone.
Haskell does this. Basically languages that are following the ML style have this syntax including Haskell. You must not have experience with this family of languages at it is very common and a huge part of functional programming.
A good number of "functional programmers" only have experience with JavaScript these days.
Re: Ante: A low-level functional language
#98I'm confused how data structures work in this language, and there's no documentation about it as far as I can tell. Is this going to be a Rust-style vectors+iterators system? It it going to use purely-functional concatenative structures? The first example you show invokes `map` and `sum` over an Array, but what is this code actually doing? Making a copy of the data in the array? Creating a mapping iterator?
Re: Ante: A low-level functional language
#99Earlier quoted context omitted.
Most functional languages parse a b c d e f as a(b, c, d, e, f), it does not matter what b, c, d, e, f are. Do you know any language where this is different?
OCaml and Haskell parse `a b c d e f` as `((((a b) c) d) e) f`.
And while different than Algol-descended languages, I don't think that's particularly confusing. (Not that you were saying so, just continuing the conversation.) You can put together a confusing expression with it, but I can put together confusing things with the Algol syntax with not too much effort too. I've got the source code with my name on the blame to prove it.
Re: Ante: A low-level functional language
#100Earlier quoted context omitted.
Age of "var, val" is over. Now age of "significant whitespace". If seriously, seems like indent syntax is default to go nowadays. Python has way too big influence on language designers.
I'm not a fan of python (it handles significant whitespace somewhat poorly). Cases like mixed tab-space whitespace and single-line only lambdas are python-specific problems for example. I chose it mainly because I like the style and I haven't found it to be an issue in practice yet, especially with flexible rules for line continuations. The biggest detriment to me is the lack of auto-formatters for indentation. Edit:…
You claim, significant whitespace helps mitigate "goto fail" errors.
As for me, indent syntax allows more human errors during refactoring. When moving code blocks around, you can easily misplace whitespaces and compiler/editor has no ability to help you.