M
Mark Lawrence
Because it's written in (say) C++ in an object orientated style, so by
rewriting it using assembler in a procedural style it will be fixed?
Python was designed (was Re: Multi-threading in Python vs Java)
Because it's written in (say) C++ in an object orientated style, so by
rewriting it using assembler in a procedural style it will be fixed?
C
Chris Angelico
Certainly not. The solution is to use FORTRAN and functional style.
That should be obvious!
ChrisA
S
Steven D'Aprano
I don't know who you are responding to, or what they said to give you the
impression that they believe that all differences between languages is
*merely* syntactic sugar, but I certainly don't believe that.
In fact, given that you haven't quoted anyone, I'm tempted to call it a
straw-man, except you don't appear to be arguing against anyone, so there
is nobody it could be a straw-man of
M
Metallicow
Python is the Best!
P
Peter Cacioppi
Specifically the following seems so misguided as to be deliberate trolling.
"One of the reasons multiple languages exist is because people find that
useful programming idioms and styles are *hard to use* or "ugly" in some
languages, so they create new languages with different syntax to make
those useful patterns easier to use."
This is just profoundly wrong. If anything, different languages strive to maintain common syntax. You can see foo.bar() as legal syntax meaning essentially the same thing in C++, C#, Java and Python (and likely quite a few other languages). There is NOT a deliberate effort to create new syntax just for aesthetics, there is the exact opposite. There is a deliberate effort to maintain consistency with the syntax of pre-existing languages.
Languages sprout up for a variety of reasons. C++ has very significant functionality that doesn't exist in C. Java/C# can say the same thing to C++, and Python to all of the others.
Please lets not pretend that it's all just ballpark equivalent facades plastered on top of a Turing machine. New languages pop up to automate boring and repetitive tasks that chew up your time in older languages. That's the trend - abstractions automating repetitious and error-prone tasks.
Not "hey, this syntax isn't too my taste, I'm going to toodle it up".
"One of the reasons multiple languages exist is because people find that
useful programming idioms and styles are *hard to use* or "ugly" in some
languages, so they create new languages with different syntax to make
those useful patterns easier to use."
This is just profoundly wrong. If anything, different languages strive to maintain common syntax. You can see foo.bar() as legal syntax meaning essentially the same thing in C++, C#, Java and Python (and likely quite a few other languages). There is NOT a deliberate effort to create new syntax just for aesthetics, there is the exact opposite. There is a deliberate effort to maintain consistency with the syntax of pre-existing languages.
Languages sprout up for a variety of reasons. C++ has very significant functionality that doesn't exist in C. Java/C# can say the same thing to C++, and Python to all of the others.
Please lets not pretend that it's all just ballpark equivalent facades plastered on top of a Turing machine. New languages pop up to automate boring and repetitive tasks that chew up your time in older languages. That's the trend - abstractions automating repetitious and error-prone tasks.
Not "hey, this syntax isn't too my taste, I'm going to toodle it up".
M
Metallicow
Are you suggesting Advertising is the Best language there is....?
# After many years, I agree not, but what to may...
def If I do Something do, you not react():
IsMySyntaxNotCorrect()
CanINotCorrectMyGrammaticalMistakesAndSeekAcceptance():
# The most arguable language is arguably the most important to discuss.
# Everyone is of the same basic mindset here.
# 16 years of reading everyone elses words hasn't changed my view.
# I make it real, and sometime I don't like it either.
# Actions speak loader than comments.
language = python
benefits = failures
failures = newTerminology
newTerminology = newIdeas
newIdeas = benefits
Sometimes when the whole world doesn't complain about your newTerminology, they are trying to say let it live, but more often they say "leave it alone". And Vise Versa.
But more often they complain about the readability.
Or the Indenation.
Or the style of a personal poem.
Or how the next person should learn it best.
I read a indented book first, then I read a un indented book. Sir.
go figure....
nowpost()
# After many years, I agree not, but what to may...
def If I do Something do, you not react():
IsMySyntaxNotCorrect()
CanINotCorrectMyGrammaticalMistakesAndSeekAcceptance():
# The most arguable language is arguably the most important to discuss.
# Everyone is of the same basic mindset here.
# 16 years of reading everyone elses words hasn't changed my view.
# I make it real, and sometime I don't like it either.
# Actions speak loader than comments.
language = python
benefits = failures
failures = newTerminology
newTerminology = newIdeas
newIdeas = benefits
Sometimes when the whole world doesn't complain about your newTerminology, they are trying to say let it live, but more often they say "leave it alone". And Vise Versa.
But more often they complain about the readability.
Or the Indenation.
Or the style of a personal poem.
Or how the next person should learn it best.
I read a indented book first, then I read a un indented book. Sir.
go figure....
nowpost()
R
rusi
The same could be said for this below… but…
… but I am not going to do so.
Instead I reiterate:
The whole point of studying programming language semantics is just so that we can distinguish between the 'just toodle it up' differences and the bigger ones.
And so projects that take the Alice' Humpty Dumpty attitude:
"When I use a word," Humpty Dumpty said in rather a scornful tone, "it means just what I choose it to mean -- neither more nor less."
should be treated with suspicion in correspondence with the scorn.
R
Roy Smith
You missed the ever-so-special Objective C syntax:
[object method arg1 withSomething arg2 withSomethingElse arg3]
I'm sure I got that slightly wrong. I don't do Objective C, and my eyes
glaze over every time I have to read it.
And, of course, there's Postscript (stolen from Forth) stack syntax:
arg3
arg2
arg1
function
although it's more than just syntax; it's a totally different program
architecture. A lot of people don't realize that PostScript is not just
a printer file format, it's a real language with functions, variables,
loops, and all that good stuff.
S
Steven D'Aprano
As the author of that quote -- and I wonder why you're dropping
attributions -- I can assure you I am not trolling.
Why do you think that my comment is misguided? If you don't believe that
people write new languages because they are dissatisfied with the
existing ones, why do you think they write new languages?
I think that my comment should be uncontroversial. At least some
languages were invented because the author was dissatisfied with some
existing language and wanted a "better" language. Bjarne Stroustrup wrote
C++ to be a better C supporting data abstraction, OOP and generic
programming, which were too hard to do right in C.
http://www.stroustrup.com/bs_faq.html
Niklaus Wirth wrote Pascal because he wanted a *simpler* language than
Algol -- he famously walked out of one of the Algol design conferences
because he disagreed with the direction they were taking -- and then he
followed Pascal with Modula 2 and Oberon to be "better" Pascals, e.g.
adding support for parallisation, which was hard to do in Pascal.
Bertrand Meyer invented Eiffel because he liked the style of Ada and the
OOP of Stimula, and wanted to make Design By Contract easier to use.
With respect, I think that demonstrates a lack of experience with
programming languages. What "common syntax" do you perceive between
languages such as these?
- Hypertalk
- Forth
- Pascal
- Lisp
- Haskell
- bash
- Inform 7
- Prolog
All of these are real languages; none of them are joke languages. If you
aren't at least aware of their existence, and the general "feel" of their
syntax, then you aren't qualified to comment on programming language
syntax. The world is much bigger than just the C family of languages.
Of course, languages tend to resemble the languages that most influenced
them, and there are distinct "family resemblances", e.g. XTalk languages,
Algol-based languages, etc. Some pairs of languages are closer than
others, e.g. both Hypertalk and Haskell would accept "x + 1" as a valid
expression to evaluate one more than x, whereas in Forth it means
something completely different.
Perhaps you ought to re-read my earlier comment. I did not say that
people "create new syntax just for aesthetics". I said that one reason
for making a new language (there may be more than one!) is if a useful
idiom or design pattern is *hard to use* in a language. Parallel
processing is hard in Pascal, so Wirth created Oberon; OOP is hard in C,
so Stroustrup created C++.
Often languages aren't just "another language, plus foo" for some foo.
Java isn't just C-with-garbage-collection-and-objects, but James Gosling
invented Java because he wasn't happy with the level of support for
garbage collection and OOP in existing languages. They're not just gluing
"one more feature" on top of an existing language. Here is Rob Pike's
explanation for why Go was invented:
http://commandcenter.blogspot.com.au/2012/06/less-is-exponentially-
more.html
Short version: they wanted a language where concurrency was easy, and
were dissatisfied with C and C++. Pike tried to do concurrency in C++ and
failed:
P
Peter Cacioppi
"but it's "ugly", by which I mean it is hard to use, error prone, and not
easily maintained."
OK, I see the problem. What you call "ugly" is really just objectively bad.
Ugliness and beauty are subjective qualities that can't really be debated on a deep level. Like I mentioned in other post, I find the lazy-evaluation idiom that avoids __init__ initialization of the stored value to be pretty,so I code it that way (in C#, in Java, in Python, even though the syntax is slightly different in each one).
But I wouldn't say that using the __init__ (or the constructor) to initialize the lazy variable is "hard to use, error prone, not easily maintained". I would say it's ugly (or less pretty), and that it does seem to have some minor functional drawbacks. But I wouldn't make a big deal out of it if a colleague wanted to code it that way.
Looking at Fortran, C, C++, C#, Java and Python (the languages I have done large bodies of work in, and, not coincidentally, some of the most popular languages ever, since I like to get paid and that requires going with the flow a little) it's easy to see that a lot of cosmetic things are maintained(i.e. foo.bar(), k += 1, etc) but some important, conceptual things are improved in profound ways. So a colleague that was advocating coding a project in C when Python would work ... yeah, that's a deal breaker, we're going to lock horns over that.
I wasn't going to ramble on like this but I think you, Stephen, were the one encouraging me to step into the flames.
easily maintained."
OK, I see the problem. What you call "ugly" is really just objectively bad.
Ugliness and beauty are subjective qualities that can't really be debated on a deep level. Like I mentioned in other post, I find the lazy-evaluation idiom that avoids __init__ initialization of the stored value to be pretty,so I code it that way (in C#, in Java, in Python, even though the syntax is slightly different in each one).
But I wouldn't say that using the __init__ (or the constructor) to initialize the lazy variable is "hard to use, error prone, not easily maintained". I would say it's ugly (or less pretty), and that it does seem to have some minor functional drawbacks. But I wouldn't make a big deal out of it if a colleague wanted to code it that way.
Looking at Fortran, C, C++, C#, Java and Python (the languages I have done large bodies of work in, and, not coincidentally, some of the most popular languages ever, since I like to get paid and that requires going with the flow a little) it's easy to see that a lot of cosmetic things are maintained(i.e. foo.bar(), k += 1, etc) but some important, conceptual things are improved in profound ways. So a colleague that was advocating coding a project in C when Python would work ... yeah, that's a deal breaker, we're going to lock horns over that.
I wasn't going to ramble on like this but I think you, Stephen, were the one encouraging me to step into the flames.
R
rusi
You continue to not attribute quotes.
What user agent/group are you using?
C
Chris Angelico
I don't know what headers come through on comp.lang.python, but on the
mailing list, I can see some clear fingerprints that it's the one so
many of us hate...
Message-ID: <[email protected]>
Complaints-To: (e-mail address removed)
Though I don't think the abuse address would do much with complaints
regarding citation courtesy
ChrisA
L
Lele Gaifax
Roy Smith said:
The actual syntax would be
[object method: arg1 withSomething: arg2 withSomethingElse: arg3]
and IMHO once you train your eyes the result is very readable, and
closely resembles Python's keywords (and I took advantage of the
similarity when I enjoyed developing PyObjC
ciao, lele.
P
Peter Cacioppi
rusi said :
"You continue to not attribute quotes. "
Sorry, I'll try to be better about this all-important aspect of sharing knowledge.
"You continue to not attribute quotes. "
Sorry, I'll try to be better about this all-important aspect of sharing knowledge.
S
Skip Montanaro
Steven said:
And even within that space, the original authors of C left plenty of
room for debate/improvement. In at least two dimensions (object
oriented programming, and memory management), various C descendants
have tried multiple different approaches to solve those problems.
Skip
S
Steven D'Aprano
I don't get how to map that to Python's syntax.
object.method(arg1, arg2, arg3)
What are "withSomething" and "withSomethingElse"?
N
Ned Batchelder
The Python would be:
object.method(arg1, withSomething=arg2, withSomethingElse=arg3)
--Ned.
G
Gregory Ewing
Steven said:
It's roughly morally equivalent to
object.method(arg1, withSomething = arg2, withSomethingElse = arg3)
But there are several reasons why it's not really equivalent
to that. PyObjC actually maps it to
object.method_withSomething_withSomethingElse_(arg1, arg2, arg3)
which is very close to what Objective C is doing under the hood.
G
Grant Edwards
FWIW, the Objective C syntax and semantics are both based on Smalltalk
(which, IMO, is a somewhat easier to understand than OC).
L
Lele Gaifax
Gregory Ewing said:
Right (IIRC, I initially used a double underscore as separator), and
that's because in ObjC the method
[object method:arg1 withSomething:arg2 withSomethingElse:arg3]
is completely unrelated to
[object method:arg1 withSomethingElse:arg3 withSomething:arg2]
I wish I had a way, at the time (we were in the 1.x era), to use
something like OrderedDict to carry around the kwargs argument of a
function/method, that could let me use a nicer syntax... I did even
cook-up a quick&dirty patch, but being too biased toward the "dirty"
side it did not go too far.
ciao, lele.