p-lang thread: (now (have you (problems two)))

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »

hackbunny: Jul 22, 2007; I haven't been on SA for years but the person who gave me my previous av as a joke felt guilty for doing so and decided to get me a non-shitty av

vbtable is a "virtual base table" :eng101:

and it's a table of offsets to shared base classes

# ? Oct 28, 2016 14:58

Adbot: ADBOT LOVES YOU

# ? May 22, 2024 13:15

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

wrong, its a table of virtualbasic function calls

# ? Oct 28, 2016 15:24

Mr SuperAwesome: Apr 6, 2011; im from the bad post police, and i'm afraid i have bad news

Snapchat A Titty posted:

whatw wrong with swift, i like it

nothing

but he's complaining about breaking changes which swift has done twice already

# ? Oct 28, 2016 15:41

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

Mr SuperAwesome posted:

nothing

but he's complaining about breaking changes which swift has done twice already

$ dont count imo

unless theres another ive missed

# ? Oct 28, 2016 15:48

Volte: Oct 4, 2004; woosh woosh

Symbolic Butt posted:

I disagree, it's definitely clearer for most working programmers for sure. but that's just a matter of social circumstances, the vast majority of people learn to code with ifs and loops and not maps and filters.

I can't fault python's conservative attitude here, it's not in their best interests to risk alienating people in order to push features that doesn't even bode well with the language.

Yes, my point is that the only reason a loop is "clearer" than a superior, more expressive pattern is because people won't learn new things.

"the vast majority of people learn to code with ifs and loops and not maps and filters." Oh, and why is that? The answer is: "the vast majority of people learn to code with ifs and loops and not maps and filters." There's no actual reason.

# ? Oct 28, 2016 16:09

brap: Aug 23, 2004; Grimey Drawer

it's because education is trying to ease them into finding out how the computer actually does things

# ? Oct 28, 2016 16:31

Mr SuperAwesome: Apr 6, 2011; im from the bad post police, and i'm afraid i have bad news

Volte posted:

Yes, my point is that the only reason a loop is "clearer" than a superior, more expressive pattern is because people won't learn new things.

"the vast majority of people learn to code with ifs and loops and not maps and filters." Oh, and why is that? The answer is: "the vast majority of people learn to code with ifs and loops and not maps and filters." There's no actual reason.

look @ all these capital letters in the POS, nerd

# ? Oct 28, 2016 16:34

Xarn: Jun 26, 2015

hackbunny posted:

why does this class layout make no loving sense, why is the base class in the right place but the base's base at the rear end end of the class why doesn't it show in the debug symbols

*notices "virtual public" thinks nothing of it*
*notices typecasts access memory*
*resolves symbol for memory*
*"vbtable" *
*remembers about "virtual public"
*googles virtual inheritance*

->

god drat when you think you know a language. c++ can still surprise me sometimes

I currently teach semi introductory course to C++ and our materials on virtual inheritance is

"Virtual inheritance exists. Don't use it, everyone else will thank you*

* It might be required in some specific circumstances. Don't use it anyway"

While our real stance is to use it when necessary, we would rather not have our students try to gently caress with it during our course. :v:

# ? Oct 28, 2016 17:42

Symbolic Butt: Mar 22, 2009; (_!_); Buglord

Xarn posted:

"Some C++ feature exists. Don't use it, everyone else will thank you*

more generally this is true for a lot of things in C++

# ? Oct 28, 2016 17:56

hackbunny: Jul 22, 2007; I haven't been on SA for years but the person who gave me my previous av as a joke felt guilty for doing so and decided to get me a non-shitty av

virtual inheritance is strictly speaking unavoidable because iostreams uses it (it's used to make sure a iostream has a single ios_base, shared between its istream and its ostream, instead of two). you can however do your part as a good citizen and avoid adding new uses of it

# ? Oct 28, 2016 18:24

qntm: Jun 17, 2009

Symbolic Butt posted:

more generally this is true for a lot of things in C++

independent of what the features themselves are, basically, use as few features of C++ as you possibly can

# ? Oct 28, 2016 18:39

hobbesmaster: Jan 28, 2008

virtual inheritance is interesting as it relates to the diamond problem. that is kinda advanced for a basic c++ class though.

i actually just took a pair of job screening exams on c++ and c - there were 2 virtual inheritance questions. the first c question was on the 'auto' keyword which is the craziest trivia test i've seen so far in a job search

# ? Oct 28, 2016 18:46

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Snapchat A Titty posted:

$ dont count imo

unless theres another ive missed

probably means the 2.0 and 3.0 breaks. it's a fair rap against the language. 4.0 will be a break, too, it's just (1) it will hopefully be much smaller and (2) we'll have a 3.0 compatibility mode that still supports the vast majority of 3.0 code

# ? Oct 28, 2016 20:05

Dr Monkeysee: Oct 11, 2002; just a fox like a hundred thousand others; Nap Ghost

comedyblissoption posted:

this is what i'm asking for as a counterexample to the claim that python poorly supports higher order functions

to your point i agree that python's syntax makes higher order functions awkward to model. i think it's weird to have that as a yardstick for whether a language is "bad".

it's okay to have different languages emphasize different things!

# ? Oct 28, 2016 20:14

Dr Monkeysee: Oct 11, 2002; just a fox like a hundred thousand others; Nap Ghost

Cybernetic Vermin posted:

the python3000 debacle goes a pretty long ways towards my distrust of the stewards of the language

python's choice to switch the string type to unicode was *absolutely* the right call and for their part they seemed to realize what a huge schism that was going to be and tried to mitigate as best they could.

either way these days i don't run into any packages that don't support 3.

and lol if your language still thinks of text as arrays of ascii bytes.

# ? Oct 28, 2016 20:18

Sapozhnik: Jan 2, 2005; Nap Ghost

I'm glad that they cleaned up the Python stdlib while they were at it so that it wasn't such a patchwork quilt shitshow

# ? Oct 28, 2016 20:54

VikingofRock: Aug 24, 2008

hackbunny posted:

virtual inheritance is strictly speaking unavoidable because iostreams uses it (it's used to make sure a iostream has a single ios_base, shared between its istream and its ostream, instead of two). you can however do your part as a good citizen and avoid adding new uses of it

just use <cstdio> instead

# ? Oct 28, 2016 21:13

hackbunny: Jul 22, 2007; I haven't been on SA for years but the person who gave me my previous av as a joke felt guilty for doing so and decided to get me a non-shitty av

VikingofRock posted:

just use <cstdio> instead

I generally do, I can't stand iostreams. only problem with stdio is that it has no (standard) equivalent of stringbuf. also I'm in fact not using iostreams but reverse engineering code that uses it and I'm ready for death. nobody should see what out << "string" << std::endl compiles to or how out << std::hex << integer works. what a tragic mistake that iostream was

# ? Oct 28, 2016 21:27

pseudorandom name: May 6, 2007

open_memstream and fmemopen are both standardized

# ? Oct 28, 2016 21:31

hackbunny: Jul 22, 2007; I haven't been on SA for years but the person who gave me my previous av as a joke felt guilty for doing so and decided to get me a non-shitty av

pseudorandom name posted:

open_memstream and fmemopen are both standardized

from where I'm standing they're marked [CX] ie. POSIX, not ANSI C. not standard enough

# ? Oct 28, 2016 21:37

Edison was a dick: Apr 3, 2010; direct current only

Sapozhnik posted:

I'm glad that they cleaned up the Python stdlib while they were at it so that it wasn't such a patchwork quilt shitshow

Timestamps and file paths on Linux are irredeemably hosed up.

Linux timestamps have nanosecond precision, but Python insists on coercing it to a double which can't encode the whole range.
So if you're copying files you can't give them the same modification time.

Linux file paths are byte strings, so there are valid file paths that aren't valid utf-8 strings.
But as part of the python 3 transition they made a whole bunch of stuff return unicode strings only.
Some of the stdlib is in the weird position of returning a unicode string or byte string depending on the type of the string you passed in as a parameter, but that doesn't work if your function doesn't take any parameters.

mkstemp for example can be called without any parameters to make a temporary file in the default location, but if you do this it will always return a unicode string.
If you want a byte string from it you need to explicitly pass the result of gettempprefixb as the prefix parameter. Which is a pain if you are on a version of python before it was added to the standard library.

You then have the problem of what happens when you pass this string to a third party library.
In the python 2 world these libraries used to just join the byte strings together, which would work ok,
and in python 3 the types aren't implicitly convertable so you at least know early where you need to change things.
However you also get libraries that check if they were given a bytes and implicitly convert it to a unicode string, and don't handle escaping the non-utf-8 bits (I'm looking at you pyfilesystem), and the damage has also made its way into python2 because you see code that tries to be compatible with both versions and defaults to unicode strings without converting properly and break everything.

os.fsencode is supposed to be the answer to this, as it promises to safely let you encode file paths in unicode strings via the "surrogateescape" encoding.
However the big warning at the top says that if you pass a unicode string to a system call it will use sys.getfilesystemencoding to turn it into a byte string before passing it to the raw system call.
Your file system encoding is not the same as os.fsencode, so this will break.
It then grew support for falling back to the "surrogateescape" encoding, but sys.getfilesystemencoding depends on your per-user configuration, so if your program involves changing the encoding or file paths passed across process or user boundaries then it can decode the strings incorrectly, and could silently get it wrong rather than falling back to the "surrogateescape".

This could all be fixed if python had a separate type for file paths from other types of strings.

Python 3 added a pathlib library to the standard library to attempt to fix this, but last time I looked it was hot garbage, as it assumed all file paths are utf-8 strings, so if your home directory wasn't encodable as utf-8 you could cause it to throw unicode exceptions.

If I'm completely wrong about strings and it's all fine, please tell me so I can stop being angry about file paths.

# ? Oct 28, 2016 21:47

Xarn: Jun 26, 2015

Dr Monkeysee posted:

either way these days i don't run into any packages that don't support 3.

I am paid to code for AWS lambda (that means Python 2.7 only) :v:

# ? Oct 28, 2016 21:57

hackbunny: Jul 22, 2007; I haven't been on SA for years but the person who gave me my previous av as a joke felt guilty for doing so and decided to get me a non-shitty av

Edison was a dick posted:

Timestamps and file paths on Linux are irredeemably hosed up.

Linux timestamps have nanosecond precision, but Python insists on coercing it to a double which can't encode the whole range.
So if you're copying files you can't give them the same modification time.

Linux file paths are byte strings, so there are valid file paths that aren't valid utf-8 strings.
But as part of the python 3 transition they made a whole bunch of stuff return unicode strings only.
Some of the stdlib is in the weird position of returning a unicode string or byte string depending on the type of the string you passed in as a parameter, but that doesn't work if your function doesn't take any parameters.

mkstemp for example can be called without any parameters to make a temporary file in the default location, but if you do this it will always return a unicode string.
If you want a byte string from it you need to explicitly pass the result of gettempprefixb as the prefix parameter. Which is a pain if you are on a version of python before it was added to the standard library.

You then have the problem of what happens when you pass this string to a third party library.
In the python 2 world these libraries used to just join the byte strings together, which would work ok,
and in python 3 the types aren't implicitly convertable so you at least know early where you need to change things.
However you also get libraries that check if they were given a bytes and implicitly convert it to a unicode string, and don't handle escaping the non-utf-8 bits (I'm looking at you pyfilesystem), and the damage has also made its way into python2 because you see code that tries to be compatible with both versions and defaults to unicode strings without converting properly and break everything.

os.fsencode is supposed to be the answer to this, as it promises to safely let you encode file paths in unicode strings via the "surrogateescape" encoding.
However the big warning at the top says that if you pass a unicode string to a system call it will use sys.getfilesystemencoding to turn it into a byte string before passing it to the raw system call.
Your file system encoding is not the same as os.fsencode, so this will break.
It then grew support for falling back to the "surrogateescape" encoding, but sys.getfilesystemencoding depends on your per-user configuration, so if your program involves changing the encoding or file paths passed across process or user boundaries then it can decode the strings incorrectly, and could silently get it wrong rather than falling back to the "surrogateescape".

This could all be fixed if python had a separate type for file paths from other types of strings.

Python 3 added a pathlib library to the standard library to attempt to fix this, but last time I looked it was hot garbage, as it assumed all file paths are utf-8 strings, so if your home directory wasn't encodable as utf-8 you could cause it to throw unicode exceptions.

If I'm completely wrong about strings and it's all fine, please tell me so I can stop being angry about file paths.

no, you're right. paths and filenames are never standard strings, never. they're byte strings on linux. on mac, they're unicode strings in nfd form, encoded in utf-8. on windows, they're utf-16. I know a bit more about paths in windows, and "utf-16" doesn't quite cover it. illegal surrogate pairs are legal, because it's really ucs-2: I think even unassigned codepoints are legal; for case insensitive comparison, windows paths are converted to upper case (in almost all other contexts, lower case is used. uppercase/lowercase folding is not perfectly symmetrical); absolute paths include object namespace components, which are subject to much fewer limitations: literally all characters are legal except backslash, including \0 and slash. try with registry keys if you don't believe me

let's talk about object namespace paths a bit. \\?\C:\piss\poo poo\gently caress and \\?\C:/piss\poo poo\gently caress are two completely different paths, because slash is a valid character in a path component (and using the \\?\ escape syntax means no translation of slashes into backslashes). in the context of file paths, it's impossible to know for sure which component in a path is the device name (in \\?\C:/piss\poo poo\gently caress, the device name may in fact be "poo poo"). not all filesystems use the standard fsrtl routines, and the standard fsrtl set of illegal characters: a big one is the named pipes filesystem, which is flat and allows backslash in filenames (if a pipe exists with the name \\.\pipe\named\pipe, it doesn't mean that \\.pipe\named exists. on the other hand, it might exist, and it would be a different, entirely unrelated named pipe. and \\.\pipe\named\ would be a third, distinct named pipe). this is legal because the object namespace stops at the first non-directory object it finds (in this case, the "pipe" device) and delegates the parsing of the rest of the path (named\pipe) to that object. let's not even get into the mess caused by paths that contain embedded \0 characters (internally, paths are counted strings; at the win32 layer, they're nul terminated)

basically, a windows path is not self describing: it's in fact a program that must be executed on a live system, there is no way to manipulate it safely as "dead" data. but things like setting the current directory are based entirely on manipulating paths as strings (when you cd to "..", unix opens the file named ".." and sets it as the current directory; windows strips the last component from the current directory path, opens the full path and sets it as the current directory; getcwd on unix traverses the filesystem backwards until the root directory and reconstructs the path step by step; GetCurrentDirectory on windows copies a string from memory), so if you ask "how do I perform the impossible task of safely parsing a windows path" the answer is "very carefully"

hackbunny fucked around with this message at 22:36 on Oct 28, 2016

# ? Oct 28, 2016 22:33

qntm: Jun 17, 2009

write programs which handle text, because that is a universal interface except for file paths which are opaque binary

# ? Oct 28, 2016 22:50

Soricidus: Oct 21, 2010; freedom-hating statist shill

how the gently caress did we mess up filesystems so badly

I mean with things like dates we at least have thousands of years of inertia to explain why it's so difficult to make a programming language handle them neatly. but filesystems were literally invented for computers, and they're still a mess

# ? Oct 28, 2016 22:52

hackbunny: Jul 22, 2007; I haven't been on SA for years but the person who gave me my previous av as a joke felt guilty for doing so and decided to get me a non-shitty av

VMS syntax is pretty unambiguous! it's also MACHINE::DEVICE:[DIR1.DIR2]FILE.EXT;1 so, uh

# ? Oct 28, 2016 22:57

The MUMPSorceress: Jan 6, 2012; ^SHTPSTS; Gary’s Answer

hackbunny posted:

VMS syntax is pretty unambiguous! it's also MACHINE:EVICE:[DIR1.DIR2]FILE.EXT;1 so, uh

i love vms. i think i am a computer hipster.

# ? Oct 28, 2016 23:11

comedyblissoption: Mar 15, 2006

also a bunch of the windows development toolchain cannot deal with paths > ~255 characters

yes this is a practical issue i've run into multiple times on a team that developed only on windows

# ? Oct 28, 2016 23:23

Edison was a dick: Apr 3, 2010; direct current only

hackbunny posted:

getcwd on unix traverses the filesystem backwards until the root directory and reconstructs the path step by step

Huh, never knew this one existed, since Linux has a syscall and a magic symlink in /proc that can tell you it, but glibc still has it in there as a fallback for if you manage to get a cwd larger than a page.

# ? Oct 28, 2016 23:44

jony neuemonic: Nov 13, 2009

comedyblissoption posted:

also a bunch of the windows development toolchain cannot deal with paths > ~255 characters

yes this is a practical issue i've run into multiple times on a team that developed only on windows

npm always had awful problems with windows because of that limitation. i think it's better since version 3, thank god.

# ? Oct 29, 2016 01:29

fritz: Jul 26, 2003

VikingofRock posted:

just use <cstdio> instead

im liking cppformat

# ? Oct 29, 2016 01:58

fritz: Jul 26, 2003

jony neuemonic posted:

npm always had awful problems with windows because of that limitation. i think it's better since version 3, thank god.

maybe it's not so bad if it slows down npm

# ? Oct 29, 2016 01:58

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

Communist Pie posted:

from functools import reduce
from operator import mul

reduce(mul, [x*100 for x in [1, 2, 3, 4, 5] if x*100 < 300])

code:

  1+!5
1 2 3 4 5

  100*1+!5
100 200 300 400 500

  (300>)#100*1+!5
100 200

  */(300>)#100*1+!5
20000

# ? Oct 29, 2016 03:12

tef: May 30, 2004; -> some l-system crap ->

comedyblissoption posted:

the main issue with the procedural style is when you start adding more complexity the obfuscation factor starts increasing rapidly

what do we want: clean, simple readable code

how do we do it? well we find a powerful language so we can pretend our complex unreadable code is good because it fits on one line

# ? Oct 29, 2016 03:34

tef: May 30, 2004; -> some l-system crap ->

here's some code that illustrates this

comb([], []).
comb([A|B],[C|D]) :- member(C,A), comb(B,D).

# ? Oct 29, 2016 03:35

tef: May 30, 2004; -> some l-system crap ->

honestly python is fine if you're doing some routine automation, or text janitoring

it's pretty ok at numeric code that's mostly "call these library functions", or other glue stuff

it also turns out these tasks are actually a large proportion of the code people need to write

# ? Oct 29, 2016 03:37

tef: May 30, 2004; -> some l-system crap ->

comedyblissoption posted:

what's the equivalent of this pseudocode in python
code:
[1, 2, 3, 4, 5].map(x => x * 100).filter(x => x < 300).reduce(*, 1)

if you define a product function, which you picked specifically to trip python up

it's product(x*100 for x in range(1,6) if x < 3)

# ? Oct 29, 2016 03:40

tef: May 30, 2004; -> some l-system crap ->

a literal thing a functional programmer has said to me

"i don't know how you can program without a type checker, i can't write fifth order functions without them"

at a certain point the use of functional programming enables rather than reducing complexity, as with any other powerful abstraction

# ? Oct 29, 2016 03:43

tef: May 30, 2004; -> some l-system crap ->

the likelyhood of someone writing something that requires the PLT trickery like a theorem-prover or a compiler is low, especially if they're asking "is this language good enough"

# ? Oct 29, 2016 03:44

Adbot: ADBOT LOVES YOU

# ? May 22, 2024 13:15

tef: May 30, 2004; -> some l-system crap ->

*just* so you know, defining map, filter et al as methods on a class makes it hard to do proper adt style.

this is why python stuffs them into itertools, so that every user list type only need return a generator over implement 30+ methods for each specific type of iteration combination

# ? Oct 29, 2016 03:47

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »