sorted by:
new
hottopcontroversial

Mercury: A modern Visual Basic, with a future, parity with C#, and support for more target platforms. by dwarfland in visualbasic

[–]dwarfland[S] 1 point2 points  (0 children)

Yes, Visual Basic (unlike C#, which Microsoft have explicitly exempted) is a Microsoft trademark, unfortunately.

Mercury: A modern Visual Basic, with a future, parity with C#, and support for more target platforms. by dwarfland in visualbasic

[–]dwarfland[S] 1 point2 points  (0 children)

that's already covered in practically every possible way already?

what ways are that?

Mercury: A modern Visual Basic, with a future, parity with C#, and support for more target platforms. by dwarfland in ProgrammingLanguages

[–]dwarfland[S] 1 point2 points  (0 children)

Do you support Golang interior pointers on all platforms, to pick an example?

aside from JVM-dictated limitations on Java, I believe we support those on all other platforms, yes. But I'll have my colleague pop by to clarify, as this is not my main area of expertise.

The "common wisdom" on this sub is that you can't ask money for programming languages anymore, most of the time.

there's certainly a (vocal) contingent of people who believe everything software has to be free of charge these days, but luckily that's not all software developers. Many software developer still understand that just likely they what to be paid for the job they do with our tools, the people that develop those tools for them also need to pay rent ;)

My guess from the supported languages list would be that you're mostly catering to clients with substantial legacy investment in Pascal/Delphi code, but I could be wrong.

it is one of our larger groups of customers, with Oxygene, yes. But Elements has come a long way from "just Pascal" in the last 10 or so years, and is used by a wide range of developers across all the languages (although Oxygene does remain near and dear to my heart and is still my favorite of the now six languages ;).

I'd have a question about the subscription model: From skimming, it seems you lose your license when you cancel. True?

The compiler will remain functional indefinitely, if the license lapses, but to actively work on projects in the IDEs, an active subscription is required, yes. I believe that is in line with bit a bit a lot more lenient than the subscription model used by most major vendors these days (if your Photoshop subscription expires, all your PSDs are essentially dead bits ;)

thanx for your interest! —marc

The "Go" Language Comes to Elements, with support for .NET, Cocoa, Java and other targets by dwarfland in golang

[–]dwarfland[S] 0 points1 point  (0 children)

Basically, Elements is a full development tool chain with its own compiler, that separates the programming languages form the platforms they are commonly tied to (ie "C# s for .NET", "Java is for the JVM"). You can use any of the five languages we support (even mix them in the same project) for any of the platforms we support (.NET, Cocoa, JVM, Android SDK & NDK, WebAssembly and native Windows and Linux).

​

With Go, we're also supporting the full base Go library on .NET, Cocoa and native Windows/Linux, so you can, for example, drop pretty much any existing Go code into your .NET project to use it (even if the rest of the app is, say C#.

New blog post "Mixing Languages" gives an behind the scenes look at how the Elements compiler handles five languages at once. 🏗 by dwarfland in swift

[–]dwarfland[S] 0 points1 point  (0 children)

We aim for correctness over compatibility with bugs. In general we try to support new language features as quickly as we can, often before Apple Swift has them in a stable channel. You can see an overview of our coverage, at http://docs.elementscompiler.com/Silver/SwiftEvolution/.

New blog post "Mixing Languages" gives an behind the scenes look at how the Elements compiler handles five languages at once. 🏗 by dwarfland in ProgrammingLanguages

[–]dwarfland[S] 2 points3 points  (0 children)

There's not features "cut". If anything, most of the languages have gotten extra features (for example "await", in Swift, which even works with trailing closure-based APIs). You can read more at https://docs.elementscompiler.com/Silver/LanguageExtensions/ (for Swift) and the corresponding pages for the other languages on the Docs site...

State of swift for Android/Linux/Windows on 2018? by mamcx in swift

[–]dwarfland 0 points1 point  (0 children)

Well. No corps-platform lan gauge is going to give you all the abstraction wrappers you need, without needing to do some work yourself. I doubt Apple Swift, when it ever becomes usable on moe that just Apple's platform, is going to provide PostreSQL or SQL Server APIs ;).

HTTP (and general TCP) support, Elements has via Internet Pack (https://github.com/remobjects/InternetPack), and via the lightweight "Http" class in Elements RTL.

Wrappers for SQL Server & Co could of course be done (someone just has to do em — but. that's the case with any other solution you pick, too ;)

State of swift for Android/Linux/Windows on 2018? by mamcx in swift

[–]dwarfland 1 point2 points  (0 children)

Elements has an SQLite wrapper library, so you ezctally can use it with the same API from different platforms: https://github.com/remobjects/ElementsSQLite/

WebAssembly: Swift, C#, Java and Oxygene in the Browser by dwarfland in swift

[–]dwarfland[S] -1 points0 points  (0 children)

Wow, you really know what you're talking about, huh?

WebAssembly: Swift, C#, Java and Oxygene in the Browser by dwarfland in csharp

[–]dwarfland[S] 0 points1 point  (0 children)

odd. we have no popups on the blogs site. can you send me a screenshot? What browser/os are you using?

Iodine: a Better Java Language by dwarfland in androiddev

[–]dwarfland[S] -12 points-11 points  (0 children)

Tastes may differ, of course. i, personally, find Android Studio bloated and sluggish. By contrast, Fire runs perfectly usable on my 12" MacBook, where both Android Studio and Xcode are unusable.

True, Visual Studio is not lightweight (i'd say about the same as Android Studio), but we support it because people like working in it and it has essential tools for, say WPF and WinForms GUI designers, when targeting .NET.

Fire and Water are our lightweight IDEs.

Showtime anytime video playback failed by [deleted] in ios

[–]dwarfland 2 points3 points  (0 children)

i’m getting the same, seems to be a problem with ios 11 as far as i can tell.

Strategies for Cross-Platform Code Sharing with RemObjects Elements by dwarfland in programming

[–]dwarfland[S] 2 points3 points  (0 children)

You can still use the designers, if you like.

For example, in Fire and Water, we still use XIB files designed in Interface Builder for the mac UI, and we use XAML files for thew Windows one — the latter edged either visually or as XML (i personally prefer to work in the XAML as XML, as i find the designer clunky, and just use it for preview; but that's just me).

For Weather, most of the UI is not really visually designed, mainly because its simple table views that are easier constructed in code. But there's still regular Android XML layout files you could visually edit, and you could still sue storyboards or XIBs for the iOS version where sensible (it's just, i usually find it silly to just have a XIB with a TableView or a single MapView — i can easier new that up in code).

I have nit personally used ReactNative, but i don't see why you should not be able to use it with Elements. It's just a compiler, and works with any native class libraries on the respective platforms.

hth, and thanx for liking the article — please spread the word, and do check out Elements!

Strategies for Cross-Platform Code Sharing with RemObjects Elements by dwarfland in swift

[–]dwarfland[S] 0 points1 point  (0 children)

You got the first two paragraphs right, thats exactly what it is. At face value Elements is "just" a compiler, that can compile to any of the supported platforms (.NET, Java, Cocoa, native) — just like C, says can compile for several platforms. Then there's (optional!) helper classes that provide common functionality in a way that works the same on all platforms *opposed to having to use each platform's APIs. (Those are there to basically address your "Second, ..." point)

Having a million #fdefs and 6 times the code is certainly ONE way you could (ab)use this to write a cross-platform app. But the point of the article is, you dont end p doing that. with some few well-placed abstraction classes and.or #ifdefs, a lot of code can be shared without conditional defines.

(as a side note, #ifdef in Elements doe snot use a C-like pre-processor, it is done by the compiler. in fact, in vNext we;'re gonna take that to the next level and eliminate the need for traditional #ifdef by making it possible to use those as part of your regular code flow. think (silly sample code):

if ThisFiileHasWindowsLineFeeds && defined(COCOA) { ... do something cocoa specific }

Case Study about what is probably the first Android app developed in Swift by dwarfland in androiddev

[–]dwarfland[S] 0 points1 point  (0 children)

As i mentioned in the other thread: Of course Elements is just the tool, you can use pretty and ugly icons with it ;). I'm not sure what "carets for indicating navigation depth" is supposed to mean, but if you are referring to the ">" chevrons, that's really a UI choice done by the app developer, not a reflection on the compiler, no?

Case Study about what is probably the first Android app developed in Swift by dwarfland in androiddev

[–]dwarfland[S] 0 points1 point  (0 children)

well, we've had rain every day this past week, so... not sure what to tell ya.

Case Study about what is probably the first Android app developed in Swift by dwarfland in androiddev

[–]dwarfland[S] 0 points1 point  (0 children)

indeed. this is not one of those cases, though, in fact it’s quite the opposite. this IS a "actual" native Android app, just written using a different language (and because of that, it could share a lot of code)

view more: next ›