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

231–240 of 332 posts

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

#231

Post by grey-area »

librasteve wrote: post #224
miffy900 wrote: post #161

As someone who first began using Swift in 2021, after almost 10 years in C#/.NET land, I was already a bit grumpy at how complex C# was, (C# was 21 years at that point), but then coming to Swift, I couldn't believe how complex Swift was compared to C# - Swift was released in 2014, so would've been 8 years old in 2022. How is a language less than half the age of C# MORE complex than C#? And this was me trying to use S…

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.

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

#232

Post by lioeters »

LeFantome wrote: post #190
amluto wrote: post #11

Earlier quoted context omitted.

> a subset of C++ written with contemporary memory safety practices What is this mythical subset of C++? Does it include use of contemporary STL features like string_view? (Don’t get me wrong — modern STL is considerably improved, but it’s not even close to being memory-safe.)

> What is this mythical subset of C++ Ladybird inherits its C++ from SerenityOS. Ladybird has an almost completely homegrown standard library including their own pointer classes and a couple of different string classes that do some interesting things with memory. But perhaps the most novel stuff are things like TRY and MUST: https://github.com/SerenityOS/serenity/blob/master/Documenta... You see this reflected all th…

So interesting to hear about the internals of the browser, how it evolved from a standard library in an OS project. It's the kind of insight that's rarely documented, spoken about, or even known to anybody other than the author.

I can totally imagine how a prolific and ambitious developer would create a world of their own, essentially another language with domain-specific vocabulary and primitives. People often talk about using a "subset of C++" to make it manageable for mortals, and I think the somewhat unusual consideration of Swift was related to this desire for an ergonomic language to express and solve the needs of the project.

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

#233

Post by bahmboo »

satvikpendem wrote: post #134
bahmboo wrote: post #59

Earlier quoted context omitted.

You don't explain or support your position, you are calling Lattner names. That's not helpful to me or anyone else if we are trying to evaluate his work. Swift has millions of users as does Mojo and Modular in general. These are not trivial accomplishments.

Mojo and Modular have millions of users?

You can answer that question yourself.

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

#234

Post by librasteve »

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.

I fully accept that formalism is an important factor in programming language design. But all HLLs (well, even ASM) are a compromise between machine speak (https://youtu.be/CTjolEUj00g?si=79zMVRl0oMQo4Tby) and human speak. My case is that the current fashion is to draw the line at an overly simple level, and that there are ways to wrap the formalism in more natural constructs that trigger the parts of the brain that have evolved to hanle language (nouns, verbs, adverbs, prepositions and so on).

Here's a very simple, lexical declaration made more human friendly by use of the preposition `my` (or `our` if it is packaged scoped)...

  my $x = 42;

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

#235

Post by integralid »

librasteve wrote: post #224
miffy900 wrote: post #161

As someone who first began using Swift in 2021, after almost 10 years in C#/.NET land, I was already a bit grumpy at how complex C# was, (C# was 21 years at that point), but then coming to Swift, I couldn't believe how complex Swift was compared to C# - Swift was released in 2014, so would've been 8 years old in 2022. How is a language less than half the age of C# MORE complex than C#? And this was me trying to use S…

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…

>But writing and reading are asymmetrical and a more expressive language used well can expose the code patterns and algorithms in a way that is easier for multiple maintainers to read and comprehend.

It's exactly the opposite. Writing and reading are asymmetrical, and that's why it's important to write code that is as simple as possible.

It's easy to introduce a lot of complexity and clever hacks, because as the author you understand it. But good code is readable for people, and that's why very expressive languages like perl are abhorred.

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

#236

Post by [deleted] »

librasteve wrote: post #224
miffy900 wrote: post #161

As someone who first began using Swift in 2021, after almost 10 years in C#/.NET land, I was already a bit grumpy at how complex C# was, (C# was 21 years at that point), but then coming to Swift, I couldn't believe how complex Swift was compared to C# - Swift was released in 2014, so would've been 8 years old in 2022. How is a language less than half the age of C# MORE complex than C#? And this was me trying to use S…

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…

[deleted]

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

#237

Post by librasteve »

integralid wrote: post #235
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…

>But writing and reading are asymmetrical and a more expressive language used well can expose the code patterns and algorithms in a way that is easier for multiple maintainers to read and comprehend. It's exactly the opposite. Writing and reading are asymmetrical, and that's why it's important to write code that is as simple as possible. It's easy to introduce a lot of complexity and clever hacks, because as the auth…

> Writing and reading are asymmetrical, and that's why it's important to write code that is as simple as possible.

I 100% agree with your statement. My case is that a simple language does not necessarily result in simpler and more readable code. You need a language that fits the problem domain and that does not require a lot of boilerplate to handle more complex structures. If you are shoehorning a problem into an overly simplistic language, then you are fighting your tool. OO for OO. FP for FP. and so on.

I fear that the current fashion to very simple languages is a result of confusing these aspects and by way of enforcing certain corporate behaviours on coders. Perhaps that has its place eg Go in Google - but the presumption that one size fits all is quite a big limitation for many areas.

The corollary of this is that richness places an burden of responsibility on the coder not to write code golf. By tbh you can write bad code in any language if you put your mind to it.

Perhaps many find richness and expressivity abhorrent - but to those of us who like Larry's thinking it is a really nice, addictive feeling when the compiler gets out of the way. Don't knock it until you give it a fair try!

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

#238

Post by TazeTSchnitzel »

alper wrote: post #229
ChrisMarshallNY wrote: post #211

Earlier quoted context omitted.

I think Swift was developed to keep a number of constituencies happy. You can do classic OOP, FP, Protocol-Oriented Programming, etc., or mix them all (like I do). A lot of purists get salty that it doesn’t force implementation of their choice, but I’m actually fine with it. I tend to have a “chimeric” approach, so it suits me. Been using it since 2014 (the day it was announced). I enjoy it.

No Swift was developed as a strategic moat around Apple's devices. They cannot be dependent on any other party for the main language that runs on their hardware. Controlling your own destiny full stack means having your own language.

Apple already had that "strategic moat" with Objective-C. It was already a language you could effectively only use on Apple platforms (the runtime and the standard library only run on Darwin) and for which Apple controlled the compiler (they have their own fork of Clang).

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

#239

Post by spongebobism »

librasteve wrote: post #224
miffy900 wrote: post #161

As someone who first began using Swift in 2021, after almost 10 years in C#/.NET land, I was already a bit grumpy at how complex C# was, (C# was 21 years at that point), but then coming to Swift, I couldn't believe how complex Swift was compared to C# - Swift was released in 2014, so would've been 8 years old in 2022. How is a language less than half the age of C# MORE complex than C#? And this was me trying to use S…

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…

Perlis's 10th epigram feels germane:

> Get into a rut early: Do the same process the same way. Accumulate idioms. Standardize. The only difference(!) between Shakespeare and you was the size of his idiom list - not the size of his vocabulary.

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

#240

Post by __d »

dismalaf wrote: post #197
levodelellis wrote: post #192

Earlier quoted context omitted.

I never heard of hardware without one

Avoiding interacting with LLVM as a user doesn't mean you've created something equivalent to LLVM. And if the C compiler you use is clang then you're still literally making use of LLVM.

IIRC, the Inmos Transputer shipped without a C compiler, and while third party products (including a port of GCC) did come later, it was Occam-only for quite some time.
Post reply on HN