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

[alex23]

On Apr 3, 2:55 pm, Nathan Rice <nathan.alexander.r... at gmail.com>
wrote:
> I don't care what people do related to legacy systems.

And that's what earns you the label 'architecture astronaut'. Legacy
systems are _part_ of the problem; it's very easy to  hold to a purist
approach when you ignore the bulk of the domain that causes the
issues. There's _never_ going to be an InfoTech3k where we just stop
supporting older code.

> I do care about programmers that are too lazy to
> learn, and would be happy to ignore the fact that programming is hard
> for most people to learn, so they can continue not learning.  Those
> programmers are scumbags.

Wait, what?

Programmers are both "too lazy to learn" and yet somehow happy that
the skills they've acquired are "too hard for most people to learn"?
So how did they learn them?

And they're also somehow "lazy" because they have to learn multiple
languages to be effective,  rather than one mythical ur-language?

In my 20 years as a software developer, I have _never_ encountered
anyone trying to deliberately expand the knowledge gap. This isn't a
priesthood.

> Just don't let me hear you complaining because some syntax is not "C
> like" enough for you.  Whenever I hear that I want to strangle the
> self-serving 'tard that wrote it.  When I see people defending "C
> like" syntax as optimal or somehow much more expressive, that makes me
> doubly irritated.  These are the people who are selfishly defending
> the status quo because they're invested.

Syntax is never the issue, it's the deeper semantics. Is the scoping
of one C-like language the same as C? How does it differ? Why does it
differ? Is the difference a fundamental implementation issue that you
really need to know before you actually grok the language? Are
functions first-class objects? Are they actual objects or some kind of
magical stub? Can you extend those objects with properties? etc etc

Every language tackles _so many_ things differently. It's not lazy to
say that you prefer something to resemble/be based on a language you
have experience with, that's human nature. If you're insistent that
your non-typical syntax is so much better, the onus is on you to prove
it, not to insist that the lack of uptake is 'laziness'.

And one again: code is _communication_. Not having to understand new
optimal patterns for every single language is a Good Thing.

> Don't try to delude people that our modern
> ALGOL derivatives are the best possible way to model knowledge
> (including process knowledge) to a computer, because that is a lie.

Um, okay, I'll stop doing that...not that I've ever seen anyone make
that claim...

A large part of what makes languages popular _is their popularity_. In
many ways, ALGOL is English to your hypothetical language's Lojban.
You can argue until the end of time for the superiority of Lojban due
to it's lack of ambiguity, it's not going to affect it's acquisition
at all.

> You should be able to live in your reality if you want, as long that
> doesn't impinge on others.  Of course, if you disagree on basic
> grammar, then I would have to ask you, do you disagree about English
> grammar, or have you accepted it so that you can communicate with
> people?  This is why I advocate following English grammar closely for
> syntax - people have accepted it and don't make a big deal, and it is
> the way we represent information already.

And programmers have accepted ALGOL and don't etc

The idea of coding in English just fills me with horror and dread.
COBOL died for a reason.

> > You're arguing for a top-down centralised approach to language
> > development that just will _never_ exist, simply because it cannot. If
> > you don't accept that, I believe there's a fascinating fork called
> > "Python 4000" where your ideas would be readily adopted.
>
> You completely missed my point.  In fact, my argument is for a bottom
> up approach, with a meeting point which is much closer than the
> machine code which is currently used.

You missed my point; I was referring more to the _adoption_ of your ur-
language. The only way to push this is to force it on everyone.

> However you want to represent
> it, the knowledge is the same, and that is what matters.  We need to
> get past the idea of different, incompatible languages, and settle on
> a common knowledge representation format that underlies all languages,
> and is compatible.  If you want to make an alex23 DSL where up is down
> and inside is upside down, go for it, just as long as it is
> represented in a sensible set of semantic primes that I can transform
> to whatever reality I want.

So effectively for any given project I'd need to know: the underlying
representation (because we have to be able to discuss _something_ as a
team), my DSL, how my DSL transforms to the underlying representation,
and to be really effective, every team member's DSL and how it
transforms. Because _no one_ on my team works alone, debugs alone 100%
of the time.

How do I share cool patterns? Show them the underlying representation?
How do they copy them? Back trace the representation to their own DSL
and reimplement? What if the elegance in my DSL is a nightmare to
construct in a peer's? How does my code look to them? Does it even
include my identifiers & comments or is the representation too low
level for that? How do they debug it?

How do we learn? How do we share?