Apple Releases First Preview of Swift 3.0 (macrumors.com) 227
DaGoatSpanka quotes a report from MacRumors: Apple yesterday released the first preview build of Swift 3.0, a major update to Apple's open source Swift programming language. Swift 3.0's official release is expected to come in late 2016 after proposed changes are finalized. The Swift 3.0 preview can be downloaded from the official Swift website. There are versions of Swift 3.0 available for Xcode 7.2, Ubuntu 14.04, and Ubuntu 15.10. [Swift 3.0 is not source compatible with Swift 2.2 as it introduces source-breaking changes, but going forward, the goal is to make Swift 3.0 source compatible with future Swift language updates.] Swift 3.0 will likely be shown at Apple's upcoming Worldwide Developers Conference (WWDC).
what did they break this time (Score:4, Funny)
Last release broke for loops, what was broken now? If statements??
Re:what did they break this time (Score:5, Informative)
No, function calls.
https://www.hackingwithswift.c... [hackingwithswift.com]
Yes, it'll make code shorter and simpler, but renaming most library methods is still a kick in the teeth to developers.
Re: what did they break this time (Score:3)
Re: (Score:3)
I agree. Every damn time they update Xcode, I'm having to refactor code. This is bullshit.
Re:what did they break this time (Score:5, Insightful)
And enums, apparently.
I understand having it consistent (which is their argument for the changes), but this just means that they they screwed it up in 1 and 2. Seriously, you change naming conventions from UpperCamelCase to lowerCamelCase? Now? That's the sort of decision that should be made (with reasons) when you are designing the language the first time; and then you have a group of really nitpicky, anal-retentive types go through the language to check for all the inconsistencies, and then you fix them, and then you release it. This whole thing screams amateur hour; yeah, I understand it a little more when python says 'oops, we messed up because there was a single guy who designed the language, and he didn't have a team behind him'. However, this is frigging Apple, and they have lots of people and money, and Swift was (I hope??) intended from pretty early on to be where people were going to go, so it should have been done right the first time or two.
Re:what did they break this time (Score:5, Insightful)
Swift inherited this mess from Objective-C. The Swift team stuck with the old conventions for a while to make the transition easier, but now they want to shed the ugly bits and move forward. I'm not sure there's a better way they could have handled this, to be honest. Everything has tradeoffs.
Re: (Score:2)
Lots of choices. (Score:4, Interesting)
I write applications (big ones) for OS X using c and c++. Targeting 10.6.8, my code still works fine under 10.11 today. It ports to Windows easily as well. Re Windows, targeting XP, it all works right up to the current version of Windows. XP broke the OS windowing metrics, otherwise my stuff would still work with Win98. :) Apple hasn't done anything quite that stupid. Well, yet. 10.6.8 is where 64-bit code began to work; and it's the last OS X that supports PPC (my HP calculator emulation, bunch of audio drivers, my old mame (which is actually fairly important to me, because some of those games are my code, and code from close friends in the day, and I want that stuff to work as long as possible), all kinds of stuff in Appleworks, etc., etc. So 10.6.8 is where I planted my flag, so to speak.
Of course if you decide Swift or Objective C is your chosen coding mechanism, that's fine, but there's no externally imposed requirement that it must be your coding mechanism; at the worst, a few boilerplate intermediate layers based on basic OS APIs will do ya.
Sometimes -- for instance, with Apple's OS file dialogs -- the stuff Apple supplies is either broken, feature-poor, or both. After being bitten over and over by that stupid file dialog, I spent an afternoon and wrote my own. Which works a damn sight better, and faster, and with less hangups than Apple's does. My users benefit a great deal from my unwillingness to let Apple screw them with the bug-infested trail of tears they leave behind them as they blunder onwards into their new and shinier future.
Same thing for most (all?) of Apple and Microsoft's "new and shiny." For every new thing you decide you depend on in the OS, you're leaving users behind, and making your code more and more dependent upon Apple's latest whim.
Which, again, you can do, absolutely -- but you don't have to.
Almost every time I see some application that "requires" some fairly late version of an operating system, I think dark thoughts. There are few things, particularly things that are focused upon new features, where it is likely reasonable. But mostly... not. Mostly it's just thoughtless development where the user takes a back seat to... let's face it: "shiny."
Apple is expected to be perfect on the first try? (Score:3)
I'm not aware of any good programming language that never required any revision. So you are basically holding Apple to a standard that noone else has ever met before...
But hey, if it makes you feel better about your own miserable life to complain on the internet...
Re: (Score:2)
The set of things classified as a "revision" is obviously a superset of things classified as "breaking change". If you stay out of the "breaking change" category (e.g. only new syntax that did not previously compile) then it isn't a problem.
Yes, there are plenty of language updates which do not break existing code. When they do, many language design teams strive to limit any breaking changes to concepts that are only used by a very small number of people, or bugs which result in undocumented behaviors tha
Re: (Score:3)
Have other languages made the syntax incompatible on each version?
Compatibility was broken between Python 2 and Python 3 to clean up the language. For example, print "Text" in Python 2 got replaced by print("Text") in Python 3.
Python != Python; now Swift != Swift. (Score:3)
Python 3 is not Python specifically because it will not run Python 2 code. Python 3 isn't just a "little" different. It's a lot different. Which is fine. Although they should have called it something other than Python, frankly, because it confuses a lot of people that Python != Python. Justifiably so.
Swift appears to be undergoing the exact same schism. The new Swift is not the old Swift; if it breaks your compliant code, it's a new language. If it breaks some undocumented crap, that's something else entire
Re: (Score:3, Insightful)
And Qt5 breaks code written for Qt4 which, in turn, breaks code written for Qt3. And Windows 10 breaks drivers written for Windows 8. And Linux 2.6 broke code written for Linux 2.4 which broke code written for Linux 2.2. And I'm pretty sure modern C broke code written for ye olde C.
That's what major version numbers are for: to announce Major Breakage (or possibly even General Breakage) and his mighty army of doom.
Re: (Score:3)
Right. And it took, what, 15 years for Python to accumulate enough cruft that they decided to do this kind of major breaking milestone?
Here, we're talking about a language that isn't even 2 years old.
Re:what did they break this time (Score:5, Informative)
Clearly all the people complaining don't actually use Swift for production code and/or just like to complain.
I converted my antenna modelling project to 3.0 in about three minutes. Most of this was due to the new selector syntax, which I had to spend time looking up on Stackoverflow. The rest was trivial, and my code is cleaner and shorter than ever.
Re: (Score:2)
If the code is in production it is production code.
Plain and simply.
No idea why you want to piss every one on /. off all the time with your insults.
Re: (Score:3)
Well that sounds an awful lot like what Swift is!
They both target into the same direction, but rust is a far more "safe" language than Swift is.
While Swift has already seen major adoption and use in the real world, we haven't seen that from Rust.
Quite on the contrary: https://www.rust-lang.org/frie... [rust-lang.org]
And that page only contains the corporate users of rust. There is a really big community of free time rust developers as well.
Others have pointed out that C++14 and C++17 actually make much of Rust redundant.
That might be partially right, but C++ has lots and lots of backwards compatibility to very old concepts. C++ relies on the C preprocessor, which is very limited, on doing macros. Thanks to this you don't have scoped macros for example
C++ has templates and lambdas (Score:2)
C++ relies on the C preprocessor, which is very limited, on doing macros.
C++ has type-safe and/or scoped alternatives to a lot of things that used to need C macros.
Thanks to this you don't have scoped macros for example.
C++ has namespaced templates.
In rust the macro system is done much later in the process, so that you can declare a macro inside a function, and after the } closing brace the macro scope ends!
In modern C++, you can likewise declare a lambda inside a function (example [nesdev.com]). This could replace the C-inspired use of macros as ghetto inline functions.
Re: (Score:2)
C++ has namespaced templates.
The template system in C++ is really not something the language creators can be proud of. If you write a templated class, why do you have to prepend the template name before each and every method?? And it gets even harder if you don't want to put the entire class implementation into the header, but a separate file.
In Rust making templated structs/functions/traits is really easy, but you are a bit more limited. For example, you can't do a template on things different than scopes and types (like numbers). May
Re: (Score:2)
They were also added later on in C++'s development.
Well yeah this is one of the problems of C++. Rust is a very clean language because it was designed with lots of features in mind, while C++ was published, and then those features got added on top, for decades. You end up with a very messy end product. Yes, Rust will most likely meet this fate as well, but when its outdated you can simply switch over to a newer language that promises to be stable.
This is what Rust is about for me: breaking backwards compatibility with C/C++ so that you have a clean base wit
Re: (Score:2)
Swift is infected as well: https://swift.org/community/#c... [swift.org]
The claws of the SJWs are sharp and they are drilled deep into the flesh of the software development industry.
But that code of conduct usually only applies to the core project (like the compiler), and many libraries. If you "only" are an user you won't get harassed by any SJW.
Re: (Score:2)
Swift is infected as well: https://swift.org/community/#c... [swift.org]
I'm about as anti-Social Justice Whiner as they come, but I don't really see anything to object to in the code of conduct posted above.
Re: (Score:2)
but rust is a far more "safe" language than Swift is.
Rust has been infected with cancer of SJW's and a stupidly crazy code of conduct [rust-lang.org]. All the good developers will leave soon, driven away by the anti-meritocracists.
I'm no SJW; far from it. But Slashdot could do worse than to adopt at least some of those "Stupidly Crazy" Code of Conduct rules.
Re: (Score:3)
Today I learned that SJW means 'civility'.
Re: (Score:2)
If this is too burdensome for you, then perhaps you need to get off your phone and listen to the teacher, there may be a long division test tomorrow.
I'm sure the adults won't mind waiting a few years until you claim your adulthood.
Re: (Score:2)
Re: (Score:2)
The Rust implementation is buggy. I know, because I've experienced such bugs first hand.
Can you tell me about the bugs you experienced, and the projects you've tried to do with Rust? There is a troll on slashdot who uses this same argument, and that troll is a bit unfounded.
while still being a familiar and friendly language
The examples of swift I saw don't really seem friendly to me. But I can't judge Swift's friendliness as I haven't programmed with swift.
Rust, on the other hand, has so far only shown itself to be a painful language
I haven't coded much in Rust myself, but it didn't feel painful. Yes, there is a high entry barrier due to the many compiler checks, but its generally feeling not painful for me. idk, I'm a
Re: (Score:2)
Swift > Objective C (Score:3)
But that's not saying much...
Apple's infinite loop road named for engineering (Score:2, Insightful)
No Windows version... (Score:3)
Re: (Score:3)
You might want to use rust instead, it has first class support for windows, linux and mac:
https://github.com/rust-lang-n... [github.com]
Where is the source tarball? (Score:2)
Is anybody going to bite on a new proprietary language? Have we not learned anything from what Oracle has done with Java?
Re: (Score:2)
Re: (Score:3)
To be fair, the language just hit two years old today. Most languages were still in flux at that age.
Re: (Score:2)
Make no mistake: this isn't Swift version 3 - it is the language Swift 3. I guess Swift 4 will not be (completely) backwards compatible either. Because the idea of a programming language evolving from a stable, thoroughly tested base specification is old - not fit for the Apple(TM) generation...
You conveniently missed the part in TFS where Apple said they are going to try not to make sweeping syntactic changes from here on out.
Re: (Score:2)
Because the idea of a programming language evolving from a stable, thoroughly tested base specification is old....
One of the many reasons I stay with Java is stability. Every single piece of Java code I have written since 1998 (when I first started writing Java code) still runs unmodified.
Changing API's is the main reason I stopped programming with Qt. I don't want to have to rewrite all my software every few years. I just don't have the time for it.
Re:The "new" trend - eternal Alpha... (Score:4, Insightful)
Like C? Even C has broken backwards compatibility at times. C started out in the 70's, yet we still have C99. Oh wait, that didn't work, we have C11. 40 years later we're still changing it.
C++ was once a superset of C. It is no longer, and some C code can not be compiled in C++ compilers.
Java has methods that are deprecated.
Swift is a pretty new language. It's also a bit of a new paradigm. You start with an idea of what you want in the language, most works, some doesn't, you try again. Some of this breaks backwards compatibility. Better to do this now, then 40 years later.
Re: (Score:2)
C++ was once a superset of C. It is no longer, and some C code can not be compiled in C++ compilers
It was never a strict superset since it introduced new keyword(s) (see what I did there?). The superset of C and C++ was most of C however. It still is.
Re: (Score:2)
Apple has always done this with everything they do. They don't treat backwards-compatibility as ultra important like Microsoft does.
No! instead! MS just obsoletes and renames entire technologies and APIs on a regular basis.
Re: (Score:2)
Apple has always done this with everything they do. They don't treat backwards-compatibility as ultra important like Microsoft does.
That's because they still write their major apps in Objective-C.
Re: (Score:3)
They probably should have kept Swift behind closed doors while tinkering with it to make all of these changes. I realize that you need people using the l
Re: (Score:2)
Apple developers are probably used to the abuse by this point considering that the Mac itself has undergone three architecture changes as they moved from the Motorola 68000 to IBM PowerPC and then to x86. I wouldn't be surprised if in another five years they've completed abandoned x86 and move to using their own ARM SoC designs for all of their products.
It's not abuse; it's evolution, and Apple, it's development community (assisted in no small measure by some VERY clever tools and APIs by Apple), and it's OSes have done a FANTASTIC job of making those transitions nearly painless for the average Mac user.
Can you imagine the clusterfuck that would ensue if MS tried to do that with Windows? Hell, they couldn't even do a transition from 32 bit to 64 bit ON THE SAME CPU without a bunch of bullshit THAT AFFECTS THE USER (separate 32 and 64 bit OSes, APIs, Driv
Re: (Score:2)
True, but relatively speaking, the change overs weren't completely horrific. The 68K and Mac OS 9 emulation stuck around for quite a while before being dropped. The "Universal apps" were also quite a clever use of NeXT's tech with multi-arch binaries.
I think you can STILL run Carbon Apps (as long as they are at least universal binary), even though Carbon has been deprecated for SEVERAL years now.
Same happens for open source languages! (Score:2, Interesting)
Your argument makes no sense.
First of all, there's no such thing as "obsolete" knowledge when it comes to programming languages. This knowledge is very useful if you ever have to maintain code. And the newer knowledge typically builds upon the older knowledge.
Additionally, programming languages developed by open source communities or working groups suffer from exactly the same problem. Yes, when moving to a new version of a programming language we as programmers need to learn new things! It doesn't matter i
Re:Same happens for open source languages! (Score:5, Insightful)
Re:Same happens for open source languages! (Score:5, Insightful)
C++ advances and still maintains backward compatibility. It does matter. If you learned C++ 10 years ago, that knowledge still applies today.
There have been breaking changes in C++ [stackoverflow.com] in the past.
Swift 2.2 was released in MARCH 16, 2016, and is already obsolete. Ridiculous.
Hardly obsolete. No-one is saying you now can't still write Swift in 2.2 or even 1. Swift is not included in iOS and is instead bundled with the App that uses it. You just need to use the tooling version that supports your desired Swift version.
Re: (Score:3)
Swift 2.2 *is* obsolete. All the libraries will have switched to swift 3 and in order to use the new versions of the libraries (which may have fixed bugs) you need to update your entire codebase to the new language.
Generally though, you *can* do backwards incompatible changes for certain functionalities of your language, just make them in a way that compilation breaks. Nobody wants to debug a problem just because some standard library function changed the order of its arguments.
Re: (Score:3)
Yes, there are breaking changes in C++. In most cases, they go through two iterations of the standard - one to deprecate the old thing, another to remove or replace it. They also look at actual usage to see how safe they have to play - e.g. operator ++ for bools is still not removed, even though it has been deprecated since C++98.
What this means is that, in practice, you can take almost any C++98 codebase, and compile it with a C++14 compiler with zero changes - your chances of actually running into any of
Re: (Score:2)
In 5 years Swift won't even be around. Apple will have moved on to something else. But enjoy chasing them around.
HOW long has it been since Apple moved from Pascal as the preferred language to Objective-C?
Apple does NOT have a history of creating and abandoning Languages willy-nilly (Dylan notwithstanding).
Re: (Score:2)
Apple adopted Objective-C in the late 1990s (first public release was with OS X in 2000). I don't think they'll drop Swift all that quickly.
Re: (Score:2, Troll)
Too bad if you put time into learning Swift 2.0. That knowledge is now obsolete. And when Swift 4.0 comes out, your Swift 3.0 knowledge will be obsolete. My advice to young programmers: avoid languages owned by corporations. They have time and money to waste. You don't.
LOL I take it that you have never looked at C++, an ISO standardized language. Code written in C++98 and C++14 almost appear to be written in different languages.
And actually one of the advantages of a corporate controlled language is you totally avoid the "Designed by committee approach" to things.
Re: (Score:3)
Re: (Score:2)
And as I mentioned above there have been breaking changes in C++
Re: (Score:3)
Re: (Score:2)
Yes, the newer language should be experiencing much more flux as it is developed. Which, by the way, is exactly what apple told developers to expect.
Re: (Score:2)
Re:Swift 2.0 (Score:4, Informative)
Apple stated when Swift 1.0 was released that it was a work in progress and that there would be a flurry of updates coming and that, while they would maintain binary compatibility, they would not be able to maintain source compatibility as they changed and streamlined the language. Anyone using swift is well aware of this.
Re: (Score:2)
Re:Swift 2.0 (Score:4, Informative)
Not everyone is a lazy shit. It takes about 5 minutes to update a moderately-sized code base from 2.2 to 3.0 syntax. Xcode provides a built-in tool to do it for you, and you just have to fix up the few cases it doesn't find on its own. It's really trivial for anyone who isn't a spoon-fed piece of dirt.
Re: (Score:2)
C++ is 30+ years old. Swift 2.2 is 4 MONTHS old and is obsolete. I hope you see the difference here.
Yes, C++ is mature (God help it). Swift is still evolving.
Re: (Score:2)
Apache License 2.0 (Score:3)
Apple could discontinue Swift tomorrow and you would by out of luck.
Unless someone else takes up maintainership of a fork of Swift under the Apache License [github.com].
Re: (Score:2)
Re: (Score:2)
Sure but C++98 was 18 YEARS ago. Swift 2.2 was released 4 MONTHS AGO. What a joke.
Is that you Donald?
Re: (Score:2)
Re: (Score:2)
I guess the fact that 18 years >> 4 months is lost on you.
Obviously you weren't around 18 years ago, otherwise you wouldn't be comparing Apples to Oranges. New languages in their infancy are always in a state of flux.
Oh well, enjoy Swift until Apple gets bored with it and discontinues it and replaces it with something "better".
What, things change? Say it ain't so.
Re: (Score:2)
Re: (Score:2)
I was around 18 years ago. That is my point: why would you use a language that is in flux and a single corporate entity can control or drop on their whim?
Oh please enlighten me then. What is this magical language that you would have me develop in?
And no: things don't have to change every 4 months.
As stated previously by me and several other people, Apple stated at the outset that Swift would go through syntactical changes until it settled down. But it appears that you think a language needs to spring from the bosom of its creator in a perfect yet fixed, state.
But go ahead and waste your time "learning" Swift, Rust, ObjC, etc if you want.
Knowledge is never wasted.
Re: (Score:3)
Perhaps a nicer way to express it might have been "As of right now, this language is too unstable for me to use in production. I'll let others be the guinea pigs until it matures."
Re: (Score:3)
I think the reason you are attracting such replies is that you appear to be completely ignoring the changes in computing since C++ came out. The two are clearly not comparable, as C++ was developed during a time where access to the internet was out of reach of most people. Where languages had to be incredibly stable simply because changes to them could not be disseminated to all affected parties very quickly. Where documentation was in printed books instead of digital. Where transpilers were a lot less
Re: (Score:2)
Re: (Score:3)
Too bad if you put time into learning Swift 2.0. That knowledge is now obsolete. And when Swift 4.0 comes out, your Swift 3.0 knowledge will be obsolete. My advice to young programmers: avoid languages owned by corporations. They have time and money to waste. You don't.
LOL I take it that you have never looked at C++, an ISO standardized language. Code written in C++98 and C++14 almost appear to be written in different languages.
And actually one of the advantages of a corporate controlled language is you totally avoid the "Designed by committee approach" to things.
You know, I sorta /broadly/ agree, but c'mon - you're comparing differences across 18 years for C++ to differences across 4 months for Swift. Why not compare C++11 and C++14?
Why not compare C++85 with C++89? (Score:2)
Some minor tweaks added in '89 (from wikipedia): multiple inheritance, abstract classes, static member functions, const member functions, and protected members.
And even later still were added: templates, exceptions, namespaces, new casts, and a boolean type.
C++ underwent way more fundamental changes in its first 10 years than Swift has undergone in its first 2...so maybe we should all just chill out a little bit.
Re: (Score:3)
Some minor tweaks added in '89 (from wikipedia): multiple inheritance, abstract classes, static member functions, const member functions, and protected members.
And even later still were added: templates, exceptions, namespaces, new casts, and a boolean type.
C++ underwent way more fundamental changes in its first 10 years than Swift has undergone in its first 2...so maybe we should all just chill out a little bit.
From what I remember of C++98 (the first C++ ANSI standard; I'm not sure where you got '89 from - perhaps you were thinking of C89 - the first ANSI C standard?), the committee used the standard to merely document the most popular behaviours of the most common compilers, hence by design the C++98 broke no existing code.
And, as far as I can tell, the committee repeats this intention for each new standard - you can be almost guaranteed ("I've not heard of it happening") that a new C++ standard will not break
Re: (Score:2)
As obsolet as my knowlege in
* Cobol
* K&R C
* Pascal
* Java 1.1
???
You seem not to work in the software industry.
Re: (Score:2)
Re: (Score:2)
So, I'm not able to maintain my Swift 2.2 code anymore just because Swift 3.0 or 4.0 is out?
Strange, I had assumed my old Swift 2.2 compiler just runs as usually.
What strange Computers are you working on that old Compilers suddenly stop working?
Moron? Again so insulting ... you suffer from an ulkur or something?
However you are right about Java 1.1, another corporate product. :D
You missquote me. My Java 1.1 knowledge is still needed for maintaining legacy code, just as my rudimentary Cobol knowledge
Re: (Score:3)
So, I'm not able to maintain my Swift 2.2 code anymore just because Swift 3.0 or 4.0 is out?
Strange, I had assumed my old Swift 2.2 compiler just runs as usually.
Well Xcode 7 only came with a Swift 2 compiler, so you could not maintain Swift 1 code with that version. I assume that once Swift 3 is officially out that Xcode will pull a similar trick regarding Swift 2.x
However Apple does supply migration tools that the "person" you are replying too is seeming to totally ignore.
Re: (Score:2)
Re: (Score:2)
Discontinue? They open-sourced the standard library, not to mention the compiler. If someone wants to use it, they can, no matter what Apple does with it.
Re: (Score:3, Informative)
Swift is a good idea of how to do things wrong. But what about C#. It's made my Microsoft, who everybody loves to hate, yet C# and the .Net framework is probably one of the best development environments out there. They have a pretty good record of not breaking too many things with new releases. They also do pretty well adding new features that programmers want. I prefer it much more to other languages that aren't controlled by corporations such as PHP, Python, or C++..
Re: (Score:2)
What corporations control Python?
Re: (Score:2)
What corporations control Python?
I can think of two possibilities: Python Software Foundation Inc. [python.org] and Dropbox, which employs Python BDFL Guido van Rossum.
Re: (Score:2)
C# and the .Net framework is probably one of the best development environments out there.
Add to that the quality of Visual Studio compare to other IDEs. Case in point Xcode can't refactor Swift.
Re: (Score:2)
avoid languages owned by corporations
So you suggest C++ is any better? One of the companies at the table which determines the future of C++ is Microsoft, and they want as much lock-in into their OS as possible. This has caused things like multi-threading not appear until 2011, and only on the pressure of other languages as C++. Coding cross platform programs that exceed the simple hello-world in C++ is entirely impossible except for very simple hello-world programs if you don't use libraries. In other languages this is true of course as well,
Re: (Score:2)
Re: (Score:2)
Microsoft controls the MSVC compiler which is one of the C++ implementations, and this gives microsoft a seat at the table: https://isocpp.org/std/the-com... [isocpp.org]
Only because C++ has multiple compiler vendors it does not mean that the vendors do not try to do evil stuff with the control they have over the compilers, and therefore over the users. The usual suspect here is always Microsoft.
You may not be locked in into a particular compiler vendor, but as the std is very small you either use the unofficial extensi
Re:Swift 2.0 (Score:4, Informative)
Python is controlled by a single person. (Score:2)
should the world stop using Python?
And PDP11 ML isn't a programming language, dumbass.
Re: (Score:2)
Erm, as much as I despcie your parent for his foul posts, you are wrong.
Or your english is bad.
www.ml1.org.uk/pdf/ml1apph.pdf
Obviously he ment "ML" running on "PDP11".
And yes, ML is a programming language.
However I belive he ment this language: https://en.wikipedia.org/wiki/... [wikipedia.org] and not that JCL described in the PDF above.
Re: (Score:2)
He said PDP11 ML, which I assumed meant the PDP11 machine-language or macro-assembly language--otherwise what's the point of saying "PDP11"?
Re: (Score:2)
So you are saying my PDP11 ML knowledge isn't obsolete?
Different people define "obsolete" in different ways. I might feel justified in calling my 6502 assembly language knowledge not obsolete because just last year I found work as lead programmer for a project using it [3dcartstores.com].
it is a warning to avoid languages controlled by a single corporate entity.
Which non-retro ISA isn't controlled by one company or a small handful thereof? ARM is controlled by ARM Ltd., and x86-64 is controlled by the Intel/AMD cartel. This leaves what? An older version of MIPS that Loongson processor adopted?
Re: (Score:2)
Different people define "obsolete" in different ways. I might feel justified in calling my 6502 assembly language knowledge not obsolete because just last year I found work as lead programmer for a project using it [3dcartstores.com].
Hey! I read somewhere a few years ago that the 6502 is/was the most popular CPU core in application-specific ICs. Might not be true anymore, but you don't exactly need a 32 bit ARM for a LOT of things even now, and PICs are too pricey for a lot of applications.
Plus, there isn't a more "accessible" ML than the 650x instruction set.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
If by "rewrite" you mean "spend 5 minutes using the built-in Xcode wizard", I guess just about the entire world. It's a shame you choose to be a degenerate shit.
Re: (Score:3)
So this language is so "open" that it's only usable within Xcode? It sounds like a small world propritary deal.
And 5 seconds on google finds Introduction to Open source Swift on Linux [raywenderlich.com]
Re: (Score:2)
Re: (Score:2)
None of their products work well. They're all hopelessly out of date. Why would anyone ever use Swift? Java is far superior.
God DAMN!!!
Some people will even bitch when somebody GIVES them something!!!
Now go crawl back under your slime-encrusted rock and DIE MOTHERFUCKER DIE!!!!
You are not worth wasting the planet's oxygen.