freenode/#lisp - IRC Chatlog
Search
4:49:59
beach
ebzzry: As I recall, pjb has been working with CCL for OpenMusic. Again, as I recall, CCL is a derivative of MCL, and IRCAM was into Macs and Common Lisp in the past.
12:06:35
syntaxfree
I did "dr. scheme" in college for a course that was a light dumbed down sicp-alike. sure, fun stuff.
12:07:05
syntaxfree
but I came across Hy. and I'm replacing bits of this larger ML-oriented API products.
12:14:03
no-defun-allowed
Hy doesn't have lexical block scoping, so you might have some more surprises from here.
12:15:09
syntaxfree
as far as I can tell Hy follows Python rules of scoping. It would be awkward to learn otherwise.
12:15:53
no-defun-allowed
More awkward to have automatic type coercion and function scoping in a Lisp to me.
12:19:14
syntaxfree
I wish there was more support for type hinting. newer python things are extensively using type hints (eg to validate json inputs and produce valid Python objects from JS objects)
12:20:32
syntaxfree
almost all of my "higher level", organizational Python code is type-hinted, with semantic type synonyms, etc. But macros appear to fill in a lot of missing teeth in implementation-level, numpy-based code)
12:21:03
beach
I recommend you program in Common Lisp instead. That way, you have all the type declarations you need.
12:21:42
syntaxfree
beach: it's a good ideal. I'm very fond of Haskell too. But hey, it's a node shop and I'm the weirdo already.
12:22:00
syntaxfree
anyway, this should exist (defmacro np-count [conditional-expression] `(np.sum (np.where ~conditional-expression)))
12:27:13
no-defun-allowed
Yeah, I would rather work in a proper Lisp that has a compiler that can actally take advantage of type declarations.
12:29:40
syntaxfree
theré's also the fact that python is not very good at inlining code. if it does it at all. a lot of syntactic effects can be achieved in "pure functions" style, but that's less good with large non-sparse matrices.
12:31:46
syntaxfree
I basically learned the basics of programming with Haskell. So I see pure functions everywhere. The enlightenment is that a lot of what I do with "pure functions" is literally syntactic sugar. Should be unrolled at the get-go.
12:33:30
syntaxfree
also often many functions-to-make-syntactic-sugar are a single macro. Because reasoning about syntax and reasoning about semantics can be separated. This is brilliant.
12:35:37
LdBeth
I guess you get confused by what’s should be called user definable control flow and what’s real syntactic sugar
12:37:41
syntaxfree
because there's a lot of functional programming that's actually reasoning semantically with functions. It can't all be unrolled at "compile time" (this is ill-defined for python but anyway)
12:37:52
no-defun-allowed
I should mention that if you use CPython, there's basically no compilation that would make use of any optimisation techniques, it's just a plain bytecode interpreter. But that's the end of that.
12:39:24
syntaxfree
but there's a lot of higher-order functions that are really about "ergonomic improvements".
12:39:28
jackdaniel
maybe more direct approach will be better: please move the offtopic to #lispcafe ;p
12:39:54
LdBeth
syntaxfree: it’s usually a bad idea mimicking features of functional programming in a language not designed with at least some functional things in mind
12:41:02
syntaxfree
LdBeth: that was half a comment. I was saying there's genuine use cases for functional programming and cases where higher-order functions are used for programmer convenience. I'm moving to #lispcafe as directed by community leaders.