Gracias. Muy bueno el contenido. Me llamó la atención el revuelo que causa el uso de letras griegas. Yo lo veo con simpatía por la estética que aproxima lo escrito a lápiz y papel en matemáticas y la programación. Entiendo que Edelman es matemático, co-creador de Julia. Podría ser su impronta. Preguntémonos por la deuda de la informática a las matemáticas. Es tan poco el pago con usar la letra eta o cualquier otra del alfabeto griego. Además, es una pequeña muestra de cultura general reconocer esos bellos caracteres que ayudan a comprimir conceptos abstractos con sentido.
I’m sorry I really want to like Julia but there’s some eccentric quirkiness in this community which is a turn off for me. This whole “eta” symbol thing is an example of that. Another example is Pluto, where the output shows above the cell and the developer is super resistant to a plethora of users begging him for years to give them an option to change this but he refuses to listen and all of Julia community stands behind him and this shows that there is this weird quirkiness which will eventually not be a good thing and i don’t want to invest any time in an ecosystem that actively ignores its users for the sake of “opinionated ness”
So you don't want to learn a language because of has a weirded symbol in it (?), And an editor, which you are under no obligation to use ( like really, you can use any editor), has some developer with strong opinions? Have you looked into why Julia is different as a language, what it can offer ? Sure, I am on the fence about Julia as well, I have python stockholm syndrome - but one would be really shortsighted to just ignore a language because "it didn't feel good when I looked at it".
@@f3arbhyTL;DR: Julia seems like a really nice language. The community is a little too nice and that usually becomes a breeding ground for sociopaths and capricious techbros; something which eventually runs the whole project into the ground. I think you should re-read my comment carefully. My problem is with the attitudes, not with the language. One, the community is too permissive and "nice" for potential bad actors who act in the name of "innovation and opinionated-ness". Use of these symbols is a gimmick and should not be encouraged. It is also an equity issue. A text based source file is more accessible to a larger audience. I don't want to make my variable names emojis either, for similar reasons. Not being able to use fancy math symbols is NOT what's holding Julia back tbh. The second criticism is also about community and certain developers being disrespectful towards the users. This is the case of Pluto.jl where despite decades of convention of putting output under the input (every single interactive program out there,) the developer (who seems like a very nice and quiet person btw) arbitrarily decided to put the output _above_ the cell. This causes all kinds of issues when it comes to UX. He could've given users the option to configure this, but no, he forced this "opinion" on everyone without so much as a fig leaf of a consultation process. The Julia community, despite this anti-social and disrespectful behaviour by the developer, continues to support this choice meekly and without protest (spinlessly would be too strong a word.) Pluto is not "an editor" btw, and appears to be destined to become the standard notebook platform for Julia. So, it's not really a personal choice for long when Julia community will be spending all its time improving Pluto instead of making Julia related enhancements to Jupyter (which ironically, was there first to support Julia , the "Ju" in the name represents Julia btw) . If I want to work with Julia in data-science, then I have to deal with Pluto and the (frankly, boneheaded and capricious) decisions made by one person without any community oversight. I refuse to be held hostage to individual developer whims. Using a language is not about just the technical merits, it is also about the community. If the community stands by silently when certain developers (despite how "nice" they seem) impose their will -- contravening decades of UX standards and best practices -- in an arbitrary and capricious manner, and refuse to listen to repeated pleas by the users to at least give them a configuration option to choose the output method, then I think there's a deeper issue there, and I won't invest any time in a language where the general prevailing attitudes of people in charge are degenerative and harmful to the long term viability of the language. I've been around the block long enough to recognize such things as I've lived through some of these in other language communities. Just look at how LISP destroyed itself.
@@laalbujhakkar I understand what you said, and it does make some sense. I have never used Pluto - the Jupyter integration was good enough and honestly, the repl of Julia is good enough for most prototyping. As for the UI design choices, I was looking into an issue on the Pluto GitHub issue, and it was honestly a mix bag of emotions - but it is really an ass backward way to not include an option to choose between top and bottom output. I wholeheartedly agree. As for symbols, this is where I kind of disagree. One of the main highlight of Julia is that it is more tailored for the scientific community than anyone else. It replaces the idea using python+ compiled language for performance gain paradigm which is so prevalent in the scientific community. And most often, what we would do is reproducing/ translating academic paper into libraries. To me, and I am sure it is the case of everyone who does this - the existence and support of mathematical symbols with its intended meaning makes this whole experience more enjoyable. Imo it is more clean and elegant. So it is a design choice by the Julia community to target those relevant audience who finds meaning in having those symbols. As someone said in a blog post - Julia is designed and maintained by academic "programmers". The lack of professional programming design choices are clear - but that is something we can improve upon.
It's not really quirky to use η for the learning rate, it's the symbol that has been used for the learning rate in the papers for a long time. Julia supports unicode symbols, there is nothing wrong with using them when it makes sense (in this case, it does). The symbol "η" is a lot shorter than "learning_rate" and more descriptive than the potentially ambiguous "lr". If anyone is confused about what η means in this context, the docs are always easy to get to in Julia. Frankly, I really don't get what you're on about. If any language is needlessly opinionated, it's Python. If you have a problem with Pluto.jl, that's one package and not the whole language. My experience with Pluto.jl has been much more enjoyable than the bloated mess that is Jupyter. Julia is really not "quirky", the community is very pragmatic from what I've seen. The Julia community is less quirky than, say, the Rust community. Julia is principled where it makes sense, and pragmatic where it makes sense. If it was a "big idea" language, it wouldn't be multi-paradigm.
@@laalbujhakkar The whole output above or below the cell issue in Pluto.jl is just a matter of opinion, though I do agree it should be configurable. Pluto.jl didn't have things for a long time I wanted, that I thought would never be added, but eventually were. For example, being able to open a notebook without everything immediately running. So I don't know for certain that the feature you want won't be eventually added as well. Whether the output of a cell is above or below it just isn't that big of a deal to me, I don't think it has anything to do with "decades of UX standards and best practices". It's just your preference vs someone else's. Neither is objectively correct. Also, you don't seem to realize you don't need to use Pluto.jl. Jupyter is well supported as you well know, there is no "standard notebook platform" for Julia. The idea of one monolithic thing being "the standard" is a Pythonic and anti-Unix way of thinking that is best abandoned in the Julia sphere. Julia is more about composible and extensible code. It's just that many prefer the lightweight and unbloated Pluto.jl. It is nowhere close to the only serious option. In fact, Pluto.jl was originally made explicitly for teaching purposes and not as a scientific notebook thing. It just happened to evolve into a scientific notebook tool because people like it.
Invaluable insights, thanks a lot for these podcasts!
Gracias. Muy bueno el contenido. Me llamó la atención el revuelo que causa el uso de letras griegas. Yo lo veo con simpatía por la estética que aproxima lo escrito a lápiz y papel en matemáticas y la programación. Entiendo que Edelman es matemático, co-creador de Julia. Podría ser su impronta. Preguntémonos por la deuda de la informática a las matemáticas. Es tan poco el pago con usar la letra eta o cualquier otra del alfabeto griego. Además, es una pequeña muestra de cultura general reconocer esos bellos caracteres que ayudan a comprimir conceptos abstractos con sentido.
I’m sorry I really want to like Julia but there’s some eccentric quirkiness in this community which is a turn off for me. This whole “eta” symbol thing is an example of that. Another example is Pluto, where the output shows above the cell and the developer is super resistant to a plethora of users begging him for years to give them an option to change this but he refuses to listen and all of Julia community stands behind him and this shows that there is this weird quirkiness which will eventually not be a good thing and i don’t want to invest any time in an ecosystem that actively ignores its users for the sake of “opinionated ness”
So you don't want to learn a language because of has a weirded symbol in it (?), And an editor, which you are under no obligation to use ( like really, you can use any editor), has some developer with strong opinions? Have you looked into why Julia is different as a language, what it can offer ? Sure, I am on the fence about Julia as well, I have python stockholm syndrome - but one would be really shortsighted to just ignore a language because "it didn't feel good when I looked at it".
@@f3arbhyTL;DR: Julia seems like a really nice language. The community is a little too nice and that usually becomes a breeding ground for sociopaths and capricious techbros; something which eventually runs the whole project into the ground.
I think you should re-read my comment carefully. My problem is with the attitudes, not with the language. One, the community is too permissive and "nice" for potential bad actors who act in the name of "innovation and opinionated-ness". Use of these symbols is a gimmick and should not be encouraged. It is also an equity issue. A text based source file is more accessible to a larger audience. I don't want to make my variable names emojis either, for similar reasons. Not being able to use fancy math symbols is NOT what's holding Julia back tbh.
The second criticism is also about community and certain developers being disrespectful towards the users. This is the case of Pluto.jl where despite decades of convention of putting output under the input (every single interactive program out there,) the developer (who seems like a very nice and quiet person btw) arbitrarily decided to put the output _above_ the cell. This causes all kinds of issues when it comes to UX. He could've given users the option to configure this, but no, he forced this "opinion" on everyone without so much as a fig leaf of a consultation process. The Julia community, despite this anti-social and disrespectful behaviour by the developer, continues to support this choice meekly and without protest (spinlessly would be too strong a word.)
Pluto is not "an editor" btw, and appears to be destined to become the standard notebook platform for Julia. So, it's not really a personal choice for long when Julia community will be spending all its time improving Pluto instead of making Julia related enhancements to Jupyter (which ironically, was there first to support Julia , the "Ju" in the name represents Julia btw) . If I want to work with Julia in data-science, then I have to deal with Pluto and the (frankly, boneheaded and capricious) decisions made by one person without any community oversight. I refuse to be held hostage to individual developer whims.
Using a language is not about just the technical merits, it is also about the community. If the community stands by silently when certain developers (despite how "nice" they seem) impose their will -- contravening decades of UX standards and best practices -- in an arbitrary and capricious manner, and refuse to listen to repeated pleas by the users to at least give them a configuration option to choose the output method, then I think there's a deeper issue there, and I won't invest any time in a language where the general prevailing attitudes of people in charge are degenerative and harmful to the long term viability of the language.
I've been around the block long enough to recognize such things as I've lived through some of these in other language communities. Just look at how LISP destroyed itself.
@@laalbujhakkar I understand what you said, and it does make some sense. I have never used Pluto - the Jupyter integration was good enough and honestly, the repl of Julia is good enough for most prototyping. As for the UI design choices, I was looking into an issue on the Pluto GitHub issue, and it was honestly a mix bag of emotions - but it is really an ass backward way to not include an option to choose between top and bottom output. I wholeheartedly agree.
As for symbols, this is where I kind of disagree. One of the main highlight of Julia is that it is more tailored for the scientific community than anyone else. It replaces the idea using python+ compiled language for performance gain paradigm which is so prevalent in the scientific community. And most often, what we would do is reproducing/ translating academic paper into libraries. To me, and I am sure it is the case of everyone who does this - the existence and support of mathematical symbols with its intended meaning makes this whole experience more enjoyable. Imo it is more clean and elegant. So it is a design choice by the Julia community to target those relevant audience who finds meaning in having those symbols.
As someone said in a blog post - Julia is designed and maintained by academic "programmers". The lack of professional programming design choices are clear - but that is something we can improve upon.
It's not really quirky to use η for the learning rate, it's the symbol that has been used for the learning rate in the papers for a long time. Julia supports unicode symbols, there is nothing wrong with using them when it makes sense (in this case, it does). The symbol "η" is a lot shorter than "learning_rate" and more descriptive than the potentially ambiguous "lr". If anyone is confused about what η means in this context, the docs are always easy to get to in Julia.
Frankly, I really don't get what you're on about. If any language is needlessly opinionated, it's Python. If you have a problem with Pluto.jl, that's one package and not the whole language. My experience with Pluto.jl has been much more enjoyable than the bloated mess that is Jupyter. Julia is really not "quirky", the community is very pragmatic from what I've seen. The Julia community is less quirky than, say, the Rust community. Julia is principled where it makes sense, and pragmatic where it makes sense. If it was a "big idea" language, it wouldn't be multi-paradigm.
@@laalbujhakkar The whole output above or below the cell issue in Pluto.jl is just a matter of opinion, though I do agree it should be configurable. Pluto.jl didn't have things for a long time I wanted, that I thought would never be added, but eventually were. For example, being able to open a notebook without everything immediately running. So I don't know for certain that the feature you want won't be eventually added as well. Whether the output of a cell is above or below it just isn't that big of a deal to me, I don't think it has anything to do with "decades of UX standards and best practices". It's just your preference vs someone else's. Neither is objectively correct.
Also, you don't seem to realize you don't need to use Pluto.jl. Jupyter is well supported as you well know, there is no "standard notebook platform" for Julia. The idea of one monolithic thing being "the standard" is a Pythonic and anti-Unix way of thinking that is best abandoned in the Julia sphere. Julia is more about composible and extensible code. It's just that many prefer the lightweight and unbloated Pluto.jl. It is nowhere close to the only serious option. In fact, Pluto.jl was originally made explicitly for teaching purposes and not as a scientific notebook thing. It just happened to evolve into a scientific notebook tool because people like it.
Thank you so much for mentioning TruthTables.jl in this episode!
Parabéns!!! Show esse pacote criado por vocês.