I'm doing a trade study for Ada development on Linux. Do you have any good compiler/OS recommendations?
So far, I've got GNAT from AdaCore running on CentOS 5.4, and I have license requests in for Rational Apex and Aonix ObjectAda.
This is a porting effort. The original codebase is Apex 3.0 on OSF1 4.0d.
Anything else I should be considering? Ideally, it would be a supported environment.
One issue you need to take into consideration is to determine to what degree your system that's being ported utilizes vendor-supplied packages to perform its function. What I've seen with older, large systems, especially Apex ones, is a propensity for the language gurus during its development time to have decided that vanilla Ada just wasn't good enough, and so tie into all these vendor-supplied packages. If that's what your system does right now, it's a strong argument for upgrading within the vendor and sticking with Apex (all other things being mostly equal).
Whenever I've done ports of such systems, if given the opportunity I've done my best to tear out all the vendor-supplied stuff--nine times out of ten replacing the vendor-specific stuff with vanilla Ada implementations worked just as well, and you no longer have to deal with the quirks of a compiler-specific package. Plus, you increase the portability and maintainability of the system, allowing it to better adapt to future changes.
There is always SPARK, but I believe its a specialized/subsetted version of the Ada language. You might want to contact SigAda or the Ada usenet group to see if there are any other ideas.
Honestly though, GNAT is a great tool set. You can use GNATBench, an Eclipse interface, or GPS, a light-weight GTK+ IDE, to interface with the GNAT tools.
Other compilers I am aware of are Green Hills AdaMULTI (for various RTOSes), and DDC-I's SCORE (also for various RTOSes)
Providers of certified compilers that support Linux (in addition to those listed in the question):
Irvine Compiler Corp.
OC Systems
RR Software
Sofcheck
Related
The motivation for this question is a far-fetched dream I have where a lot of the excellent software available on *nix platforms could be trivially ported to Windows. Microsoft has taken a different approach to open source and openness in general recently, so I'd really like to know how viable such a thing would be if Microsoft were so inclined. Some of the more specific things I'm curious about is if it could be done without breaking backwards compatibility, and perhaps some sort of gauge on the amount of effort that would be involved. If there were any specific technical examples that would highlight particular difficulties in doing such a thing, that would also be greatly appreciated.
Windows has already been such. The NT kernel itself has supported the concept of "personalities" (API layers over the NT layer) since the beginning, to support by design at the very least the Win32 API, the POSIX API and the OS/2 API.
The POSIX layer circulated for a long time in higher end SKUs (typically server-related) with different names (Microsoft POSIX subsystem/SFU/SUA), but it never really caught on for non-specialized use, both because it was not universally available (Microsoft never really pushed it, probably for commercial reasons) and because other solutions became widespread (think Cygwin/MSYS/MinGW).
Notice that, although the "personality API" is an interesting concept (and probably one of the cleanest way to implement a multi-API OS) it suffers a bit from a "deep segregation" problem - i.e., it's true that you can access kernel objects through a POSIX interface, but all services that have been built over the Win32 interface (like Windows, GDI & co.) aren't easily available; besides, however good the interface may be, there are some details (like the format of paths) that cannot be ironed over, so a POSIX application will always look a bit out of place.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'd just like to ask if there are other alternatives for REALStudio or Runtime Revolution?
I'm not looking for something like a .NET framework or a plugin. I want it to be fully self-contained like the aforementioned IDEs.
It should also be cross-platform.
NOTE:
Please don't mention Java. I already know of it.
Just to be clear, I'm looking for a programming environment that would let me create a desktop application for Windows, Mac OS X and Linux...
I still feel like I'm shooting in the dark by answering this question. It's unclear if you're looking for a programming language and GUI toolkit, or if you just want an IDE that is cross-platform. It's also unclear why you are abandoning REAL Studio, since it seems to meet your requirements.
Anyway, there are really a lot of options here, especially if you don't need one that uses the REALbasic language. I can only talk about the ones I am familiar with and have experience in using. Others can surely tell you more about dynamic languages like Perl, Python, Ruby, etc. etc.
First off, I'm not sure why you think that the .NET Framework is not "fully self-contained". Yes, it requires a runtime, much like Java does. But those two managed languages have gotten quite a bad rap for requiring a runtime. It seems people have forgotten that programs compiled in C and C++ can often require a runtime as well (at least they do on Windows).
I would take a second look at .NET. It is an extremely easy-to-use, rapid development environment, much in the style of REALbasic. VB.NET retains a lot of the syntax, while bringing you (in my opinion) even more powerful features. Since almost all desktop applications should be distributed with an installer (setup program), the requirement of a runtime is really a non-issue. Your installer should install the necessary dependencies at the same time as your application—the user will never be the wiser.
Of course, producing a desktop application with a user interface that is truly native across all three of your target platforms is going to be difficult at best. Windows, Mac OS X, and Linux all have vastly different platform conventions, and even though you can find environments that will let you generate an executable that runs on all those platforms, none of them are going to produce interfaces that actually look like a native application. I'm extremely picky about this, and you'll find that Mac users are, too. Windows and Linux users are much more accepting, but following standard platform conventions is the key to making your app easy to use and easy to understand. Conforming to the behavior the user expects and taking advantage of native widgets has a lot of advantage that developers (often prone to reinvent the wheel) seem to be forgetting recently.
The absolute best thing to do (in my opinion) is to write your code in a portable language like C++, and create the user interface using tools provided for each platform (For Windows, you might use the Windows API, or WinForms or WPF provided by the .NET Framework. For Mac OS X, you'll use Cocoa and Apple's Xcode/Interface Builder. For Linux, you'll do whatever it is Linux people do.) Then, you just have to recompile your application on each platform, and you get the best of both worlds.
A good compromise would be to use a GUI toolkit for C++ like Qt or wxWidgets that promises to generate cross-platform applications. Yes, the apps themselves are truly cross-platform, but they don't always have truly native interfaces. I understand that Qt has gotten better recently, but it's still not up to my standards. You and your users might be less picky. Note the "your users" part there. The Mac Office team discovered that Mac OS X users just wouldn't accept the ribbon as it was implemented in Windows. Mac Office 11 finally brings the ribbon to the Mac, but it looks completely different, having been entirely reimplemented to look like a native Mac OS X widget. By contrast, Apple's iTunes sticks out like a sore thumb on Windows. What's long been the standard for an innovative, easy-to-use interface on the Mac is regarded by many PC users as an abomination. But then again, native GUI is sort of my soapbox, so if you care, I recommend perusing my answers to other, similar questions:
Advice for supporting both Mac and Windows Desktops
What is the best library to use when writing GUI applications in C++?
If you goal is to have a self contained IDE with an easy to use GUI builder, that can produce standalone cross platform executables, then to the best of my knowledge, the options are pretty limited.
If you like BASIC (similar to RealBasic or RunRev), then you may want to look at www.PureBasic.com . Documentation and new material is sparse, IMHO. It has it’s own GUI builder, but for a bit more cash, you may want to pair it with PureVision.
For cross platform development using wxWidgets programming in C++, wxPython, wxLua or wxRuby, you may want to consider DialogBlocks.
The answers given here are terrible of course, but the question you are asking is a difficult one and there may not be an answer. I'm asking myself the same question as REALStudio doesn't work as well as I would like. Java is poor, difficult and ugly. .NET is the favourite but not cross platform.
Consider that appearance is a major problem. If the GUI doesn't look native, there's no reason why you can't design something superior (look at MojoWorld for example). I would tentatively suggest REBOL. Although it appears to be an interpreter a compiler could be purchased. As the software is free, if your program works reasonably well you might then buy the compiler. Not sure if it has an interface builder as the buttons are generated by code. The free version is moderately poor but has been improving in recent years.
Not being able to update the interface from a thread (Cocoa for example, I guess NextStep is really old now) seems to defeat the whole object of the exercise. Having Timers that don't run (REALStudio) also seems hopeless given that those are supposed to update the interface instead. Then you have Object-Orientation, an excuse for poor programmers unable to understand code. Not being able to 'GOTO' a button unless you put the code into a Timer pretending that it's a module (yey for for REALStudio). I can understand your problems. Try to realise that programming is HARD and that it only looks easy when you see the end results produced by experts like Apple.
So Java is proof that cross platform doesn't work. Give REBOL a try.
I'm interested in contributing to a Linux distro, but regarding the various distro's developer communities, I'm having a bit of trouble figuring out which one I'd most like to join.
What languages I know: C, C++, Lua, Python, and fairly familiar with Perl (though I wouldn't say I "know" it). In particular, I have very little experience with x86 assembly besides hacking stuff together for performance tweaks, though that will be partially rectified soon.
What I'm looking for: A community that provides plenty of opportunities for developers to work on various aspects of the distribution. To be honest I'm most interested in reading and working on the kernel source (in which case the distro doesn't matter), but it's pretty daunting and I figure getting into the Linux community and working with experienced Linux developers might give me a better idea of how to jump into the guts(let me know if this is bogus, or if you have any advice regarding that).
So...
Which distro has the "best" developer community in terms of organization, people who are fun to work with, and opportunities to contribute?
I've read various "Contributing to XXX" pages and mailing lists for distros like Ubuntu, OpenSuse, Fedora, etc. but I'd rather get a more personal testament from an actual developer.
Unless you have a specific desire to learn the ins and outs of various packaging formats you would probably be better off contributing directly upstream to applications/libraries that you find interesting. While individual distributions often have a few management applications that are unique(ish) to them most core applications and libraries are shared between them.
As you have expressed an interest in guts it would make sense to stick to one of the main community distros (Fedora and Ubuntu/Debian) as the rest tend to be variations on a base distro. The other option is to choose a source based distribution which have a number of advantages to developers although you may find yourself spending a bit of time keeping your machine trim.
As I'm a developer I personally use Gentoo which gives me a number of things:
Rolling release: New versions of applications are generally available soon after release
Stable/Unstable mix: I can run stable core with bleeding edge on upstream packages I care about
Development ready: Any installed package is by default a "dev" package, the distinction between buildtime/runtime dependencies is blurred
Packaging is easy: If it's a simple as "configure/make/make install" writing and ebuild is very easy.
Contribution is easy: Contributing new ebuilds is fairly painless, from there you can get as involved as you like
Of course there are downsides, not least of all your machine spends a considerable amount of time building things and if your run a large selection of "unstable" packages you may find you occasionally need to fix-up your machine. However I find these disadvantages minor compared to giving me an up to date platform with which to contribute to upstream from.
If you want to work with the kernel then you shouldn't be picking a distribution, but rather working upstream.
Somebody correct me if I'm wrong, but I think that contributing to Ubuntu can be very easy and fun if you use Launchpad. I haven't tried contributing code, but I contribute translations and file bugs on some projects.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I've been writing software in Java for many years now, but it was always for internal applications that would be deployed to a server. I'd like to get into writing desktop applications now but I don't know where to start. I've written a few Java/Swing applications but again they were for internal use.
My understanding is that Java and other semi-compiled and interpreted languages are too easy to reverse engineer, making them unsuitable for commercial software. I am aware that there are compilers for Java and some other interpreted language, but I've also heard that they are pricey and/or unreliable.
Assuming I start a microISV and wish to develop and sell applications to a broad audience, what's my best bet? I would prefer something that can be written close to once, and compiled for different operating systems but I am not opposed to .NET and a Windows-only audience if other languages would compromise the experience (installation ease & user experience) in Windows. My only issue there is that I don't have a large starting budget and paying out the wazoo for the required development tools is not really in the cards.
Why would people want to reverse engineer your software? They might pirate it, but you can't prevent pirating no matter what language you use. I doubt you have a top-secret algorithm that you're trying to hide either, in which case reverse-engineering might be an issue.
You should go with whatever you know best, and Java can work just fine.
If you are intent on switching to another language, I recommend taking a look at Qt. Qt is a free and open-source cross-platform toolkit for C++ that allows you to write applications in that will compile and run on Windows, Mac, and Linux with minimal effort. You CAN write commercial software for free with Qt with its LGPL license.
Edit: GCJ compiles Java to native code, but only supports Java 1.4.
Well, if you're trying to be an Independent Service Vendor -- and not a Software Vendor -- then in a sense it doesn't matter if you use a language like Java which can be decompiled. Because you'd be selling yourself as the best person to integrate and customize the software for your clients. The software is the delivery mechanism for the thing that will actually make you the money: you and your skills. Plenty of companies make a profit by giving away their software for free and contracting their services to set it up for their clients. You can mitigate the Java decompiling issue somewhat by using an obfuscator, but it's kind of fighting the wrong battle.
If you intent to make your money selling software and not service, then Java would be a relatively risky route to take.
It all depends on your business plan.
If you are starting a one-man company, then you are selling your personal expertise. So the language you use must be the one (or maybe two) that you are most familiar with and expert in. I'm surprised you felt it necessary to ask this.
Any code can be decompiled to some degree. I think you can obfuscate Java to a degree that will deter the casual user... but I think the other people hit the nail on the head. Of all the reasons not to use Java, the ease of decompiling should be very very low on your list. If that is all that is stopping you, go for it! Google Java obfuscater and you will find something.
I'm skeptical about the risk of reverse engineering a complex piece of software written in Java, but for purposes of your question I'm willing to stipulate it. I assume the same issues rule out any other language that is implemented only on the JVM.
The most salient aspects of Java are
Static type system
Class-based object system
Automatic memory management
No freestanding functions or modules outside the class/interface system
Generics
This combination could be replicated in a language like C#, but I assume the same objections you have about distributing JVM bytecode also apply to MSIL bytecodes.
I'm having a hard time coming up with a language that has all these features. Here are some nearby languages:
C++ has everything except automatic memory management, plus it allows freestanding functions. However the C++ generic mechanism (templates) is not for the faint of heart, and it doesn't (yet) support modular typechecking. Lots more flexibility than Java but also lots more ways to shoot your foot off. Use with caution.
Modula-3 has all of the above but it's essentially a dead language, plus like C++ there's no modular type checking for the generics.
I'm not familiar enough with Eiffel to be able to make good comparisons, but I think it's worth looking into.
Delphi may also be worth looking into. It seems to have everything above except generics. It's primarily a proprietary Windows environment (formerly known as Object Pascal), but there seems to exist an open-source 'Free Pascal' compiler that supports Delphi.
There are many object-oriented languages with automatic memory management and dynamic typing, among which one might highlight ruby, Python, and Smalltalk. None of these really compiles well and reliably to standalone native machine code, although all push toward some form of experimental compilation. And they are all dynamically typed, which is quite different from what you're used to.
If I were in your position I would probably go ahead an use Java and accept some risk of reverse engineering. Decompilers aren't as wonderful as you might think, and they don't produce wildly maintainable code, either. But if you really want to be able to produce native machine code, I would investigate Delphi and Eiffel. (I myself would use Modula-3, but that's because I once invested substantial effort in learning it. It's a very well designed language for its niche, but the user community is about gone and I think it's a dead letter. Pity.)
This is probably more of a subjective question, but which language (not API like .NET or JDK) would you use should you write your own operating system? Which language provides flexibility, simplicity, and possibly a low-level interface to the hardware? I was thinking Java or C...
C, of course.
Haskell.
Once you have flipped the right hardware bits, C is a terrible language to use for the rest of the OS. Things like the scheduler, filesystems, drivers, etc. are complex high-level algorithms, and you don't want to be writing those in assembly language (or C; same thing). It's too hard to get right. (The VM subsystem and memory manager may need to be written in something low-level, as you will need to bootstrap your high-level langauge's runtime somehow.)
Anyway, this isn't just a crazy idea that I am coming up with for SO. Here is an OS written in Haskell: http://programatica.cs.pdx.edu/House/
Lisp is another good choice; the original Lisp machines were infinitely more tweakable (at runtime) than "modern" OSes like UNIX and Windows.
Sometimes history forgets good ideas (often in the name of "maximum performance"), and that makes me sad.
D would be an interesting choice. From its own description:
D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability.
The D runtime assumes the existence of a garbage collector, which would not be appropriate for the very lowest levels of the kernel. However, it would be appropriate for many of the higher layers.
Build the basic components like task schedulers and drivers etc with Assembly, then build the higher level components like applications and tools with C
I believe this is how Windows XP was built too (unsure about Windows Vista and Windows 7).
Definitely... C
C, ASM, C#
Singularity
Low-level in something like Haskell or D. Productivity over performance, in my opinion. You can rewrite slow parts in C++ or even assembly later if the need arises.
High-level in Python or Ruby. Ideally I'd also have a really fast JIT-capable VM for that language, but that's not going to happen for either language for a while. Lua would be a good alternative if speed gets in the way.
The kernel has to be written in a low-level language, C is by far the best choice for this, because it is so memory efficient. The higher levels could be built with a combination of Java or more ideally Objective-C, and scripting languages like python and ruby, or lua.
Honestly, I would either use C or some hierarchy of languages that I had either designed or fit together completely seamlessly. What I would be looking for is a seamless experience that starts at the bare metal level and then I could move to higher and higher level languages as I moved up the problem space. I would probably chose something like:
C - for bare metal stuff like drivers, kernel, etc
Java/C# - for application-level things like administration consoles, OS apps
Python/PowerShell - for scripting activities like common administrative tasks (creating a new user, etc)
Personally, I think C/C#/PowerShell is more tightly integrated and the type of experience I'd be looking for. Of course, if I ever got so ambitious as to write an OS, I would have a lot of spare time on my hands and would probably really enjoy tackling the language stack first. So maybe it would be L/L#/LScript ...
BitC seems to have this in mind. Despite it's name it seems to be the midpoint of assembly language and lisp. The goal was to make a language with a strong correspondence with machine language but have an intermediate representation that supports stronger correctness inferences than is possible with most other common languages. The languages was created as part of the Coyotos project, an operating system with lofty goals of security and reliability. Formal verification is made significantly possible with the ir used in BitC.
Ada:
Ada is a structured, statically typed, imperative, and object-oriented high-level computer programming language, extended from Pascal and other languages. It was originally designed by a team led by Jean Ichbiah of CII Honeywell Bull under contract to the United States Department of Defense (DoD) from 1977 to 1983 to supersede the hundreds of programming languages then used by the DoD. Ada is strongly typed and compilers are validated for reliability in mission-critical applications, such as avionics software.
Ada, because it was not only specifically developed for such projects, but it also provides support for several very useful high level features (such as support for strong typing, concurrency and abstraction) that are simply not available in standard C.
So that, even as a project grows, you don't have to work around language limitations (think encapsulation, abstraction, namespaces in C).
Don't get me wrong, C works obviously for a great many of projects, but once a project has gained a certain size (think Linux kernel, gcc, GNOME), you will inevitably appreciate certain features of more high level languages to make the development process less tedious and also less obfuscated.
In C however, these features usually end up being -pretty poorly- emulated by excessive and almost pervert use of the pre-processor (this can for example be seen in the gcc code base), so that you get to see lots of nested macros, that from an implementation point of view, actually emulate features found in other programming languages.
In addition, Ada is the only programming language, that I am aware of, that actually provides standardized support for source code analysis using the ASIS, having such a facility in place is however the prerequisite to actually be able to maintain and transform/re-engineer a code base in the long run (think refactoring).
Having an interface like ASIS available, means that you can actually implement "semantic patching", where you can automatically rename a file, function or variable/data structure and it will actually work.
Java ?? no jave runs on a virtual machine which needs an os to run on top of ,
maybe C and some ASM ;)
I would go with D to see whether it can do it.
I would only pick the following 3 out of practicality.
C (good old fashioned)
C++ (C with stuff tacked on. Windows is partially written in this)
Java (the medium level language that just might have a capable garbage collector with controllable pauses with G1).
If I were going to start a new OS I'd do it with the subset of C++ recommended by the embedded industry. You can use things like classes and use it "as a better C" and be just as fast. Just avoid things that have massive overhead. You can even use some template features, if you stick to a certain subet that basically don't have any overhead. Look on embedded.com for features in C++ that have little to no overhead, but will allow you organize your code better than you ever could in C.
Oberon? I guess I miss Pascal too much some times. C paid the bills for quite a while, but I don't really love it.
Lisp of course!
Title text: Some say the world will end in fire; some say in segfaults.
For an OS, you want speed at the lowest levels. So assembly, C, C++, Objective-C, or Java seem to be the current choices. Although it's just recently that Java got fast, and it's hard for me to imagine an OS with garbage collection.
If I were writing my own, it would be a mix of assembly and C.
A C or C++ microkernel with a JIT for a highly dynamic language like Ruby or maybe a language with native support for the Prototype pattern. Even device drivers in that language.
Not because it's practical but because it's really cool. Cool in the way that NeXTStep was cool for using Obj-C for pretty much everything.
http://www.dwheeler.com/sloc/redhat71-v1/redhat71sloc.html - share of languages in Linux's source code.
C, by a number of reasons. Other candidates, like D, are great. However, C has this advantage: there's a lot of available open-sourced C code that you could reuse in your project (much more than is for other languages appropriate for system programming).
I would be torn between using some existing low level language and write my own based on C# but with much better generics support.
In second case I would make each method generic, but all the constraints will be resolved by compiler - to allow "duck typing" like in Scala but still language should be static. Also static virtual methods would lower the codebase.
I've had that idea for a long time, but it never seems to be doable in real timeframe, so who knows maybe in the future. :-)
Some would say Java.
Note that openfirmware is written partly in Forth, and it's very low level.
Have an open mind.
"The kernel has to be written in a low-level language, C is by far the best choice for this, because it is so memory efficient. "
Um... What about FORTH?
FORTH can be low level and high level, so you could have a whole operating system written in FORTH from the ground up, and still have a nice easy REPL scripting environment on top, also in FORTH.
However, any decent operating system should support lots of langauges on top, from C all the way to Python Ruby and Javascript. Making FORTH the basis for it all has a lot of benefits though.
edit: I'd only ever attempt this for an embedded environment with a single known hardware set. Trying to write an OS that could compete with Linux or Windows is a fools job.
If this isn't a hypothetical question, and you're looking to create your own OS, I'd probably go with C because most of the examples out there are written in C.
Also, (And I haven't build an OS yet so take this with a grain of salt), I'm thinking that the c runtime libraries would be a lot easier to port to your new OS than say .NET.
Pascal + Oberon: they have the power of C and C++ but they're not as daunting to use. Both these languages are grossly under appreciated.