Haskell probably has the steepest learning curve of all programming languages and perhaps the most rewarding one. Haskell has a relatively tiny grammar since everything is functions and monads. So, its grammar is relatively easy to learn. But the concepts and abstract algebra behind Haskell's infrastructure are somewhat hard to understand and new to most programmers.
The A-Z of Programming Languages: Haskell Simon Peyton-Jones tells us why he is most proud of Haskell's purity, type system and monads. http://www.computerworld.com.au/article/261007/a-z_programming_languages_haskell/ Regarding massive parallelism, Haskell is naturally parallelizable because it is 100% pure. That is, Haskell doesn't have mutating state. You never modify memory locations. You only create new constants and let the garbage collector remove them when they are out of scope. So, you will never have multiple-concurrency issues and memory collisions. That is perfect for massively parallel and concurrent software like AI. The results of functions are always stored in new memory locations, aka pointers of constants. That avoids memory collisions. Parallel and Concurrent Programming in Haskell By Simon Marlow http://chimera.labs.oreilly.com/books/1230000000929/index.html Regarding 100% purity, Haskell gives you the peace of mind necessary to focus on programming 95% of the time. Only 5% of the time you debug on compile time, not on runtime unless you make a logical error. Whereas other imperative, stateful, and dirty languages are very error-prone and you debug 95% of the time at both compile time and run time. And you are actually programming 5% of the time. Imperative, stateful, and dirty programming languages make you paranoid about bugs. Whereas Haskell gives you peace of mind because your implementation is correct at the first run. That's also due to Haskell's strong, static, and expressive type system. Haskell is designed for hard problems like AI. Stop wasting billions of dollars using the wrong software languages http://venturebeat.com/2013/10/11/stop-wasting-billions-of-dollars-using-the-wrong-software-languages/ If you have more questions, please ask me or join our facebook group on Haskell: Programming Haskell https://www.facebook.com/groups/programming.haskell/?ref=bookmarks On Thu, Aug 13, 2015 at 1:33 PM, Steve Richfield <[email protected]> wrote: > Juan Carlos, > > On Thu, Aug 13, 2015 at 1:58 AM, Juan Carlos Kuri Pinto <[email protected]> > wrote: > >> Bro, do you even Haskell? :) >> > > No. I looked at the links you provided, but don't (yet) grok the > connection to HIGHLY parallel (e.g. no program counter) FPGA programming. > The problem is that these and other descriptions are all oriented toward > touting the Haskell's abilities in other areas, which if done just right, > might also work for FPGAs. > > Note that the language I am attempting to identify/design probably would > NOT be popular or efficient when run on conventional processors, with some > possible exceptions like robotics applications. That conventional > processors are SO ill adapted to such things has stood in the way of > language development, because however you do these things they are likely > to run slooooly on conventional processors. > > It is my belief that GPUs will (eventually) be obsoleted by FPGAs, but NOT > before a suitable programming language has been found. Once languages are > available in which to better describe processes so a compiler can see them > from a data chaining point of view, there are orders of magnitude in > performance just waiting to be harvested from the silicon foundries. > Haskell's "purity" might do this, but I am resistant to learning a new > language just to evaluate whether it could work for an application - when > the language was designed to do other things. > > Anyway, perhaps you could provide a few paragraphs explaining how Haskell > has what it takes to bridge this gap? It would sure be nice if I could > avoid re-inventing the wheel. > > It may also be possible that Haskell has 90% of what it takes, which would > greatly simplify my task. > > If Haskell has what it takes to program FPGAs, then I am the guy to > convince, because I have the ears of others who want to solve this problem, > so they can propel FPGAs to replace other forms of processors, and > hopefully make millions/billions in the process. > > Steve > ============== > >> >> >> https://www.facebook.com/notes/juan-carlos-kuri-pinto/how-to-program-stateful-intertwined-ai-networks-graphs-in-stateless-modular-prog/10151687175972712 >> >> >> http://www.computerworld.com.au/article/261007/a-z_programming_languages_haskell/ >> >> On Thu, Aug 13, 2015 at 2:01 AM, Steve Richfield < >> [email protected]> wrote: >> >>> Mike, >>> >>> On Mon, Aug 3, 2015 at 12:34 PM, Mike Archbold <[email protected]> >>> wrote: >>> >>>> This is a great classic book on programming languages, the Programming >>>> Language Landscape. >>>> >>>> >>>> http://www.amazon.com/Programming-Language-Landscape-Semantics-Implementation/dp/0023758716/ref=sr_1_1?ie=UTF8&qid=1438630302&sr=8-1&keywords=programming+language+landscape >>>> >>>> My favorite chapter is "The Swamp of Complexity." In a nutshell -- >>>> too many languages with too much crap in them! >>> >>> >>> The author completely missed the REAL problem with language complexity - >>> that when it becomes necessary to radically alter the execution, e.g. >>> vectorize the program to run on a supercomputer, then the size of the >>> compiler grows as the SQUARE of the size of the language (actually, >>> n*(n-1)/2, the number of interactions of components). Where more than two >>> elements must be considered together, there is often a cubic component that >>> can swamp even the quadratic component. If you have twice the language >>> complexity, it takes four (or eight) times as much compiler code to compile >>> it to a radically different architecture than that of the language. THAT is >>> why so many supercomputers start out with APL and FORTRAN compilers, and >>> why C compilers only vectorize simple loops that utilize a small subset of >>> the language. >>> >>> Of course, having lots of cute statements that all translate to >>> arithmetic and IF statements don't affect the compiler complexity much at >>> all. >>> >>> Unfortunately, this book never considered truly parallel >>> implementations, where everything runs at once - but rather they considered >>> "parallel" programming to be simple multi-threaded programing. >>> >>> Indeed, on page 6 they list "the" dozen classes of computer languages, >>> none of which come close to what I am trying to create. >>> >>> Still - I got my dollar's worth. >>> >>> Thanks. >>> Steve >>> ================ >>> >>>> It looks like you can >>>> get a copy for less than a buck.... >>>> Mike A >>>> >>>> >>>> On 8/3/15, Steve Richfield <[email protected]> wrote: >>>> > Hi all, >>>> > >>>> > I am working on a high-level FPGA programming language, that should >>>> also >>>> > serve better than existing languages as an AGI implementation >>>> language and >>>> > a robotics programming language. This is designed to be executed on >>>> FPGAs >>>> > rather than CPUs, though a PC version is contemplated. >>>> > >>>> > Here are my early thoughts. All comments are welcome. >>>> > >>>> > Parallel Computing Language >>>> > *Design Notes by Steve Richfield *as of Aug 2, 2015 >>>> > >>>> > The goal of PCL is to provide a language to express algorithms in >>>> parallel >>>> > form for easy compilation to either parallel or sequential platforms, >>>> > rather than forcing programmers to express their algorithms in a >>>> probably >>>> > inefficient sequential form, for a (nonexistent) compiler to >>>> translate to a >>>> > parallel form. >>>> > >>>> > >>>> > The special need is to be able to translate to FPGA implementations, >>>> which >>>> > presently require efficient translation to be able to fit into >>>> existing >>>> > hardware. >>>> > >>>> > >>>> > *Existing Technology from which to Borrow* >>>> > >>>> > *APL structure:* In APL, everything is a matrix of varying >>>> dimensionality, >>>> > including zero dimensions (a simple variable). It includes numerous >>>> array >>>> > operations as operators in the language. Unfortunately, its promoters >>>> have >>>> > adopted syntax reminiscent to Sanskrit, which is enough to chase away >>>> > anyone not well versed in matrix inversions, etc. Some of the IBM-360 >>>> > architecture was first worked out in APL. >>>> > >>>> > >>>> > *Dartmouth BASIC MAT statements: *The original Dartmouth BASIC >>>> recognized >>>> > MAT at the beginning of statements to indicate that the statements >>>> > specified matrix operations, rather than operations on variables. >>>> Hence, >>>> > *MAT >>>> > C=A*B* multiplied matrix *A* by matrix *B*, and stored the result in >>>> matrix >>>> > *C*. APL-like procedure is MUCH less opaque in this syntax. >>>> > >>>> > >>>> > *COBOL PICTURE clauses:* COBOL provided an easy (though now arcane) >>>> way of >>>> > easily describing variable structure, which could be easily extended >>>> to >>>> > meet present needs. Specifying *PICTURE 9999*, which could be >>>> abbreviated >>>> > *PIC >>>> > 9(4)*, a programmer could easily state that a variable had to hold 4 >>>> > decimal digit values. In our implementation, *PICTURE 111111111111* >>>> or *PIC >>>> > 1(12)* could specify a 12-bit field, as could *PICTURE 7777* or >>>> *PICTURE >>>> > FFF*. COBOL also allowed for fixed-point notation, which is also >>>> important >>>> > in FPGA context, e.g. with *PICTURE 999V99* to represent 3 digits to >>>> the >>>> > left and two digits to the right of the implied decimal point. >>>> Provision >>>> > would have to also be made for logarithmic notation. Note that in >>>> addition >>>> > to precisely specifying “variables”, this also guides debuggers on >>>> how to >>>> > display what they find. This approach would allow for specifying >>>> pipeline >>>> > widths to be as narrow as possible for each operation. >>>> > >>>> > >>>> > *FORTRAN Arithmetic Statement Functions:* FORTRAN provides a one-line >>>> way >>>> > of specifying simple function subroutines, e.g. >>>> > *RMS(A,B)=SQRT((A**2)+(B**2))* that are usually implemented by simple >>>> > string substitution into their references, so they are executed as an >>>> > in-line subroutine in C, but without the need to specify they are >>>> in-line. >>>> > Data chaining in complex operations would be easy to specify with such >>>> > syntax. >>>> > >>>> > >>>> > *Eliminating **GOTO** statements: *Parallel processing aside, there >>>> are >>>> > plenty of good reasons to eliminate *GOTO* statements. In the >>>> process, we >>>> > should probably eliminate everything else that specifies anything >>>> > conditional beyond conditional storage of computed results. The >>>> presence of >>>> > a particular condition that necessitates particular processing should >>>> be >>>> > handled as an event, though it would be possible to fake it by >>>> translating >>>> > conditional logic into an event handler. >>>> > >>>> > >>>> > *All “procedure” will be event-driven:* Where sequence is needed, it >>>> will >>>> > be triggered step-by-step, e.g. by *WHEN* statements. Where a long >>>> sequence >>>> > is needed, each step must be triggered by completing the previous >>>> step. To >>>> > avoid programming flags and *WHEN* clauses for each step, a >>>> *PROCEDURE* >>>> > will be declared, that necessarily starts with a *WHEN* clause, after >>>> which >>>> > the compiler will assume that each step starts when the previous step >>>> has >>>> > completed. There may be any number of procedures simultaneously >>>> active at >>>> > any one time, but only one instance of any particular procedure, >>>> unless it >>>> > is declared as being *RECURSIVE* and/or *REENTRANT*. Where a procedure >>>> > requires conditional operation within it, the conditional operation >>>> will be >>>> > triggered and entered via a *WHEN* statement. Note that complex *WHEN* >>>> > statements, when implemented in hardware, only cost gates and NOT any >>>> time. >>>> > >>>> > >>>> > *Familiar Operations: *Familiar operations like SELECT ... CASE >>>> statements >>>> > will be provided, though they will “execute” in unfamiliar ways. For >>>> > example, a SELECT statement will simultaneously “execute” all CASEs >>>> for >>>> > which the stated conditions are satisfied. >>>> > >>>> > >>>> > *Syntax:* Three different syntaxes will be supported, which can be >>>> > intermixed on input. They are mathematical, familiar (similar to C), >>>> and >>>> > verbose (similar to COBOL). For example, familiar *MAT C=A*B *in the >>>> > example above would be simply *C=A*B* in mathematical form, and >>>> *Multiply >>>> > matrix A by matrix B giving matrix C* in verbose form. Error >>>> messages from >>>> > the compiler would show both the input and the equivalent verbose >>>> forms, to >>>> > show how the compiler interpreted the statements. >>>> > >>>> > >>>> > *Early implementations:* Initially this PCL will be a publication >>>> language >>>> > to specify the construction of complex programmable logic. Then, a >>>> > translator will be written in a portable language like C to translate >>>> > programs from PCL to C so that programs can be tested on personal >>>> > computers, etc. Then, translators will be written to translate to >>>> FPGAs >>>> > programming languages *Verilog* and *VHDL*, and finally, FPGAs will be >>>> > adapted to become better targets for code produced by this process, >>>> much as >>>> > IBM 360/370 mainframes were designed as prime targets for COBOL >>>> programs. >>>> > >>>> > >>>> > *Other Applications:* This language comes VERY close to also meeting >>>> the >>>> > needs for robotics applications, with many simultaneous tasks and >>>> close >>>> > coupling to I/O, so it should be expanded to include anything that >>>> might be >>>> > missing to also serve robotics. >>>> > >>>> > >>>> > *Comments:* PLEASE comment on this at any level, most especially what >>>> > other languages might serve this need, what features of other >>>> languages >>>> > should be incorporated, what it might be missing, what might be >>>> wrong, etc. >>>> > >>>> > >>>> > Steve >>>> > >>>> > >>>> > >>>> > ------------------------------------------- >>>> > AGI >>>> > Archives: https://www.listbox.com/member/archive/303/=now >>>> > RSS Feed: >>>> https://www.listbox.com/member/archive/rss/303/11943661-d9279dae >>>> > Modify Your Subscription: >>>> > https://www.listbox.com/member/?&; >>>> > Powered by Listbox: http://www.listbox.com >>>> > >>>> >>>> >>>> ------------------------------------------- >>>> AGI >>>> Archives: https://www.listbox.com/member/archive/303/=now >>>> RSS Feed: >>>> https://www.listbox.com/member/archive/rss/303/10443978-6f4c28ac >>>> >>>> Modify Your Subscription: https://www.listbox.com/member/?&; >>>> Powered by Listbox: http://www.listbox.com >>>> >>> >>> >>> >>> -- >>> Full employment can be had with the stoke of a pen. Simply institute a >>> six hour workday. That will easily create enough new jobs to bring back >>> full employment. >>> >>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now> >>> <https://www.listbox.com/member/archive/rss/303/23601136-e0982844> | >>> Modify <https://www.listbox.com/member/?&;> Your Subscription >>> <http://www.listbox.com> >>> >> >> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now> >> <https://www.listbox.com/member/archive/rss/303/10443978-6f4c28ac> | >> Modify <https://www.listbox.com/member/?&;> Your Subscription >> <http://www.listbox.com> >> > > > > -- > Full employment can be had with the stoke of a pen. Simply institute a six > hour workday. That will easily create enough new jobs to bring back full > employment. > > *AGI* | Archives <https://www.listbox.com/member/archive/303/=now> > <https://www.listbox.com/member/archive/rss/303/23601136-e0982844> | > Modify > <https://www.listbox.com/member/?&;> > Your Subscription <http://www.listbox.com> > ------------------------------------------- AGI Archives: https://www.listbox.com/member/archive/303/=now RSS Feed: https://www.listbox.com/member/archive/rss/303/21088071-f452e424 Modify Your Subscription: https://www.listbox.com/member/?member_id=21088071&id_secret=21088071-58d57657 Powered by Listbox: http://www.listbox.com
