After playing with Element for several days, here are my suggestions to it. Hope they will be useful.
Add refactor-rename function in Water IDE.
I don’t have a Mac, so I am not sure if Fire has this function. But, renaming a function, identifier, class is a function which will be used very often. And Element in VS already support this, so the engine is already there?
Unicode support in Water IDE.
I open a thread yesterday, for the problem of deleting Chinese character in Water. So here, just mention it.
The ! in silver
I am a fan of naming variable like:
var s:string
So I like Oxygene, Kotlin, Swift
When I see Swift on .Net, my first thinking is WOW, that’s pretty cool.
Then I try to convert some of my C# codes to Swift, and I see a lot of !
I know this is something related to the Swift languge design, but as a people coming from C#, the:
var s:string! =“hello”;
! = //always makes me feel like it is != in C#, although there is a space between !and=
I wonder, if it is possible in the IDE, such variable type shows in a different way(in a different color or something like that), so that no need to see ! ?
Or, it is possible to bring Kotlin as a front end like Java, so that there is also no ! when writing .net application (Actually, I believe most Java developer will prefer Kotlin over Java)
Windows Form, WPF template for .Net Core
As .Net Core 3.0 previous already support building Windows Form, WPF desktop application on net Core, I thinkg such template can be added to Element, too.
Visual designer for XAML and Windows Form
Using the designer in VS is good. But, as Microsoft roll out VS new version so often, I don’t think it is easy for Remobjects to catch up with their VS APIs change so quickly. I always have to keep both VS 2017 and 2019 RC on the disk just to use the stable designer in 2017.
Oxygene/Remobjects C#/Java/Silver + Xamarin
I beleive this is the best combination.
Xamarin now is free to use and adopt by Microsoft, I don’t think Xamarin and Element is two soluctions in heavy competition.
In China, for RMB 108 per month, we got 100M broadband in home + unlimited traffic plan (the first 10G is high speed) on mobile phone + IPTV. So an app is 20M or 50M, actually it is not a problem.
And Microsoft does not provide VB.net support for Xamarin (I will do it if I were Bill Gate, I may even name VB.NET as B Sharp:grinning:), Oxygene+Xamarin will beat soluation like React Native.
For language
Nowaday, almost all programming language and its toolchain are free to use.
For example:
Kotlin with IntelliJ IDEA
Swift with Xcode VB.net and C# with Visual Studio
Delphi (Object Pascal) with Delphi Communitiy Edition and Lazarus
QT (Not sure how it charge, but using it to learn programming should be free)
For Oxygene, just my personal opinion, language itself should be free to use (at least allow people to use it to build .dll), and maybe Remobjects can charge on templates. So that Oxygene can spread to the world, and build up the communitiy.
For the .Net platform, there is only Oxygene and PascalABC on it for Object Pascal.
On the list; the functionality is there, it’s “just” a matter of exposing the UI in Fire and Water.
Handled there. The next build should handle most cases (with the exception of mouse-clicks/drags in non-monospaced test, and support for properly treating emojis made up out of multiple unicode code points as one single entity.
It is what it is; we cannot change the language syntax of Swift for this.
It’s on the list for consideration as one of the next languages we might add yes. It seems much saner than Swift, for one thing.
Good idea, we’ll add that. In the mean time, simple changing the TargetFramework of your project to .NET Core (and maybe removing/changing some references) should do the trick, right?
We’ll have some story form form deign, in the long run. Maybe Xml, maybe something higher level. WinForms is out of the question at this stage.
Note that we do support all current and upcoming VS versions quickly, always.
Should work fine as is, but it’s not our recommended solution fir cross-platform.
Yeah, here’s the thing: the people working on Elements here at RemObjects need to pay rent and buy food. Stupid, I know…
Not really. Right now I’m reluctant to add yet another language at all (5 is a lot, al lot of the supporting infrastructure expands not linearly but exponentially when we add new ones). But if we were to think about adding a new one, Kotlin would be probably my first choice.
@mh
For functional programming, I think F# is already there, and Oxygene readibility of F# backend would make MUCH MORE sense for RemObjects roadmap, from BOTH technical and business perspective.
Erlang is nice but it is minority language, it won’t help RemObjects pay “bills and rents” from revenue perspective. F# is different. It has much larger user population especially in Financial industry. To go Functional, better go F# direction.
So advisably, it would be one of the following, or maybe both, depending on RemObject team’s resource:
RemObjects F#, on all the platforms that RemObjects other languages support such as .NET, Java, Island etc
Or,
Functional Oxygene, with Oxygene readiability, but a functional F# backend.
This is a catch-22 problem. I guess, F# support is for attracting new users, not for keeping the existing ones? I could be way wrong, and this is just for your consideration -
I meant, RemObjects has already a solid foundation/expertise with .NET ecosystem, I guess porting language features of F# (which currently is a .NET language) to RemObjects own Oxygene language would be …a piece of cake? I am not a Programming Language (PL) expert, so it is just my wild guess.
I misty admit I’m not familiar enough with F# to know if it’s “just” a language thats built on top of existing .NET infrastructure, or if it brings any additional infrastructure with it that would need poritng.
In the former case, yeah, it would be “just” a matter of porting the language syntax (that’s very big scare-quotes a und the word “just”, there, of course), and F# would automatically be supported on all Elements platforms, including Island.
In the latter case there might be additional helper classes, APIs and the like to port and provide (think of how LINQ as a language feature is really useful only because of the underlying Sequence operators, which we had to port to each platform ourselves).
F# is a great functional language with same access as C# to all .NET resource/eco-system. It is Microsoft’s version of OCaml.
I am not suggesting F# is a necessity inclusion to Elements languages family. I am saying, if and only if RemObjects has the resource and is considering adding a functional language to the Elements languages family, F# IMHO, is a better choice than Erlang. That is all I meant.
Personally, I’d love to see F# to be available on Island platform. But I guess, NOT at the expense compromising the support of my beloved Oxygene!
I think a functional “version” of Oxygene would be good, particularly, the following new language features:
Currying (so we could have functional recursion)
Pattern Matching
Pipe
Additionally, it would be super cool to have F# added to Elements language family, ESPECIALLY, a LLVM-based F# that generates native code. I have always wanted to have a native F# (right now, the WinRT could generate some scope-limited native F# binary, though).
I just realized that all those functional elements are already available in Swift, such as higher order functions, partial function application, currying, pattern matching, and pipe forward operator etc.
And Elements family does support Swift… and for FREE!
I haven’t extensively used RemObjects Swift. Before I delve into it - I guess I have a dumb question: how RemObjects Swift compare to Apple’s original swift? Any “limitations”? Is it a sub-set, or super-set of Apple Swift?
If “sub” set, what is missing? @mh
It has generally good overlap, but both support features the other lacks.
I assume the features of Silver over Apple Swift are well documented in the language extensions section of the docs.
However, while there is a differences and limitations section it inaccurately implies that Apple Swift supports Type Extensions “(a) adding new fields or stored properties” and is incomplete:
I have been submitting bugs for the deficiencies of Silver with respect to Apple Swift, and I list the currently outstanding ones below (to my knowledge none of these are mentioned in the docs currently):
Thank you very much. I guess those functional elements (higher order functions, currying, pattern matching, discriminated union, Pipe forward operator) supported right? I am asking because I will need to port F# code to Swift
not implicitly, but does support closures / anonymous functions with implicit context
pattern matching
in switch, if case and catch statements
support discriminated union
enums with associated values
Pipe forward operator
not natively (unless Silver adds it)
but does support defining both custom operators and operator implementations
using (almost) any string of ascii punctuation (unless Silver doesn’t support such?)
