You can read about it here: https://www.irs.gov/Businesses...
You can read about it here: https://www.irs.gov/Businesses...
But (a) I don't have a Linux box. Part of the discussion here is the ubiquity of Emacs, so a good quality Emacs that fits well in Mac OS X is relevant. I'd expect Emacs to be part of any (reasonable) Linux distribution, (b) which windowing environment would be running on my Linux box if I had one? (c) when I actively cranked out code for a living on Sun workstations, the only reason I ran the window manager was to get screen acceleration for my terminal windows, one of which ran old-fashioned Emacs. (the second was the command line shell for running the compiler, and the third ran Rogue/NetHack, to give me something to do while compiling
NO! I should have mentioned that. THE ONLY WAY to file this form ("substantial penalties for failure to file" and they will go after you because of money-laundering initiatives) is through Adobe Acrobat!!
Treasury Dept requires the use of Adobe Acrobat to fill out and submit the 'foreign bank account' form (I have to report every year on my Canadian RRSP - 401k equivalent- since it's more than $10k.)
You would think the obvious way to do this is with a (secure) website. But no, that's not how Treasury does it. Instead, they have to have some back-end that extracts information from the specially crafted PDF that can only be submitted through Acrobat Reader (you can't just email or upload the filled-out PDF form.)
So every year I install Acrobat, fill out the form, and then uninstall Acrobat Reader (letting Mac OS X Preview.app handle all other PDF duties.)
Frankly, I've never been much of a fan of IDEs. My biggest project used Rational Apex, which was a full up IDE (long before Eclipse, etc.) The most productive programmers on that project, though, used a text editor (Emacs or VI) and ran the compiler from the command line. No point wasting cycles on fancy GUIs that mostly got in the way. The only time I cranked up the Rational IDE was to run the debugger, and any time I had to run a debugger, it was a direct admission that I had -no clue- what my code (or someone else's code) was doing, and I considered that a personal defeat.
Usually, I had an Emacs session, a command line session, and a terminal session running rogue (for something to do while the compiler/linker was running, I could usually knock off a level or two.)
Too late! I've already posted and disqualified myself.
When I was doing Real Work writing software, I developed the classic Emacs 'carpal tunnel' in the left hand from stretching the pinkie too much for moderator keys. A couple other people I know who are dyed-in-the-wool Emacs users have also developed that.
What other software produces its own injury?
Yes, I can. Emacs run from the terminal is the classic Emacs experience. Aquamacs has a lot tighter integration with Mac OS X including better handling of both frames and windows.
Mod parent up, this is my experience, too. (And I love Aquamacs on my Mac.)
Why is it I don't have moderator points when I really want them?
Well, I've worked on several IEEE and ISO standards projects in software, so I do have experience with the processes.
Standards activities might well be the way you describe, but those I've worked on are not.
I think the SDOs (ISO, ANSI, IEEE, etc) made a fundamental mistake when they decided to accept patented technologies as part of formal (de jure) standards.
If I were King, the FRAND license cost for any patent that appears in a de jure standard would be $0. If the patent-holder won't give up the rights, then the technology should not appear in a standard. Now that clearly would restrict what can be standardized, but that's a tradeoff that both society and patent holders should accept.
(And technology R&D funded by governments should be royalty/license free. DoD certainly used to do that, and look at the advantages -commercial companies- have gotten from the fact that the basic Internet protocols are royalty free/not patented.)
I think that's a fair summary. The Military got into a huge case of "commercial industry is better" (despite evidence to the contrary for large software intensive systems.) The Ada compiler vendors charged high prices to their captive market, discouraging commercial use with the bar to entry being too high. C, on the other hand, had $99 PC compilers (or cheaper) and it was easier to learn the basics (but it takes at least as much time to become competent in C as in Ada, particularly when you take into account learning all the idioms and conventions on the one hand, and the things to -not do- on the other hand.)
There has been (and still is) pockets of Ada usage in transportation (air traffic control, avionics, train control) where the safety of large software systems is a driving consideration. The primary viable Ada compiler is open source, see http://www.adacore.com/
Availability of Ada programmers is not the issue (although it's often used as an excuse.) My back-of-the-envelope calculation is there are at least 100k people in the US with Ada training. The problem is that most of them are making much more money doing C (in part because Ada provided a good foundation for reasoning about software systems, making them better-than-average C programmers.) Case-in-point: My friend who was making $100+/hr doing C, and never got an offer for more than about $55/hr for Ada. That being said, he often does prototyping in Ada, and then if necessary recodes the application into C or Java.
DoD got in many respects what it wanted, a 'universal language' with low entry cost, lots of cheap programmers, and commercial tools, from C. Unfortunately, they also got the 'throw low cost bodies at it' culture that produces so much crappy software.
APL is probably the least verbose language ever. Not used much, these days: https://en.wikipedia.org/wiki/... In this context, APL would have a lot going for it. However, understandability is probably none of those....
ISO/IEC JTC1/SC22 has had a group looking at programming language vulnerabilities, including (a) how to define a 'vulnerability'; (b) how to assess languages against those definitions; (c) an assessment of languages (that have de-jure standards) for vulnerabilities, and related work. There is an introduction here http://www.open-std.org/jtc1/s... and the work is documented here: http://grouper.ieee.org/groups...
(Do you suppose the authors of this report are aware of the ISO work?)
The normal metric for languages like Ada, Pascal and yes C or C++ (those should not be considered the same language!) is "statement" as defined by the grammar, and usually simplified by counting "semicolons". If you figure out how to add preprocessor/header files, you'll probably see that for equivalent applications, the statement count between C and Ada is about the same. That's based on my real-world experience working with both languages over the last 30 years, I have no idea if the parent poster has much real experience in Ada (I kinda doubt it.)
There are some things that are very concise in C or C++. There are also some things that are very concise in Ada (imagine how many hundreds of lines of C and threads packages you need to code to get the equivalent of Ada tasking rendezvous.)
True story: as part of an experiment we implemented part of TCP (in particular, the timeout provisions associated with NAK) in both Ada95 and C. It took me 5 lines of Ada95 (Asynchronous Transfer of Control) to do what the other developer (who had experience coding protocols) did in 300 lines of C. His code had a bug in it, too.
Money cannot buy love, nor even friendship.