Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming Open Source

Why Swift Creator Chris Lattner Stepped Down From Its Core Team This Week (devclass.com) 98

Posted by EditorDavid from the Swift-exit dept.
The creator of Apple's Swift programming language stayed involved in the Swift core team and Evolution community... until this week. Though he'd left Apple more than five years ago, "Swift is important to me, so I've been happy to spend a significant amount of time to help improve and steer it," Lattner wrote in an explanatory comment on the Swift community forum. "This included the ~weekly core team meetings (initially in person, then over WebEx)..."

The tech news site DevClass notes Lattner is also "the mind behind compiler infrastructure project LLVM," but reports that "Apparently, Lattner hasn't been part of the [Swift] core team since autumn 2021, when he tried discussing what he perceived as a toxic meeting environment with project leadership after an especially noteworthy call made him take a break in summer." "[...] after avoiding dealing with it, they made excuses, and made it clear they weren't planning to do anything about it. As such, I decided not to return," Lattner wrote in his explanation post. Back then, he planned to keep participating via the Swift Evolution community "but after several discussions generating more heat than light, when my formal proposal review comments and concerns were ignored by the unilateral accepts, and the general challenges with transparency working with core team, I decided that my effort was triggering the same friction with the same people, and thus I was just wasting my time."

Lattner had been the steering force behind Swift since the language's inception in 2010. However, after leaving Apple in 2017 and handing over his project lead role, design premises like "single things that compose" seem to have fallen by the wayside, making the decision to move on completely easier for language-creator Lattner.
The article points out Lattner's latest endeavour is AI infrastructure company Modular.AI.

And Lattner wrote in his comment that Swift's leadership "reassures me they 'want to make sure things are better for others in the future based on what we talked about' though...." Swift has a ton of well meaning and super talented people involved in and driving it. They are trying to be doing the best they can with a complicated situation and many pressures (including lofty goals, fixed schedules, deep bug queues to clear, internal folks that want to review/design things before the public has access to them, and pressures outside their team) that induce odd interactions with the community. By the time things get out to us, the plans are already very far along and sometimes the individuals are attached to the designs they've put a lot of energy into. This leads to a challenging dynamic for everyone involved.

I think that Swift is a phenomenal language and has a long and successful future ahead, but it certainly isn't a community designed language, and this isn't ambiguous. The new ideas on how to improve things sounds promising — I hope they address the fundamental incentive system challenges that the engineers/leaders face that cause the symptoms we see. I think that a healthy and inclusive community will continue to benefit the design and evolution of Swift.
DevClass also reported on the aftermath: Probably as a consequence of the move, the Swift core team is currently looking to restructure project leadership. According to Swift project lead Ted Kremenek... "The intent is to free the core team to invest more in overall project stewardship and create a larger language workgroup that can incorporate more community members in language decisions."

Kremenek also used the announcement to thank Lattner for his leadership throughout the formative years of the project, writing "it has been one of the greatest privileges of my life to work with Chris on Swift."
In 2017 Chris Lattner answered questions from Slashdot's readers.
This discussion has been archived. No new comments can be posted.

Why Swift Creator Chris Lattner Stepped Down From Its Core Team This Week More

Why Swift Creator Chris Lattner Stepped Down From Its Core Team This Week

Comments Filter:

  • Swift (Score:3, Interesting)

    by phantomfive ( 622387 ) on Sunday February 27, 2022 @09:39PM (#62310261) Journal

    Swift - a language no one would use if they weren't forced to.

    • Why do you think that?
      The language looks quite ice in my eyes, but I never used it in a project.

      • Re:Swift (Score:4, Interesting)

        by ShanghaiBill ( 739463 ) on Sunday February 27, 2022 @10:30PM (#62310403)

        Why do you think that?

        Because it is true. I use Swift because I am forced to. I would not use it if there was a reasonable alternative.

        The language looks quite ice in my eyes, but I never used it in a project.

        There are many nice languages. What is the point of forcing developers to use yet another language?

        The only reason Swift exists is to lock in developers to Apple's ecosystem by making code less portable.

        • Swift is portable. Just like .Net languages.
          The only missing part is the GUI, just like .NET languages.

          And if you want to use a more portable language on Macs/iOs then use C++.

          No one is forcing you to use Swift.

          That is typical anti Apple hater rhetoric.

          Swift is a nice language like Dart, nicer than Java or C#. If you do not agree, up to you. Calling it a "force to something" is simply stupid.

          • Re: (Score:3)

            by dynamo ( 6127 )

            No, it is true. And Swift is an awful language, last time I used it a lot, in my opinion as an iOS developer - since a few months after iPhone OS has been programmable by 3rd parties. ObjectiveC is a MUCH, MUCH better language, but it's very hard to find work making apps in it these days. It gets old having to explain how much and why Swift sucks, and why Apple is still pushing it, in every single interview.

            It's not merely a lack of knowledge. I know Swift well, I have taught it to several other iOS develop

            • Objective C is ok for writing Apps , but that is all. It is absolutely IMPOSSIBLE to use outside of the Apple platform - there are no libraries outside of Apple's OS's. Swift (thanks to the opensource version) is somewhat useable outside of Apple (i.e. there are some libraries).

              I recently needed to develop some high performance code (linear algebra optimisation using hardware acceleration) on Linux to compliment an App running on Apple. Tried all sorts of "Nice" (i.e. high performance and modern) langua

              • Objective C is ok for writing Apps , but that is all. It is absolutely IMPOSSIBLE to use outside of the Apple platform - there are no libraries outside of Apple's OS's.

                Oolite [oolite.org] is written in Objective C [github.com] and runs on Mac OS X, Linux, Windows, SGI Irix, FreeBSD & Pandora [wikipedia.org].

                • OK, maybe I need to qualify more. NextStep's base object (NSObject) is kinda essential to writing anything in objective C, and the open source versions I tried to use were hopelessly out of date. I really couldn't get a dam thing to easily compile and work on Linux - at the end of the day, if you're starting new projects, you're not going to choose Objective C unless you:
                  • can afford to self-maintain the old objective C base libraries (at least NSObject)
                  • Can find a source for maintained base libraries (whi
                • Sorry for the multiple replies- I couldn't remember the exact details of what I found when I tried to use Obj C on. Linux.. I've just had another quick zip through.

                  Objective C needs GNUStep, GNUStep is largely dead.

                  The GNUStep Wiki pages I looked through are dated more than 7 years ago (the FAQ was last updated in 2015, the intro 2006 !!), I hit a number of dead links on the web site.

                  All in all, few are going to pursue a project on tech that may not have been updated for decades - hence to all intents

            • ObjectiveC is a MUCH, MUCH better language

              It also has a few DECADES on Swift.

              It gets old having to explain how much and why Swift sucks, and why Apple is still pushing it, in every single interview.

              If you are interviewing at Apple, then it makes sense why the Project Leads are pushing Swift. Apple has clearly decided that Swift is the future for them. But outside the Spaceship, I would find it hard to believe that Third-Party Devs Projects, many of which are no doubt already written in ObjC, or have Project Managers that are more experienced in ObjC, would be so anxious to jump on the bandwagon.

              Unless it really is that good; in which case, perhaps it is time for you

            • > ObjectiveC is a MUCH, MUCH better language, but it's very hard to find work making apps in it these days.

              As someone who has worked for the last 12 years as a full time iOS developer... ObjC is inmensely inferior to Swift in so many ways, the bigger one probably being the lack of optionals.

              Because of optionals alone, pure Swift codebases deal away (almost entirely if it wasn't for IUOs) with what's the number 1 issue in ObjC, which is `nil` object exceptions.

              And even if you disregard the technical advan

              • Re: (Score:2)

                by dgatwood ( 11270 )

                How is ObjC superior to Swift in any way?

                For starters:

                • Guaranteed dynamic dispatch makes swizzling feasible.
                • Transparent integration with existing C/C++ library code.
                • More natural, readable method names.

                • Objective-C is basically most of the goodness of Smalltalk combined with the efficiency of C. You still feel that Smalltalk magic coming through.

                  Swift lost that magic.

                • Swizzling isn't a good feature.
                  Swift can integrate with C/C++ too.
                  For the naming, I disagree... Swift is much better in terms of readability.

              • As a long time iOS developer and some time manager, I will sidestep the language merit debate entirely. I loved ObjC. None of it matters. The thing that does matter: Swift is apparently easier to learn. It is not difficult to find Swift developers if you are building with it. It is increasingly impossible to find ObjC developers. Someone made the comment that managers have no motivation or rationale to migrate beyond the kool aid factor: Not so. Managers need, arguably above all else, to hire and run teams

          • Swift is portable. Just like .Net languages.
            The only missing part is the GUI

            "Only" the GUI?

            Swift is a language for writing apps. The GUI is the app.

            When I write an app for iOS, the only other platform I am interested in porting it to is Android. Does Swift work on Android? No. It does not.

            And if you want to use a more portable language on Macs/iOs then use C++.

            Apple is hostile to C++ on iOS and makes it painful to use.

            No one is forcing you to use Swift.

            No one is holding a gun to my head. But Apple has crippled other options.

            That is typical anti-Apple hater rhetoric.

            I don't hate Apple. I just hate some of Apple's behavior. The reason I use Swift is that I support Apple.

            Swift is a nice language

            There are plenty of nice languages. Why should I have to lear

          • Swift is portable. Just like .Net languages.

            Swift *kind of* works on Linux and Windows, basically no support at all for Android, and probably never will be. I wouldn't call that portable, certainly not in comparison to .Net.

            The only missing part is the GUI, just like .NET languages.

            Not true. .Net currently has full GUI support for windows, ios, and android. Currently the latter two use xamarin while windows uses WPF, but everything is just about to be unified under one roof, and it also supports macos as well:

            https://docs.microsoft.com/en-... [microsoft.com]

            It's actually already functional, you can write applications with i

          • Well jdpf you lift your eyes abit outside the ms fence there are certainly cross platform ( even including linux) gui frameworks for .net, yea we might nit like xaml and the like, but it's never the less avalable
          • Not sure what you mean about .NET languages missing GUI? Mono/Xamarin have existed for a long while now and Maui is in preview and looks quite promising.

        • Why do you think that?

          Because it is true. I use Swift because I am forced to. I would not use it if there was a reasonable alternative.

          The language looks quite ice in my eyes, but I never used it in a project.

          There are many nice languages. What is the point of forcing developers to use yet another language?

          The only reason Swift exists is to lock in developers to Apple's ecosystem by making code less portable.

          Sure; that's why Apple Open Sourced the Language.

          The Hate is strong in this one.

        • Re: (Score:2)

          by 605dave ( 722736 )

          Give some concrete examples of what you consider unappealing about the language, and maybe people will take you seriously.

        • Exactly. We have too many languages. I have even written one. There are no good reasons to invent new ones that are not application specific. It's fun to make up new languages but the primary business driver is trapping customers.

      • Two reasons:

        1) The language has some cool features, but overall it encourages people to use it in strange ways (and then I have to fix it). The C++ analogy here is operator overloading. It's a cool feature, but people used to really go crazy with it.

        2) Apple needs to open up their platform. Let people program with whatever language they want (in this sense, .net is superior).

        • Let people program with whatever language they want ...

          You only need to write the macOS-, iOS-, etc., specific parts in Swift. The core of your application can be written in any language you can compile on the OS. You just interface the two via glue layer written in C or Objective-C.

        • But you can program in what ever language you want, including .Net based ones.
          E.g. Lua is quite common, so is Python ... Qt based C++ ... if you do not like the Apple GUI API, etc.

          • It seems you are thinking of OSX, not iOS, whereas I am doing the opposite.

            • Well, Qt based apps live on iOS, and the new .Net based GUI library, someone above mentioned, too.

              However for x-Platform, I switched to Dart. It is surprisingly similar to Swift.

              • Well, Qt based apps live on iOS, and the new .Net based GUI library, someone above mentioned, too.

                Oh, that's good to know.

    • Following a language discussion on facebook, I tried zig. Now I'm actively wanting to do my projects in zig because it's nicer than C but addresses problems at the same level of low abstraction.

      I tried swift and backed away slowly. It seemed to be programmer hostile and quite unstable despite being the 'default' language in xcode.

      Like Python, zig welcomes you in and gives you reasons to hang around.

    • Swift 5 has grown on me.

      I am generally more a fan of "dynamic" languages like Python and Objective-C and even Javascript. That said, my research is all very low level systems programming where C/C++ still rule. Rust is promising, but in some respects it is a solution looking for a problem. The "safety" of Rust is destroyed when using "unsafe" constructs, and there is no way to interface to hardware without using "unsafe" constructs in Rust. I would say Rust's safety and security aspects emerge only when try

      • As an aside, linked lists are NEVER the best choice for a data structure. They are never best in terms of memory use, and they are never best in computational complexity no matter what problem you try to solve with linked lists.

        What about inserting an object in the middle of a list?

        • Extending the array (if it doesn't already have some un-used buffer at the end), bulk shifting everything's memory address - is still very efficient compared to the overhead of wrapping every object with a node with at least a forward pointer.

          With modern CPUs I honestly don't think you'll find any real life scenario where a linked list is a superior choice anymore.

          • What about a list of RAM allocation in the kernel?

          • Extending the array (if it doesn't already have some un-used buffer at the end), bulk shifting everything's memory address - is still very efficient compared to the overhead of wrapping every object with a node with at least a forward pointer.

            Gosh, that is quite an extreme assumption to make. It would depend a lot on the size of each object vs the number of objects in the list as to whether the iteration time vs bulk copy time was worse. This in turn depends greatly on the cache and memory performance of your particular system - not everyone is developing for desktop class systems, and mobile gets pretty fuzzy in terms of capabilities. Also, do you want the code to be generally portable or is it for a specific system? You'd need to consider that

        • On modern computers, vectors will still outperform linked lists for that. Yes, if you do an insert then your intuition might tell you that it's faster with a linked list because with a vector you then have to shift everything after it to the right, whereas a linked list you just modify the pointer to the next item and to reference your new one.

          But, there's a problem: In order to actually get to the point that you want to insert it, you more than likely have to iterate over every single item in the linked li

          • unless you stored the pointer to the specific item somewhere else, which you almost certainly didn't do.

            Very often you do. (although "very often" is relative...in most cases your data set is so small it doesn't matter what algorithm you use).

            • If your data set is small, you want them to be packed together to fit more into the cache.

              If your data set is huge, you want them to be packed together so that the jumps you do aren't entirely random.

              Either way, the whole cache locality thing is old news, but it's surprising that people still don't know about it, and really think that linked data structures with data scattered all around memory can ever be as efficient as contiguous memory.

              • It seems like the only thing you think people do with data structures is iterate over them.

                • That's pretty much all you can ever do with a linked list, actually. If you wanted to pick specific items within the linked list, you either have to iterate the list until you get to the one you want, or you have to store references to them elsewhere, in which case, why bother with a linked list?

      • As an aside, linked lists are NEVER the best choice for a data structure.
        That is plain wrong, especially if the data you want to store has its own pointers to the next one, aka is the list.

        They are never best in terms of memory use,
        That is even more wrong. Read above.

        and they are never best in computational complexity no matter what problem you try to solve with linked lists.
        Sometimes you simply need some things in an iterable order ... and be free to add something at both ends. And for that a linked list

        • especially if the data you want to store has its own pointers to the next one
          Well yeah if your data elements are already linked list then sure keep them as linked, but in practise I find very few data structures are naturally a 1 dimensional linked list that couldn't be an array.

          They are never best in terms of memory use,
          That is even more wrong. Read above.
          Well yeah, in the scenario where you've already forced something to be a linked list, redundantly putting it in array uses more memory. In all other scen

          • For inserting in the middle most CPUs have instructions to shift contents of array so that can be done in a few instructions.
            Yes. But not in "very few time".
            The time scales O(n) by the amount of data to shift ...

        • Sometimes you simply need some things in an iterable order ... and be free to add something at both ends. And for that a linked list is ideal And depending on "problem" you can even add in the middle trivially.

          It is up to you, if you use a linked list, or not. Or make your data structures into linked lists or not. But your claim is imply nonsense.

          No, he's pretty much correct. It's not 1980 anymore. With modern CPUs having features like branch prediction and out of order execution, storing memory discontinuously is inevitably going to be slower than contiguous memory, which linked lists don't give you. If you want to add stuff to both ends, depending on the language you probably want to use a deque. Deque in some languages is basically a linked list, and in more modern languages its a ring buffer. The latter approach isn't necessarily totally contigu

          • I know for a fact that the highest performance TSP solver codes uses various forms of linked lists. Satellite lists for example allow you to perform O(1) reversal of a subpath. Your ring buffer would make that an O(N) operation. Guess what, subpath reversal is an elementary operation in TSP solving. So are the other k-opt moves (which are disconnections of segments of a closed path that reconnect some of them in a potentially reversed orientation to make a different closed path, and all that can be translat

            • I didn't say a ring buffer deque would replace every instance of where you'd think to use a linked list, just that his specific requirement is best done that way, not with linked lists.

              It is possible that a linked list in some way, somehow can be the best choice. It's highly application specific, and that is why modern languages still include a variation of them. But most people tend to use it in places where it really doesn't belong. The person I replied to did exactly that.

              For TSP, I haven't really looked

              • I haven't studied CS either but it's extensively used in mathematical economics. Since many practical optimization problems reduce to it, I'm not sure how is it "mostly just an academic exercise". Even related not-quite-TSP problems like VRP are likely to use the very similar data structures to represent intermediate solutions.

                • I think he means a "template" or "generics" of a linked list where, the linked list and the data they hold (especially in generics) are spread out over memory.

                  A shame he did not study CS, if he at least had read a book about the stuff, he would not talk that nonsense.

                  E.g. in C++ you perhaps would not use a "linked list container class" and have a pointer to your type inside it, you would have an flat object of said type. Or you would only use a "dimensional" type, as in enum NorthSouth { north, south }; and

                  • I think he means a "template" or "generics" of a linked list where, the linked list and the data they hold (especially in generics) are spread out over memory.

                    That is ANY linked list. By definition they do not guarantee contiguous memory, and even in the rare cases where you will get that, you're then wasting cache.

                    https://www.youtube.com/watch?... [youtube.com]

                    A shame he did not study CS, if he at least had read a book about the stuff, he would not talk that nonsense.

                    ... Says the hipster brogrammer who uses a linked list in a situation that is begging for a deque. Kind of like a bad artist getting an art degree in your case.

                    • That is ANY linked list. By definition they do not guarantee contiguous memory
                      That is wrong.
                      a) I gave you an example where the links are inside the data structure.
                      b) I can write my own allocator in C++ - and guarantee that all elements in the linked list are sitting side by side

                      You are simply an idiot who never really read a book about the stuff he wants to argue.

                      Good luck with your CS career ...

                      who uses a linked list in a situation that is begging for a deque
                      The examples I gave do not beg for a dequeue a

          • I explicitly mentioned data-structures where the links are inside the node.

            aka:

            struct Something {
            int myInt;
            String myString;
            Something prev, next;
            }

            Iterating such lists are much much faster than having an array.
            the performance difference probably won't be noticeable, but in the context of high performance code it will make a pretty big difference.
            Exactly. In my example it makes a huge difference, because it is the fastest way to do it, and always was. You hardly find a situation where an array is faster.

            It get

            • I explicitly mentioned data-structures where the links are inside the node. ...

              It gets even better when your links have their own dimensions, like up, down, north, west, south, east.

              Here's what you said:

              Sometimes you simply need some things in an iterable order ... and be free to add something at both ends. And for that a linked list is ideal And depending on "problem" you can even add in the middle trivially.

              Uh huh, "both" up, down, north, west...and in the middle of them too!

              Where did you say you got your degree again?

              • North east west south were examples.
                I actually wrote a small C++ template based example.

                No idea what is wrong with your comprehension level.

                No one with a degree would argue with me about the example I gave: it was plain obvious how it works.

                My degree is from KiT.

            • It gets even better when your links have their own dimensions, like up, down, north, west, south, east.

              CAD Applications are a great example for that.

              Wait - for what would you actually use anything even remotely like that in CAD? You're not thinking about storing vertices with that I hope?

              And for your struct, what is the practical use for that?

              • Not sure if this is what he had in mind, but for example winged-edge is a fairly famous data structure in CAD applications that needs several "directions" of traversal.

              • Sometimes you simple not only have a data structure like:

                struct {
                double x;
                double y;
                } tPoint;

                But you already know how the structure is used. E.g. that every point can only be in one list of points, forming an area.

                Then you might want to have a structure look like this:

                struct {
                double x;
                double y;
                tPoint next;
                } tPoint;

                And no: there wont be random arrays that refer to those points.

                You're not

      • I am generally more a fan of "dynamic" languages like Python and Objective-C and even Javascript. That said, my research is all very low level systems programming where C/C++ still rule. Rust is promising, but in some respects it is a solution looking for a problem. The "safety" of Rust is destroyed when using "unsafe" constructs, and there is no way to interface to hardware without using "unsafe" constructs in Rust. I would say Rust's safety and security aspects emerge only when trying to implement constructs that should not be in a system programming context to begin with.

        Not true. At all. People keep repeating this stupid line on slashdot, and it's just outright false.

        Even in unsafe rust, you still have a ton of safety guarantees, so it's not "destroyed" in any sense of the word. Unsafe allows you to do three things that can lead to undefined behavior if not done correctly: Dereference raw pointers, read or write data from a mutable static [rust-lang.org] variable, or read or write data from C union elements. When you're interacting with hardware, the only one of those you should need is t

      • As an aside, linked lists are NEVER the best choice for a data structure. They are never best in terms of memory use, and they are never best in computational complexity no matter what problem you try to solve with linked lists.

        OK, please tell us how do you for example beat satellite lists in TSP solver code.

        They are never best in terms of memory use

        I'd be somewhat skeptical about this claim at the very least when it comes to shared-structure representation of hierarchical environments. Sharing data about the bindings in the surrounding environment means you need O(1) space to represent all bindings outside of your current environment, no matter how many are there, and it doesn't get any smaller than that. But this implies a "next" link pointing to the immediately surroun

        • I recommend sparse matrix or hash table based solutions for TSP style problems, but I also suggest finding solutions that do not look like TSP problems. I certainly suggest that solving TSP problems is not usually considered "systems programming".

          - Linked list requires O(n) for insertion or deletion at any place other than the head unless of course you use doubly linked list in which case you are using even more memory and might as well use a binary tree. The tree at least gives you O(Log n) search as oppos

          • I recommend sparse matrix or hash table based solutions for TSP style problems

            How? To represent a permutation using a permutation matrix, which is sparse? But that reduces to a vector, which has the same problem of certain desired elementary operations working in O(N).

            Linked list requires O(n) for insertion or deletion at any place other than the head unless of course you use doubly linked list

            Honestly I fail to see how being doubly linked changes anything about that operation. Either you already have the right pointer into the middle of the list and then it's O(1) regardless of whether it's doubly or singly linked, or you don't and then it's O(N) in either case.

            If search is not a need, a simple stack provides identical performance to linked list without requiring storage for links.

            But of course, CDR-coding trivially removes tho

    • Re: (Score:2)

      by 605dave ( 722736 )

      Have you ever used it? Because I have used it every day for the last five years, and it is great. Tell me about your personal experience? Or are you just a fan boi dissing things you know nothing about?

      • Have you ever used it?

        Yes.

        Because I have used it every day for the last five years, and it is great

        Of course you think so, it's mandatory for Apple fanbois. If you want to make a criticism of Swift in Apple forums, you can't just make it. You have to start your complaint with a disclaimer, "Of course Swift is a great language, but..."

  • Actively worse than Objective C, which is already almost as bad as it could possibly be. Sorry to the creator of the language and all, but it will never be a good language.

    • Genuine question, why do you dislike Swift so much?

      I do find with Swift I need a lot more forward planning of my code, where with Python I can make it up as I go along a lot easier. Also if I haven't done Swift in a few months I do have to re-learn a lot, especially when it comes to how protocols and generics get along or not.

      Though the benefit is, if my Swift code compiles, it works - I can refactor it safely, it's super fast. Enums and switch statements are surprisingly powerful, extensions work without s

      • Re: (Score:2)

        by Bahbus ( 1180627 )

        Because Swift is only useful for the Apple ecosystem (in general - I know there are a few side cases). It's basically a weird evolution of Objective C, which, as stated, is already bad (and never standardized). There are probably some super specific use cases for Swift, but C# is just a better language all around for development. It's standardized and can be used to easily create cross-platform apps in one go without a ton of fuss. Python, standardized and great for generalized scripting. Very good, and the

  • another fad language had a peak but is fading away.

  • This is a management problem. They should really be engaging strongly with the Swift programming community to get new ideas and solicit opinions and alternatives on proposed directions. This behind closed doors approach is too outdated and leads to these interpersonal conflicts torpedoing good working relationships. They should look at how Microsoft have been engaging with the C# developer community https://github.com/dotnet/csha... [github.com] , they've been managing this so well it's hard to believe it's run by Micro

    • This is a management problem. They should really be engaging strongly with the Swift programming community to get new ideas and solicit opinions and alternatives on proposed directions

      The post addressed that point. They don't want to have a community based language.

  • If you move on from being in charge, don't start bitching when the new lead takes the project in a different direction. You can't have it both ways - either stay they and put up with the "toxic enviroment" (bitter ex-manager speak for "they disagreed with my vision and wouldn't do what I suggested all the time") or go find something else to do.

    • Re: (Score:2)

      by Mal-2 ( 675116 )

      Open Source provides another option: fork it. (Or tell the others to go fork themselves.)

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close