Sure, if you write Python in Lisp, but not if you actually take advantage of Lisp.
with open('foo.txt', 'w') as f:
f.write('hello world\n')
Plus really most IRL works just need:
Path('foo.txt').write_text('hello world\n')
I don't think that's the point of the author. The point is that they look like enough if you remove the cruft, that you can make helpful associations to learn the one you don't know.
This, the whole Unicode mess and the fact that lisp allows you to write at the same level of abstraction (or greater) without sacrificing performance as much, led me to abandon Python for almost everything.
How do you distribute your programs/applications? As Lisp source code or as a binary generated by dumping core or some such technique?
In any way you like including creating executable files.
(defun example ()
(ascertain that (+ 1 1) is 2)
(ascertain that (+ 1 1) is not zero)
(ascertain that 0 is not zero)
(ascertain that 0 is zero)
(ascertain that (+ 2 2) is 5)
(ascertain that (+ 2 2) is not 5)
(ascertain that (+ 2 2) is = 4.0)
(ascertain that (+ 1 1) is member of '(1 2 3))
(ascertain that 0 is a member of '(1 2 3))
(ascertain that pi is not a member of '(foo bar zot pi))
(ascertain that (error "blah") signals simple-error)
(ascertain that (error "blah") signals a serious-condition)
(ascertain that (error 'unexpected-result) signals an unexpected-result))
def example ():
assert 1 + 1 is 2
assert 1 + 1 is not zero
...
assert 1 + 1 in (1, 2, 3)
assert 0 in (1, 2, 3)
assert math.pi not in (foo, bar, zot, pi)
...You should also know that, unlike "assert" in Python, "ascertain" is not something defined by the Common Lisp language. It was defined by a Common Lisp user (me), just some 50-line macro that can be extended at will, to fit whatever clauses I would like it to support, in any way I see fit.
I'm glad that you took a stab at answering my question, but I hope you can see my point more clearly - that in Lisp you can taylor the language to suit your needs, and while sometimes Python may provide similar syntax, other times it may not. In fact many operators already existing in Common Lisp have no direct correspondence. You can also find tons more examples in the code of other people.
Anyway, hope it at least piqued your interest. Have a good day!
I didn't get what it meant, so I couldn't really try to translate something I couldn't understand.
> It was defined by a Common Lisp user (me), just some 50-line macro that can be extended at will, to fit whatever clauses I would like it to support, in any way I see fit.
I understood that after looking it up on google and finding nothing. Which is one of the reason I dislike DSL. Usually their specs resides in the head of their dev, with the unit tests.
> I hope you can see my point more clearly
I do, it's just not the point of the author. You can make lisp whatever you want, but the basic syntax has similarities that are helpful for a transition. I don't see why this bother you. Nobody try to limit the quality of lisp.
> Anyway, hope it at least piqued your interest. Have a good day!
Oh it's on my list with Erlang, Haskell and Prolog. Next to the list of books to read, food to try and habits to drop.
And you too.
That said, both will come out fine. What will not be apparent in the final product is that the Lisp version would have been formatted by a Lisp-aware editor, while the Python version will have been formatted by the programmer.