Maybe a quick spell check would've caught the misspelling of prgrams or maybe more proof reading is the answer.

/s :D

Types are a tool just like auto spell checking. Why not leverage them to reduce cognitive load?

Amusing example, since my phone's autocorrect seems quite often to increase my cognitive load.

This seems like some bizarre luddite-esque argument. We should use computers to aid our work, but not too much!!

It's more an expression of "if it any broke don't fix it" or a minimalist approach to prorgamming.

Programming is broken though. If it weren't, we wouldn't have so many issues with our main operating systems and popular applications.

The desire to remain ignorant of the problems (by not using tooling which can reveal it) is remarkably popular, however. Enjoy your bliss!

Well the tooling you are referring to is more like buildingin an automatic sensor into a basic tool. So it's an enhancement to a basic rtool functionality, not a new tool. I'm only questioning the usefulness of that enhancement, since it results in programmers not caring about a certain aspect of their programming. It's sort of like exception handling, while it exists, it rarely gets activtaed in real programs.

I've read many people complain about static typing + more advanced type systems making programming too hard. This is the first time I've ever read someone assert that they make programming too easy.

They try to make programming easier but fail at it. Experienced programmers take this change in their stride. New programmers are most effected.

We should also remove airbags and seatbelts in automobiles. Surely then better driving habits would form.

Removing protective padding and helmets might help in American Football. Rugby doesn't use them and it's actually a safer sport.

But apart from that: the guy is wrong of course! Working in JavaScript still drives me crazy because I don't have decent autocomplete and no IDE warnings I'm using an API wrong.

It's worth checking out Visual studio code. It is a fairly advanced JavaScript IDE in my experience. Using it with TypeScript is amazing if you're willing to put up with the overhead of compiling to JavaScript (though you can run TypeScript without a compile step in the server using node-ts). These tools make JavaScript a lot nicer for me, and actually pretty enjoyable!

It's more like pre-tensioners in seatbelts are not as neccessary as seatbelts themselves.

I assume you mean the static typing that Swift has, in favor of something like Python or Ruby, where the type of thing in a variable is both implicit and unfixed. Saying that there should be no types at all is...well, maybe it's just a failure of my imagination, but I don't even know how you could write a program. Even assembler has types.

Well I think basic data types are enough to express what the variable is expected to hold. Any highewr level types above that, such as what higher level languages provide are, I think a luxury for lazy programmers

What would a typeless language look like?

"In BCPL,flexibility is retained by eliminating the concept of data types and representing all quantities by bit patterns of the same length. A single vector may, for example, hold bit patterns representing numbers, booleans and pointers to other vectors. Variables are declared before use, but simply as variables, not as variables of any particular type."

See chapter 13 example BCPL programs:

http://www.cl.cam.ac.uk/~mr10/bcplman.pdf

See chapter 13 example MCPL programs:

http://www.cl.cam.ac.uk/~mr10/mcplman.pdf

Sounds like a nightmare, this is basically the type system of vanilla verilog: Everything is just a bitvector of a certain length, each bit can have four states X,Z,0,1, so that it allows you to assign to a 32bit vector a 16bit vector resulting in the upper 16bit to be undefined. System verilog added structs, but if you declare them packed they allow unstructured assignment. Overall it is a complete nightmare given the fact that at the end you will tape out a chip that might cost >1 million to produce.

BCPL main goal was to Bootstrap CPL, but then some people decided to use it on its own, and the rest is history.

C. Just basic data types.

C is in no way typeless.

Furthermore, i would expect a well behaved dev to avoid c at all cost.

Well, this article is about Result types in Swift, and my point is, I think this kind of thing is overkill. It tends to make the learning curve for a new programmer steeper because there's all these extra bells and whistles provided by the language that have to be learnt before you can get going, and then you have sample code and tutorials and so on. Learning and using C was and is a lot simpler than say Swift.

I keep hearing for about 30 years now, how writing correct code in C is just a matter of being good.

It's a matter of getting good at it and that takes time and effort, but the end result is far better than not getting good at it and using a more automated, higher level lanuggae to take the easy way out

If not even Linux kernel developers with their merge review process and stress tooling are good at it, what to say of the more mundane developer...

https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...

http://openwall.com/lists/oss-security/

Some people develop good coding techniques, like Donald Knuth. If you're new, you set out on your own or read up on what they've done or get lucky and work with a good programmer. That's how you pick it up. But, it's all pedal to the metal. Knuth's entire work is for C.

Nowadays, everything is done at a high level using some kind of pre-existing framework and the type of code being written is cookie-cutter so none of this applies. Swift belongs to this new age trend in coding,

So you are stating no one on Linux kernel development is a match to Donald Knuth, and given the CVE track record they should improve themselves to Donald Knuth level.

If there is anything new about Swift, it is a return to the past of proper programming languages.

"Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue....

Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels?

Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities."

-- Fran Allen interview, Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming

I'm not trying to glorify Knuth or downgrade Linux kernel developers. I'm only saying that you can leanr a lot from a good programmer, and an apprentice type arrangement is probably the best way to learn programming and we need more of that than new languages

I understand what you're saying, and I agree to some extent. I'm not sure if these kinds of types are actually making things easier or more difficult for learning the underlying language. There's something to be said for stopping at a certain point, or taking more caution with "kitchen sinking" the language design. For example, I think that promises in JS are a mess, and Go has it right with coroutines. The underlying problem was callback hell, and promises just replaced one set of problems with another and are, IMO, not nearly as easy to reason about.

This is completely true. However, after having learned both sides, I certainly appreciate the compiler’s help. I think it’s the classic tradeoff between specialization and accessability at play here.

I think the designers (Apple) have targeted a certain class of apps with Swift, XCode and the underlying libraries (Cocoa). A majority of their existing developer base will likely benefit from what they've done. But from the point of view of new developers and someone who's just trying to use the hardware in an effective way, this is not a step forward.