einhverfr

But here you are talking about functional style rather than functional programming on a definitional level. I do agree that Java is not well suited for FP. I think you can apply the base theory of FP to the language, but it may be little more than an academic exercise.

The problem with FP and Java is that FP and object encapsulation don't really go very well hand in hand. I.e. in Java you are encouraged to think about objects and their behavior, as encapsulating state. Encapsulated state in not a goal in any FP I have done -- rather the problem is solved by making state structures immutable.

But this doesn't mean you can't. It certainly won't look like Haskell though. It won't be idiomatic Java either. In fact it may be almost, though not entirely, unlike normal Java code.

Having worked on some major financial web sites (globally), including password code, I can say a few things that may be relevant.

The thing is, you never get a sense of how bad legacy code can be at restricting options in reforming sanity until you have worked on such sites.

It took me about 5 months to restore sanity to one codebase with a bunch of problems regarding encryption and passwords. Fortunately security was a priority, and not just security checkboxes in PCI requirements but real security. But it wasn't cheap and it wasn't easy, and we ran into a lot of unpleasant surprises along the way.

Looking at this the chance is that you have tons of legacy code, and these fit together in not very nice ways. People are afraid to change things because of PCI requirements, security scan results, etc. And the cost of fixing things my be very high. In these cases, I can imagine a "don't rock the boat" mentality developing and a large part of security-critical code becoming effectively untouchable.

Agreed, but one huge problem here is that getting a customer often requires more than a checklist of features, but rather a product that solves a customer's problem well.

I agree that sales, support, and engineering should all have rotations. The sales and support give you very different insights into what customers need which help you out with your engineering.

> So instead of temporary staff, they take people off of their current projects to work in customer service?? This doesn't sound like a good idea to me.

Why not? It improves solidarity. Actually when I worked at Microsoft doing tech support, I got pulled off the phones to help with sudden mandatory tech support rotations due to virus outbreaks. It was great to see marketing managers have to help people assess whether their systems were infected and apply appropriate tools. I would take escallations but generally people did a good job. (Oh and these people showed up with very little training on customer service or tech support so that was fun).

But I think one thing that Microsoft got out of it (this was in 2002-2003) was a stronger sense by everyone why it was important to focus more on system security. I think this improved the company and lead to better software.

> Especially since I've been in positions where I have been on tight deadlines.

If management know of the rotation, they will have to adjust the deadlines. How many deadlines are really necessary beyond a simple measurement rationale? Management can usually adjust as needed, or reschedule the rotation to a better point.

> With me, it's difficult to move from customer service right back to software development/engineering.

Isn't the point though to ensure that people are engineering and developing software with customer service in mind?

Not just weak developers though. I don't have a CS degree, so I took one look at the job market and realized my only option was self-employment because I would never get past resume screeners.

I am not entirely sure that ASM can be used directly for functional programming. Also I am not entirely sure that functional == declarative although that is a very powerful combination. As far as I am concerned functional programming centers around the guarantee that f(x) has the properties associated with a function, i.e. for every x, exactly one f(x) is correct. That's why your data structures must be immutable. That's why you need referential transparency, etc. But how you calculate f(x) really doesn't determine whether this is FP or not. There's certainly a lot of power that can come from a language that can compose or decompose functions for you. But I wouldn't use that as a litmus test for FP.

But I suspect (not entirely sure, but suspect) that if you apply sufficient discipline, and omit from the equation the global necessities of registers, you can probably create functions in assembly, and call them in a functional way. In fact I suspect if this were not possible, then FP languages would not be possible to create.

But FP in ASM sounds really really painful.

In the Seattle area it was bad enough I started my own business, moved my family of 3 into my parent's house and tried to make do on my income tax refund.

This is also true. OOP in Java is certainly not the same as OOP using CLOS, and not the same as Perl and Moose.

But there is a common thread through these. Namely with OOP, you are tying structure and behavior together so that behavior can encapsulate structure. OOP, like FP, isn't so much "a paradigm" as a "family of paradigms," one or more per language.

Well, a 200k line codebase, maintaining it for current users. Yeah might have been better to start from scratch.

OTOH what one gets by going this way is a community of users, and therefore it will still beat Hurd 1.0 to completion. Starting an ERP from scratch without funding as a multi-vendor effort would lead to something that would never be released.

But you should see the legacy code. The code we forked from was a textbook of how not to write (secure, maintainable, bug-free, etc) software.

But that isn't taking into effect the contagion issue. In theory your view is the way it works. In practice doing it "properly" comes out half-properly because you spent all your other time maintaining horrible code so that it infects your thought processes and design.

The problem is this. Let me put it clearly:

If you are maintaining bad code, it will take you several tries to come up with a good architecture to replace it. You will make better progress having someone entirely outside do the architecture themselves.

OTOH, if employers are going to use credit scores to decide whether to hire you, then technical debt may be an even better metaphor if you factor that in ;-)

This is true. However....

The basic premise that you are operating with mathematical functions, which allow you to reason equationally can be done in any language.

Of course when you move from C to Perl you pick up a lot of power in what you can do functionally, and when you move from Perl to Common Lisp you pick up even more, and when you move to Scala or Haskell, you pick up even more from what I have seen.

But just as you can do object-oriented programming in C (a language really not designed for it), you can do functional programming in a lot of languages not really designed for it too.

It's a good paper, but what it hints at (but doesn't really come out and say) is that in separating concerns, functional programming actually eliminates concerns from the programmer. This isn't really just a question of the language -- you can do FP in any language.

But by thinking about programming differently, we can eliminate concerns entirely. This is what garbage collection does, and it is what FP does.

Well, with LedgerSMB (http://www.ledgersmb.org), we forked from an absolutely horrid codebase. The author has been described by Matt Trout as "The guy Matt's Scripting Archive would have fired for bad coding." I mean the codebase was a total mess. Total, total, total mess.

After 6 years of refactoring we now have a framework in place to start on the financial logic. It shouldn't take us more than 6 years to get the rest rewritten.

One of the hidden costs of bad code is that it is contagious. After staring at bad code, it is very hard to write very good code. So it takes several revisions to go from bad code to good code, to get the patterns right, etc.

Then why not just send a dog to Mars?

PostgreSQL doesn't give you an unsigned int option but if they did I wouldn't use it.

Having a negative pkey space is actually useful. In LSMB we reserve all negative id's for test cases, which are guaranteed to roll back. This has a number of advantages including the ability to run a full test run on a production system without any possibility of leaving traces in the db.

It might be politically easier to justify the program if we do....

Maybe, but the problem is that the larger a company is, the harder time they have recognizing talent, so it seems like a wash to me.

There is a reason why successful startups tend to be friends who closely know eachother and recognize the talent in eachother. Recognizing talent takes time and knowledge and it isn't something you can foist onto an HR department or recruiter.

> - Development no longer relies on developers' internal mental models of the code. Developers now code against a model which is incarnate in the test suite -- itself a deliverable, documentable artifact.

And yet I have run into too many people who valued using the test suites for documentation.

IMO test suites should test that the software implements the documentation. Nothing more and nothing less.

First, I sympathize with your reaction against building in functionality that is not required. This typically causes a lot of problems. However, for a library, that is less of an issue because you aren't maintaining it. It sounds to me like the guy used what was essentially a library he had previously developed to do this and that's a step towards having the flexibility in the right place.

> Why would your way have been different? If you are using the database to store logic in, it's still logic and still needs the same level of testing as it does in code. And you don't get existing tools like VCS, release systems, staging environments to help you with that.

My largest open source project does a lot with database stored procedures. We use all the tools you mention above, and we have written some of our own tooling to make that easier. So I don't think there is any reason why those tools don't work. So you have to spend a little time on tooling? That gets paid off many times over.

> I know we're just comparing anecdotes, but everywhere I've worked the business effectiveness has been directly proportional to the extent to which they actually followed the agile principles.

There are many things that agile gets right. As a reaction against the waterfall engineering model, the emphasis on integrating design into coding is a welcome advancement. There are many other things as well.

But agile development, because of short release cycles, tends to de-emphasize design and code contracts because it comes from the assumption of changing requirements, and here it gets a lot of things wrong. You can't do agile development if you don't have a stable platform to develop on because otherwise the ground is always being pulled out from under your feet. That platform needs to be well designed, and I am not sure you can do that iteratively without a fair bit of up-front thought. This doesn't mean a waterfall (except in the area of UX). Rather it means getting the right amount of design done at each level and having the right person do it.

Most of my work at the moment is done for a client which had exactly this problem, and it nearly destroyed their business. I came in about two years into the cleanup and things were still a mess. With a lot of work all around (and some pushing by me to focus on code contracts more), things have continued to steadily improve.

But the problem you mention is real and it can sink businesses.

It's not just that. The difficulties in sending a human to Mars and safely returning him/her are way beyond anything we have ever tried. It wouldn't be that bad to send a human to, say, Phobos, but Mars poses some extra problems, not the least of which is how to land.

An atmosphere too thick for retro rockets and too thin for parachutes is a major impediment.

So until I start seeing progress on those issues, I will see this just as sci-fi.

I would also bet that the craftsman will show less overt progress as he works. He will appear to be moving slower, but will in fact complete the three to requirements faster. And in the initial phase, in particular, the craftsman may take a lot more time. The speed will be shown not over the initial design, but over the whole production cycle.

This is also why I don't think moving faster is almost always better. There's a certain point at which moving faster slows you down.

A better way of saying it might be "optimize your progress over the next 10 years, not over the next week."

I think there is a false choice usually presented between agile, move fast and break things, vs old waterfall approach. I don't think waterfall is the right alternative. The waterfall approach is really difficult to get right because to some extent it insulates design from coding. The integration of these two is something that agile gets right.

But what agile gets wrong is in de-emphasizing design too much. Design is important, and it is important regarding long-term progress. And if you don't design, you will pay for it a hundred times over. But the best design is where technology is designed bottom-up and UX is designed top-down. Done right, this integrates design into coding but it also emphasizes design and code contracts.

I agree but the concentration that comes with slowing down thoughts is also a very valuable skill. I suggest learning to write with a quill pen, or at least a dip fountain pen.

Coincidentally many of the better coders I have known have valued dip fountain pens.....

I am not sure that ship it late necessarily becomes a part of slow coding. The point is to code deliberately and with quality. Once you have a production codebase, if you do things right, there's no reason you can't ship on a fixed schedule. You might ship less initially than you expected, but in the long run, you will ship more than you expect, because the delay of design pays back later.

Regarding rate limiting, must really suck to live in Qatar and be behind a proxy server with a single IP address with the whole rest of the country...

No matter how you do it, taking notes on paper is very good.

One advantage, I think, is that we can type faster than we can write with pen and paper. Thus paper is a more deliberate medium than a keyboard is.

I agree with you to a point. I am a touch typist. There's something to be said about a lack of friction.

However, at the same time, there is also something to be said for friction and learning to work with friction. It is about time and the amount of deliberation the concentration of holding a thought in your mind for longer.

I am a touch typist and I appreciate that I am. However, I also find that spending some time periodically with a quill pen, writing thoughts down with that, is extremely valuable for the opposite reason.

One of the core challenges is how to slow down thought. This is something which has many, many benefits, and touch typing at the speed of thought would not be conducive to quality code.

One of the things I have had to learn is how to code slowly in a fast code organization. This means understanding where I am going and doing lots of small iterations to get there.

One of the reasons for small iterations of a working system is that it gives you a limited QA footprint. This is far underrated. But it means that over the course of many iterations, my code ends up coming out, well designed and elegant, and playing well with others.

Short iterations and fast releases of a production web site, for example, are not the enemies of slow coding. In fact they have a role to play as well. What is the enemy is trying to do everything at once within a fast release cycle.

I find that to a point (and let me emphasize this is to a point), every hour I spend on design saves me 10 hours of coding.

I also find I am a code gardener and a slow programmer but I get told I ship working code faster than most of the fast programmers out there.