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 »

JawnV6: Jul 4, 2004; So hot ...

because having to look past the lparen to figure out what the stuff before it means is c++ garbage

# ? May 16, 2015 15:55

Adbot: ADBOT LOVES YOU

# ? Jun 11, 2024 23:31

Sweeper: Nov 29, 2007; The Joe Buck of Posting; Dinosaur Gum

JawnV6 posted:

because having to look past the lparen to figure out what the stuff before it means is c++ garbage

# ? May 16, 2015 16:22

Slurps Mad Rips: Jan 25, 2009; Bwaltow!

Sweeper posted:

can someone explain why I can't have both of these methods in rust
code:
variable()
variable(value)

it wouldnt be so bad if they had allowed default arguments but that apparently got away from them so the workaround is to write a function that takes a trait on tuples but then your code looks like

code:


function(())
function((variable))

and thats just gross and dumb and is my primary complaint of the language. The other is that you have to write explicit lifetimes for types that need to exist for less than the ones they reference and the compiler is not smart enough to figure this out on its own. conversely C++ compilers cant either but thats why you can delete copy and move constructors so that a type can only exist in the scope its defined. there doesnt appear to be a way to prevent this in Rust and then have it translate to the same meaning. (but that's what the explicit lifetimes are. but you need to then propagate the explicit lifetimes through all trait implementations and that's just a huge pain)

# ? May 16, 2015 17:04

brap: Aug 23, 2004; Grimey Drawer

arguments should be part of the name of a method.

# ? May 16, 2015 17:07

Brain Candy: May 18, 2006

fleshweasel posted:

arguments should be part of the name of a method.

notepad user spotted

# ? May 16, 2015 17:55

jony neuemonic: Nov 13, 2009

fleshweasel posted:

arguments should be part of the name of a method.

objective-c and swift got this absolutely right and i wish it had caught on in other languages.

# ? May 16, 2015 20:26

Bloody: Mar 3, 2013

huh

# ? May 16, 2015 20:55

giogadi: Oct 27, 2009

fidel sarcastro posted:

objective-c and swift got this absolutely right and i wish it had caught on in other languages.

Can you explain? Genuinely curious here.

# ? May 17, 2015 13:32

M31: Jun 12, 2012

both obj-c and swift have required named parameters (you specify which names are required).

code:

func find(#query: String, #recursive: Bool)

And then you would call the function as

code:

find(query: "foo", recursive: true)

leaving out the parameter names throws an error.

this leads to very readable function calls, especially for primitive type parameters. No more doSomething(true, true, false)
although Apple does take this a step to far sometimes, requiring writing entire paragraphs for one function call

# ? May 17, 2015 15:53

Notorious b.s.d.: Jan 25, 2003; by Reene

i refuse to use a language without named parameters

java's original sin

# ? May 17, 2015 16:21

giogadi: Oct 27, 2009

M31 posted:

both obj-c and swift have required named parameters (you specify which names are required).
code:
func find(#query: String, #recursive: Bool)
And then you would call the function as
code:
find(query: "foo", recursive: true)
leaving out the parameter names throws an error.

this leads to very readable function calls, especially for primitive type parameters. No more doSomething(true, true, false)
although Apple does take this a step to far sometimes, requiring writing entire paragraphs for one function call

This is real tight. It also discourages functions with a bajillion arguments since after maybe 3 or 4 arguments the function calls get way too long.

# ? May 17, 2015 16:47

jony neuemonic: Nov 13, 2009

giogadi posted:

Can you explain? Genuinely curious here.

M31 got it, but it's worth repeating that "required" is the most important part. lots of languages have named parameters, objective-c and swift are the only two i've used that make them a mandatory part of the language.

# ? May 17, 2015 16:47

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

I'm not sure how I feel about being required to name the parameter in a single parameter function though

# ? May 17, 2015 17:05

Bloody: Mar 3, 2013

fartBoner(gay=itsyou);

# ? May 17, 2015 17:09

leftist heap: Feb 28, 2013; Fun Shoe

small talk leaves the parameter name off when there's only one

# ? May 17, 2015 17:14

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

the lack of named parameters really bothers me in C

and what's worse is that there seems to be a strong "programming paradigm" that is against like packing x, y, z in a coordinate struct because.... that's unnecessary indirection or something?

rrrrrrrrrrrt posted:

small talk leaves the parameter name off when there's only one

nice, smalltalk was the lang made for me

# ? May 17, 2015 17:15

leftist heap: Feb 28, 2013; Fun Shoe

alan kay gave us his only child

and we repaid him by using java. smdh

# ? May 17, 2015 17:38

comedyblissoption: Mar 15, 2006

requiring named parameters (instead of just optional) seems like an awful lot of boilerplate

static typing w/ a tool that can easily let you see the types and names of parameters if you need to seems better

# ? May 17, 2015 18:13

havelock: Jan 20, 2004; IGNORE ME; Soiled Meat

C# has optional named arguments. If you name your methods sensibly, then it's only really worth it for booleans (so you don't have to make a bunch of dual-valued enums instead).

Also sensible IDEs help.

# ? May 17, 2015 18:37

brap: Aug 23, 2004; Grimey Drawer

the functions with lots of parameters are exactly those functions that need to have their parameters named.

# ? May 17, 2015 19:10

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

you can opt out of them in swift, and you have to opt in to the first argument getting one

but labels are the right default

swift is currently inconsistent about this rule, but we're fixing that

# ? May 17, 2015 19:15

Bloody: Mar 3, 2013

fleshweasel posted:

the functions with lots of parameters are exactly those functions that need to be refactored

# ? May 17, 2015 19:27

Workaday Wizard: Oct 23, 2009; by Pragmatica

Bloody posted:

jokes on you. they will get refactored to "void buttbuttinate(params ButtbuttinateParameters)"

# ? May 17, 2015 20:49

leftist heap: Feb 28, 2013; Fun Shoe

Shinku ABOOKEN posted:

jokes on you. they will get refactored to "void buttbuttinate(params ButtbuttinateParameters)"

still better tho? i mean, it's kind of silly but if you're passing umpteen params to a function then yeah, maybe they are correlated enough to warrant being an actual object?

# ? May 17, 2015 20:59

Shaggar: Apr 26, 2006

if buttbuttinateparameters is reusable then great, otherwise that's kind of gross.

# ? May 17, 2015 22:27

Brain Candy: May 18, 2006

buttinateparams can be good if you are using them as builders instead of structs

on the surface builders are lovely hacks to get around not having named parameters, but since they are full objects you can add actual functions

take (x, y) versus (r, θ), sure fine

take a thing that has a string representation or an actual string? why not

&c

# ? May 18, 2015 01:06

Brain Candy: May 18, 2006

of course they'd much much better as a language feature since then you have compile time checks about whether you've given enough data to build a thing and you wouldn't have to write boilerplate

# ? May 18, 2015 01:10

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

Symbolic Butt posted:

the lack of named parameters really bothers me in C

C++ code:

#include <stdio.h>

struct foo_params {
  int bar;
  int baz;
  int qux;
};
#define FOO_DEFAULTS .bar = 1, .baz = 2, .qux = 3,
int foo(struct foo_params *kwargs){
  printf("bar: %d, baz: %d, qux: %d\n", kwargs->bar, kwargs->baz, kwargs->qux);
  return 0;
}
#define FOO(...) foo(&(struct foo_params){ FOO_DEFAULTS __VA_ARGS__ })

int main(void){
  /* No parameters given, uses defaults */
  FOO();
  /* Overriding defaults */
  FOO(.bar = 12, .baz = 24);
  /* Positional parameters give a warning if defaults are defined,
     they would work if zero initialization was correct
  */
  FOO(32, 64);
  return 0;
}

# ? May 18, 2015 08:06

coffeetable: Feb 5, 2006; TELL ME AGAIN HOW GREAT BRITAIN WOULD BE IF IT WAS RULED BY THE MERCILESS JACKBOOT OF PRINCE CHARLES

YES I DO TALK TO PLANTS ACTUALLY

Hello all,

I am pleased to announce that I am accepting PEP 484 (Type Hints).

Given the proximity of the beta release I thought I would get this
announcement out now, even though there are some (very) minor details to
iron out.
(If you want to know the details, it's all at
https://github.com/ambv/typehinting)

I hope that PEP 484 will be a benefit to all users of Python.
I think the proposed annotation semantics and accompanying module are
technically sound and I hope that they are socially acceptable to the
Python community.

I have long been aware that as well as a powerful, sophisticated and
"production quality" language, Python is also used by many casual
programmers, and as a language to introduce children to programming.
I also realise that this PEP does not look like it will be any help to
the part-time programmer or beginner. However, I am convinced that it
will enable significant improvements to IDEs (hopefully including IDLE),
static checkers and other tools.
These tools will then help us all, beginners included.

This PEP has been a huge amount of work, involving a lot of people.
So thank you to everyone involved. If I were to list names I would
inevitably miss someone out. You know who you are.

Finally, if you are worried that this will make Python ugly and turn it
into some sort of inferior Java, then I share you concerns, but I would
like to remind you of another potential ugliness; operator overloading.

C++, Perl and Haskell have operator overloading and it gets abused
something rotten to produce "concise" (a.k.a. line noise) code.
Python also has operator overloading and it is used sensibly, as it
should be. Why?
It's a cultural issue; readability matters.

Python is your language, please use type-hints responsibly

Cheers,
Mark.

# ? May 23, 2015 17:43

suffix: Jul 27, 2013; Wheeee!

basic type checking has worked in pycharm for a while, but the interesting part is that they're standardizing generics

so with pep-0484 you could do

Python code:

from typing import TypeVar, Generic

T = TypeVar('T')

class Future(Generic[T]):
    def set_result(result: T):
        ...
    def result(timeout: float = None) -> T:
        ...

def get_int_async() -> Future[int]:
    ....

and when you try get_int_async().result() + 'foo' pycharm wouldsay excuse me this is an int wtf are you doing

im glad python is the current hipste

# ? May 23, 2015 18:36

comedyblissoption: Mar 15, 2006

Closed Issue: The use of comments to communicate with the type checker #35

https://github.com/ambv/typehinting/blob/master/pep-0484.txt

quote:

While annotations are normally the best format for type hints,
there are times when it is more appropriate to represent them
by a special comment, or in a separately distributed stub
file. (See below for examples.)

...

Type comments
=============

No first-class syntax support for explicitly marking variables as being
of a specific type is added by this PEP. To help with type inference in
complex cases, a comment of the following format may be used::

x = [] # type: List[Employee]
x, y, z = [], [], [] # type: List[int], List[int], List[str]
x, y, z = [], [], [] # type: (List[int], List[int], List[str])
x = [
1,
2,
] # type: List[int]

Type comments should be put on the last line of the statement that
contains the variable definition. They can also be placed on
``with`` statements and ``for`` statements, right after the colon.

Examples of type comments on ``with`` and ``for`` statements::

with frobnicate() as foo: # type: int
# Here foo is an int
...

for x, y in points: # type: float, float
# Here x and y are floats
...

In stubs it may be useful to declare the existence of a variable
without giving it an initial value. This can be done using a literal
ellipsis::

from typing import IO

stream = ... # type: IO[str]

In non-stub code, there is a similar special case:

from typing import IO

stream = None # type: IO[str]

Type checkers should not complain about this (despite the value
``None`` not matching the given type), nor should they change the
inferred type to ``Optional[...]`` (despite the rule that does this
for annotated arguments with a default value of ``None``). The
assumption here is that other code will ensure that the variable is
given a value of the proper type, and all uses can assume that the
variable has the given type.

The ``# type: ignore`` comment should be put on the line that the
error refers to::

import http.client
errors = {
'not_found': http.client.NOT_FOUND # type: ignore
}

A ``# type: ignore`` comment on a line by itself disables all type
checking for the rest of the file.

If type hinting proves useful in general, a syntax for typing variables
may be provided in a future Python version.

lol

# ? May 23, 2015 18:47

Bloody: Mar 3, 2013

lol magic comments

# ? May 23, 2015 18:51

comedyblissoption: Mar 15, 2006

what are all the languages that are or will give comments semantic meaning

golang
python

# ? May 23, 2015 18:54

comedyblissoption: Mar 15, 2006

just re-quoting the best part in the section about variable type annotations required to be in comments:

quote:

If type hinting proves useful in general, a syntax for typing variables may be provided in a future Python version.

# ? May 23, 2015 18:58

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

comedyblissoption posted:

just re-quoting the best part in the section about variable type annotations required to be in comments:

isn't that the PEP that coffeetable just posted about being accepted?

# ? May 23, 2015 19:01

comedyblissoption: Mar 15, 2006

it's directly from the PEP
https://github.com/ambv/typehinting/blob/master/pep-0484.txt

# ? May 23, 2015 19:06

Arcsech: Aug 5, 2008

Bloody posted:

lol magic comments

magic comments are terrible but I'd rather have type checking via magic comments than not at all, tbh

I haven't read through the pep since I'm on my phone but since the type hints appear to be optional could they de-magicify the comments in a later release without causing code to break?

# ? May 23, 2015 19:07

comedyblissoption: Mar 15, 2006

quote:

A ``# type: ignore`` comment on a line by itself disables all type checking for the rest of the file.

lol

# ? May 23, 2015 19:17

suffix: Jul 27, 2013; Wheeee!

Arcsech posted:

magic comments are terrible but I'd rather have type checking via magic comments than not at all, tbh

I haven't read through the pep since I'm on my phone but since the type hints appear to be optional could they de-magicify the comments in a later release without causing code to break?

the type hinting has no effect on how the code is actually run, it's purely for ides and linters

# ? May 23, 2015 19:20

Adbot: ADBOT LOVES YOU

# ? Jun 11, 2024 23:31

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

suffix posted:

the type hinting has no effect on how the code is actually run, it's purely for ides and linters

so it's purely decorative? that's helpful.

# ? May 23, 2015 19:26

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

«‹›1784 »