
Luna: Visual and textual functional programming language - zby
http://www.luna-lang.org/
======
dang
Landing pages with signup forms aren't a great fit for Hacker News. It would
be better to post and discuss this once it's out.

~~~
zby
Sorry - I was curious what the HN bunch would tell about this. But you are
right - there is not enough information right now for any deep comments. The
examples so far are too simple.

------
CyberDildonics
It seems a bit strange to me that they would take the directed acyclical graph
interface of a compositing program (like Nuke as one example) and call it a
general purpose language, then show it off by doing compositing image
operations. If you want to work with images like this, download Nuke, if you
want to work with images, geometry and more like this, download Houdini.

There is a lot to be gained from structures like this in general programming,
but what they are showing has already been done for 20 years. The real test is
when you get in to branching, loops, and all sorts of things that aren't
straight data flow. Whether people realize it or not, pure data flow is
basically a solved problem, even from an interface view, it just isn't evenly
distributed.

~~~
wdanilo
Hello! I'm one of the guys behind Luna. You might be right, that the first
example on the website should not be connected to image processing, because it
could make the reader biased. In fact any example could affect the reader in
the same way. You can observe "branching" and some kind of "folds" in the
second example on the website. There are no loops in Luna, because it's
purelly functional language and everything can be done simply by recurrence or
by using "fold" or "map" operations. As a side note - there is a startup using
Luna as a core engine for image processing (flowbox.io) and a lot of movie
studios around the world are testing it right now because it gives much
greater power than Nuke's graphical representation. On the other hand there is
a topic on sidefx forum (makers of Houdini) about incorporating Luna to
Houdini to increase its power. Luna is above these domain specific use cases.

I think the most important thing here is that although VPL was introduced many
years ago (like textual programming), Luna is the first language that allows
switching between code and graphs on demand.

~~~
CyberDildonics
I think what you guys are doing is very interesting and I think in some ways
you are on the right track, however:

> You can observe "branching" and some kind of "folds" in the second example
> on the website.

That is a static branch hardcoded from the GUI. That isn't branching because
nothing is switching the boolean, which comes back to question of how you
would switch the boolean in this structure.

> a lot of movie studios around the world are testing it right now because it
> gives much greater power than Nuke's graphical representation

This is a bold claim that I'm very skeptical of and my initial reaction is
that this seems like a bit of a bluff. What studios are using it and what
exactly are the benefits over Nuke that you're talking about?

> Luna is the first language that allows switching between code and graphs on
> demand.

This is far from true of course. Compositing program's file formats are
essentially data flow scripting languages and Houdini's shading language
allows you to look at the shader text while modifying it through a node graph.

It really does seem cool but your claims are pretty bold. If you can show off
a general purpose program written like this, something that would typically be
done imperatively, then that would be much more of step forward from what has
been done before.

~~~
wdanilo
Thank you for your reply!

> That is a static branch hardcoded from the GUI. That isn't branching because
> nothing is switching the boolean, which comes back to question of how you
> would switch the boolean in this structure.

Of course. Such static, GUI hardcoded switching is a very common one when
testing / prototyping solutions, but of course it gets finally parametrized by
some runtime variable. The dynamic branching looks very similar, with another
input connected to the switch. This additional input has a Boolean type and
triggers the switch between using the first and the second input.

> This is a bold claim that I'm very skeptical of and my initial reaction is
> that this seems like a bit of a bluff. What studios are using it and what
> exactly are the benefits over Nuke that you're talking about?

I cannot provide any further information regarding Flowbox, but you can freely
ask them about it. We can freely discuss Luna though. Why its superior over
the graphs representations shipped with Nuke or Houdini? In contrast to those
representations Luna is a _real_ programming language, that allows you to
process any kind of data, not only images or 3D geometry. It can access all
system level properties (like disk or network operations). You can also define
your own data structures. Moreover Luna compiles to native code, so there is
no runtime overhead that comes from graph interpretation. I think that those
are just few of very important differences here.

> This is far from true of course. Compositing program's file formats are
> essentially data flow scripting languages and Houdini's shading language
> allows you to look at the shader text while modifying it through a node
> graph.

I was using Houdini for years and I know it really well. Houdini allows for
conversion between VOPs and VEX (graphs and imperative code) but not vice
versa. You'll not be able to modify text and get graphical representation
again.

------
king_magic
Well, I've been programming for 20+ years across dozens of languages, and I
can't understand what a single one of those diagrams is actually doing.

But I can grok the "textual code" example almost instantly, so fast that the
difference in effort is almost laughable. I find the mental overhead in
understanding the diagrams vs. "textual code" (that phrase makes me mentally
chuckle each time I read it) is orders of magnitude higher. Sorry, but I
simply don't buy what they're selling ( _and I say this as someone who lives
and dies by the whiteboard_ ).

About the only thing out of this that looks actually useful for real-world
software engineering is the visual profiling piece. If I were them, I'd
probably throw out everything else they are working on and focus on that
single piece alone, because that could be pretty useful.

~~~
xg15
As you said, you have been programming for 20 years, therefore you likely have
built a lot of experience and innate skills for dealing with text and
considerably less for dealing with diagrams.

I don't think this tells anything whether someone with the same amount of
experience in diagrams might be able to make more of it than you with the
equivalent text representation.

~~~
jules
For what it's worth, mathematicians work on paper so they aren't constrained
by anything, but they still use textual nested syntax instead of visual
dataflow graphs.

~~~
logicrook
That's a completely false analogy. We rely on text to represent what's best
written as text. When you want to speak of a specific automaton or graph,
you'll give a figure, unless the mathematical structure is really big
(infinite maybe) and thus best described intentionally.

Frege's notation is another example, although it was a bit idiosyncratic, but
its legacy very much lives in proof theory.

And then there are string diagrams, proof nets, ...

Do you know anybody doing maths who could say "well I've never felt the need
to use a figure in my life"?

~~~
paulhodge
> We rely on text to represent what's best written as text.

Yes exactly. And if you look at the common methods for how knowledge is
represented, in mathematics or any field really, it's very roughly around 80%
knowledge as text and 20% graphs/diagrams/figures.

An image can be extremely helpful and illustrative if appropriate. But almost
nowhere do you see people communicate primarily with images.

Text is king. I think if the programming environment doesn't embrace text as
the primary input method, then it's not really good as a general-purpose
environment; it'll only be successful in niches.

~~~
xg15
> _But almost nowhere do you see people communicate primarily with images._

I'm not quite sure how humans _could_ communicate primarily with images, at
least until neural interfaces are in widespread use... I would argue that,
yes, we communicate primarily with text, because we have the innate skill -
speech - to do so efficiently and we have no equivalent skill for images. This
doesn't tell anything about how knowledge would be best expressed in theory.

> _And if you look at the common methods for how knowledge is represented, in
> [...] any field, it 's very roughly around 80% knowledge as text and 20%
> graphs/diagrams/figures._

Sources, please. But even assuming this is true, this would leave 20% which
are better represented visually. And I believe it's a worthwhile goal to
integrate visualisations for those 20%. An integration like this seems
possible with Luna's approach of offering both, a text and a visual
representation.

> _Text is king. I think if the programming environment doesn 't embrace text
> as the primary input method, then it's not really good as a general-purpose
> environment_

I agree with you that it's a good idea to have _some_ textual representation -
If for nothing else so you can use existing tools. But that seems to be
exactly what Luna is going for, if I understand the site correctly.

I don't see why text has to be the _primary_ input method.

~~~
paulhodge
> But that seems to be exactly what Luna is going for, if I understand the
> site correctly.

Yeah, I'm withholding judgement on Luna specifically, until we can see it in
action. Their model could be a good one, it all depends on whether they treat
the text representation as a first class citizen or not.

~~~
wdanilo
Paul we do treat BOTH text and visual graphs as first class citizens. Luna's
compiler is all about AST modification. In fact Luna provides few different
AST models, the most important are:

1) Standard AST - one that is a common and extendible syntax representation.
Both the textual code as well as visual graphs are able to translate to and
from this AST model. To be most precise - both representations are just some
kind plug-ins (with some funny type-level-safety built-in) over this AST
representation, so they are both first class citizens and they are completely
equal to each other.

2) Core AST - a desugared, type-checked, minimal lambda calculus language,
that is used to perform all sort of optimizations before next steps towards
generating the target code (assembly / js).

We treat the graphical interface exactly the same way, never favoriting any
representation over the other. If you would like to develop another one, like
natural language input, you have just to provide methods for translating it to
and from AST and our infrastructure delivers everything you need to translate
it to and from visual or textual one.

I hope this spots a light over the internal design of Luna :)

------
elviejo
This looks too good to be true.

I always thought there should be a graphical language to do the high level
architecture.. And a text representation to do the details. But it should be
the SAME language.

Not like CASE tools where the uml diagrams are different than the code.

'The good thing about bubbles and arrows, as opposed to programs, is that they
never crash.' — Bertrand Meyer

Now in visual languages.. The bubbles do crash.

I'd love to learn more.

~~~
wdanilo
Hello! I'm one of the foudners of New Byte Order (the company behind Luna). We
think the same - the visual representation is natural for high level
abstraction model, while textual code fits really well when dealing with low-
level stuff. And Luna is one language with both of these representations. If
you want to learn more and have any specific questions, I would love to answer
them.

~~~
elcano
"Luna is the world’s first programming language featuring two exchangeable
representations: textual and visual, which you can freely switch at any time."

I have not made an extensive research, but this doesn't sound right to me. The
SAS Enterprise Guide version of the SAS language came first (and probably
others). In one panel you have the visual version while the other has the
traditional SAS text language. There are other environments live Learntomod
where one panel shows Javascript while the other has a visual, Scratch-like
representation of the same code. Just like Luna, they consist of an IDE
coupled with two languages each: the visual and the textual. Why is that they
don't make that argument false?

~~~
wdanilo
I would love to be proven that I'm wrong, but I don't think they allow for
bidirectional, lossless conversion, namely graph -> text and text -> graph? Do
they? If so, then you are right, the statement is wrong and we will change it
on our website.

------
cs702
Great idea. _Looks_ promising.

Questions:

* The website states that a compiler and an interpreter will be open-sourced, but this language probably requires some kind of "graph IDE" as well. Will that tool be open-sourced too?

* Are the authors trying to make money from this? How?

* Who is behind this?

~~~
raphar
For what the site says, there must be lot of infrastructure needed to run and
profile a program.

Will that distributed runtime be open sourced as well?

~~~
wdanilo
The only infrastructure needed for running Luna on your hardware is the
compiler. If you want interactive mode with interactive visual development you
will need also Luna interactive interpreter and visual environment. Both
compiler as well as interpreter are going to be Open Source, while the visual
IDE will be free (and we consider releasing it as Open Source too). There is
nothing more that you need here :)

------
Jupe
Without an equally elegant/powerful test framework, this is just child's play.

If the concept allows, as some have mentioned, to let non-programmers make
changes, then a fully-integrated test framework is absolutely required.

Other questions come to mind:

\- How are global 'variables' (config, settings, etc.) represented? As more
lines, or traditional named variables?

\- Although the Category Oriented Programming seems compelling, I'm not seeing
how this visual world will address concurrency in any meaningful way (maybe
I'm missing something) - although the profiler is nice.

\- Visual programming is also extremely messy when dealing with exceptions:
not sure how that is addressed here - again more lines?

Before long you end up with spaghetti... but perhaps they've solved that via
views / layers or something.

I highly applaud this effort, but it needs to address the complexities of
software development /on the development side/... or it won't get much use by
professional developers.

~~~
wdanilo
Hello! I belong to the team behind Luna :)

When we are talking about testing framework, we should ask ourselves - what
kind of tests are we talking about. In languges such as Python, Ruby or
JavaScript (I don't consider JS to be a language, but this is just a side
note) everything should be covered with all kind of tests - unit tests,
behaviors testing etc. There are languages like C++ or Java, where some
testing is not required, because it is done by the compiler - and I'm talking
right now about just type system. Luna incorporates much better type system
than C++ or Java. In fact Luna will throw compilation error if you want to
access head element of an array if it cannot prove this element would be
always there (Luna incorporates a complex type inferencer and dependent type
system). You can tweak the compiler and allow for more liberal behavior if you
like thought.

To sum this up - I'm not talking that test framework is not necessary. It is,
it is curtial and need to be polished to allow a language to be widely used. I
wanted to clarify, that a great type syste, like the one in Luna, prevents
from making errors so much, that you can write much fewer tests and be sure
everything works as it should.

Answering other questions: \- there are no global variables in the traditional
meaning (in fact there are no global variables in purelly functional languages
at all). If you want to have something like a global variable you use monads!
"Oh no, monads, I'm running away!" \- this is a completely understandable
reaction for vast majority of programmers. Because of that Luna incorporates
an automatic monad management system. What it does is simple and allows using
monads without thinking about it. You just put a "State.run" node and you pass
all variables to it, that shoudl be accessible from every palce of its sub
netwrok. Then you can put "get" node, that will access these "locally global"
variables for you. It's just like a State monad in Haskell (this is
explanation for Haskellers), but with visual, easy interface.

And one more thing. Global variables are pure evil. I would call them bilion
dollar mistake, such as null pointer references. Monadic states are pure and
nice solution for it. (btw. Luna of course doesnt have something like `null`).

\- The lines you see represent all data dependencies in a graph. Anything not
connected with lines (or monadic lines - like two actions that print something
to the screen) can be run side by side. Our compiler understands that and can
shedule the nodes to be executed in parallel.

\- Exceptions are represented on the bottom of our page. Exceptions in the
meaning known from imperative programming are messy, ugly and doesnt fit in
the visual environment well. In fact they are hard to deal by developers too -
have you ever tracked an exception stack of poorly written code? This is pure
nightmare. Luna introduces dataflow exceptions - please look at our website
and I will answer any qeuestions that could appear after reading it :)

\- We have created a really big graphs with Luna without ending with spagetti
- each node is build outo of graph of other nodes. If you've got to many nodes
on the stage is justl ike writing a collosal 1k lines long function in textual
code. You can then select some nodes and collapse them into one (just like
refactoring functions out of such code block).

We are aware of all these things and we do what we can to create a REALLY
useful visual programming expirence. We've started this project because nobody
ever did it and all the tools currently available (excluding some domain
specific ones like Houdini, Labview etc) are just toys and cannot be
considered programming tools.

~~~
yorwba
> Exceptions are represented on the bottom of our page.

Are you referring to this?

    
    
      fileAge = open 'age.txt' . to Int
      age     = age.catch e:
           print 'An error occured: ' + e
           read 'Provide your age: ' . to Int

First, I think you probably meant to write _fileAge.catch_ there. Second, what
would that look like as a graph? Having a visual programming language is not
really interesting if you have to go back to text for exception handling.
Maybe you should show a side-by-side comparison of the other examples as well.

~~~
wdanilo
Oh, thank you for spotting the error. Of course, there should be
`fileAge.catch` there. I'll fix that in a moment. I will prepare a visual
example of exceptions and put it in the website later today. For now think of
it like that: running an operation results in a data and this data is
transmitted over connection between nodes. If you read data from file it can
be "broken" in different ways, for example it did not exist on disk. If you
convert it to integer - it still could be broken or become broken (for example
we were not able to convert this text to integer). So far you've got such
graph of nodes: open --> to Int --> ... and the resulting edge could be broken
if one of the exceptions occured. If you put there `catch` node you can either
double click it and define its subgraph, that has input of the `e` variable or
simply connect other input that would be used if the error occurs. Thats all -
in contrast to imperative languages exceptions in Luna do NOT propagate over
blocks of code - they propagate over the data dependencies. In fact the
exceptions in Luna are just algebraic data structures that could have 2 values
- Just ok or Error e - something like Either in Haskell (side note for
Haskellers). Does it make sense to you? :)

------
soroushjp
There are a number of incredibly promising features here. Visualizing code
graphs could be incredibly helpful in many contexts, especially in
understanding high-level control flows by folding up subroutines as needed.
Visual profiling is a dream come true. The functional language features make
it seem like joy to use.

With that said, this is still just a concept until a language actually brings
all these features together. Will believe it when I see it.

~~~
tom_mellior
> There are a number of incredibly promising features here. Visualizing code
> graphs could be incredibly helpful

Excited overuse of the word "incredibly", just like the author of the featured
article.

> make it seem like joy to use.

Missing article, just like the author of the featured article. Interesting ;-)
(OK, this one happens to a lot of people who come from a Russian background,
for example.) If you are involved with this, I'm sure people would be
interested to know! Maybe you could answer some questions...

~~~
wdanilo
As far as I know neither the author of the post on hackernews neither
"soroushjp" are not involved in the project, but I am. I've been answering
some questions here, so If you have any specific ones, I would like to help :)

------
gsanghera
This is brilliant. I work in finance (trading) - and have been trying to learn
Clojure and Rust on my own over the last year (no CS background). For people
like me - this is phenomenal - if it works. The ability to think logically
doesn't translate directly into the ability to program, or vice versa and a
person must spend a considerable amount of time learning the tools of
programming. This tool could fill that gap for non-CS engineers. Couple of
questions (as you mentioned functional language) a) In the opinion of the
makers - what is this language NOT good for? b) How good are the mathematical
libraries going to be? As a benchmark I'd take Mathematica (not for speed -
but width and depth of mathematical functions). If this question is redundant
due to the ability to call Haskell - feel free to say so. c) How far does the
automatic parallelism go? Is it truly distributed over any scale? Thanks again

~~~
wdanilo
Hello! First of all - thank you for a nice greeting! :)

Answering your questions:

a) This language is NOT good for any _really_ low-level stuff like programming
realtime hardware systems or low-level processors programming. You should then
use pure C or assembler instead. If you are programming other low-level stuff,
you could feel comfortable using Luna's textual representation. The visual one
gives incredible boost when designing the high-level architecture.

b) At the current stage Luna ships with a very limited standard library, but
we will work hard in order to incorporate as many usefull libraries as
possible. As you have spotted, Luna is able to directly call Haskell and we
also provide foreign C interface, so binding any Haskell library is almost out
of the box right now.

c) We are strongly working on this topic. Currently our graphs are able to run
in parallel all operations that are not data-dependent in any way. However it
does NOT scale well if you're thinking about distributed systems, because it's
not easy to determine where to partition your program, so sending data over
network will not kill the performance. We will though be working toward
addressing it in longer perspective.

Did I answer your question? :)

~~~
gsanghera
Thanks for replying! (a) and (b) make sense. (b) will depend on adoption as
well, so your answer is fully understandable.

Just a follow-up question on (c) - if you will allow me please. Are the data
structures immutable like Clojure and Erlang, so that they could be
distributed eventually, once the optimizations are done (and you are able to
package the non-functional code like C into their own partitions for the
distribution)? Reason I ask is that the page mentions Category Oriented
Programming - which I am not at all familiar with. Regards

~~~
wdanilo
I would really love to answer any questions regarding Luna, so feel free to
ask them as many as you need!

c) Yes, Luna supports immutable data structures in the form of composable
algebraic data types. Composability means in this context that you can compose
the sum and product types directly using Luna's built-in combinators, so you
can for example build data types that share some constructor definitions (this
is just a generalization of algebraic data types in general. As a side note,
the first Luna release lacks some mechanisms to fully handle this abstraction,
but this is understandable as this is an alpha release). Luna data types allow
for efficient binary serialization, if you mean it by asking about "own
partitions for the distribution". The Category Oriented Programming paradigm,
on the other hand, is developed by us. It is widely described in the Luna user
manual, that for now will be available for alpha testers only, but we will
work towards releasing it to the public as fast as possible.

Did I answer your questions?

~~~
gsanghera
Thanks a lot, yes. All the best and look forward to this!

------
tdaltonc
I love the idea of graphical programing, but whenever I use one (nipype,
labview, or puredata), I end up with an unreadable mess.

------
riotdash
There have been tons of "graphical programming" languages and IDEs trying to
pull it off for the last 15 years and pretty much all them have been total
shit.

This doesn't look any different. Someone already said it, but the fundamental
problem with these are that it's extremely hard to build big and complex
software without making it look like a huge mess. In a normal programming you
can always call any part of code and make any number of instances and put them
almost anywhere you want with very simple, logical and linear code which is
executed in a normal standard prodecure (= line after another). With this
almost everytime you make some changes you'd have to rethink the whole program
flow and move all the components/blocks to different places and there are
millions of lines going all around the place.

1/10, will fail.

~~~
analog31
_...the fundamental problem with these are that it 's extremely hard to build
big and complex software without making it look like a huge mess..._

In my view, text based languages could be this way too, except that the habits
of making code at least marginally readable (e.g., indentation) and modular
(subroutines, local variables, etc.) are drilled into everybody who learns
programming, or learned through "the apprenticeship of observation."

Also, those habits require only a bare minimum of physical effort, such as
reaching for the tab button or enclosing some code in a function definition.

I think a problem with graphical programming is the sheer physical effort that
it requires, encouraging sloppy work. Maintaining readable code as it grows in
complexity is a major chore, involving physical and not just mental, effort.
In practice it doesn't happen.

------
Rafbill
I have a few questions:

a) When is the first alpha release planned ?

b) Did you go the Coq/Agda route with dependent types (only total functions
can be defined), the Haskell (once the DependentTypes extension lands) route
(partial/looping functions can be used in types and may need to be evaluated
at compile time, the compiler can loop, there is no associated coherent
logic), or the Idris route (only total functions can be used dependently) ?

c) How extensible is the Standard AST ? (e.g. would it be possible to define
something like the Coq tactic interface from within the language, or through a
compiler plugin ?)

~~~
wdanilo
Hello! :)

a) We will release it to the first group of alpha testers in couple of weeks
from now. This will be couple of weeks, not couple of months.

b) We're going the Haskell route - we allow for non-total functions, and we
will extend Luna's type-checker to understand as much as possible. In fact we
treat type level very similar to the value-level, very similar to the type of
types - level, etc, so there could be functions evaluated at compile-time and
they could cause infinite loop. Please note that although we design Luna in
order to be fully dependent type language, the compiler just hit the alpha
stage and there is much more work to be done in this field.

c) The standard AST is really __very __extensible. In fact every term that
belongs to AST is just different data type. We 've written a library in
Haskell that allows handling open sum types using all the type-level machinery
to help it be bullet-proof. Luna will incorporate a library that allows you to
change and manipulate the AST from within a language - something like
TemplateHaskell, but without the stage restriction known from GHC. This is not
available at the moment though. I doubt though you will ever need to extend
the AST using a plugin, because it allows to express _really_ wide logic,
however I'm very interesting what idea do you have in your mind here! :)

------
mavdi
Looks cool but it doesn't look like it's going to be fully open sourced. I
can't spend a minute more of my time on closed platforms, just not worth the
lock in and the eventual pull out.

~~~
wdanilo
The Language, its compiler and its whole ecosystem will be released as Open
Source project. The only thing that we are still considering if releasing or
not under Open Source license is the visual editor.

------
misiti3780
for a minute i thought asana open sourced their internal web framework

[https://asana.com/luna](https://asana.com/luna)

------
Arcsech
Typo: "printing the first _hundread_ to the screen"

Anyway, looks interesting. I'll be keeping an eye on it, even if the whole
visual part turns out to be a steaming pile, the text-based language looks
quite promising.

------
carapace
You should identify yourselves. This seems like it should be very exciting,
but I'm turned off by the "high hat" and anonymous presentation.

~~~
wdanilo
Hi! I'm one of the founders of New Byte Order (the company behind Luna). Do
you mean that our website lacks information about who we are? Right, we will
ad it there! :) In the meantime you can read some of the comments below, where
I describe in details who I am and provide link to my linkedin account. Still
I would like to apologize for the inconvenience caused by lack of these
information at the website! :)

~~~
carapace
Yes, exactly. Without knowing anything about the people involved I am (was)
reluctant to invest further time and attention (I'm studying Category Theory
right now with an aim to implement programming tools, so you can imagine I'm
very interested!)

It's really great that you're addressing this. Thank you! ;-)

------
wantreprenr007
It looks strongly influenced by Python, probably to ease novice users into it.

Edit: Not to be confused with another Luna Language:
[https://github.com/luna/luna](https://github.com/luna/luna)

~~~
eklavya
I don't think so. It looks like haskell.

~~~
rch
Looks like elements of both, with some Erlang concepts as well.

~~~
wdanilo
I can very precisely answer the question as one of Luna designers. Luna's
textual syntax is strongly influenced by Python and Ruby, because we think
that it is one of the most widely understandable and easy to use syntax out
there at the moment - just like wantreprenr007 said.

The concepts in Luna were influenced mainly by Haskell, Idris, Erlang and
other functional languages.

------
aw3c2
That looks amazing but the "functional" bit is offputting me as I am a stupid
user and never got functional programming. Something like this for dumb
scripting would be a godsend.

~~~
Shoop
How did you try to learn functional programming? What was the most difficult
to grasp?

~~~
aw3c2
To be honest I did not. I am happy with the procedural/OO code I write in
Python. But whenever I even see functional code, I can't even read it.

~~~
wantreprenr007
Maybe there is a lack of available video courses teaching functional style, it
might not be as hard as it seems (wan't for me, but a sample size of 1 is
anecdotal). Give it another try perhaps?

~~~
such_a_casual
Honestly, I nor anyone else has any idea what she or he means by functional
since they didn't provide any sort of example, and it's not even clear that
the user would even know functional programming if they saw it. They
referenced python, so should we assume they don't understand what map does?
Map is just a function which is properly documented and easy to find help on.
Is the user saying that they aren't able to look up the definition for a
function they don't understand? Are they saying they refuse to look up
definitions for functions they don't understand? How on earth do they get
anything done if they refuse/can't look up function definitions?

What I'm trying to say is that it's very likely the user doesn't even know
what "functional" means. They just hear some keyword they don't understand and
dismiss anything that follows. Because when you think about it, it doesn't
really make any sense that a programmer could be a programmer if they couldn't
look up things they don't understand.

