Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The type system is a programmer's best friend

dusted.codes

Post reply on HN
Print view View original

331–340 of 467 posts

Re: The type system is a programmer's best friend

#331

Post by yellowapple »

kinkrtyavimoodh wrote: post #298
yellowapple wrote: post #249

> I want that data type to have helpful methods such as .Domain() or .NonAliasValue() which would return gmail.com and foo@gmail.com respectively for an input of foo+bar@gmail.com. No the hell you don't. Please please please do not attempt to separate the alias from an email address I submit. It's there for a reason - specifically, to hold you accountable if I experience a sudden influx of spam, and generally to keep…

> "recognize that trying to parse any meaning from an email address' local-part is blatantly ignorant of IETF specifications and almost certainly will create bugs" I am sorry but this makes no sense. You do realize that the only reason you are able to use aliases is because your email provider chooses to parse meaning out of the supposedly "opaque" text right? If your email provider is free to "break" the spec, so ar…

And that is solely the business of myself and my email provider. It's my email address, and therefore I am within my rights to assign whatever internal meaning I so choose. It is absolutely not the business of someone sending an email whether or not that opaque text has further-parseable meaning, and pretending otherwise absolutely will cause bugs (say, when sending emails to mailservers which don't use that alias syntax).

EDIT:

> If your email provider is free to "break" the spec, so are people you give your id to.

Wrong. See above. The email provider is free to "break" the spec because it is the thing in control of that email address and can therefore process it as it sees fit. The people to whom I give an ID are not my email provider, and therefore do not have the same degree of control; consequently, attempting to parse meaning from that opaque string will cause bugs, and also is a dick move which will not be tolerated.

If you're defending this practice because you, too, are parsing the opaque components of email addresses which you do not control, then I will take note to look into your code contributions as well and avoid anything you've touched.

Do. Not. Parse. The. Local-part. For. Aliases. Full stop. It's my email address, not yours. Respect how I enter it, or else remove it from your system entirely. Anything different is asking for bugs and is blatantly disrepsectful to users.

Re: The type system is a programmer's best friend

#332

Post by yellowapple »

pencilguin wrote: post #263
yellowapple wrote: post #249

> I want that data type to have helpful methods such as .Domain() or .NonAliasValue() which would return gmail.com and foo@gmail.com respectively for an input of foo+bar@gmail.com. No the hell you don't. Please please please do not attempt to separate the alias from an email address I submit. It's there for a reason - specifically, to hold you accountable if I experience a sudden influx of spam, and generally to keep…

True enough, as far as it goes. But if you are concerned about subscribing to something twice, you may want to try to check delivery uniqueness. They might be your own addresses. Of more interest to me, omitted from the presentation--as almost always--is anything about what is disliked about a malformed address. You see this when some web form says it doesn't like your address, but won't say why, leaving you to guess…

> But if you are concerned about subscribing to something twice

I'm concerned about some service collecting my email address and "accidentally" exposing it to spammers.

> Of more interest to me, omitted from the presentation--as almost always--is anything about what is disliked about a malformed address. You see this when some web form says it doesn't like your address, but won't say why, leaving you to guess and try things until it is satisfied.

That is indeed yet another reason why you should never ever try to parse meaning from email addresses you do not own.

Re: The type system is a programmer's best friend

#333

Post by rowanG077 »

jstimpfle wrote: post #326
rowanG077 wrote: post #324

Earlier quoted context omitted.

escaping requires validation. You don't know what to escape if you aren't allowed to validate.

You don't know what you're talking about. For example, HTML escaping (a.k.a quoting) rules don't care what you're escaping - an email, a street name. It's just text. And that's the point of it. You quote precisely because the container syntax doesn't know the syntax of what you're embedding. If it knew, there would be no need of the escaping. It's called abstraction.

HTML escaping requires you to look for characters to escape for it to not interfere with HTML. This is quite literally validating symbols in the input. If they fail validation they need to be escaped. It's literally IMPOSSIBLE to do escaping without first validating every single symbol in the input.

Re: The type system is a programmer's best friend

#334

Post by kazinator »

kinkrtyavimoodh wrote: post #298
yellowapple wrote: post #249

> I want that data type to have helpful methods such as .Domain() or .NonAliasValue() which would return gmail.com and foo@gmail.com respectively for an input of foo+bar@gmail.com. No the hell you don't. Please please please do not attempt to separate the alias from an email address I submit. It's there for a reason - specifically, to hold you accountable if I experience a sudden influx of spam, and generally to keep…

> "recognize that trying to parse any meaning from an email address' local-part is blatantly ignorant of IETF specifications and almost certainly will create bugs" I am sorry but this makes no sense. You do realize that the only reason you are able to use aliases is because your email provider chooses to parse meaning out of the supposedly "opaque" text right? If your email provider is free to "break" the spec, so ar…

> If your email provider is free to "break" the spec, so are people you give your id to.

There is no reasoning behind this argument; it is purely a verbal construct memetically derived from some inapplicable equality ethic that might make sense in a completely unrelated situation.

The correct application of ethics is that someone agency who is given abc+def@gmail.com, and infers from it that this gives them permission to send email to abc@gmail.com (or, worse, sell that address to harvesters) is behaving unethically.

Re: The type system is a programmer's best friend

#335

Post by sixstringtheory »

kazinator wrote: post #322
sixstringtheory wrote: post #319

Earlier quoted context omitted.

Are there any widely used statically typed languages where there is no such thing as null? Wish I could find a job using one of those!

Hmm, oh! C++ comes to mind. Of course, there is such a thing as null, but in: void fun(string x) // std::string { } x cannot be null. The reference semantics (like a copy of a string sharing the data with the original) is an implementation detail/optimization encapsulated inside what appears to be a value type. The tools are there in C++ to create ideal types for your problem domain which just look like value types t…

You’ve moved the goal posts, but seem to have forgotten that you can create pointers to C++ strings, which then can of course be null.

Re: The type system is a programmer's best friend

#336

Post by dgan »

pipeline_peak wrote: post #277
dgan wrote: post #246

Earlier quoted context omitted.

Seems like you mix up classes, and types ... like many others in this thread

I don’t understand, classes are user defined types.

that's the issue: there is no other way to create new types aside from creating a new class in mainstream languages. Those two concepts are separate, and should be treated as such. Types are not Classes, the last is just a lousy "embodiment" of the first

Re: The type system is a programmer's best friend

#337

Post by outworlder »

noveltyaccount wrote: post #151
highwaylights wrote: post #145

Earlier quoted context omitted.

I’d take this further. I was listening to the John Carmack episode of Lex Fridman from the summer, and he makes a comment about being frustrated that in the Valley there’s an almost religious opposition to IDEs, debuggers, and static analysis. Some of those tools have only become more powerful over time and I’m perplexed as to the mindset that would make a person averse to automating the drudgiest parts of their job…

When I graduated college in the '00s I thought Vim was the most amazing thing I'd ever learned. Then a colleague at my first job showed me what happend when you typed . after a variable name in Visual Studio. Code completion, inline documentation...my mind was blown, and I never looked back. When I meet a young chap extolling the benefits of Vim or Emacs or really anything that doesn't have stepped debugging and code…

> When I meet a young chap extolling the benefits of Vim or Emacs or really anything that doesn't have stepped debugging and code competition...well, there are no bonus points for doing things the hard way.

Why do you think they are doing things "the hard way"? Emacs can have all the things you have described. And it can do that for languages that are not part of the .NET Framework, they just have to have a language server implementation.

The problem with "IDEs" was placing all your eggs into a single basket. You are on Visual Studio and then you need to do some Java(or Scala, or whatever). And now you have to get another IDE. Some tried to be one IDE to rule them all (Eclipse, Netbeans), didn't work all that well.

You need a good editor - most IDEs don't have one. You need integration with your language of choice. You need compilers and linters and a bunch of other things. Better to glue components that do one thing and do it well, than having one IDE trying to do everything. And those components can fell just as integrated.

Re: The type system is a programmer's best friend

#338

Post by xigoi »

rowanG077 wrote: post #333
jstimpfle wrote: post #326

Earlier quoted context omitted.

You don't know what you're talking about. For example, HTML escaping (a.k.a quoting) rules don't care what you're escaping - an email, a street name. It's just text. And that's the point of it. You quote precisely because the container syntax doesn't know the syntax of what you're embedding. If it knew, there would be no need of the escaping. It's called abstraction.

HTML escaping requires you to look for characters to escape for it to not interfere with HTML. This is quite literally validating symbols in the input. If they fail validation they need to be escaped. It's literally IMPOSSIBLE to do escaping without first validating every single symbol in the input.

You seem to have a weird definition of “validation”.

Re: The type system is a programmer's best friend

#339

Post by outworlder »

acchow wrote: post #223
highwaylights wrote: post #145

Earlier quoted context omitted.

I’d take this further. I was listening to the John Carmack episode of Lex Fridman from the summer, and he makes a comment about being frustrated that in the Valley there’s an almost religious opposition to IDEs, debuggers, and static analysis. Some of those tools have only become more powerful over time and I’m perplexed as to the mindset that would make a person averse to automating the drudgiest parts of their job…

This must be strictly an old school Valley problem. Up in the city, IDEs are standard. How would you even write Scala at Twitter without an IDE?

How, you ask?

https://scalameta.org/metals/docs/editors/emacs/

Re: The type system is a programmer's best friend

#340

Post by kazinator »

sixstringtheory wrote: post #335
kazinator wrote: post #322

Earlier quoted context omitted.

Hmm, oh! C++ comes to mind. Of course, there is such a thing as null, but in: void fun(string x) // std::string { } x cannot be null. The reference semantics (like a copy of a string sharing the data with the original) is an implementation detail/optimization encapsulated inside what appears to be a value type. The tools are there in C++ to create ideal types for your problem domain which just look like value types t…

You’ve moved the goal posts, but seem to have forgotten that you can create pointers to C++ strings, which then can of course be null.

Pointers to std::string are almost never required, though. A pointer to std::string is not something you have to use to write a string handling C++ program or module; and such a pointer p is itself not a string, *p is (if p is non-null and valid).

About the only time you would need a pointer to std::string when calling some C API that takes a callback function with a void * context, and you'd like that context to be a std::string. Then you might take the address of string object to pass to that API. (That pointer would likely never be null, but could go bad due to lifetime mismanagement.)

Most other uses of such a thing would be unidiomatic. Whereas, in some languages, string references that can be null are foisted on programmers as the standard, idiomatic string representation. That's a big difference.

Post reply on HN