Number of languages known [was Re: Python is readable] - somewhat OT
showell30 at yahoo.com
Fri Mar 30 04:19:23 CEST 2012
On Mar 29, 9:42 am, Devin Jeanpierre <jeanpierr... at gmail.com> wrote:
> On Thu, Mar 29, 2012 at 10:03 AM, Chris Angelico <ros... at gmail.com> wrote:
> > You can't merge all of them without making a language that's
> > suboptimal at most of those tasks - probably, one that's woeful at all
> > of them. I mention SQL because, even if you were to unify all
> > programming languages, you'd still need other non-application
> > languages to get the job done.
> Not really. You can turn SQL (or something equivalent) into a subset
> of your programming language, like C# does with LINQ, or like Scheme
> does with macros.
I'm glad your moving the discussion away from the fake debate between
"diversity" (good) and "one-language-fits-all" (horribly naive at
best, evil at worse).
Of course, there's a middle ground, where (some degree of) language
unification is a completely sane goal, at least worthy of discussion.
SQL is a well-established lingua franca for describing relationships
between sets, or relational algebra. General-purpose languages like
C#, Scheme, and Python are well suited to subsuming SQL semantics,
and, in fact, they already do, but sometimes they do it a way that's
unnecessarily foreign to people who quite easily grok the basics of
SQL. The extreme position for language unification would be that
Python completely subsumes SQL under its umbrella as first-class
syntax. I don't necessarily advocate for that, but I think it's an
interesting thought experiment to ask why it doesn't. Just to be
clear, I'm talking about SQL as a mechanism to transform sets within
Python itself, not external RDMBS engines (although first-class SQL
integration could also be useful for that as well).
> On the other hand, even similar languages are really hard to run in
> the same VM: imagine the hoops you'd have to jump through to get
> libraries written in Python 2 and 3 to work together.
My take on Python 2 vs. Python 3 is that it's simply a tactical
program to get people to upgrade to Python 3. The fact that the two
languages can't run on the same VM doesn't really bother me.
> With that in mind, the interesting languages to "merge" aren't things
> like SQL or regular expressions -- these are so easy to make work with
> programming languages, that we do it all the time already (via string
> manipulation, but first-class syntax would also be easily possible).
> The hard problems are when trying to merge in the semantics of
> languages that only "make sense" because they have drastically
> different expectations of the world. The example that comes to mind is
> Haskell, which relies incredibly strongly on the lack of side effects.
> How do you merge Haskell and Python?
My view on Haskell and Python is that they should stay alive as
competing paradigms. I think you're making a useful distinction
between Haskell and SQL. Neither language is well integrated with
Python. With Haskell, I think it's for good reason. With SQL, I
don't quite understand the status quo (beyond the obvious reasons--
maybe we're just not there yet).
> I guess what I really want to say is that the world looks, to me, to
> be more optimistic than so many people think it is. If we wanted to,
> we could absolutely take the best features from a bunch of things.
> This is what C++ does, this is what Scheme does, this is what D does.
> They sometimes do it in different ways, they have varying tradeoffs,
> but this isn't a hard problem except when it is, and the examples you
> mentioned are actually the easy cases. We can merge Python and C,
> while keeping roughly the power of both, it's called Cython.
I love the fact that C dominates all other languages at its level of
abstraction. I wish this were the case one level up, where you still
solving the same classes of problems. Don't get me wrong--I'm all for
diversity; I'm not saying we should arbitrarily kill off languages,
etc. I'm just saying that there will be *some* benefit when a clear
victor emerges, and hopefully that will be Python 3. Whatever
language emerges as the victor, it will probably subsume some of the
best features of the conquered. To a degree that has already
> We can
> merge Python and PHP, in that PHP adds nothing incompatible with
> Python technically (it'd be a lot of work and there would be many
> tears shed because it's insane) -- but Python Server Pages probably
> add the feature you want.
PHP is a language that I wish would die off quickly and gracefully. I
feel like the good things of PHP have already been subsumed into the
ecosystems of stronger programming languages (including Python).
> We could merge SQL and Python, arguably we
> already do via e.g. SQLAlchemy's query API (etc.) or DBAPI2's string
> API. These can all becomes subsets of a language that interoperate
> well with the rest of the language with no problems. These are
> non-issues: the reasons for not doing so are not technical, they are
> political or sociological (e.g., "bloat the language", "there should
> be one obvious way to do it", "PHP's mixing of business logic with
> presentation logic is bad", etc.)
The way that I view the world now is that we have lots of languages
that don't interoperate well.
To some degree, it's a non-problem of course. The world has many
problems to solve, and it's a good thing that we have a diversity of
languages to tackle those problems. I get it.
Some languages don't interoperate for purely technical reasons, and it
would be foolish to fight a losing battle to force square pegs into
round holes. I get that, too.
Some non-compatible languages coexist with each other for political
reasons that are completely legitimate. Even for the same problem
domains, there are strongly competing philosophies on fundamental
programming concepts, such as mutation, expressiveness, etc. I get
Finally, though, there is a bunch of *non-essential* diversity, or at
least a lot of options that serve more to confuse than empower.
Diversity is great, but some level of convergence should be the end
game. Diversity is the engine behind progress, of course, but the
fuel doesn't always burn clean.
> There _are_ times when this is technical, and there are specific areas
> of this that have technical difficulties, but... that's different, and
> interesting, and being actively researched, and not really impossible
> I don't know. This is maybe a bit too rant-y and disorganized; if so I
> apologize. I've been rethinking a lot of my views on programming
> languages lately. :) I hope at least the links help make this
> interesting to someone.
I enjoyed hearing your thought process. Thanks!
More information about the Python-list