Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #22349 > unrolled thread

Re: Number of languages known [was Re: Python is readable] - somewhat OT

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Number of languages known [was Re: Python is readable] - somewhat OT Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-03-29 12:42 -0400
    Re: Number of languages known [was Re: Python is readable] - somewhat OT Steve Howell <showell30@yahoo.com> - 2012-03-29 19:19 -0700
      Re: Number of languages known [was Re: Python is readable] - somewhat OT Tim Chase <python.list@tim.thechases.com> - 2012-04-02 18:28 -0500

#22349 — Re: Number of languages known [was Re: Python is readable] - somewhat OT

On Thu, Mar 29, 2012 at 10:03 AM, Chris Angelico <rosuav@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. The Scheme approach generalizes to programming
languages in general with even some fairly alien semantics (e.g. you
can do prolog using macros and first-class continuations). In fact,
for a more difficult target, I even recently saw an implementation of
Python in Common-Lisp that uses reader macros to compile a subset of
Python to equivalent Common-Lisp code:
http://common-lisp.net/project/clpython/

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. For a more
concrete example, take the attempt to make elisp and guile work
together in guilemacs:
http://www.red-bean.com/guile/notes/emacs-lisp.html

But this has nothing to do with being "suboptimal at most tasks". It's
easy to make a language that can do everything C can do, and also
everything that Haskell can do. I can write an implementation of this
programming language in one line of bash[*]. The easy way is to make
those features mutually exclusive. We don't have to sacrifice anything
by including more features until we want them to work together.

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?

Well, you can't. As soon as you add side-effects, you can no longer
rely on the weak equivalence of things executed eagerly versus lazily,
and the semantics of Haskell go kaput. So the only actual effort (that
I am aware of) to implement side-effects with Haskell *deliberately*
makes mutability and laziness mutually exclusive. Anything else is
impossible. The effort mentioned here is called Disciple, and the
relevant thesis is very fun reading, check it out:
http://www.cse.unsw.edu.au/~benl/papers/thesis/lippmeier-impure-world.pdf

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. 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. 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.)

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
either.

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.

-- Devin

[*] A "language" is really just a set of programs that compile. If we
assume that the set of haskell and C programs are disjoint, then we
can create a new language that combines both of them, by trying the C
(or Haskell) compiler first, and then running the other if that should
fail. This is really an argument from the absurd, though. I just said
it 'cause it sounds awesome.

[toc] | [next] | [standalone]

#22505

On Mar 29, 9:42 am, Devin Jeanpierre <jeanpierr...@gmail.com> wrote:
> On Thu, Mar 29, 2012 at 10:03 AM, Chris Angelico <ros...@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
have Python, Ruby, JavaScript, PHP, Perl, and others essentially
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
happened.

> 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
that.

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
> either.
>
> 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!

[toc] | [prev] | [next] | [standalone]

#22556

> 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).

The one killer feature PHP has to offer over other languages: 
ease of efficient deployment on cheap/free hosting.  When I go to 
deploy Python projects, it ends up either being as slow CGI on 
the cheap/free hosting, or it ends up needing 
WSGI/gunicorn/whatever on a more expensive service (whether 
shared, VPS, or full hardware).

I dream of a day that deploying Python/Django apps is as 
cheap/easy as deploying PHP code.

-tkc

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web