I know your making a big effort to build Fire … after living with the maturation of Xcode from the dicey 3.0 days until now … I don’t really want to go through that again. Is any one playing around with building a Xcode project template for Android using the Silver compiler … something like this …
http://code.davidjanes.com/blog/2009/11/20/how-to-use-xcode-for-android-projects/
??
The problem is that Xcode does not have a stable integration API. any work we’d put into integrating even the simplest logic into Xcode, would break with Xcode 6.0.1, if past is prolog.
The same goes for Xcode templates. we ship those for DA, and they break with every damn update. In fact, we haven’t updated them for Xcode 6 yet and will go with a different solution, moving forward…
I completely understand that you can’t build a product on such a moving foundation. But my mind is wandering.
I agree with your caution here given Apple’s history. How about working with Jetbrains to integrate with AppCode? Stable extension API and it’s already in use by a lot of your potential market - anyone who’s a heavy C++ user has hopefully found the much better experience AppCode offers. They already have Swift parsing integration and you would seem to be natural allies.
(Just to clarify the C++ reference - a lot of the const and semantic declarative style in Swift is very natural to C++ programmers, we’re not all just OO people!)
Two problems with that. well, three really
(a) doing an IDE integration is A LOT of work. way more than the core compiler. I’d rather not do “yet another IDE”, just for kicks, as it basically doubles your resources needed.
(b) JetBrains IDE is all Java. our core compiler and shared IDE smarts are all .NET/Mono. Java and Mono cannot live in the same process space on UNIX, without interfering. That would make integrating a real pain.
© i really don’t like the JetBrains IDEs. They feel clunky and Java-y.
For now, our focus is to make Fire awesome, for developers on Mac, and stick to VS for developers on Windows.
With regard to AppCode integration you should probably take another look at this…
First though you may not like JetBrains IDEs a large majority of Professional developers do, especially those targeting the platforms you support.
But the main reason to revisit it is the recent developments in the JetBrains ecosystem. Such as the stuff they are doing with Project Rider (codename for their stand alone C# IDE), the fact they are the basis for Android Studio, and that they have a fully working Swift IDE which is included in CLion now aswell as AppCode, therefore they will have working tools that work with all your target platform environments (.NET/Android/Java/Cocoa), and fully working edit time support for Swift and C# two of your 3 supported languages.
Having the ability to integrate the Elements compiler into the platform would be a game changer for the adoption of Silver and Elements, the exposure alone would probably pay for the extra resource requirements in no time.
In regard to the Java and Mono issue, this does not seem to be a problem for JetBrains a recent talk they gave about the architecture of Rider they are using Resharper’s backend which is written in .NET and interfacing .NET/Mono to the Java front end, allowing them to share most of the IDE smarts with the Resharper Visual Studio plugin which is entirely written in C#.
Yeah, it all comes down to point (a) again. We’re maxed out supporting two IDEs — Visual Studio and Fire, and we’re focusing on those two. Fire is our IDE for Mac, Visual Studio for Windows. With that, we have all major platforms covered where people do coding, IMHO. At least until the year of Linux on the Desktop arrives…
I can understand the appeal of wanting Elements in the JetBtrains IDE, but i don’t see this happening any time soon, we just dont have the resources for not, to spread our focus across more IDEs, sorry.
I don’t use VS, XCode or Fire, but another tool, and I get more than enough integration using the Elements command line tools, online resources and my own tinkering. I do use Fire to change the project file and the like, and maybe debugging on occasion, but that’s pretty infrequent.
You’ve got to ask yourself how powerful your tools are if they can’t effectively integrate with command line compilers and tools. It’s understandable to want someone else to make your life easy but I’m just glad that RemObjects are in business and are working on tools that cut across the “my language/IDE/ecosystem or the highway” paradigm of the bigger players and help little developers like me actually solve big problems.
Just my 2 cents…
‘darkov’ at no point did I say that I can’t or haven’t put together integration with my tools. Due to my past work I have a rather large library of msbuild file auto-generators that can work directly from multiple source project types / IDEs along with msbuild/xbuild invocation and source error output remapping so I was able to piece together decent compile/deploy integration with all my IDEs irrelevant of deployment platform without ever having to touch Fire. But most people won’t want have the inclination to to do this, I’ll take a guess you’re some way along the Autism/Aspergers spectrum so this empathy would be lost on you.
The key reason for recommending it to be revisited is they would probably find that JetBrains might actually be receptive to doing the integration themselves - they have pretty much all the required components already, or in the works - so it might have been worth opening a dialogue. At the end of the day Fire is the first thing that OSX users see when interfacing with Silver/Elements and it doesn’t create a good impression, it’s a very poor impersonation of an IDE.
RemObjects strength is the compiler, getting non-core stuff like an IDE to people who do that for a business - without taking away from RemObjects bottom line - would just be smart business practice.
Just my tuppence worth (about 3 cents at the current rate)…
Thanx for the kind words,much appreciated.
Yes, clearly I’m autistic. Thank you for your diagnosis.
But back here in the real world, it’s normal to expect any half decent programmer to hack together some solutions for building to suit their particular needs, since they tend to be very particular, but it’s not reasonable to expect a small vendor of tools to cover every, or even many, environment or tools.
You seem to be smitten by JetBrains. That’s great. Personally I don’t give a toss about it, and I’d have a lot of problems with RemObjects investing time or money in supporting it because there are things they could be working on that benefit me, since I don’t use JetBrains. They could expand their support for external tools in general, which would benefit everyone.
How is it good business sense to support a minority of users over the majority? I understand why they support VS and have built Fire, but unless improvements benefit most of their customers they’ll simply be out of business at some point. I guess supporting JetBrains would provide customers with a migration path, right?
When I starting using RemObject I dismissed Fire out of hand, because it did not suit my needs, but at the same time, when I wasn’t distracted by calculating increasingly large prime numbers with a prime number of digits in the base 23 number system, I knew what drew me to their products: their great cross platform compilers and related tools. If and when they get seriously distracted from that core product and mission, I’ll look elsewhere (hopefully never).
Its relatively easy to integrate the Fire/Elements compiler into other tools using scripting or build tools. You just need to work out the right command line - this could be better documented, but see here for an example
http://talk.remobjects.com/t/getting-a-command-line-build-going/7733/7
I did this in our Android Gradle script so that the Fire build just runs when you press Run in Android Studio (which is IntelliJ/JetBrains behind the scenes)
The downside is you have to jump back to Fire or XCode and hunt down the errors by line number.
I’ll make sure we get the docs improved on this, yes. Elements 8.3 will also greatly improve the Elements.exe (opposed to xbuild) command line compiler, as well.