Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove ref to Python in language similarities #11021

Closed
wants to merge 1 commit into from

Conversation

fubuloubu
Copy link

I was looking at the ethereum.org website, and noticed it said "Solidity is inspired by C++, Python and JavaScript" and I got to thinking to myself "where's the Python influence?"

I think most people agree that Solidity has really heavy influence from Javascript and C++, but I really don't see the Python. It looks like this change was introduced from this commit, which doesn't really explain where it came from either: 03b3faa

Feel free to accept or reject, it just causes me a little cognitive dissonance to see it listed as an influence since I definitely don't think of Solidity as having much Python influence.

@hrkrshnn
Copy link
Member

hrkrshnn commented Mar 1, 2021

There is a comment about the connection to python: #3195 (comment)

@leonardoalt
Copy link
Member

leonardoalt commented Mar 1, 2021

There is a comment about the connection to python: #3195 (comment)

I guess considering this it's more similar to Python than JS

@fubuloubu
Copy link
Author

Looks like I am not the only one who finds the comparison confusing #3195 (comment)

Responding to @chriseth's comment however:

  1. C3 linearization is an algorithm for resolving inheritance structuring that is in use in many languages, and was only made popular by Python (https://en.wikipedia.org/wiki/C3_linearization). Reusing an parsing algorithm from another language is part of language design, the syntax of inheritance is very different here.
  2. How Python implements decorators is very different than how Solidity enables them, which works more like a compiler macro. While similar in concept, the syntax of modifers is very different here.

I won't make this molehill into a mountain, but if we had to write down every language we borrowed a concept from, you'd have a list of "inspired by" quite a few levels deep. I think most people look at Solidity and see Javascript and then C++. These are docs casually per-viewed by new developers, not a rigorous taxonomy meant for hardcore programming language aficionados.

@leonardoalt
Copy link
Member

@fubuloubu how exactly do you see JavaScript in Solidity? To me that's the most confusing part here.

@leonardoalt
Copy link
Member

@fubuloubu It looks like you're simplifying all these languages to their syntax, and whether they use indentation for scoping or not.

@chriseth
Copy link
Contributor

chriseth commented Mar 1, 2021

@fubuloubu sure, the syntax is rather different from Python's but I would think semantic influence is just as important as syntactic. Even if python's decorators are very different, they actually were the inspiration, and the same for inheritance. While we are listing language aspects there were inspired by python, we should also include the slice notation. I don't know who invented it, but it was suggested during a design discussion because the people designing Solidity knew it from Python.

@fubuloubu
Copy link
Author

@fubuloubu It looks like you're simplifying all these languages to their syntax, and whether they use indentation for scoping or not.

You and I care about semantics and language design. 99% of the people reading your docs don't.

@fubuloubu
Copy link
Author

fubuloubu commented Mar 1, 2021

@fubuloubu sure, the syntax is rather different from Python's but I would think semantic influence is just as important as syntactic. Even if python's decorators are very different, they actually were the inspiration, and the same for inheritance. While we are listing language aspects there were inspired by python, we should also include the slice notation. I don't know who invented it, but it was suggested during a design discussion because the people designing Solidity knew it from Python.

Python is the inspiration for a lot of language designers, because it is successful language and is very comfortable and easy to use. You can look at languages like Rust and see the influence of Python quite clearly, that is the nature of language design: constantly borrowing and improving and moving in a different direction.

My point here is entirely about understanding your audience for your docs. If most people raise an eyebrow seeing "Python" when they're quickly skimming over your docs, perhaps it is not helping any to mention it.

If I were to list all of the influences to Vyper, I would of course mention Python first, but then I'd have to mention Rust, Solidity, Scala, Nim, and about a half dozen other languages we've lifted ideas from over the years. It's interesting to us as programming language designers to know the taxonomy, but we just have the "Python" in our docs because that is all most people see.

@fubuloubu
Copy link
Author

Anyways, feel free to close this PR if you do not want to make the change.

@chriseth
Copy link
Contributor

chriseth commented Mar 1, 2021

Ok, understood!

@chriseth chriseth closed this Mar 1, 2021
@fubuloubu fubuloubu deleted the patch-1 branch March 1, 2021 18:01
@axic
Copy link
Member

axic commented Mar 1, 2021

It seems the main argument here is that "influence" would register as "syntax" in the mind of the "average reader". Perhaps the better way to resolve is to make that distinction: #11025.

@axic
Copy link
Member

axic commented Mar 1, 2021

Regarding the argument that "Solidity was influenced by C++, Python and JavaScript" suggests the syntax is Python-esque: why would that sentence suggest it is Python-esque and not C++-esque, given C++ is the first in the list? Also two out three in the list are curly-bracket languages, why does Python takes precedence over them in influencing the syntax?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants