OSDev.org

The Place to Start for Operating System Developers
It is currently Mon Oct 22, 2018 7:57 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 34 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject: Re: Why do I despise python
PostPosted: Tue May 23, 2017 7:32 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 21, 2011 9:47 pm
Posts: 263
Location: Tustin, CA USA
Solar wrote:
Schol-R-LEA wrote:
Solar wrote:
That's why I like sticking to the older languages.


Do I even need to say what I am thinking, here? You, of all people here, should have a better idea of why that are the way they are, and more to the point, how long this approach has been around.


And the next thing that comes up is a Lisp-alike -- the one type of programming language that I never was able to really wrap my head around. ;-)


Lisp is far too parenthetically exuberant for me. I had to use it for one course in college. It made me cross-eyed.

Also, I just can't bring myself to use a language where white-space is a semantic element. On the other side of the spectrum, I've been forced to swallow RPG in my day job due to the hardware I work with, which uses fixed columns as a lexical component.

I'm happy with C.

_________________
Adam

The name is fitting: Century Hobby OS -- At this rate, it's gonna take me that long!
"Sometimes things just don't make sense until you figure them out." -- Phil Stahlheber


Top
 Profile  
 
 Post subject: Re: Why do I despise python
PostPosted: Tue May 23, 2017 8:44 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1341
Location: Athens, GA, USA
Solar wrote:
And the next thing that comes up is a Lisp-alike -- the one type of programming language that I never was able to really wrap my head around. ;-)


S'OK, a lot of people don't get Lisps. They are really weird, as are the people who like them (but you knew that about me already).

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
μή εἶναι βασιλικήν ἀτραπόν ἐπί γεωμετρίαν
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: Why do I despise python
PostPosted: Tue May 23, 2017 9:56 am 
Offline
Member
Member
User avatar

Joined: Thu Nov 16, 2006 12:01 pm
Posts: 7295
Location: Germany
I've "closed in" on functional programming on two different vectors so far -- of course I've written Makefiles (which are, after all, a kind of functional language in themselves). And I've done some Tcl, which -- to my gut feeling -- seems like a nice way to go from "this is just another scripting language" over "what's this, I can overload 'if'?" to "real" functional programming. Only, what I had to do in Tcl I did without really going all the way, syntax-wise, and so I was left with this nagging feeling that I was this close to "getting it".

Ah well. I can do C++ template metaprogramming, and many people don't get that, either. :twisted:

_________________
Every good solution is obvious once you've found it.


Top
 Profile  
 
 Post subject: Re: Why do I despise python
PostPosted: Tue May 23, 2017 11:22 am 
Offline
Member
Member
User avatar

Joined: Wed Jan 06, 2010 7:07 pm
Posts: 792
Eh, if you've done C++ TMP then Lisp holds nothing weird for you. Semantically Lisp is just a typical dynamically-typed language with an idiomatic preference for avoiding mutation, and syntactically it just moves the delimiters around with things like "if (expr) { a } else { b }" vs "(if expr a b)". Its macro system is maybe less error-prone than others you've used, but it's still just a macro system.

All this stuff about Lisp being weird and pure in some pseudo-religious sense is just an affectation at this point.

_________________
[www.abubalay.com]


Top
 Profile  
 
 Post subject: Re: Why do I despise python
PostPosted: Sun May 28, 2017 8:53 am 
Offline
Member
Member

Joined: Wed Nov 18, 2015 3:04 pm
Posts: 321
Location: San Jose San Francisco Bay Area
found it was due to a something of a concept called mutable and immutable types. It explains why it happens, Weird stuff. Still despite it. I am using python just because work requires it.

_________________
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails


Top
 Profile  
 
 Post subject: Re: Why do I despise python
PostPosted: Mon May 29, 2017 8:40 pm 
Offline
Member
Member

Joined: Wed Jul 10, 2013 9:11 am
Posts: 52
The comparisons made between C and Python regarding value/pointers/references aren't really fair here as you are comparing apples to oranges. I myself do not like Python (for various reasons), but I found this in the FAQ:

https://docs.python.org/3/library/copy.html

Quote:
Assignment statements in Python do not copy objects, they create bindings between a target and an object. For collections that are mutable or contain mutable items, a copy is sometimes needed so one can change one copy without changing the other.


Further if you read the documentation on assignment (https://docs.python.org/3/reference/simple_stmts.html) you can see that it really has nothing in common with C.


Top
 Profile  
 
 Post subject: Re: Why do I despise python
PostPosted: Mon Aug 06, 2018 12:21 pm 
Offline
Member
Member

Joined: Wed Nov 18, 2015 3:04 pm
Posts: 321
Location: San Jose San Francisco Bay Area
f*k python
[ggankhuy@bios]$ python
Python 2.7.8 (default, Nov 5 2017, 18:49:13)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = 1
>>> b = a
>>> a
1
>>> b
1
>>> a1 = [100, 200]
>>> b1 = a1
>>> a
1
>>> a1
[100, 200]
>>> b1
[100, 200]
>>>
>>>
>>>
>>> a1 = [100, 200, 300]
>>> a1
[100, 200, 300]
>>> b1
[100, 200]
>>> a1.append(400)
>>> a1
[100, 200, 300, 400]
>>> b1
[100, 200]
>>> b1
[100, 200]
>>> a1
[100, 200, 300, 400]
>>> b1.append(1000)
>>> a1
[100, 200, 300, 400]
>>> b1
[100, 200, 1000]
>>>
>>>
>>> list1 = []
>>> list1.append(100)
>>> list2=list1
>>> list1
[100]
>>> list2
[100]
>>> list1.append(101)
>>> list1
[100, 101]
>>> list2
[100, 101]
>>> quit()

_________________
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails


Top
 Profile  
 
 Post subject: Re: Why do I despise python
PostPosted: Mon Aug 06, 2018 7:13 pm 
Offline
Member
Member

Joined: Mon Jul 25, 2016 6:54 pm
Posts: 135
Location: Adelaide, Australia
15 months later, the basic semantics of a programming language continue to confuse.


Top
 Profile  
 
 Post subject: Re: Why do I despise python
PostPosted: Tue Aug 07, 2018 2:12 am 
Offline
Member
Member

Joined: Thu Jul 03, 2014 5:18 am
Posts: 67
Location: The Netherlands
StudlyCaps wrote:
15 months later, the basic semantics of a programming language continue to confuse.


Yep, and that even despite his "years spent in software industry" as can be seen in his signature.

_________________
My blog: http://www.rivencove.com/


Top
 Profile  
 
 Post subject: Re: Why do I despise python
PostPosted: Tue Aug 07, 2018 12:41 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1341
Location: Athens, GA, USA
To be fair, indirection - which is what this confusion is all about - is damn hard to get without the hinting C and C++ use with the indirection ('*' and '->') and reference ('&') operators. Take a look at P. J. Plauger's 'Programming on Purpose' article 'The Knob on the Back of the Set' for examples of far worse confusions with indirection in Algol-68 (I'll go into more detail on that travesty in a separate thread on the General Ramblings board, as this post is way too long even without it).

But in this case, the problem is that ggodw000 keeps expecting direct operations where they should be expecting indirected ones, because that is all that Python has - and all most languages designed after 1990 have, for that matter.

Maybe it would be less confusing if Python didn't automatically create lists from list literals, or required a new keyword in front of them as in Java or Ruby. I dunno. But it doesn't, and that seems to be what ggodw000 is getting tripped up over.

What is happening here is that the basic semantics of Python objects - regardless of type, and regardless of the implementation - are that of variables as references or pointers to objects, and that objects themselves are independent and anonymous. This is, as I've said before, the same semantics used in Lisp, in Ruby, Java for objects (but not primitive types, damn their eyes for that piece of confusion), and C# (which did the same thing as Java but then added POD structures).

While this set of semantics implies a corresponding implementation, a good compiler will snap the pointers silently for some things to improve efficiency. That's a separate issue, though, and I've already discussed that in this thread.

The point is, the value of the variable itself is hidden, and handled directly by the automatic memory management system. At no point does the variable hold a non-pointer value, at least as far as the visible semantics are concerned.

For a C programmer, you have to imagine all of the variables are pointers, and objects are something which was allocated with malloc() somewhere else (even if it is a literal). Try this: every time you use a variable in a reference semantics language for anything other than assigning its reference to another variable, mentally append a * in front of it. That might help, though I can't promise it will.

So, what that happened is this:

Code:
a  = foo

Variable a now points to a number object with the literal value of one - the fact that the Python interpreter is actually putting that 1 in the memory space of the variable doesn't change the semantics of this, since tagging etc is done underneath the hood and the only way to know the details is with some sort of introspection library, or through an abstraction leak.

Code:
b = a

The reference in variable a is copied to variable b.

In C, this would be (semantically, at least) equivalent to:

Code:
int *a, *b;

a = malloc(sizeof(int));

*a = 1;

b = a;


So now both of them point to the same allocated memory.

Code:
a1 = [100, 200]

Variable a1 is assigned a reference to a list comprised of two object references.

Code:
b1 = a1

The reference in variable a is copied to variable b.

Code:
a1 = [100, 200, 300]

Variable a1 is assigned a reference to a new list comprised of three object references. The original object (which b1 still points to) is unchanged, and if b1 haddn't been assigned to it, that list would now have zero references and would get garbage collected eventually.

For the C code to illustrate this, I've needed to have some handwaving, in the form of some typedefs and utility functions for handling the specifics of Python allocation and typing. Sample typedefs and implementations for some of the utility functions are at the bottom of the post if you care to look, no promises that they would work as they are just something I threw together for this and it really isn't relevant. Anyway, note that the earlier C code should have had the same, but I omitted it entirely because the details of the integer type handling would have just cluttered things.

Code:
PyListNode* append(PyListNode* head, PyObject* data);
PyObjectType* lookupTypeSize(PyObjectType *registry, char typeName[]);
PyObject* makePyInt(int value);    // allocates a Python big-int

PyObjectType *typeReg;
// a lookup table of type sizes, details don't matter

PyListNode *a1, *b1;

a1 = malloc(lookupTypeSize(typeReg, "list"));

append(a1, makePyInt(100));
append(a1, makePyInt(200));
// note that the append() function is operating
// on the list allocated earlier, not on 'a1' -
// in this case, a1 is just being used
// to pass the pointer to the head of the list

b1 = a1;      // both now point to the same list

a1 = malloc(lookupTypeSize(typeReg, "list"));
// creates a *new* list, and assigns a1 a pointer to that list
// - b1 is still pointing to the existing list

append(a1, makePyInt(100));
append(a1, makePyInt(200));
append(a1, makePyInt(300));
// these operations are all on the second list,
// not the first one


The important thing to see here is that while it might look as if

Code:
a1 = [100, 200, 300]


is appending a value to the existing list, it is in fact creating a completely different list.

So, for

Code:
list1 = []


A new list is created, but not appended to, and the variable list1 is assigned a reference to it.

Code:
list1.append(100)


This appends to the list pointed to by list1. Note that this is not changing list1 in any way, shape or form - the method dispatch uses the variable as a handle to access the object, which is the list which is actually getting changed.

Code:
list2 = list1


Here again, this is going variable to variable, not object to object. Both variables now point to the same list.

Code:
list1.append(101)


This is once again appending to the list, which both variables are still pointing to. Neither list1 no list2 have been modified, only the list object itself.

The matching C code is:

Code:
PyListNode *list1, *list2;

list1 = malloc(lookupTypeSize(typeReg, "list"));

append(list1, makePyInt(100));

list2 = list1;      // both now point to the same list

append(a1, makePyInt(101));
// these operations are all on the second list, not the first one


The point is, what seems to be confusing you is not the second set of operations, but the first set, but it looks to you like it is an append when it isn't.


Anyway, here's that example implementation I mentioned. I can pretty much guess that the actual CPython imlpementation is very different.

Code:
typedef struct {
    char typename[MaxIdentifierSize];
    uint64_t minimum_size;
} PyObjectType;

typedef struct {
    PyObjectType* type_tag;
    uint64_t size;
    void* data;
} PyObject;
// a tagged structure for an untyped pointer,
// as typing is handled at run time by
// the interpreter

typedef struct {
    PyObject *data;
    PyListNode *next;
} PyListNode;

PyListNode *a1, *b1;

//  somewhere we have this function, which takes a pointer to a list and a piece of data to append to the end of the list:
PyListNode* append(PyListNode* head, PyObject* data)
{
    PyListNode *curr;

    for (curr = head; curr != null; curr = curr ->next)
    { }   // iterate to the end of the list
   
    curr = curr ->next = malloc(lookupTypeSize(typeReg, "list"));
    curr ->data = data;
    return head;
}

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
μή εἶναι βασιλικήν ἀτραπόν ἐπί γεωμετρίαν
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: Why do I despise python
PostPosted: Wed Aug 08, 2018 2:53 pm 
Offline

Joined: Tue Jan 02, 2018 12:53 am
Posts: 17
Location: Australia
Schol-R-LEA wrote:
To be fair, indirection is damn hard to get without the hinting C and C++ use with the indirection ('*' and '->') operators.

Drawing a syntactic distinction between accessing a struct directly vs indirectly is actually one of the few things I dislike about C; it's syntactic salt rather than sugar and only serves to diminish a subtle but useful form of encapsulation. There's no good reason for not allowing the regular dot operator to dereference a pointer to a struct, as doing so is never ambiguous. Having redundant operators is bad, especially multi-symbol ones.


Top
 Profile  
 
 Post subject: Re: Why do I despise python
PostPosted: Thu Aug 09, 2018 10:35 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

Qbyte wrote:
Schol-R-LEA wrote:
To be fair, indirection is damn hard to get without the hinting C and C++ use with the indirection ('*' and '->') operators.

Drawing a syntactic distinction between accessing a struct directly vs indirectly is actually one of the few things I dislike about C; it's syntactic salt rather than sugar and only serves to diminish a subtle but useful form of encapsulation. There's no good reason for not allowing the regular dot operator to dereference a pointer to a struct, as doing so is never ambiguous. Having redundant operators is bad, especially multi-symbol ones.


A potential cache miss is also a potential TLB miss, and either of these things on their own can be more expensive than almost anything else a CPU is capable of, and both combined is even worse.

For this reason my "language litmus test" is how hard it is to spot potential cache misses in code you're not familiar with.

If you can't easily see the potential cache misses, then you have no hope of writing software that doesn't suck. Languages that give you no hope of writing code that doesn't suck are not good languages. Sure they might help to reduce development time slightly, but that just makes them worse - it lures people towards writing poor quality crud to save development time, and once there's some working poor quality crud there's a lot less incentive for anyone to write an acceptable quality alternative.

This is one of the few things that C actually gets right - e.g. for something like "x = myStruct->myField;" there's one extra potential cache miss that "x = myStruct.myField;" doesn't have; and this difference is obvious even when you don't know anything about any of the surrounding code.


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: Why do I despise python
PostPosted: Fri Aug 10, 2018 9:56 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1341
Location: Athens, GA, USA
Brendan wrote:
A potential cache miss is also a potential TLB miss, and either of these things on their own can be more expensive than almost anything else a CPU is capable of, and both combined is even worse.

For this reason my "language litmus test" is how hard it is to spot potential cache misses in code you're not familiar with.

If you can't easily see the potential cache misses, then you have no hope of writing software that doesn't suck. Languages that give you no hope of writing code that doesn't suck are not good languages.


This is getting away from the topic, but I will say I think that you and I need to agree to disagree on this. First off, most of the time for user applications, performance isn't a major consideration, period. The time spent waiting on user input vastly outweighs the time spend on any part of the code, and the difference in performance is usually going to be below the threshold of user perception - and if you think performance for its own sake is what matters, or that development time is not a consideration, you don't really grasp how much the demand for software outweighs the ability to supply it.

The fact that most of what actually does get supplied is trash is a secondary issue, as it has less to do with code quality or even design quality than it does the psychology of both the project managers and the customers. If the user needs something yesterday, damn it, and doesn't want to take "doing it fast is doing it wrong" for an answer, or if a software house can make more money churning out clones of Candy Crush than it can making critical infrastructure systems, that's not a software problem. And yes, those are both real world examples I have actually seen, and far from the worst at that.

OS dev hobbyists can to some extent cherry-pick their priorities, but as I've said before, if you think you can sell a product based solely on it being technically superior to the solutions which are seen as adequate by the customers, you are living in a fantasy world. Better mousetraps only sell if people think the ones they have now aren't cutting it. As pathetic as it sounds, most people are content with hamburger today instead of filet mignon tomorrow - especially when their experience tells them that the steak is likely to turn out to be a PB&J on Wonderbread with bits of sawdust lodged in it, which is the case for promises of this type in the software world to a sixth sigma.

Perhaps more importantly, I think the fine control you think this is giving you is an illusion, and decisions of the type you are talking about can be computed algorithmically by the compiler and the runtime system far better than any human being could, if only because those can take into account information not available when the code is written. Just why so few compilers actually do that level of optimization is another question. I may be foisting it off on an imaginary 'sufficiently smart compiler' (which is more plausible than your 'sufficiently informed consumer', IMAO), it is demonstrably the case that there is no sufficiently smart programmer who can do the job, if only because the necessary state information doesn't exist until too late in the process for the programmer to be involved.

In other words, you are advocating premature optimization. That ought to give you pause.

I've been there too, so it isn't as if I am talking out of my butt. To paraphrase: “I have traversed this bottomless night, which extinguished all the light and joy of my life; I entreat you my friend, leave the science of manual optimization alone. You should detest it more than spaghetti code. Pray, learn from my example.”

(And yes, I know that in the end Janos Bolyai did make useful progress on the problem his father was despairing over, but he only did it by discarding the same parallels postulate which he was being warned not to try to prove. By assuming that 2000 years of work was simply wrong, and Euclid's fifth postulate didn't hold absolutely, this led him and others to develop the hyperbolic and elliptic geometries. Which I guess means, if the analogy holds, that the real solution is something no one has tried yet?)

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
μή εἶναι βασιλικήν ἀτραπόν ἐπί γεωμετρίαν
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: Why do I despise python
PostPosted: Fri Aug 10, 2018 6:55 pm 
Offline
Member
Member
User avatar

Joined: Thu Nov 16, 2006 12:01 pm
Posts: 7295
Location: Germany
Hm.... most of the time waiting for user input?

Not all software is created equal, you know.

There are compilers, virtual machines, servers...

Currently I am working two applications at the office.

One does fuzzy logic comparisons on personal and address data, in the rough ballpark of thousands of comparisons / second. Still takes hours to run through a customer's database.

The other does matrix calculations on image data. Current version takes about 40 minutes per run, I am tasked at optimizing the stuff.

Thinking about it, none of the software done in my whole department is ever "waiting for user input", and speed is a hard selling point...

_________________
Every good solution is obvious once you've found it.


Top
 Profile  
 
 Post subject: Re: Why do I despise python
PostPosted: Fri Aug 10, 2018 7:23 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1341
Location: Athens, GA, USA
I did say 'user applications' - which, at least until recently, would have been at least 75% of PC software projects, and perhaps 90% of programming jobs.

Today, however, those percentages apply to something even more user-bound and I/O-bound: web pages and webapps. I would estimate that the majority of programmers working professionally today have never worked on anything else for pay - probably a significant majority, up to perhaps 60%.

While the mocking term 'skins around databases' isn't entirely true of this class of software, it often is more true than false - and for the most part, they involve relatively simple queries, with most of the database server loading coming from volume rather than complexity.

So no, not all software is so user-bound; but most of the software being written and maintained almost certainly is.

Of course, this group is weighted towards developing new operating systems, a task which isn't bound by (realistic) economic restraints. We are working on things we are interested in, but the overwhelming majority of software projects aren't interesting to anyone, least of all the user and the developer - it is relatively mundane, focused on some simple thing done thousands of times in minor variations that cannot (or at least will not, given most software houses) generalized in any meaningful way.

Manual CRUD screen generation is the real dominant design paradigm of the industry, which isn't really all that different from the days when dinosaurs ruled the Big Iron world and RPG III was the most commonly used software language in the world (most assume that it was COBOL, but note that I didn't say programming language; while RPG III was more of a programming language than, say, HTML, or TeX, it was still mostly about presentation, hence the name Report Program Generator).

But then, as I've said many times before, most of the 'real world' projects I've been hired for were utterly crack-brained. In almost 30 years in the industry, I can count on one hand the number of projects I was hired to work on where the correct answer to "how should we do this?" should have been anything other than, "You don't, and you should all be fired for even considering it." I can only hope that this is not the experience of the majority of professional developers...

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
μή εἶναι βασιλικήν ἀτραπόν ἐπί γεωμετρίαν
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 34 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot] and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group