Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
(Edited to narrow the question to Ada. Have posted other questions for Fortran and COBOL.)
I've spent some time in the past year dealing with changes to my code due to Python v2->v3 and R v3->v4 changes. It got me curious as to some of the older languages that are still in use.
I know Ada still sees occasional updates and functionality upgrades. I would assume that their mission-critical nature makes those changes smaller and more backward-compatible, but I don't really know and couldn't find it with a web search.
What and when were the last changes to Ada that was on the same rough order as the Python 2->3 changes?
Ada pays a lot of attention to reverse compatibility, to avoid breaking existing code, when making changes.
Last formal Ada release was Ada-2012, there is another one (Ada-202X) in progress.
Ada-2012 has a lot that Ada-83 doesn't, but I'd be surprised if there was anything more than trivial work to build an Ada-83 project (or Ada-95 or Ada-2005) in Ada-2012.
There are some differences though : from Ada-83 to Ada-2012 As you can see, there's really not much to say for 30 years of development.
Related
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 6 years ago.
Improve this question
I have looked around and have not found many opinions on if it is important to update your R software as soon as a new version is released.
Any opinions would be welcomed!
As with any software, you should carefully evaluate what is included in any new release. If the release consists only of bug-fixes, it is usually expedient to install it as soon as it is practicable for you to do so. If the scope of the release is more expansive -- new features, etc. -- you should review the release more carefully.
If you're in the middle of an important project with a killer deadline, it's quite reasonable to wait a little while before applying any update.
Also, you should as a matter of routine re-run a selection of jobs, that you know the answers to, in order to be sure that the answers are still the same. "No, mistakes of this nature don't happen often, but they do happen."
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 7 years ago.
Improve this question
I have been using prepros for a while. It's a easy to use precompiler that pretty much does everything I need. I heard it is not good for team work but didn't know why.
Why would you spend time to set up gulp to for minification, concatenation, uglify/mangle, live reload and live server when you can simply press one button and do all of these works in 5 secs?
I've never used Prepros and therefore have nothing negative to say about it. However, I think:
a) Your point is somewhat reductionist. Gulp isn't just a precompiler, it's a task runner and can likely do a lot more than what Prepros is able to do out of the box. It's great if Prepros fits your needs, but what happens when you run into something that it can't do?
b) Gulp/Grunt/etc. are free (limiting proprietary software purchases is often beneficial in a team setting) and open source (easily tailorable to your needs)
As an aside, I'm not sure if Prepros allows settings to be shared by different members of the development team, but will gulp/grunt/etc. you check your gulpfile/gruntfile/etc. into source control and build tasks/etc. are available to all developers with access to said repository/project
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 9 years ago.
Improve this question
Not sure if this is the right forum (and if so, point out to me and I will delete this post!).
I had been evaluating languages to replace a existing code written in R that has around 4k-5k lines(and used for live trading), primarily to get speed and I liked Julia (v0.2.0) - not only for its speed, but also because the language is easy to learn.
I would like to initiate a project to rewrite the existing R code in Julia, but since it can be a major exercise for me, I wanted to ask if there is any information available anywhere whether the future releases of Julia will be largely backward compatible with Julia v0.2.0?
For example, one issue I faced earlier with Python was that v3.0 onwards are not quite backward compatible with v2.7, and v2.5 codes don't often work on v2.6, v2.6 codes don't often work on v2.7, requiring significant rewrites because you have to carefully evaluate where the old code broke (and was almost always better to rewrite the code from fresh). I want to avoid the same issue with Julia.
While Dirk is right that anything is on the table for changing up to version 1.0, we do have some assurances about compatibility:
There is a release-0.2 branch that will contain only bug-fixes, so if you write code for Julia 0.2, it will continue to work on that branch
We try very hard to deprecate APIs that we change, rather than just yanking them out from under you. This means that your code will keep working, but you will get a warning telling you the new way to do something.
There have been very few basic syntax changes in the past year, and I don't really foresee any big ones. Most of the changes that still need to happen are standard library API changes.
"Maybe" but probably not.
Goals for the 0.3 to 1.0 transition are (among other things) to get all breaking changes out of the way.
In other words, between now and 1.0 changes are to be expected.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I've just finished and tested the core of a common lisp application and want to optimize it for speed now. It works with SBCL and makes use of CLOS.
Could someone outline the way to optimize my code for speed?
Where will I have to start? Will I just have to provide some global declaration or will I have to blow up my code with type information for each binding? Is there a way to find out which parts of my code could be compiled better with further type information?
The programm makes heavy use of a single 1-dimensional array 0..119 where it shifts CLOS-Instances around.
Thank you you Advance!
It's not great to optimize in a vacuum, because there's no limit to the ugliness you can introduce to make things some fraction of a percent faster.
If it's not fast enough, it's helpful to define what success means so you know when to stop.
With that in mind, a good first pass is to run your project under the profiler (sb-sprof) to get an idea of where the time is spent. If it's in generic arithmetic, it can help to judiciously use modular arithmetic in inner loops. If it's in CLOS stuff, it might possibly help to switch to structures for key bits of data. Whatever's the most wasteful will direct where to spend your effort in optimization.
I think it could be helpful if, after profiling, you post a followup question along the lines of "A lot of my program's time is spent in <foo>, how do I make it faster?"
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
i understand well the parent-child relationship in unix processes creation. But i don't understand the rationale behind it :( why do we need to fork from the current process to create a new one, then overwrite its image with a new code if any? cheers
The rationale is that unix system calls (at least originally) are "elementary" operations done by the kernel.
In practice, applications often do some specific things between fork(2) and execve(2), in particular calls to close(2) and dup2(2), also sigaction(2) to ignore some signals (with perhaps some pipe(2) syscalls done before the fork).
If you wanted to have a single syscall handling all this at a time, it would have been very complex, and less flexible.
I suggest to read some book like Advanced Linux Programming (it is free and online) or Advanced Unix Programming in addition of intro(2).
I find on the contrary the intent to separate creating a process and executing a program quite natural. I don't really understand why you want both operations to be combined.
See also this mine answer about syscalls.