Lisp-stick on a Python
docs.hylang.org
docs.hylang.org
For instance, it's easy to demonstrate how Rust is superior to C: Just show a short piece of code where an array is returned from a function. In C, this will involve raw pointers and manual memory management with all associated safety and security pitfalls, whereas in Rust you just return a `Vec` and everything is taken care of. Simple, obvious, real-world superiority.
How does such an example for Lisp look like? I'd love to see 10 lines of Lisp that show me something that:
1. I can't easily do in, say, Rust.
2. Actually matters in practice.
Re Lisp's superiority - Lisp was certainly a superior language when it was devised many decades ago, but over time much of its comparative advantage has been absorbed by other languages. Starting in the 90s when productive, GC'd scripting languages like Python started being prominent this trend accelerated.
For a nice discussion of this see https://norvig.com/Lisp-retro.html
[1]: https://letoverlambda.com/index.cl/guest/chap5.html#sec_
[2]: Compiler macro chapters aren't free, but I guess read-time is covered here https://letoverlambda.com/index.cl/guest/chap4.html#sec_1
[3]: https://irreal.org/blog/?p=809 / https://web.archive.org/web/20140711171755/symbo1ics.com/blo...
typedef struct {int v[4];} Vec;
Vec get_vec(void){return Vec {3,2,1,0};}
typedef struct {int v[4];} Vec;
Vec get_vec(void){Vec v={{3,2,1,0}}; return v;}C is a much simpler language than many people assume -- of course, it can get really hairy and complicated especially when you need to do dynamic memory management, but that's not what the GP was asking for in this case.
You really think that when they mentioned the dynamically allocated `Vec` in Rust (which has fixed-sized arrays) and "manual memory management" in C, what they were actually talking about was a static array?
Vec get_vec(void) {
return (Vec){ { 3, 2, 1, 0 } };
}
Vec get_vec(void) {
return (Vec){ .v = { 3, 2, 1, 0 } };
}I'd love to see 10 lines of Rust that showed me something that:
1. I can't easily do in Lisp.
2. Actually matters in practice.
1. https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
2. https://elliottslaughter.com/2011/06/blackthorn-3d
- Last updated in 2020 https://bitbucket.org/elliottslaughter/blackthorn-engine-3d/src/master/
4. https://github.com/BradWBeer/clinch
5. https://github.com/Shirakumo/trial
- This has games released on Steam built in it
otoh how much rust is there in firefox? a:
These questions are so silly. Nobody's written a web-browser in Rust, Python, Ruby, Java, Clojure, Haskell, Erlang, Typescript, Javascript, etc. but that hasn't stopped anybody from using them.
Just admit you don't want to learn Lisp.
in 1986 ?
> don't think it's suitable for all tasks
to this day im yet to see an example of a software engineering problem that lisp is not suitable to solve. if you have such an example ready i would be genuinely curious. otherwise its just a thought from a very common and lazy misunderstanding of what lisp actually is
im talking about computational problems. things that are non-examples include such things as business sense/requirements, availability of programers, availability of ready made libraries/frameworks, or claims of apparent unsuitabilty in large teams
I mean, OP asked for a 10 line program showing something that can't be done easily in Rust and actually matters, so he seems to believe 10 line programs aren't trivial.
That said line counts are an awful metric because I could just cram an entire library definition in a single line as if it were minified JS.
There are a lot of video interviews with the creators. I found them extremely interesting.
https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
https://www.reddit.com/r/lisp/comments/fayhw2/how_crash_band...
https://www.ptc.com/en/products/creo/elements-direct
that's C + several million lines of Lisp
#![allow(arithmetic_overflow)]
fn main() {
let x = 1073741823;
println!("x = {}", x*3);
}
# cargo build && cargo run
thread 'main' panicked at 'attempt to multiply with overflow', src/main.rs:4:24
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
(defun main ()
(let ((x 1073741823))
(declare (type (signed-byte 32) x))
(format t "x = ~a~%" (the (signed-byte 32) (* x 32)))))
(handler-case
(main)
(simple-type-error (e)
(format *error-output* "Panicking because of ~a~%" e)
(uiop:quit 1)))
# sbcl --script main.lisp
; file: /tmp/main.lisp
; in: DEFUN MAIN
; (THE (SIGNED-BYTE 32) (* X 32))
;
; caught WARNING:
; Derived type of (* COMMON-LISP-USER::X 32) is
; (VALUES (INTEGER 34359738336 34359738336) &OPTIONAL),
; conflicting with its asserted type
; (SIGNED-BYTE 32).
; See also:
; The SBCL Manual, Node "Handling of Types"
;
; compilation unit finished
; caught 1 WARNING condition
Panicking because of Value of (* X 32) in
(THE (SIGNED-BYTE 32) (* X 32))
is
34359738336,
not a
(SIGNED-BYTE 32).
1. Gather assembly level profiling information
2. Redefine & recompile a function
3. Gather new assembly level profiling
I can iterate dozens of times between #2 and #3 in the time of a single incremental production build in rust (debug builds are not useful for gathering profiling data).
Generally speaking it takes less than a second to recompile and load a source file, and it can be done while the program is running.
Also, C++ linkage, while far faster than rust isn't the fastest thing, and compilation can be slow too (particularly with the popularity of header-only libraries).
Wow. No. This is a really basic debugging feature that's been around for over a decade. You can also drag-and-drop the instruction pointer to another line, watch and change variables in real time, etc. I swear, every LISP-related thread has someone touting ancient features as if they are somehow new or unique.
Some form of interactivity with the debugger is common in my experience. The level of interactivity you get with Common Lisp is not.
Well then you need to learn your tools better. VS has had Edit and Continue since 2005.
I found my old VS CDs and the latest version I own is .NET 2003, so I only missed that feature by a single release. I couldn't truly be a smug lisp weenie without some snide remark about how nice it is that blub developers finally got something not quite as powerful almost 40 years after Lisp could do it, so just consider me to have made such a statement.
common lisp can actually be really good performance-wise. its one of the things that made me switch from using python+c/cpp for my numerical work
Why not? CL is very performant. You'd probably be surprised. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
not just functions, but whole classes too
https://lispcookbook.github.io/cl-cookbook/clos.html#:~:text....
(define (eval exp env)
(cond ((number? exp) exp)
((string? exp) exp)
((symbol? exp) (lookup exp env)
((eq? (car exp) 'quote) (cadr exp))
((eq? (car exp) 'lambda)
(list 'closure (cdr exp) env))
((eq? (car exp) 'cond) (eval-cond (cdr exp))
(else (apply
(eval (car exp) env)
(eval-list (cdr exp) env)))))
Indirectly this also means that lisps are very close at hand for “I want to add a scripting language onto this thing but I don't want to, say, embed the whole Lua interpreter” and it allows you to store user programs in a JSON column, say. You also can adapt this to serialize environments so that you can send a read-only lexical closure from computer to computer, plenty of situations like that.
Aside from the most famous, you have things like this:
1. The heart of logic programming is also only about 50 lines of Scheme if you want to read that:
https://github.com/jasonhemann/microKanren/blob/master/micro...
2. Hygienic macros in Rust probably owe their existence to their appearance in Lisps.
C2 asks the same question here: https://wiki.c2.com/?LispShowOffExamples with answers like
3. The object model available in Common Lisp was more powerful than languages like Java/C++ because it had to fit into Lisp terms (“the art of the metaobject protocol” was the 1991 book that explained the more powerful substructure lurking underneath this object system), so a CL programmer could maybe use it to write a quick sort of aspect-oriented programming that would match your needs.
4. Over there a link shows how in 16 LOC you can implement a new domain-specific language to define and run finite state machines: http://www.findinglisp.com/blog/2004/06/automaton-cleanup.ht...
In addition to that, Lisps are sufficiently flexible that before CLOS itself was developed people were extending Lisp in Lisp to try out different object oriented models that fed into what became CLOS. That's hard to accomplish in most other languages, if it's even possible without going to a third party tool or digging into the compiler itself.
Any recommendations on good resources for learning Lisp to a degree that this program is understandable?
But here is Norvig's Python eval for a Lisp:
def eval(x, env=global_env):
"Evaluate an expression in an environment."
if isinstance(x, Symbol): # variable reference
return env.find(x)[x]
elif not isinstance(x, List):# constant
return x
op, *args = x
if op == 'quote': # quotation
return args[0]
elif op == 'if': # conditional
(test, conseq, alt) = args
exp = (conseq if eval(test, env) else alt)
return eval(exp, env)
elif op == 'define': # definition
(symbol, exp) = args
env[symbol] = eval(exp, env)
elif op == 'set!': # assignment
(symbol, exp) = args
env.find(symbol)[symbol] = eval(exp, env)
elif op == 'lambda': # procedure
(parms, body) = args
return Procedure(parms, body, env)
else: # procedure call
proc = eval(op, env)
vals = [eval(arg, env) for arg in args]
return proc(*vals)
So, the first thing is, what's the essential difficulty versus the noise: Lisp has two features which enable the evaluator to work. The first is quotation, which means that you can put a little apostrophe before some code and then it saves that code as a data structure, rather than implicitly evaluating it. The second goes by the overfancy name “homoiconicity”, that data structure is actually just singly linked list consumed by “car” (“first”) and “cdr” (“rest”) operations.
You can focus on understanding those two aspects pretty quickly, and then there are many tutorials about building your own Lisp that will get you there in an afternoon, if you'd like.
Or, you can take the royal road to this expression, in all of its cheesy 1980s glory:
https://youtube.com/playlist?list=PLE18841CABEA24090
It's lecture 7A where this specific program gets explicitly dissected by Sussman, wearing a fez. If he seems familiar, you might have watched Strange Loop 2011’s “We Really Don't Know How To Compute”, https://youtu.be/HB5TrK7A4pI
Typedef the array, return that. One pitfall, it's not resizable.
Also Lisp makes it easier to not repeat yourself. It's shorter to create functions, even macros, leading to the ominous "DSL" rabbit hole.
Another superpower is that it has no predefined keywords or operators. So you can redefine everything to whatever unicode you want. Including other languages and writing systems. It's a lot harder to write a programming language/compiler that uses another natural language idiomatically using something more similar to C or Python.
How do you fix a waterlogged smartphone? Put out a bowl of rice, which attracts an Asian guy who will repair it for you.
Languages have pedigrees. If you pretend like your company is enamored with javascript you'll get people who love fedoras and call themselves Ninjas. Big teams, single function libraries, lots of code shipped - move fast and break things. Cats pawing at Macbook keyboards. Mumble rap.
If you pretend you love Haskell you'll attract mathematicians in elbow patches. Great stable code will sporadically appear once every couple of years seemingly at random. Genius solutions to neat problems that have nothing to do with what the company is actually trying to accomplish. Ents. Classical music.
If you pretend to love lisp you'll attract people who read PG essays and will quit to start their own companies. Maybe they'll help you close out some tickets in Jira before they bounce if they can get your Rube Goldberg monstrosity working on their laptop. Honey badgers and hamsters. U2.
If you pretend to love latin you might get elected PM.
If you actually learn a few orthogonal languages to cover the very finite amount of paradigms you'll eventually come to realize they are all crap.
If you want to code, code. Don't talk.
{ ⊃ 1 ω ∨ . ∧ 3 4 = +/ +⌿ 1 0 ‾1 ∘.θ 1 - ‾1 Φ″ ⊂ ω }
as far as writing the actual code, lisp syntax allows me to perform structural editing which to me is just on another level
but as with all things in life, you should try before you buy
The downside is that you just performed a hidden heap allocation. If automatic memory management is desired, a garbage-collected language might have been the better choice in the first place.
pub fn get_array() -> [i32;4] {
return [1, 2, 3, 4];
}
struct IntArray4 { int items[4]; } get_array(void) {
return (struct IntArray4) { .items = { 1, 2, 3, 4 } };
}
That's also one of the rare cases where Rust code actually turns out more simple and readable than the C equivalent ;)
We all know about memoize, but let's say I want to define a global hash-map, where the keys are actual pieces of code and the value the result that would be evaluated when executed. Something like this:
| Key | Value |
|----------------------------+--------------------------------|
| "hello" | "hello" |
| (square 5) | 25 |
| (factorial 5) | 120 |
| (git-tags "~/foo") | (list "1.0.0" "0.1.0" "0.0.1") |
| (make-instance 'singleton) | #<SINGLETON {1301DE5A03}> |
(let ((path "~/foo")
(tags (cache `(git-tags ,path))))
(format t "Tags of ~a~% ~{- ~a~%~}"
path tags))
One way to rephrase objections to "all those parens" of Lisp is that the most common style of using it makes it necessary to "write boring code 'in AST'", if you will, and not even in a very nice, commonly accepted 2-dimensional tree notation.
I always wonder how different the history of prog.langs would be if early on one of the many indent/offside rule based 2-D notations had become popular with "boring code" writers in Lisp and not eschewed by "fancy macro writers" in Lisp.
That sounds interesting but is hard to search for, have you got an example?
http://srfi.schemers.org/srfi-119/srfi-119.html
EDIT: To elaborate on my `quote do:`, this is a little macro to avoid doing many tedious code repetitions:
macro strp(sVars: varargs[untyped]): untyped =
result = newStmtList() # strip some string vars; Assume new-scope
for sV in sVars: result.add(quote do: (let `sV` = `sV`.strip))
strp sTm,sUs,sSy,sUt,sRS,sIn,sOu,mjF,mnF,swp,vsw,isw,isr,ixr,idr,nsg,msn,mrc
let sTm = sTm.strip
let sUs = sUs.strip
...
The static typing of Nim (rather than gradual typing defaults like Lisp or Cython) tends to make beginner programs less "performance cringe" (as long as they compile with `-d:release -d:lto`!).
As someone who loves both Lisp and Pascal, I really need to revisit Nim.
LISP had garbage collection and was designed for symbolic manipulation. Given that programs were just list of symbols, it was fully meta, from the beginning. This gave it a raw power that was decades ahead of time. Even nowadays, this malleability give Lisp languages the power to provide as libraries things than in most languages would require the modification of the language itself. For example, there is library for Clojure (a popular modern Lisp which runs on the Java and Javascript virtual machines) that adds type support. Think about that. Yes, I know. Mypy adds types to Python, but in the case of Clojure the language and runtime didn't need to be touched at for the library to work. You can basically do whatever you want as a library, because the core of the language is so powerful.
Another distinct characteristic of Lisps was the possibility to treat programs as living things you can just "talk to" through the REPL. Programs are developed in a more "conversational" way than with languages such as Java, Rust, etc. Some would say that this is a superpower and other would say that it's of marginal value. It just depends on the personal preferences.
Now, we are in 2022. Obviously, languages have evolved a lot and they are ridiculously more advanced that FORTRAN. Lisps don't have a clear killer feature that can't be found in some other languages and actually they normally lack some convenient things. There is no type system for Lisps that it's practical, convenient and with tooling support. That is a big disadvantage on an era where programs are big beasts normally done by several people mostly gluing together a bunch of libraries with big APIs that you need to explore somehow. Typed languages with accompanying IDE tooling (i.e. having a language server) offer a much quicker and effective way to develop than spending the day reading API docs.
Now, should you learn a Lisp in 2022? Well, I think there are some advantages of doing so. They have a lot of historical value and their simplicity and power are quite instructive, I'd say. Playing a bit with some Scheme (or Racket) can be very fun. If you are curious about Lisps and also functional programming, I'd suggest learning some Clojure. It's a very nice language and it really changes how you think about things, especially if you haven't been doing "hard" functional programming before.
Clojure general approach and concrete libraries as Reitit, Malli or Specter really can change how you look at things and give you a deeper understanding of other characteristics of your other languages of choice. It's a bit like learning some Japanese if you are a German or French speaker. It can help you understand, for example, how unnecessarily complex your verbal system is and how unnecessarily complex Japanese numbering system is. If you are a fish, it's difficult to understand what water is unless you get out of it. Maybe Lisps can be this breath of fresh air.
Then we have the new Coalton library, that brings ML-like type checking on top of CL.
(and yes CL still has killer features, and no one brings all of them together!)
The REPL is the center of everything and it enables you to change functions on a running program. Tracing a function (shows function arguments on every call) is a simple as calling trace(function-name). If a program crashes, it does not really crash... it enters some debug mode which offers possible resolutions, including change the function that failed. The REPL can trivially show you the assembly code of individual functions. You can also add declarations for each function with hints for the compiler (and then check the size of the resulting assembly).
I believe this series of articles highlights some of the debugging features.
https://malisper.me/debugging-lisp-part-1-recompilation/
There is also a story called "debugging code from 60 million miles away".
Other things that I did not manage to explore yet are the macros, which allows you to create your own domain specific languages.
My general impression so far is that it is a really powerful language, for lonely hackers. :)
(defun make-dbms (db &key (test #'eql))
"Make a database, db should be a list. Test determines what keys match."
;;Three closures in a list to make a database.
(list
#'(lambda (key)
(rest (assoc key db :test test)))
;;add
#'(lambda (key val)
(push (cons key val) db)
key)
;;delete
#'(lambda (key)
(setf db (delete key db :test test :key #'first))
key)))
(defun lookup-dbms (key db)
"Return the value of an entry of db associated with the key."
(funcall (first db) key))
(defun add-dbms (key val db)
"Add a key and value to db."
(funcall (second db) key val))
(defun del-dbms (key db)
(funcall (third db) key))
CL-USER> (let ((db (make-dbms nil :test #'equalp)))
(add-dbms '(+ 1 2) 3 db)
(lookup-dbms '(+ 1 2) db))
=> 3Just as examples, Common Lisp supports arbitrarily-long integers, low-level bitwise operations like popcount, rational and imaginary numbers as well as, say, POSIX file operations or easy calling into C functions. It has things like list comprehensions, pattern matching, and dictionaries, and full Unicode support since a long time.
It supports both procedural and functional-style programming, and is, like Rust, a child of the language families which stem from the Lambda calculus, where everything is an expression. The latter is an extremely valuable property because you can replace any expression in lisp code with a function or its value, even if it is an if-statement.
It has still facilities which other languages do not have, like built-in support for symbols, which are used similar to interned strings and keywords in Python.
At the same time, Common Lisp is extremely mature. For example, it is possible to define and use error handlers, which is a generalization of exceptions, and is useful in library code. Or while other languages have only local and global variables, nothing in-between, Lisp allows to define parameters, which are global values, that however can be modified in the scope and call stack of a certain function call, similar as environment variables can be inherited and changed in sub-processes of a program.
And it compiles to quite fast native code, which Python can't.
Here is an introduction to Racket, which is a dialect of Scheme - I think it shows quite nicely the uniformity and simplicity of Lisps: https://docs.racket-lang.org/quick/
They are both drawn by Karen Rustad Tölva!
I doubt anyone uses hy in production for completely other reasons, would love to be proven wrong.
* Looking at stack traces is suddenly so much harder and involves reverse-engineering the transpiler unless your transpiler is sophisticated enough that it can de-transpile the stack traces back to the source language.
* You're adding a step to your build pipeline.
* You're taking on the risk of bugs or security issues that may exist or be introduced to the transpiler itself.
* Your developers need to learn both the source and target languages.
* If the transpiler project is abandoned, you have to begin maintaining it yourself, or you need to de-obfuscate your transpiled code enough to make it your canonical code.
I think that anyone who used CoffeeScript in the late 2000s / early 2010s understands the pain of using a transpiled language that wasn't worth the trouble.
Not to say that one should never transpile, or that Hy's not worth it or not production ready! Just that, there are things to consider, and how much you need to consider them depends on what your "production" is.
Multiple languages are less of an issue when you have a small team or a team of one.
I'd be willing to use Hylang in production. I wouldn't go all-in, but rather pick something that looks like it needs a DSL. You can still interface with Python code interchangeably whenever you want, so there really is not much pain to abandon the attempt completely.
If you write your code in Hy, many people are going to have no idea. Small chance they already know it. A minority of people will have some background in Lisp, and if you already know both Python and another Lisp, learning Hy should be straightforward. But for a Lisp-naive developer, it is a big speed bump.
Also there is a lot of existing tooling around Python code – static analysis, etc – which might not be able to handle Hy. Sure, it can process the transpiled Python, but that produces a lot less pleasant experience for the developer. You really want native Hy tools, which are going to be behind native Python tools.
When I was working on Hy, almost 10 years ago, there was a couple of Hy core devs that had managed to push some Hy code into production. I won't name names, but a known company used Hy when processing firewall rules (if i recall correctly).
I doubt that code is still being used, and I'm not aware of anyone beyond a couple of previous Hy core devs that managed to push Hy into production.
I can imagine speed being a real problem in production?
And I’m not sure it won’t get shot down anyway. It’s a big step for Python.
And I say that while I wished I could use macro several times in Python because the syntax was lacking.
I mean maybe the council will go with it, but I'm bearish.
I do really like the idea of jit macros and zero-overhead decorators though.
Take dataclasses: it adds a bunch of synthesized methods to a class, and needs to use "exec" to create them. How could that be zero overhead?
To help with this, I've proposed moving knowledge of dataclasses into the Python compiler, but even I don't think it's a great idea. For example, it would leave attrs in a disadvantaged position, and I don't want to do that.
Another option would be to move dataclasses before the code generator. Syntactic macros are one way to do that. Then there really would be zero overhead when loading the cached .pyc files. That's their appeal to me. Of course there are lots of other things that could be done with syntactic macros, which is both good and bad.
I'm torn on the issue: I don't want to be restricted from improving dataclasses in what would be fairly obvious ways, but I'm sure the feature would be abused. But maybe this falls under the "we're all consenting adults" guideline.
Python already has 'enough' metaprogramming support, the last thing we need is a sudden fad of libraries defining their own gratuitous DSLs
https://github.com/Calysto/calysto_scheme
It's not blazing fast, but it's Scheme -- not paren-y syntactic sugar around Python.
(- 2 3)
(- 4 3 2)https://docs.hylang.org/en/stable/whyhy.html
Shortened from there:
Hy (or “Hylang”) is a multi-paradigm general-purpose programming language in the Lisp family. It’s implemented as a kind of alternative syntax for Python. Hy provides direct access to Python’s built-ins and third-party Python libraries, while allowing you to freely mix imperative, functional, and object-oriented styles of programming.
Why Hy? Hy (or “Hylang” for long; named after the insect order Hymenoptera, since Paul Tagliamonte was studying swarm behavior when he created the language)
It's like when you open a cooking recipe on a website and you get the author's entire life story
Missed opportunity to spread the knlowledge about the Hymenopteras…
Why would anyone pretend to program in Lisp without any benefit? Also, Python is the worst imaginable engine for running Lisp. [correction: I see there are some kind of macros...]
plus you get to benefit from paredit under emacs
I have few good things to say about Python, other than it sort of works. I classify it in the big-sack-of-stuff languages, along with Perl and shells. Not much elegance or style.
As a Clojurist I think it behooves us not to put on gatekeeping airs (because we’re up against those too).
There is a certain category of Lisp-like languages – of which Hy, Fennel and LFE are good examples – which take an existing language, and provide a Lisp-like syntax for it, but generally keep the semantics reasonably close to that of the underlying language. Beyond the syntax, the other main addition tends to be a Lisp-style macro system. Maybe we might call them "veneer Lisps", since they put a Lisp veneer on another language, but beneath the surface it is largely the same.
Clojure isn't a veneer Lisp, because its semantics are quite different from Java – Java is primarily about mutable data, and Clojure-style immutable data structures aren't the mainstream Java approach. A JVM Lisp which dropped Clojure's emphasis on immutability could be a veneer Lisp. Armed Bear Common Lisp and Kawa Scheme are examples of mutability-oriented JVM Lisps, but they don't belong to the category of veneer Lisps either, since they are ports of pre-existing languages to the JVM, and their mutability comes from those pre-existing languages not a desire to conform to Java/JVM semantics.
I'm not saying there is anything wrong with immutability, or that Clojure's focus on it is a mistake, or that one ought to either prefer (or avoid) "veneer Lisps": I'm attempting descriptive taxonomy, not prescriptivism.
Because it is superior way of writing a program. Pure, consistent and unambiguous.
What exactly do you mean by this?
I assume you're referring to an optimization, because one can write tail recursion in any language that supports subroutines.
Yes, I did mean optimization - without it you can blow through your stack quickly (and the traceback will be long and redundant :)
They made a highly redundant traceback display much more pleasant a couple years ago, writing "the same thing 1,998 more times ..." or something like that.
If only! For anyone else who got saddled with some FORTRAN 77 code, you may or may not have recursion available even with subroutines. It wasn't required by the language standard, but some implementations supported it. Not the one I "got" to use (and quickly moved on from) a while back, though.
I recall hearing it had been implemented a while back, seems like it's true!