The old motto of Burger King when I was growing up was: "Have it Your Way"
Drupal is a nice system, but note what I must do. I must visit this website, click on what I want to do and then fill out a bunch of forms to get my content up.
I have written two things recently. One on the Haskell pipeline paradigm:
And another on the ease with which top-down development is in Haskell:
But I did not savor the prospect of dealing with Drupal's limited HTML... in other words, I wanted to HAVE IT MY WAY.
Why couldn't I just open up a directory under a tree in a shell, code up my text and/or HTML and then have some sort of skulking process notice that a new directory was there and add the content to the system?
Maybe only after a darcs push was done should this happen so that you can develop and only publish when you push.
But at anyrate I envision a system that is built up from a large collection of handwritten directories without visiting websites and filling out forms, blah blah.
Well, 6 weeks ago I was low in motivation and actually bought 2 C++ books and intended to learn C++ and enter ICFP contest using it.
However, I think I am too old to learn C++... I really just didn't get the hang of it. Actually, I think I rushed things.
But anyway, Haskell is much easier on my head. I have been struggling with the image superposition exercises (6.16) for a long long time. In the process I found a bug in the Haskell tracer, hat:
And I learned how to use GHC's Debug.Trace.
I also was hit smack dab in the face with Haskell's non-determinism. I was using Debug.Trace.trace() and was confused about how output from trace and program output were interleaved:
And of course, I learned that lists in Haskell often end up reversed when you process them to generate another list... I kept staring at my final result until I realized that it was correct, only upside-down!
This was an excellent exercise and I'm glad that I did not skim over it. You've got to learn the language and how to debug the language as well and Thompson has once again shown why he has probably the best book introducing the Haskell language (at least better than Algorithms, haven't messed with my Hudak intro book).
I was wondering if you thought it was efficient to only be able to return a new array for each modification of an array.
It seems like it would be a great hindrance to efficiency in comparison with a procedural approach to a programming problem.
In figure 6.3 we see 4 figures. The starting figure is to the "West" and shows two horses superimposed.
My question is, what are the coordinates of the reference point of the two images?
All phenomena, including computational acts, are acts of creation, maintenance, or destruction. Haskell contains a number of well designed creative acts:
c1 :: Contract c1 = zcb (date "1 Jan 2001") 100 Pounds zcb :: Date -> Float -> Currency -> Contract -- Zero coupon bond
Pounds is a type constructor in the above... and zcb creates values of a certain type.
- lazy evaluation:
nothing is created until it is needed
- list comprehensions
concise ways to stating how a list is created.
Destruction is handled via automatic garbage control. There is little support for loading up and Maintaining data in-memory.
A question on #C++ caught my eye:
im waiting for user input .. using getch() .. if a user hasnt entered another key within 1 second i want to perform some action, rather than waiting for a newline or something else .. using a while doesnt work because getch() hangs until u enter a char .. any ideas?
how easy would something like this be in Haskell?
Haskell: type checking. Instead of debugging your code, trying to figure out the return types of return data, the strong type checker within the language itself does it.
Perl: type conversion. Instead of having to deal with taking a string of input and turning strings into numbers before doing math on them, Perl does all this behind the scenes for you.
Prolog: inferencing (depth-first tree search). Instead of you having to write an algorithm to explore a tree of assertions to determine the closed-world validity of a statement, you let the built-in inferencing engine do this.
PHP: web readiness. Instead of having to come up with a protocol for embedding Perl into HTML, PHP ships ready for web programming right out of the box. No need to download Perl's HTML::Mason or PLP. No need for HaXML or whatever. Load, lock and rock.
Visual Basic: .NET integration. Instead of having to write win32 libraries and then .NET libraries, Visual Basic comes ready for .NET and win32 programming from the get-go.
Emacs Lisp: IDE integration. Instead of having to use a separate tool for the edit/test part of the programming cycle, Emacs Lisp _is_ the edit/test as well a development program. Thus, you can use one tool for all aspects of development. Additionally, the base GUI for user interaction is the editor, which saves you have from having to write the basic UI widgets.
Shell: shell access. No need for foreign syntax to access shell commands (true of Tcl also). Very easy access to directory listings, etc.
I had been away from Thompson's book and left a challenging exercise half-way done. It was so easy to read my logic and just make a few more logical statements to get going again.
I also added a few more type signatures to clarify my expectations of the code.
But I can swear that Perl would not have been so easy to dive back into...
Working with the federal government is daunting. You have to fill out a ton of paperwork and it must be done precisely. Any mistakes and the spit it back at you with no compromise. However, once you get all the paperwork submitted, then you have a tremendous amount of comfort because you have a big powerful machine on your side.
Let's see why this reminds me of Haskell: you have to do a tremendous amount of type-checking and you must do it precisely. One you get all of your types and values lined up, then you have a powerful optimized program ready for reliable execution.
I do my best to avoid putting the same logic in two places in an application. However, my stored procedurees will require computations to be in other stored procedures.
Should my programming language access all of it's business logic from database stored procedures? But then I lose the power of a full-fledged programming language and must do everything in a kludgy pascal-like language.
I suppose the solution is to have the business logic/calculation in both places. Perhaps the program logic could generate the stored procedure logic???