Careful, I emphasized *Scheme* and not *Common Lisp*. All Schemes are *required* to be properly tail recursive, per spec, which combined with garbage collection completely deals with the pure-functional-style memory pressures properly. It's true that nobody in practice writes large (Common) Lisp projects in functional style, but Common Lisp doesn't guarantee proper tail recursion (and implementations don't typically provide it), so that should be unsurprising that you can't really scale that up in Common Lisp.

This is an excellent idea!! It's further explained in THE DICTATOR'S PRACTICAL INTERNET GUIDE TO POWER RETENTION (aka "Dictator's guide to the Internet") section 3.1, "Suppressing anonymity (who)": "There are two things that are simply not compatible with the regime you run: anonymizing tools and data-encrypting tools. With anonymizing tools, you can perhaps control and monitor internet activity, but you cannot tie this activity to a certain individual. Anonymity thus makes accountability evaporate. With data-encrypting tools, you cannot even see or make sense of the data which travels in the internet cables you control, as it is mangled specifically to avoid being recognizable. The proliferation of online political dissidence in non-democratic states is usually dependent on the availability of tools to anonymize and encrypt data. If you cannot effectively dismantle the use of these tools, it's often a matter of (short) time before political opposition organizes against you."

Actually, the braces are implemented in the reader. In Common Lisp terminology, they can be implemented as a "reader macro", but this is a completely different step than the Lisp "macros" usually refer to. This means that you can use {...} with data or code, and you can even use them as inputs to macros (in the usual sense). Thus, you can combine Scheme's "define-syntax" with {...} without problems. The SRFI-105 spec has some examples you might want to look at.

Actually, it turns out there's no problem.

The tools require consistency, and report an error where it's not. Then if you are a tab-only person, you can use tabs. If you are a spaces-only person, you can use spaces. If you try to use them inconsistently (tab on one line, where space was used on the previous line), then it reports an error.

Notice that this is COMPLETELY DIFFERENT from Makefiles. The problem with Makefiles is that there are cases where you can't tell where an error is, and so it quietly does the wrong thing. Requiring that you MUST be consistent means that you can use either spaces or tabs... but the next line that's indented better be consistent with its parent.

Scheme is normally considered a functional programming language. The 1989 paper "Conception, Evolution, and Application of Functional Programming Languages" by Paul Hudak defines functional programming languages as languages "in which computation is carried out entirely through the evaluation of expressions" (as opposed to setting mutable states, like variables, or allowing routines with side-effects). That paper specifically identifies Lisps (including Scheme) as languages that can be used as functional programming languages, as well as ML and Haskell. Like ML, Scheme provides mechanisms that let you "escape" outside the functional programming paradigm, but "well-written code" normally doesn't do that.

"Programmers that use Lisp or Scheme for a while end up using plain prefix."

Sure, for those few programmers who keep using (Common) Lisp or Scheme. But almost all developers say, "what, no infix?", and ignore or stop using Lisps. And those who stick around find that it's hard to use infix in most Lisps today because there's no standard mechanism for using it. We're working to fix that, while keeping Lisp homoiconic and general.

The percieved inconvenience of prefix notation is due to not being used to it.

Prefix and infix have exactly the same capabilities, notationally. But of COURSE people are used to infix. Are you saying that schools will stop teaching and using infix in school? That math books will stop using it? I do not think so, and that means that while infix and prefix have the same capabilities, failing to support the standard (infix) has been a long-standing problem in Lisps. All developers show up with 15+ years of experience with infix, and 0 with strict prefix. Even if YOU like prefix, all future developers will have a 15-year head start in reading infix. So saying, "everyone will do it this non-standard way" doesn't really make sense, and more importantly, is provably false. Lisp has has had 50 years to convince people to only use prefix and failed to convince most developers; time to do something different.

After a while you realize that prefix notation is a lot more readable and less error-prone than infix.

I disagree. They are the same in terms of capability. And when people spend 15+ years being trained in one notation, all other notations are less readable and will remain so for many years. I've been writing prefix code for 30 years, and it isn't magically more readable. Indeed, what I find is that many people are unwilling to use a language that cannot handle infix.

The *notation* is more flexible. That said, if you want to use the notation a particular way, then feel free. I normally use two-space indentation in sweet-expressions. However, to get a notation accepted for wide use, the notation has to accept the different ways that people work. Python accepts either spaces or tabs, specifically because you can't get agreement on one or the other. The same argument applies here, too.

There's no problem. You can use spaces or tabs, but you HAVE to be consistent when you use one or the other. So if you indent a line with a tab, all sibling and child lines MUST start with a tab... multiple spaces don't count. You can even mix, but you still have to be consistent, so if you use tab space space, all later siblings and child lines must start with tab space space.

Curly-infix-expressions (as well as sweet-expressions, which are a superset) are just additional abbreviations. In curly-infix, the surrounding "{...}" indicate that it's a list, but that parameters are written in a different order than they are actually stored. So {a + b + c} is just (+ a b c). We're now wrapping up sweet-expression notation, which is a superset that uses syntactically-relevant indentation (like Python). Check out http://readable.sourceforge.net/ for more info, and in particular, please join the mailing list!!

Another cool thing about GNU guile is that the most recent version supports SRFI-105, "curly-infix-expressions", as developed by the Readable Lisp S-expressions Project. Curly-infix expressions let you write stuff like {a + b} instead of (+ a b), which is a big improvement in readability.

You can see more about Ada 2012 here; the rationale is probably the best place to start.

Yes, this is similar to the assert mechanism of C, Python, etc., but because it's built into the language, it can do some extras. Often these are optimized out, because the compiler can determine that they're always met. You can also define a "Type_Invariant" once, and then the invariant is checked every time the value can be changed from the point of view of a user (e.g., after initialization, conversion, or return of a value of that type). A type_invariant is like inserting C "assert" calls in every call that might return it, but only having to say it once.

Yes, people are using Ada, in fact, it's been making a quiet comeback. Ada is the #16 most popular language according to the TIOBE programming language survey of November and December 2012, an increase from #19 in November 2011. Keller reports that by 2000 Ada use had decreased and then increased again. It's not huge compared to C or Java, of course; its use is focused in certain domains. In certain communities, such as aviation software, it continues to be a popular language and has been credited with helping to produce high-quality software within time and budget.

Historically, Ada was developed by the Department of Defense (DoD), and the DoD tried to make it the one and only universal language . An NRC report on Ada talks about this. Fundamentally, trying to make one language do everything was a bad idea, and predictably failed; there is still no one language that can be all things to all people, even many years later.

Ada isn't a complex language by today's standards, but it has a lot of "pickiness" that means you have to obey more rules. Is that a good thing? Well, you first have to understand what it was designed for - and then decide if that design is what you want.

Ada focuses on software that needs high reliability and yet absolutely no compromise of performance. If reliability isn't really all that important to you, or you can give up a lot of performance, then Ada's trade-offs may not work for you. For reliability, it has a strong typing system, and you have to use generics (etc.) instead of just saying "shut up and trust me" a la C. For performance, it doesn't mandate automatic garbage collection (as compared to Java or Python). Ada shines when you're writing programs that will could un-intentionally kill people if the program is wrong or takes too long. Think airplane flight controls, train systems, medical systems, that sort of thing. A lot of Slashdot readers have never tried to write software that could accidentally kill people, and thus can't understand why you might want a "picky" language like Ada. If your response to "it has a bug" is just "install this patch" maybe another language would be fine. But when mistakes can kill, having a language that helps prevent them can be literally a lifesaver.

I disagree. You don't wait to build a fire escape until the building is on fire. Similarly, we need a good alternative hash algorithm now, not when disaster strikes.

I believe that, in general, we should always have two widely-implemented crypto algorithms for any important purpose. That way, if one breaks, everyone can just switch their configuration to the other one. If you only have one algorithm... you have nothing to switch to. It can take a very long time to deploy things "everywhere", and it takes far longer to get agreement on what the alternatives should be. Doing it in a calm, careful way is far more likely to produce good results.

The history of cryptography has not been kind, in the sense that many algorithms that were once considered secure have been found not to be. Always having 2 algorithms seem prudent, given that history. And yes, it's possible that a future break will break both common algorithms. But if the algorithms are intentionally chosen to use different approaches, that is much less likely.

Today, symmetric key encryption is widely implemented in AES. But lots of people still implement other algorithms, such as 3DES. 3DES is really slow, but there's no known MAJOR break in it, so in a pinch people could switch to it. There are other encryption algorithms obviously; the important point is that all sending and receiving parties have to implement the same algorithms for a given message BEFORE they can be used.

Similarly, we have known concerns about SHA-2, SHA-256, and SHA-512. Maybe there will never be a problem. So what? Build the fire escape NOW, thank you.

No, you're completely wrong, this is not the current policy of the United Stated federal government.

It's true that when a US government employee develops software, as part of his official duties, it is not subject to copyright in the US (with a few tiny exceptions). But that doesn't mean it actually gets released to the public; in almost all cases it is never released to the public. (Sometimes it does, like expect and Security-Enhanced Linux, but most of the time it doesn't). Even more importantly: most software developed using government funding is developed by contractors, not by government employees, in in most cases the rule about government employees doesn't apply anyway.

For the details of when software funded by the US government can be released as OSS, see this:"Publicly Releasing Open Source Software Developed for the U.S. Government" by Dr. David A. Wheeler (me), Journal of Software Technology, February 2011, Vol. 14, Number 1.

Now it's true that a few small parts of the US government do have such a policy. In particular, the Consumer Financial Protection Bureau's source code policy does share the code with the public at no charge by default.

I do agree that when "we the people" pay for the development of software, then by default "we the people" should get it (unless there's a good reason for an exception, e.g., it's a classified weapon system). Sounds like a good idea. It's even a good idea for the government itself, because it will greatly enable competition for future work (building on past work) and reduce redevelopment (because it'll be easier to find previously-developed stuff). But that's something people need to press for... don't assume it's already happened.

Ask for "release government-funded software as OSS by default" - don't assume it's already happened.