

Idea for new readable code language  - pederbl
https://gist.github.com/2774396

======
lmm
Looks rather like scala:

def pay_employees = pay(employees)

def employees = Person where (_.employee)

def pay(persons: Seq[Person]) = persons map { person => person.pay }

~~~
pederbl
It seems you missed my point that defining none scoped functions pollute the
namespace. They also tend to drive the developer to be too generic for the
specific usage that is needed. Scoped functions can be customized both in name
and function to the specific need that they fulfills within their narrow
scope. The problem with scoped functions in Ruby and Javascript is that they
cannot be called before they are defined. Thus, the "thesis" of the code needs
to come last, which is opposite to what the reader wants.

~~~
lmm
Do functions behave the same as variables? Can I also use a variable before
I've defined it (the same logic of the "thesis" would seem to apply; I might
want to write pay() {return regular_salary + bonus; regular_salary = ...}). If
so, how do you handle changes to the value of a variable without hopelessly
confusing a reader of the code?

~~~
pederbl
Variables are one of the worst enemies to readability. Because of them a
reader often can't understand a line of code without looking at lots of other
lines of code to figure out what the meaning of a variable actually is. If
scoped functions are made easy there is no real need for variables. You might
have to try it before you are convinced its true. I currently use Ruby dagger
syntax and write code backwards to test the idea and it works beautifully.
Actually, I find its hard for me to go back to coding "normal" Ruby.

~~~
lmm
I actually agree with you, but I'd want to see how a basic CRUD webapp looks
written in this style; a lot of things that seem simple to do in a pure-
functional style become harder when you're working in a multicomponent system
and accessing a database.

A more theoretical criticism: this seems like it would encourage programming
in top-down style with all the disadvantages that has.

~~~
pederbl
What do you mean by top-down? I'd say it encourages bottom-up programming
since scoped functions are so light weight. Scoped functions can easily be
made global when it makes sense to share the logic.

~~~
lmm
I mean top-down as in writing high-level functions first and then writing the
lower-level functions which they call afterwards. It's already a tempting (but
inferior) way to program; with this function order it would be very easy to
write main() first and work down from there, hoisting inner functions out as
necessary.

~~~
pederbl
The main problem with top-down programming that I have understood is that it
tends to lead to non-DRY code (i.e. functions repeat the same logic and
patterns). I have noticed that my code becomes much more DRY with this new
approach because it becomes more obvious when I am repeating
functionality/patterns and it becomes easier to break such
functionality/patterns out to become generalized global functions when
appropriate. This is especially true for patterns since local variables are
often the main reason for why patterns do not tend to get separated out into
new functions.

~~~
lmm
Nope; the problem is that it gives you more opportunity to make mistakes,
because you're not using your freedom effectively. Your low-level functions
are generally far more constrained than your high-level ones (you often have
complete freedom over main()); by writing them first you make the constraints
on your high-level program design more apparent before you write it, and
reduce the risk of structuring your high-level functions wrongly.

------
willvarfar
Why the } and `end`?

Just use whitespace.

~~~
pederbl
I'm not taking a stance on whether significant whitespace is better or worse
than the alternative. I'd consider swapping the {} for

where ... end

which would make more sense and is more similar to Haskell

~~~
willvarfar
the glaring thing is the mixing of both } and end... at least pick only one
and be a bit consistent! :)

