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

Closing this as we are no longer pursuing Swift adoption

github.com

Post reply on HN
Print view View original

311–320 of 332 posts

Re: Closing this as we are no longer pursuing Swift adoption

#311

Post by h3lp »

grey-area wrote: post #231
librasteve wrote: post #224

Earlier quoted context omitted.

In the last years, simplistic languages such as Python and Go have “made the case” that complexity is bad, period. But when humans communicate expertly in English (Shakespeare, JK Rowling, etc) they use its vast wealth of nuance, shading and subtlety to create a better product. Sure you have to learn all the corners to have full command of the language, to wield all that expressive power (and newcomers to English are…

Not sure how I feel about Shakespeare and JK Rowling living in the same parenthesis! Computer languages are the opposite of natural languages - they are for formalising and limiting thought, the exact opposite of literature. These two things are not comparable. If natural language was so good for programs, we’d be using it - many many people have tried from literate programming onward.

Literate programming is not about programming in natural languages: it's about integrating code (i.e. the formal description in some DSL) with the meta-code such as comments, background information, specs, tests, etc.

BTW, one side benefit of LP is freedom from arbitrary structure of DSLs. A standard practice in LP is to declare and define objects in the spot in which they are being used; LP tools will parse them out and distribute to the syntactically correct places.

Re: Closing this as we are no longer pursuing Swift adoption

#312

Post by zephen »

jaen wrote: post #309
zephen wrote: post #300

Earlier quoted context omitted.

> Complexity-wise, this version is more complicated (mixing different styles and paradigms) Really? In the other Python version the author went out of his way to keep two variables, and shit out intermediate results as you went. The raku version generates a sequence that doesn't even actually get output if you're executing inside a program, but that can be used later as a sequence, if you bind it to something. I kept…

Reminds me a bit of the fish anecdote told by DFW... they've only swam in water their entire life, so they don't even understand what water is. Here are the mixed paradigms/styles in these Python snippets: - Statements vs. expressions - Eager list comprehensions vs. lazy generator expressions - Mutable vs. immutable data structures / imperative reference vs. functional semantics (note that the Raku version only picks…

> You have the hidden inner iteration loop inside the `.extend` standard library method driving the lazy generator expression with _unspecified_ one-step-at-a-time semantics

That's why it wasn't the first thing I wrote.

> To explain what this does to a beginner, or even intermediate programmer.... oooooh boy.

As if the raku were better in that respect, lol.

> Some people program in APL/J/K/Q just fine, and they prefer their symbols.

APL originally had a lot of its own symbols with very little reuse, and clear rules. Learning the symbols was one thing, but the usage rules were minimal and simple. I'm not a major fan of too many different symbols, but I really hate reuse in any context where how things will be parsed is unclear. In the raku example, what if the elements were to be multiplied?

> Calling it "stupid" is showing your prejudice. (I don't and can't write APL but still respect it) > Reminds me a bit of the fish anecdote told by DFW...

Yeah, for some reason, it's not OK for me to insult a language, but it's OK for you to insult a person.

But you apparently missed that the "twisty" part was about the multiple meanings. Because both those symbols are used in Python (the * in multiple contexts even) but the rules on parsing them are very simple.

perl and its successor raku are not about simple parsing. You are right to worry about the semantics of execution, but that starts with the semantics of how the language is parsed.

In any case, sure, if you want to be anal about paradigm purity, take my first example, and (1) ignore the print statement because the raku version wasn't doing that anyway, although the OP's python version was, and (2) change the accumulation.

  seq = [0,1]
  while len(seq)
But that won't get you very far in a shop that cares about pythonicity and coding standards.

And...

You can claim all you want that the original was "pure" but that's literally because it did nothing. Not only did it have no side effects, but, unless it was assigned or had something else done with it, the result was null and void.

Purity only gets you so far.

Re: Closing this as we are no longer pursuing Swift adoption

#313

Post by grey-area »

h3lp wrote: post #311
grey-area wrote: post #231

Earlier quoted context omitted.

Not sure how I feel about Shakespeare and JK Rowling living in the same parenthesis! Computer languages are the opposite of natural languages - they are for formalising and limiting thought, the exact opposite of literature. These two things are not comparable. If natural language was so good for programs, we’d be using it - many many people have tried from literate programming onward.

Literate programming is not about programming in natural languages: it's about integrating code (i.e. the formal description in some DSL) with the meta-code such as comments, background information, specs, tests, etc. BTW, one side benefit of LP is freedom from arbitrary structure of DSLs. A standard practice in LP is to declare and define objects in the spot in which they are being used; LP tools will parse them out…

Well I think the ambition was to have as much as possible in natural language, with macros calling out to ‘hidden’ code intended for machines. So I do think there is a good link with later attempts to write using natural language and make computer languages more human-friendly and he was one of the first to have this idea.

Neither strategy has had much success IMO.

Re: Closing this as we are no longer pursuing Swift adoption

#314

Post by lizmat »

zephen wrote: post #312
jaen wrote: post #309

Earlier quoted context omitted.

Reminds me a bit of the fish anecdote told by DFW... they've only swam in water their entire life, so they don't even understand what water is. Here are the mixed paradigms/styles in these Python snippets: - Statements vs. expressions - Eager list comprehensions vs. lazy generator expressions - Mutable vs. immutable data structures / imperative reference vs. functional semantics (note that the Raku version only picks…

> You have the hidden inner iteration loop inside the `.extend` standard library method driving the lazy generator expression with _unspecified_ one-step-at-a-time semantics That's why it wasn't the first thing I wrote. > To explain what this does to a beginner, or even intermediate programmer.... oooooh boy. As if the raku were better in that respect, lol. > Some people program in APL/J/K/Q just fine, and they prefe…

> In the raku example, what if the elements were to be multiplied?

$ raku -e 'say (0, 1, 2, * × * ... )[^10]' # for readability (0 1 2 2 4 8 32 256 8192 2097152)

$ raku -e 'say (0, 1, 2, * * ... *)[^10]' # for typeability (0 1 2 2 4 8 32 256 8192 2097152)

Re: Closing this as we are no longer pursuing Swift adoption

#315

Post by zephen »

lizmat wrote: post #314
zephen wrote: post #312

Earlier quoted context omitted.

> You have the hidden inner iteration loop inside the `.extend` standard library method driving the lazy generator expression with _unspecified_ one-step-at-a-time semantics That's why it wasn't the first thing I wrote. > To explain what this does to a beginner, or even intermediate programmer.... oooooh boy. As if the raku were better in that respect, lol. > Some people program in APL/J/K/Q just fine, and they prefe…

> In the raku example, what if the elements were to be multiplied? $ raku -e 'say (0, 1, 2, * × * ... )[^10]' # for readability (0 1 2 2 4 8 32 256 8192 2097152) $ raku -e 'say (0, 1, 2, * * ... *)[^10]' # for typeability (0 1 2 2 4 8 32 256 8192 2097152)

Yeah, no thanks.

My instincts about raku were always that perl was too fiddly, so why would I want perl 6, and this isn't doing anything to dissuade me from that position.

Re: Closing this as we are no longer pursuing Swift adoption

#316

Post by fingerlocks »

zephen wrote: post #308
fingerlocks wrote: post #285

Earlier quoted context omitted.

No, I’m not. OP is conflating multiple guidelines for different purposes and attempting to use them all simultaneously.

> OP is ... attempting to use [multiple guidelines] simultaneously. No, he's literally explaining why the guidelines can't be used simultaneously.

They aren't supposed to be used simultaneously, which is literally what my comment was explaining. Different guidelines to solve different problems.

Re: Closing this as we are no longer pursuing Swift adoption

#317

Post by zephen »

fingerlocks wrote: post #316
zephen wrote: post #308

Earlier quoted context omitted.

> OP is ... attempting to use [multiple guidelines] simultaneously. No, he's literally explaining why the guidelines can't be used simultaneously.

They aren't supposed to be used simultaneously, which is literally what my comment was explaining. Different guidelines to solve different problems.

Have one source of truth is a universal guideline.

Prefer structs over classes is a universal, if weak, guideline.

It's funny how people can be all hung up on composability of things like type systems, and then completely blow off the desire for composability of guidelines.

Re: Closing this as we are no longer pursuing Swift adoption

#318

Post by jaen »

zephen wrote: post #312
jaen wrote: post #309

Earlier quoted context omitted.

Reminds me a bit of the fish anecdote told by DFW... they've only swam in water their entire life, so they don't even understand what water is. Here are the mixed paradigms/styles in these Python snippets: - Statements vs. expressions - Eager list comprehensions vs. lazy generator expressions - Mutable vs. immutable data structures / imperative reference vs. functional semantics (note that the Raku version only picks…

> You have the hidden inner iteration loop inside the `.extend` standard library method driving the lazy generator expression with _unspecified_ one-step-at-a-time semantics That's why it wasn't the first thing I wrote. > To explain what this does to a beginner, or even intermediate programmer.... oooooh boy. As if the raku were better in that respect, lol. > Some people program in APL/J/K/Q just fine, and they prefe…

You're getting more and more irrational.

> it's OK for you to insult a person.

I made an analogy which just means that it's hard to understand what the different styles and paradigms are when those are the things you constantly use.

You're apparently taking that as an insult...

> But you apparently missed that the "twisty" part

I didn't miss anything. You just didn't explain it. "twisty" does not mean "ambiguous" or "hard to parse". Can't miss what you don't write.

Re: Closing this as we are no longer pursuing Swift adoption

#319

Post by VerifiedReports »

zffr wrote: post #208
VerifiedReports wrote: post #180

Earlier quoted context omitted.

I started using it around 2018. After being reasonably conversant in Objective-C, I fully adopted Swift for a new iOS app and thought it was a big improvement. But there's a lot of hokey, amateurish stuff in there... with more added all the time. Let's start with the arbitrary "structs are passed by value, classes by reference." And along with that: "Prefer structs over classes." But then: "Have one source of truth."…

Prefer structs over classes != only use structs. There are plenty of valid reasons to use classes in Swift. For example if you want to have shared state you will need to use a class so that each client has the same reference instead of a copy.

Yes, that's what I said.

Re: Closing this as we are no longer pursuing Swift adoption

#320

Post by account42 »

nicoburns wrote: post #145
pbohun wrote: post #112

Earlier quoted context omitted.

As far as I know, only Go uses Go's back end because it was specifically designed for Go. But the architecture is such that it makes it trivial for Go to cross compile for any OS and architecture. This is something that LLVM cannot do. You have to compile a new compiler for every OS and arch combo you wish to compile to. You could imagine creating a modified Go assembler that is more generic and not tied to Go's ABI…

> As far as I know, only Go uses Go's back end because it was specifically designed for Go. But the architecture is such that it makes it trivial for Go to cross compile for any OS and architecture. This is something that LLVM cannot do. You have to compile a new compiler for every OS and arch combo you wish to compile to. I don't think that's true. Zig have a cross-compiler (that also compiles C and C++) based on LL…

Even Clang can cross-compile from one compiler binary - whats missing is bundling the "platform SDK" for all targets like Zig does.
Post reply on HN