r/CMVProgramming

Seriously, I think it is the worst thing to exist in ages. It's a very backwards-designed language - things that would be simple and easy in other languages (like higher-order functions, pattern matching or even multiple dispatch, declarative/concatenative programming, whatever) are extremely hard in Java (so they invent bullshit anti-patterns like Strategies, Factories, Visitors, whatever).

I feel like most of the code is Enterprise crap - Java EE, Spring, all of these bullshit frameworks with stupid concepts like DI/IoC (which wouldn't be bad outside of Java) or "Aspect Oriented Programming" (we could play buzzword bingo all day long.)

One class per file is stupid, especially in a

TDD and unit testing have reached a status where they are now considered morally good, without any regard to their merit in any situation.

Sometimes I have better outcomes when I ignore unit testing altogether.

For instance, when I am automating external systems, I don't know what the failure modes are when I get started. LVM (on Linux) is a good example of an external system I might manipulate. I have discovered that exit codes for utilities aren't always sufficient to determine success or failure of an operation. I find that unit testing done before that practical experience can be counterproductive.

Unit testing and test driven design need be demoted from aspiration to just tools.

There exist many strong, near-perfect languages already for their respective domains: SQL for relational queries, date for date formatting, find for filesystem folding, regular expressions for patterns. C for the low level. Python for small scripts. Lua for embedded scripts.

What we lack is the good general purpose language. That is to say, the language for writing complex, end-user programs. It is still a royal pain to write one's own web browser or a word processor. It is still a complexity hell to write a web app approaching facebook or pintrest, though Django and RoR can create absurdly simplified, toy versions of these in fifteen minutes.

Haskell is not the answer. If you leave to

This subreddit is relatively dead. I don't think it's because there is a lack of opinions in the software world, but because there is a lack of subscribers to this subreddit. So, here are a few things I want to ask of you:

• Mention this subreddit as often as you can, but only if it is relevant.

• You've got an opinion? Post it, we need the activity.

• Posting neutral posts is fine, as long as you know there are people with opinions on both sides. Try to make them open-ended.

While I enjoy the accessibility and ease of access, it seems to me that bulletin boards, file sharing and maybe really basic webmail interfaces for when you can't use your e-mail client are pretty much the most complex things that should reside on the Internet. Otherwise, the whole web app ecosystem seems to repeat a lot of mistakes that we've already seen and made in the late 80s and early 90s, from the unnecessarily complex supporting infrastructure (both in terms of software and in terms of hardware and deployment) to the overreliance on network availability and tool bastardization (yes, CSS!).

Some reasons for this are:

• The development environment is really, really bad. You can't

So basically, I would claim that dynamic typing is just static typing with only a single type, which looks roughly like this:

data Uni = Number Float | Str String | Dict (Map String Uni) | Function (Uni -> Uni) | Nil | Etc

Syntax note: this basically says that a value of type Uni is either the tag 'Number' and a float, or the tag 'Str' and a string, etc.

Lambdas: anonymous pieces of code, defined inline. Can be passed as parameters. Pointless if their syntax is too verbose.

See this for an example.

I have tried the usual dynamically-typed languages, in particular Python, Javascript, Ruby and Lua, and so far have only found dynamic typing a hindrance, especially if a project grows to any adequate size. It may be non-idiomatic, but I usually end up writing a make-shift runtime type system for each function manually, i.e. type-check all parameters, make sure values are in the correct range, make sure return value is correct, etc. Most of the time, not having type checking doesn't introduce bugs, per se, since the usual problems that I will encounter will be obvious, but they are damn annoying. Some of the most irritating of these (taken from my experience with Python) are:

• Forgetting

I believe ease or speed of text edition has very little to do with a programmer overall productivity. Finely crafted tool chains are much more important: debuggers, code analyzer and explorer, refactoring utils... Most of them can be emulated in vim or emacs but always quite awkwardly. What do you think?

They both are ugly languages with terrible stdlib barely sufficient for their tasks. C wasn't pretty even when it was born (mind that original K&R C was extremely primitive), and now it's outright repulsive: "header files" abomination (sane languages forgot them by mid 70s), backwards syntax, array/pointer equivalence and zero-terminated strings (very convenient for exploits). Well, time to reread Unix Haters Handbook...

Typeclasses.

Also, evidence is always good. That's one thing I am convinced of.

Yeah, I'm desperate at making this active. Here we go:

The opening { should be at the end of the line it is opening a block for, not at the beginning of the next line. That is, this

if (true) {
   Egyptian braces FTW
}

not this

if (true)
{
   Gamma braces FTL
}

Why?

• It's shorter.

• It keeps the lines following the header close to the header.

• It makes more sense, syntactically. Except for very specific cases, you can see the braces as a special case of the block syntax. In the first case, we are putting the statement on the same line as the if. In the second, we are putting the statement on the next line, but without indenting it. Yes, that's a pre

It doesn't have to be full-blown macros, but some kind of metaprogramming, such a closures, is necessary to make the language sufficiently extensible.

Edit: well, one thing I learned is that people don't consider Higher Order Functions metaprogramming, which, to me, is weird, but I guess that's a thing.

Edit2: In fact, people really don't want to call HOFs metaprogramming.