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 »

kitten emergency: Jan 13, 2008; get meow this wack-ass crystal prison

https://twitter.com/mononcqc/status/723876305951924226

some rando i work with just posted this to our work slack, ur pretty popular on twitter mononcqc

# ? Apr 24, 2016 17:11

Adbot: ADBOT LOVES YOU

# ? May 22, 2024 17:41

MononcQc: May 29, 2007

yeah this is a lot of exposure for the very little effort that went into it.

# ? Apr 24, 2016 17:29

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

grover's new house looking good

# ? Apr 24, 2016 19:45

suffix: Jul 27, 2013; Wheeee!

FamDav posted:

yours is. also the best decision Java 8 made wrt lambda was opting single method interfaces or whatever into the lambda pattern. so many anonymous classes just get sit replaced by a nice lambda.

the language was kind of screaming for it

i wish there was a good way to use it with exceptions though. like generics for "takes a callback and throws whatever checked exceptions that callback throws"

# ? Apr 24, 2016 22:39

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

Shinku ABOOKEN posted:

python's lack of labeled break is a gigantic pain in the balls

gently caress u guido "code so complicated to require this feature is very rare" my rear end

use an exception, it's cool, i don't mind

people who tell you "but they're only for errors" don't understand compromise

# ? Apr 24, 2016 23:18

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

Shinku ABOOKEN posted:

searching and doing business logic/set math on multiple huge sorted lists without just searching through the whole cartesian space

its a big ugly function out of necessity. believe me I wouldn't hesitate to break it down to smaller functions if i could (i have like a billion 3 line functions so it's not like im allergic)

you can:

- make a function, and return early, and then put some if conditions or whatever
- use an exception, b/c it will work and be ok. like, you might want to define a special class inside the function, and catch it, so it's harder to accidentally catch the wrong thing

quote:

point is: why is a labeled break so taboo?

it's a useful feature that's present in a bunch of other languages, but rarely seen used outside of numeric algorithms with one letter variables.

but tbh you can get by with functions or exceptions so why add more poo poo?

with python it comes down to choice: in this case, flat is better than nested

it isn't so much taboo, just "well, gently caress your use case, nothing personal, it's not worth the effort, the language is already complex enough"

# ? Apr 24, 2016 23:27

FamDav: Mar 29, 2008

tef posted:

well, gently caress your use case, nothing personal, it's not worth the effort

every feature request

# ? Apr 24, 2016 23:33

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

the zen of python: contorted to fit the limitations of the language is better than expressed plainly in a natural way

# ? Apr 24, 2016 23:35

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

Malcolm XML posted:

stupidest python thing is the restriction to LR grammar in the main lang b/c that's real useful

i dunno, python has a lot of bad ideas, most of them are the implicit type casts

- strings are lists. characters are strings so characters are lists.

this is like implementing foo[x] so it returns foo[x:x+1]

- or everything is a boolean, which leads to `if x is not None`

tbh this is one of the few things i like about ruby, it doesn't do this

the other one is default values for functions are evaluated at definition time

edit:

the implicit type casts in python have caused me the most pain

you can't easily tell if something is a list or a string, so you end up doing isinstance(str, o) and hoping for the best
which unfortunately made a lot of the code in python break when you passed in unicode, because it isn't a bytestring

the db2 library inside lets you use prepared statements, but you have to pass a list of values for the second argument
doing foo(..., x=1) is an error, foo(..., [1]) is correct, but foo(...,"foo") throws some weird exceptions

it is the stupidest thing

implict casts are usually the worst thing in every language, code golf for a life time of suffering

tef fucked around with this message at 23:58 on Apr 24, 2016

# ? Apr 24, 2016 23:35

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

Soricidus posted:

the zen of python: contorted to fit the limitations of the language is better than expressed plainly in a natural way

the zen of python

- backwards compatibility is why we can't change a number of these bad ideas

- ok we can change some of them now

- not yours

- i don't care what you think about ternary if

- look, we can't use a "then" keyword, so we'll use "else", so a for-else statement.

- it's fine

- i am ok with this

# ? Apr 24, 2016 23:39

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

tef posted:

the zen of python

- backwards compatibility is why we can't change a number of these bad ideas

- ok we can change some of them now

- not yours

- i don't care what you think about ternary if

- look, we can't use a "then" keyword, so we'll use "else", so a for-else statement.

- it's fine

- i am ok with this

oh god i'd forgotten about for-else

the fact that python has that kind of weird loop construct, which does nothing you couldn't do with a simple flag variable (apart from make beginners' heads implode i guess), just makes their opposition to labelled breaks all the more bizarre

# ? Apr 24, 2016 23:52

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

Soricidus posted:

oh god i'd forgotten about for-else

the fact that python has that kind of weird loop construct, which does nothing you couldn't do with a simple flag variable (apart from make beginners' heads implode i guess), just makes their opposition to labelled breaks all the more bizarre

can you imagine how they would fit it into the language given for-else.

this is why i am against any new syntax in python ever

# ? Apr 24, 2016 23:59

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

suffix posted:

the language was kind of screaming for it

i wish there was a good way to use it with exceptions though. like generics for "takes a callback and throws whatever checked exceptions that callback throws"

trying to fix exception handling in java without removing checked exceptions is like nailing your other foot to the floor to stop walking in circles

tef fucked around with this message at 00:07 on Apr 25, 2016

# ? Apr 25, 2016 00:00

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

tef posted:

can you imagine how they would fit it into the language given for-else.

this is why i am against any new syntax in python ever

it'd be fine wouldn't it? a labelled break is still a break, so you skip the else block if that's how you exited the loop

at least i think that's what for-else blocks do isn't it? maybe you only do the else if you did break. hell if i or anyone knows, that's why i shoot anyone i catch using one on sight

# ? Apr 25, 2016 00:05

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

Soricidus posted:

it'd be fine wouldn't it? a labelled break is still a break, so you skip the else block if that's how you exited the loop

at least i think that's what for-else blocks do isn't it? maybe you only do the else if you did break. hell if i or anyone knows, that's why i shoot anyone i catch using one on sight

i remember it as "it's a for-then loop but they couldn't add a then keyword", i want to think a for-else is a "for x ... else if empty" and a break jumps out of the structure, but it isn't

# ? Apr 25, 2016 00:10

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

all i can ever remember about for-else is that it does the opposite of what i think it should do, which does not help me remember what it actually does as i'm always worried that i've actually internalized python's behavior and am double-negating it

# ? Apr 25, 2016 00:46

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

recently a dude proposed for-else for c++ and listed python as one of the inspirations for it, but then withdrew the proposal when it was pointed out that it was actually the opposite of what python did, and what python did wasn't at all useful for the problem he was trying to solve

# ? Apr 25, 2016 00:48

MeruFM: Jul 27, 2010

where would you use a for-then loop?

# ? Apr 25, 2016 00:52

suffix: Jul 27, 2013; Wheeee!

the only thing you need to remember about for-else (and while-else) is to never use it
im surprised they kept in in python 3

# ? Apr 25, 2016 01:15

more like dICK: Feb 15, 2010; This is inevitable.

I've written and read a lot of Python. I've never seen for-else outside of blogs and forum posts

# ? Apr 25, 2016 02:47

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

quote:

In a construct like this one:
code:
for i in foo:
  if bar(i):
    break
else:
  baz()
the else suite is executed after the for, but only if the for terminates normally (not by a break).

i kinda get the reasoning but yeah, that's not exactly intuitive.

# ? Apr 25, 2016 03:32

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Suspicious Dish posted:

and "the empty case" is exactly what everybody thinks for...else does but isn't it

doh, I should've looked that up, and yeah, that's not a particularly sensible use of the keyword else so I don't feel too bad about it.

# ? Apr 25, 2016 03:38

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

yeah

that's why nobody should use for..else

it doesn't do the obvious thing

python has a lot of bad decisions and i really wish python 3 didn't exist

# ? Apr 25, 2016 03:44

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

python 2 is hella warty but i enjoy it as a utility misc script plang more than anything else

# ? Apr 25, 2016 03:46

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

for-else is a super old feature of python, iirc it's included in the very first version that ever came up on the web

I looked up a lot of places to see Guido talk about it, what was the exact rationale behind it but no luck. I only found Raymond Hettinger making poo poo up about how natural it is when you look at the bytecode (spoiler: he's full of poo poo)

so yeah, I'm convinced it was an absolute mistake and there's absolutely no way something like it would enter the language nowadays

# ? Apr 25, 2016 05:28

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

http://nedbatchelder.com/blog/201110/forelse.html is the most sensible explanation and it's still garbage

# ? Apr 25, 2016 05:35

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

jony neuemonic posted:

if anyone doesn't know what for else does (i didn't):

that is dumb.

# ? Apr 25, 2016 06:32

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

it's the else clause on the if statement that guards the body of the loop

it's dumb as hell

# ? Apr 25, 2016 06:55

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

i still write a lot of one-off python scripts and as much as i hate python for real actual projects i dont know of anything else good for that purpose.

# ? Apr 25, 2016 07:03

gonadic io: Feb 16, 2011; >>=

python is the number 1 lang I recommend to people wanting to learn to code who would be put off by Scratch. I would never ever work in it again myself.

# ? Apr 25, 2016 07:25

Sinestro: Oct 31, 2010; The perfect day needs the perfect set of wheels.

i'm working on a project that the worst coder int he world (me!) that was started in django back before i fully realized what a mountain of poo poo python is for anything but turbo-speed bullshit, and it's lovely enough to work with that i wanna rewrite it, but i don't wanna be that junior coder.

# ? Apr 25, 2016 07:35

abraham linksys: Sep 6, 2010

hey help me out here: why do people like typescript so much when it seems like flow's type system is objectively better? is it just momentum or are there reasons to prefer typescript's type system that i'm missing

i know very little about type systems so i want to emphasize the seems in the above statement. for those not familiar, my understanding is that typescript has a type system close to c#'s or java's (not surprising given its creator) and flow has a type system close to ocaml (also not surprising), same as swift.

i'd say the biggest difference that annoys me is that flow includes optional/nullable type support that doesn't exist in typescript. much like in c# or java, anything can be null (in addition to undefined, when we're talking about object fields). basically, in typescript i can do:

code:

interface MyObjectType {
  a: number;
  b?: number;
}

const obj: MyObjectType = {
  a: 1,
  // b is left off
};

console.log(obj.b + 5);  // NaN

and it type-checks just fine. this is because in typescript you have to remember to do !== null on anything you access that can be null. meanwhile, in flow:

code:

type MyObjectType = {
    a: number;
    b?: number;
}

const obj: MyObjectType = {
    a: 1,
}

console.log(obj.b * 5);

gives an error: "undefined: This type is incompatible with number." basically, it's saying "well, b can be undefined, but there's no way you'd want to use an undefined reference with arithmetic, so you have to make sure that b actually exists." if we add a null/undefined check, this passes fine:

code:

type MyObjectType = {
    a: number;
    b?: number;
}

const obj: MyObjectType = {
    a: 1,
}

if (obj.b != null) {
    console.log(obj.b * 5);
}

i thought it was generally accepted knowledge that required null/undefined checks are a Good Thing which is why we've codified this into option and maybe types in other languages. typescript not doing so seems like a sorely lacking language feature, and there is a huge github issue on the subject, which i guess maps to a popular suggestion to add non-nullable types to c#

is this just an unfortunate implementation detail of typescript, or are there advantages to not having this feature?

gotta say that in general i'm happy with typescript as "better than no types at all," and building a universal js app with it has led to some neat advantages: for example, my websocket message schemas are defined as interface types, and i can both type-check outgoing messages when i construct them and then cast incoming messages to the correct schema as they come in on the other end, ensuring i never forget to update both sides of communication if i add or change a field in the message. just can't help but feel that flow would be the better option if there was any community at all behind it like there is for typescript

abraham linksys fucked around with this message at 08:06 on Apr 25, 2016

# ? Apr 25, 2016 08:00

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

abraham linksys posted:

hey help me out here: why do people like typescript so much when it seems like flow's type system is objectively better? is it just momentum or are there reasons to prefer typescript's type system that i'm missing

i know very little about type systems so i want to emphasize the seems in the above statement. for those not familiar, my understanding is that typescript has a type system close to c#'s or java's (not surprising given its creator) and flow has a type system close to ocaml (also not surprising), same as swift.

i'd say the biggest difference that annoys me is that flow includes optional/nullable type support that doesn't exist in typescript. much like in c# or java, anything can be null (in addition to undefined, when we're talking about object fields). basically, in typescript i can do:
code:
interface MyObjectType {
  a: number;
  b?: number;
}

const obj: MyObjectType = {
  a: 1,
  // b is left off
};

console.log(obj.b + 5);  // NaN
and it type-checks just fine. this is because in typescript you have to remember to do !== null on anything you access that can be null. meanwhile, in flow:
code:
type MyObjectType = {
    a: number;
    b?: number;
}

const obj: MyObjectType = {
    a: 1,
}

console.log(obj.b * 5);
gives an error: "undefined: This type is incompatible with number." basically, it's saying "well, b can be undefined, but there's no way you'd want to use an undefined reference with arithmetic, so you have to make sure that b actually exists." if we add a null/undefined check, this passes fine:
code:
type MyObjectType = {
    a: number;
    b?: number;
}

const obj: MyObjectType = {
    a: 1,
}

if (obj.b != null) {
    console.log(obj.b * 5);
}
i thought it was generally accepted knowledge that required null/undefined checks are a Good Thing which is why we've codified this into option and maybe types in other languages. typescript not doing so seems like a sorely lacking language feature, and there is a huge github issue on the subject, which i guess maps to a popular suggestion to add non-nullable types to c#

is this just an unfortunate implementation detail of typescript, or are there advantages to not having this feature?

gotta say that in general i'm happy with typescript as "better than no types at all," and building a universal js app with it has led to some neat advantages: for example, my websocket message schemas are defined as interface types, and i can both type-check outgoing messages when i construct them and then cast incoming messages to the correct schema as they come in on the other end, ensuring i never forget to update both sides of communication if i add or change a field in the message. just can't help but feel that flow would be the better option if there was any community at all behind it like there is for typescript

tooling and ubiquity

# ? Apr 25, 2016 08:35

redleader: Aug 18, 2005; Engage according to operational parameters

what makes python better/worse than any other dynamic lang? i'm somewhat considering going for a python job i've seen advertised

# ? Apr 25, 2016 09:45

Workaday Wizard: Oct 23, 2009; by Pragmatica

mystery meat types

# ? Apr 25, 2016 09:47

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

redleader posted:

what makes python better/worse than any other dynamic lang? i'm somewhat considering going for a python job i've seen advertised

python v perl: it's not perl
python v php: it's not php
python v ruby: it's not ruby
python v nodejs: it's not js
winner: python

... which isn't saying much

# ? Apr 25, 2016 09:50

Cybernetic Vermin: Apr 18, 2005

redleader posted:

what makes python better/worse than any other dynamic lang? i'm somewhat considering going for a python job i've seen advertised

main thing is the dynamic bit, but it also suffers from people writing un-typed java in it, whereas e.g. a large-scale lisp or erlang system will have abstractions which make the lack of types a bit less of an issue

# ? Apr 25, 2016 11:00

Adbot: ADBOT LOVES YOU

# ? May 22, 2024 17:41

M31: Jun 12, 2012

abraham linksys posted:

is this just an unfortunate implementation detail of typescript, or are there advantages to not having this feature?

It's implemented in TypeScript 2 (the next version): https://github.com/Microsoft/TypeScript/pull/7140

# ? Apr 25, 2016 11:32

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

«‹›1784 »