It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I have seen in many documentations that a piece of code is portable.
Can anyone explain to me exactly what it means to call a piece of code portable?
Portable code is code that is not tightly coupled to one specific platform, or which is coupled as loosely as possible to platform-specific APIs. It is "portable" in that the amount of work required to move it from one platform to another is low.
Portable code is desirable when you intend to write code meant to be used by a large audience, on a wide variety of platforms.
Portability is primarily a concern in compiled languages, as interpreted languages typically rely on an interpreter to provide a uniform interface at runtime. It is still quite possible to write overly platform-specific code in an interpreted language by relying on features like backticks or exec for executing commands in the local environments, rather than accessing the same features through a library which may have different platform-specific implementations.
Libraries are often very concerned with portability as their primary purpose is to provide a consistent API across platforms.
Writing portable code involves minimizing the number of places your code must "reach down" and touch the underlying operating system outside of standard APIs. Typically you would encapsulate such access so that there is a single place in your codebase which must be ported from platform to platform while the bulk remains unchanged.
What does portability mean?
It means coding a program in a way so that the same code works in different environments; for example different processors, different operating systems, different versions of libraries etc.
If your code is portable, you should be able to just re-compile it on any new system and it should run without problems.
Why is it important?
The reason it's so important is because non-portable code can cause many problems in regard to maintenance - managing multiple versions, poor readability/understandability of the code to name a few.
Portable code is easy to move to other platforms -- either other compilers or other operating systems, with a minimum of changes needed to facilitate the migration.
Ideally this is achieved by only making use of standards (types, functions, definitions that are defined in system-provided header files, where on another system those header files might be modified by the compiler / OS vendor to be correct for that system).
Sometimes use of standards is insufficient, requiring use of (generally ugly) #ifdef's sprinkled throughout the code.
My statements assume a C/C++ like language. Many other languages are more intrinsically portable.
Related
For alot of the tasks I have to do I find myself having to choose between making the program using a Shell Script in Linux or a programming language such as Java or Groovy. Does anyone havce any experience about how I should choose one over the other and why?
Shell scripts are excellent for concise filesystem operations and scripting the combination of existing functionality in filters and command line tools via pipes.
When your needs are greater - whether in functionality, robustness, performance, efficiency etc - then you can move to a more full-featured language. They tend to offer some combination of:
type safety
more advanced containers
better control over variable lifetimes and memory usage
threading
advanced IPC like shared memory and TCP/IP
full binary I/O capabilities, memory mapped file access etc.
access to OS APIs and myriad powerful libraries
better readability and maintainability as the project size increases
support for more advanced programming paradigms: Object Orientation, Functional Programming, Generative Programming etc.
better error-checking before your program starts running, hence less dependent on test case coverage
#Tony provides an excellent list of pros and cons. I would add one more general point - shell scripts, because they are so handy, risk displaying the "there is nothing more lasting than a temporary solution" characteristic with all the attendant problems of maintenance when somebody else needs to use it.
Shell script is the most intuitive way to have a "glue" on your system. However, it does not have some useful concepts, like inheritance and modularization, that languages like Python (which is very used to "glue" systems too) have.
True, the use of language depends basically on the task you are trying to do. For the most cases I've worked, shell script worked well, although I'm using a lot of Python to accomplish system related tasks. I don't think that Java would be an alternative in this case. Probably Groovy would be, but not Java (I mean Java as a language, not Java as platform.)
In a sysadmin view, I think Python and Ruby are awesome languages. Not only because of dynamic typing and the lack of need to be compiled, but because tools like Fabric, Capistrano, Puppet, and a lot of others which makes a sysadmin's life a lot easier :-)
I am using a rather obsure, proprietary langauge called WIL/Winbatch that had an awful IDE (winbatch studio).
I would like to develop an alternative environment; however, without the ability to set breakpoints, step, and examine variables, there is really no point. How does one begin even researching how to implementing a debugger for a proprietary language? Is it even legal?
I guess I'm kind of locked in a mindset that the debugger portion must be able to examine the statements that are provided to it in WIL as they are executed, right? So somehow i have to trap the output of the interpreter? Or is it just a matter of reading locations in memory using whatever language?
Thanks in advance.
Having been there and successfully completed the task, here are the things to keep in mind:
Build it as a plug-in/extension to an IDE your team is already familiar with and likes. They'll thank you for providing an interface consistent with what they really know how to use, plus you can focus entirely on the features that make your language different from others.
You'll have to learn the debugging protocol for your language. In our case, we had source access to the runtime for the interpreted language. In other cases, you may find documentation for GDB local or remote debugging interface, a library you can link to for the language's debugging protocols, or maybe even figure out what the call stacks look like and wrap the Windows Debugging API to analyze it behind the scenes.
Don't build in excess of what the language provides. Adding debugging features takes a lot of time, and they have a rather annoying habit of needing to be significantly altered or completely rewritten as versions of the target language are updated.
Why are you tied so closely to this language? If it's not well supported, there are many others you can use. Anyway, to actually answer your question, the difficulty depends on whether it is a compiled or interpreted language and whether or not you have access to any source code (which it seems of course, that you don't). That said, this would be a very challenging project as you would have to reverse engineer the compiled code for it to have any meaning. Your time would be better spent learning another (better) language.
Perhaps if you can give us an idea of why you want to use this language we could give you some help?
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I'm part of a group that starts a new development project from scratch.
Currently it is on hobby-basis but we aim to make it our living
in the time frame of 1-2 years.
We are senior developers coming from a multitude of languages and techniques
with much of the focus on Java for the last few years.
Now, we're thinking of choice of toolsets and languages (the future is
bright when starting from scratch).
We want to be able to use modern architectures efficiently and have
good experience in Java and other JRE-based techniques.
The project is in short a lot of I/O, databases and a decent UI that probably
needs to be web-based and feel quite efficient.
One route to go is classic Java and build UI using GWT (or layers on top of GWT),
another is Scala + lift.
Then there are other techniques based on Ruby, Groovy and so on.
My question is then: What would you select as tools for a new long-term
project given the above. Is Scala here to stay for instance or is one
of those with only temporary hype?
What other techniques do you consider for larger projects from scratch?
Possibly your biggest binary choice is whether you decide to stay on the Java Virtual Machine (JVM) via either Java or one of the other languages which compile into bytecode, or to move onto some other platform, possibly Ruby or Python (with the complications of working with different architectures/operating systems that this may entail). Personally, I decided that I very much wanted to stick with the JVM and hence your language choices would be...
Scala
All I can give is my own experiences coming from a Java background: migrating to scala was made easy by its natural integration into the Java ecosystem and the ability to continue to use pretty much the same toolset in the same way.
By this last point I mean that the statically-typed nature of scala means that all the refactoring and code-navigation opportunities are still available to the developer but scala's type inference means that this comes without the unnecessary verbosity of type declarations littered throughout your code.
I can still use my favourite stuff like Spring, ant, IDEA and I can still use all the libraries I've ever written in Java (this is an argument for picking a language which integrates with Java over a completely new one like Ruby, Smalltalk or Python).
From the perspective of whether scala is here to stay as a JVM language, this is what concerned me most. But consider how many questions on SO have been tagged Jython (161), JRuby (176), clojure (388) and Groovy (661), assuming you wish to stay on the JVM. Not only is scala now well ahead of these (815) but it is growing at quite a rate.
Lastly, although I have not used Lift, a colleague has been extremely impressed with it (and I would probably look at it if I were writing a web application). The fat-client alternative (scala swing) I have found to be more than useable (better than raw swing at any rate!).
Groovy
It's worth noting that the creator of Groovy recently said that had he known of the existence of Scala, he would never have bothered to create Groovy!
JRuby / Jython
I have lumped these two languages together because they both represent an attempt to port the syntax of a dynamic language onto the JVM. Unless that syntax is already familiar to you, why would you bother to go down this route? I must say, the SO stats (above) do not indicate that these have the momentum at the moment.
I would also opine that moving from a statically-compiled to a dynamic language is a big step and you might be surprised by what you miss (in terms of refactoring and development aides etc.) - you may also care about the fact that the interpreted nature of these languages makes them over an order of magnitude slower than Scala.
Clojure
I have no real opinions on clojure other than to say that with an imperative background, its syntax is scary and its flow extremely unfamiliar. I am becoming more impressed by the functional paradigm but I felt that clojure was a step too far for me; I would be a fish out of water in the language, having no previous experience of LISP/Scheme.
The choice of language implies a lot of other choices, which collectively can be more important than the language choice itself. More specifically, when you choose a language, you're also choosing that language's web framework, ORM, IDE, build tool, etc.
For example, if you choose Groovy, you're implicitly also choosing the Grails web framework, if you choose Scala you're choosing Lift, etc. Although you can use Eclipse/Netbeans/IntelliJ for almost any JVM language, the experience varies quite a bit depending on which language you're using. Eclipse is a great IDE for Java development, but a pretty crappy one for Groovy/Grails development.
The problem with this kind of question is that if you ask a guy who uses language X, he'll tell you to choose X, then list all the reasons why X is so great and a few shallow reasons not to use the other languages. Examples of such shallow criticisms include:
Scala
poor tool support
functional programming is esoteric to typical OO developers
Groovy
dynamic languages are unsuitable for large projects
dynamic languages perform poorly
Jython
whitespace indendation as code block delimiters sucks
dynamic langages (see above)
JRuby
reputation for bad performance
funky syntax (from the POV of a Java developer, at least)
Clojure
very funky syntax (from the POV of almost everyone)
very immature
I should emphasise that I don't necessarily believe any of the statements above to be true,
the point I'm trying to make is that it's very easy to dismiss languages without any real experience of them (I only really know one of the languages above). So I wouldn't put too much faith in what people say against a particular language, unless you're sure they've really used it.
If I was faced with your choice I would use Groovy/Grails, because I find it to be an extremely productive and enjoyable technology to work with for building web apps, with good tool support. Are there other choices that might be even better? Sure, but Groovy/Grails is good enough for me (for now).
If you all have strong Java background and no functional and/or dynamic languages background, then you are likely to do well by keeping to Java or migrating to Scala.
I don't mean to disparage any of the other languages here, but Scala will be more familiar to you, and you can put your Java familiarity to good use. Whether you should jump to Scala or not -- that's another question. If you do, however, take notice that you need not be stuck with Lift. Not only there are other web frameworks in Scala, but people have had success combining Scala with traditional Java frameworks such as Wicket.
I worked a lot with Scala, Groovy and JRuby and I can share my experience
Scala
This language was designed in a very in a professional way. You can see it in every aspect of it.
No performance issues because it is a static typed language.
Interesting to learn and play with because of its functional nature.
BUT:
It is very complicated. You can't spend an evening to write a hello world program. You should spend at least a weekend)) Dmitry Jemerov (one of the creators of IntelliJ) said that Scala is much more complex than C++.
Lack of a good tool support. I believe that IDEs for Groovy and Ruby is much superior.
Not well integrated into java ecosystem. Of course you can use java libraries but you will dance a lot of all conversions from one collection to another e.t.c.
Lack of pure Scala libs. You always have to write a small wrapper over a java lib.
Groovy
Has shortcuts for most java boilerplate code.
Great IDE integration.
Interactions with Java are so natural and easy. It is not important whether you use a java class or a groovy class, it just works.
Great for writing DSLs
BUT:
It is a slow language (But I think that it is not an issue in most cases)
As the integration with java is the main goal of Groovy there are some unnatural aspects of the language.
JRuby
One of the best designed languages I've ever seen.
There are a lot of cool libs that can be used.
The best language for writing internal DSLs
Easy to learn.
BUT:
The integration with java sucks.
In my opinion it is too early to use Scala in production systems. It is just too hard because of the lack of tools and libraries. I used Groovy in many big projects quite successfully so it may be the best tool from these 3 languages.
With the information given you can choose any language proposed. They will all still be here in 5 years.
If you cannot decide which tool to pick for your requirements we can't help you. The information given is just to vague to decide. Start building some prototypes for all language/framework and see what fits best. Maybe the requirements are more clear afterwards.
Have you tried Jython -- Python working on JVM? I use it quite often to do various database tasks and it works quite well with such databases as Oracle, PostgreSQL and Informix. I do not create classic UI apps, but I have read that well known Python Web frameworks like web2py or django work with Jython.
If you have experience using dynamic languages, and are able to write the unit tests to support them, go that way. The development speed should be greater than what you can achieve from a static language. However, as the project will get bigger, it may become harder & harder to mantain ( it may only be me, but compile time checks help you a great deal ).
If however, you have Scala experience, I'd choose that instead. I find Scala to be a nice mix between Java and Ruby.
Good luck!
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 3 years ago.
Improve this question
I would like some practical guidance on when I should use a Domain Specific Language. I have found resources about advantages and disadvantages, but what kind of project would warrant its use?
It seems like there is a big investment in time to create and maintain a DSL, so in what application space would I get a productivity return on my time investment?
Edit: It seems the most common use of DSL is for file formats for persisting data state, what about using a DSL for program logic and structure(perhaps code generation)? When is this feasible?
Edit #2 I am mainly asking about when is creating a specific DSL worthwhile. Of course we should use existing DSLs as much as possible to save time.
There are very few good reasons for creating yet another DSL. The world is fat with special-purpose languages.
Think along with these lines.
Solve the problem with a general-purpose language such as Python, Java, C++.. whatever.
Optimize that solution to factor out the common features and build a really nice, really elegant, really extensible class library.
Optimize that class library to emphasize "orthogonality". Make sure all features work well together, without any problems.
If you need simplification of the syntax only, create a scripting wrapper around your nice class library. This is your DSL. For Python, this is easy -- it's already a dynamic language. For Java, there are things you can leverage. For C++ it can be a bit of work to build this flexible scripting environment.
If you still need further optimization, consider writing a compiler for your DSL.
The ACM Computing Surveys article When and How to Develop Domain-Specific Languages provides advice on just this topic, as does Martin Fowler's 2010 book Domain-Specific Languages.
Firstly, I would use a DSL when the problem domain your developing against is a widely well known domain, and some business experts of that domain have already went through great lengths to build such a DSL so that you wouldn't have to go through the lengths yourself to solve all the problems they have already figured out.
If you're thinking of creating a DSL, I would consider doing so if your business is done in a very particular area, and you spend the majority of your time focusing in a specific problem domain. If you bounce around doing applications for multiple problem domains, then I wouldn't advise taking that approach.
For example, if your business is soley in building tax applications, it might be a good idea to build a tax system DSL. This would allow your language not only to be useable by you in your various tax applications, but it would also be marketeable (useable) by other businesses in your industry that want to do similar things that you're accomplishing.
Of course, you have to weight the costs/benefits of building a DSL vs a framework on top of an already existing language.
One situation that comes to mind is when the requirements requires a very high or improbable level of customization/configuration. So you would provide a kind of scripting model against a DSL instead.
Takes a car assembly "arm" for example, providing a configuration model to support various factory configurations would be impossible. (detect this, don't detect that, when this happens do this ... etc.)
But compiling a new application with specialized logic for each customer is probably not a good way to go. So in this case, you create a little framework that would becomes a kind of DSL, and then for each robotic arm you sells, you write a little app in your DSL and save it along with the core software that would compiles and runs your DSL scripts instead. Or better yet, tools to program the DSL are included along with the robotic arm so your customer can "program" the arm themselves in the DSL you created.
One real world examples that comes to mind is Yahoo Pipes (you could think of it as a DSL) or the robots.txt directive for automated web crawler for example. They may not be a full-blown DSL but they demonstrate where DSL might be useful.
Well, someone has to say it, so here goes:
Lisp is regarded by some as the domain specific language for any domain. A well-supported and very extensible DSL at that.
In some cases, fashioning a DSL from Lisp (or a similar language such as Haskell) could actually provide a lot of power with minimal effort, and thus would be quite worthwhile. DSLs do not always need to be big maintenance burdens.
The most obvious is you should definitely use them when the language already exists and is well-supported. The prime examples of this are UIL for Motif-based GUI development and make for software builds.
If you have to make your own, I'd say to look for domains a large amount of effort is in just specifying things properly, and where your compiler can't really find most errors, but a domain-specific compiler could. GUIs are a great example, as most of the work is in setting up the layout, and there are generally lots of ways to make syntacticly valid C++ calls that make no sense whatsoever to your underlying GUI system (EG: trying to embed an entire dialog widget inside a button).
I find UIL particularly a huge gain for GUI development because a UIL compiler can find errors in a GUI specification that just look like nice normal compilable code to a C++ compilter. The fact that it is well-supported means that the code is easy to port between platforms, and even GUI builders.
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 4 years ago.
Improve this question
I was looking at http://tldp.org/LDP/abs/html/why-shell.html and was struck by:
When not to use shell scripts
...
Mission-critical applications upon which you are betting the future of the company
Why not?
Using shell scripts is fine when you're using their strengths. My company has some class 5 soft switches and the call processing code and the provisioning interface is written in java. Everything else is written in KSH - DB dumps for backups, pruning, log file rotation, and all the automated reporting. I would argue that all those support functions, though not directly related to call-path, are mission critical. Especially the DB interaction. If something went wrong with the DB-interaction code and dumped the call routing tables it could put us out of business.
But nothing ever does go wrong, because shell scripts are the perfect language for stuff like this. They're small, they're well understood, manipulating files is their strength, and they're stable. It's not like KSH09 is going to be a complete rewrite because someone thinks it should compile to byte code, so it's a stable interface. Frankly, the provisioning interface written in Java goes wonky fairly often and the shell scripts have never messed up that I can remember.
I kind of think the article points out a really good list of the reasons when not to use shell scripts - with the single mission critical bullet you point out being more of a conclusion based on all the other bullets.
With that said, I think the reason you do not want to build a mission critical application on a shell script is because even if none of the other bullet points apply today, any application that is going to be maintained over a period of time will evolve to the point of being bit by at least one of the those potential pitfalls at some point.....and there isn't anything you are really going to be able to do about it without it being a complete do over to come up with a fix....wishing you used something more industrial strength from the beginning.
Scripts are nothing more or less than computer programs. Some would argue that scripts are less sophisticated. These same folks will usually admit that you can write sophisticated code in scripting languages, but that these scripts are really not scripts any more, but full-fledged programs, by definition.
Whatever.
The correct answer, in my opinion, is "it depends". Which, by the way, is the same answer to the converse question of whether you should place your trust in compiled executables for mission critical applications.
Good code is good, and bad code is bad - whether it is written as a Bash script, a Windows CMD file, in Python, Ruby, Perl, Basic, Forth, Ada, Pascal, Common Lisp, Cobol, or compiled C.
Which is not to say that choice of language doesn't matter. There are very good reasons, sometimes, for choosing a particular language or for compiling vs. interpreting (performance, scalability, capability, security, etc). But, all things being equal, I would trust a shell script written by a great programmer over an equivalent C++ program written by a doofus any day of the week.
Obviously, this is a bit of a straw man for me to knock down. I really am interested in why people believe shell scripts should be avoided in "mission-critical applications", but I can't think of a compelling reason.
For instance, I've seen (and written) some ksh scripts that interact with an Oracle database using SQL*Plus. Sadly, the system couldn't scale properly because the queries didn't use bind variables. Strike one against shell scripts, right? Wrong. The issue wasn't with the shell scripts but with SQL*Plus. in fact, the performance problem went away when I replaced SQL*Plus with a Perl script that connected to the database and used bind variables.
I can easily imagine putting shell scripts in spacecraft flight software would be a bad idea. But Java or C++ may be an equally poor choices. The best choice would be whatever language (assembly?) is usually used for that purpose.
The fact is, if you use any flavor of Unix, you are using shell scripts in mission-critical situations assuming you think booting up is mission critical. When a script needs to do something that shell isn't particularly good at, you put that portion into a sub-program. You don't throw out the script wholesale.
It is probably shell scripts that help take a company into the future. I know just from a programming standpoint that I would waste a lot of time doing repetitive tasks that I have delegated to shell scripts. For example, I know most of the subversion commands for the command line but if I can lump all those commands into one script I can fire at will I save time and mental energy.
Like a few other people have said language is a factor. For my short don't-want-to-remember steps and glue programs I completely trust my shell scripts and rely upon them. That doesn't mean I'm going to build a website that runs bash on the backend but I will surely use bash/ksh/python/whatever to help me generate the skeleton project and manage my packaging and deployment.
When I read thise quote I focus on the "applications" part rather than the "mission critical" part.
I read it as saying bash isn't for writing applications it's for, well, scripting. So sure, your application might have some housekeeping scripts but don't go writing critical-business-logic.sh because another language is probably better for stuff like that.
I would wager the author is showing they are uncomfortable with certain aspects of qualtiy wrt shell scripting. Who unit tests BASH scripts for example.
Also scripts are rather heavily coupled with the underlying operating system, which could be something of a negative thing.
No matter we all need a flexible tool to interact with os. It is human readable interaction with an os that we use; it's like using a screwdriver with the screws. The command line will always be a tool we need either admin, programmer, or network. Look at the window they even expanded on their Powershell.
Scripts are inappropriate for implementing certain mission-critical functions, since they must have both +r and +x permissions to function. Executables need only have +x.
The fact that a script has +r means users might be able to make a copy of the script, edit/subvert it, and execute their edited Cuckoo's-Egg version.