undefined | Better HN

0 pointsStefanKarpinski10y ago0 comments

> I've no idea about the "private and semi-private communications" and I can only hope things were patched up there.

I'm the co-creator that Dan was talking about. He wrote a bunch of less-than-charitable comments on the aforementioned semi-private forum – not specifically to me, but where he surely knew I would read them – to which I responded with:

https://gist.github.com/StefanKarpinski/c72219ff8ce261172b11

You can judge for yourself whether I was nasty or dishonest. Things were, unfortunately, not patched up. Dan posted a number of responses, deleted all of them before I could read them, then left the conversation permanently.

0 comments

nickpsecurity10y ago

Luu's claims made me hold off on pushing people to contribute to Julia as I waited for corroboration (or refutation) of them. I appreciate you linking to that very fair post that replies to it. The contrast between how the two of your present your claims adds credibility to yours. I also got a great laugh out of part about one guy that barely speaks English using the project as a personal Stackoverflow. A problem I'd have not anticipated starting a language/compiler project haha.

Curious, are you all still coding the internals of the compiler in femtolisp, is most of it written in Julia indirectly relying on that, or no LISP now? A barrier to entry question basically.

StefanKarpinskiOP10y ago

The parser and some lowering passes are still written in femtolisp. There has been some discussion of switching to the native JuliaParser package [1]. However, JuliaParser doesn't implement the fairly tricky lowering passes that the femtolisp parser does. I personally would prefer to have the parser in Julia, but at this point the most pressing issue with parsing and lowering is speed – so it's possible that the parsing and lowering will be converted to C instead.

[1] https://github.com/JuliaLang/JuliaParser.jl

nickpsecurity10y ago

Thanks for the update. Decent plan. An alternative would be to code it in SPARK Ada for speed and correctness. Has side benefit that each component done that way won't be touched by halfassed developers because they lack the will to learn it. Not quick n dirty enough for them. ;)

vanderZwan10y ago

> I personally would prefer to have the parser in Julia, but at this point the most pressing issue with parsing and lowering is speed – so it's possible that the parsing and lowering will be converted to C instead.

But isn't Julia supposed to be fast? ;)

1 more reply

ChrisFoster10y ago

Thanks for the link. After reading the extra context Dan's comment about the community is only more baffling than before. To me your response seems about as measured and straight forwardly honest as it could be, with a double dose of constructive investigation on the purely technical matters.

j / k navigate · click thread line to collapse

0 pointsStefanKarpinski10y ago0 comments

> I've no idea about the "private and semi-private communications" and I can only hope things were patched up there.

https://gist.github.com/StefanKarpinski/c72219ff8ce261172b11

0 comments

nickpsecurity10y ago

Curious, are you all still coding the internals of the compiler in femtolisp, is most of it written in Julia indirectly relying on that, or no LISP now? A barrier to entry question basically.

StefanKarpinskiOP10y ago

[1] https://github.com/JuliaLang/JuliaParser.jl

nickpsecurity10y ago

vanderZwan10y ago

But isn't Julia supposed to be fast? ;)

1 more reply

ChrisFoster10y ago

j / k navigate · click thread line to collapse