Quantcast

Wow Monads!

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
55 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wow Monads!

Joachim Durchholz
Am 18.04.2017 um 17:39 schrieb David McClain:
> Well, as I stated, I think failures come in several categories:
>
> 1. Machine Fault failures on successfully compiled code. That’s the
> big nasty one. Provably correct code can’t fail, right? But it
> sometimes does. And I think you can trace that to the need to
> interface with the real world. The underlying OS isn’t written in
> OCaml. Neither are many of the C-libs on which OCaml depends.

I think that any language will depend on C libs, and so all languages
are afflicted by that.
Of course some languages have their own software stack and need less
external libs, so this depends.

> 2. Experimental languages are constantly moving tools with ever
> changing syntax and semantics. It becomes a huge chore to keep your
> code base up to date, and sooner or later you will stop trying. I
> have been through that cycle so many times before. Not just in OCaml.
> There is also RSI/IDL, C++ compilers ever since 1985, even C
> compilers.
>
> The one constant, believe it or not, has been my Common Lisp. I’m
> still running code today, as part of my system environment, that I
> wrote back in 1990 and have never touched since then. It just
> continues to work. I don’t have one other example in another language
> where I can state that.

Java :-)
Breakage does happen, but it's rare, though the incident rate can go up
if you don't know what you're doing (some people routinely use APIs
wrongly, read Internet recipes rather than the docs that come with the
Java libs, and are caught flat-footed when internals change - I guess
you don't have that problem because you know your system well enough to
avoid this kind of pitfall).

> 3. Even if the underlying language were fixed, the OS never changing,
> all libraries fully debugged and cast in concrete, the language that
> you use will likely have soft edges somewhere. For Pattern-based
> languages with full type decorations (e.g., row-type fields),
> attempting to match composite patterns over several tree layers
> becomes an exercise in write-only coding.
>
> The lack of a good macro facility in current FPL is hindering. Yes,
> you can do some of it functionally, but that implies a performance
> hit. Sometimes the FPL compilers will allow you to see the initial
> AST parse trees and you might be able to implement a macro facility /
> syntax bending at that point. But then some wise guy back at language
> HQ decides that the AST tool is not really needed by anyone, and then
> you get stung for having depended on it. The manual effort to recode
> what had been machine generated becomes too much to bear.

I think Lisp-style macros are too powerful.
You can get excellent results as long as everybody involved knows all
the relevant macros and their semantics perfectly well, and for one-man
teams like yourself this can work very well.
If you need to work with average programmers, this fails. In such an
environment, you need to be able to read other peoples' code, and if
they can define macros, you don't really know anymore what's happening.

> 4. I will fault any language system for programming that doesn’t give
> you an ecosystem to live inside of, to allow for incremental
> extensions, test, recoding, etc. Edit / compile / debug cycles are
> awful. FPL allows you to generally minimize the debug cycle, by
> having you live longer at the edit / compile stage.
>
> But see some of the more recent work of Alan Kay and is now defunct
> project. They had entire GUI systems programmed in meta-language that
> compiles on the fly using JIT upon JIT. They make the claim that
> compilers were tools from another era, which they are, and that we
> should not be dealing with such things today.

Well... the Java compiler doesn't really "exist" in a modern IDE, stuff
is being compiled on-the-fly in the background, even with live reload
inside a running program (with some restrictions, so this isn't perfect
- but then Java is anything but perfect).

So I do not think that compilers per se are a problem, though they way
they often need to be used can be.

> For me, Lisp offers a
> full toolbox and allows me to decide its shape in the moment. It
> doesn’t treat me like an idiot, and it doesn’t hold me to rigid world
> views.

Problem with that is that empowering the programmer makes it harder to
be 100% sure what a given piece of code does. There might be macros
involved, there might be metaprogramming involved, or some kind of
multiple dispatch with nonobvious defaulting rules, or a gazillion of
other things that you have to be aware of.
It's not a problem if you know your system from the inside out, but it
doesn't scale well to tasks that need to be done by a team.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wow Monads!

David McClain

>
> Java :-)
> Breakage does happen, but it's rare, though the incident rate can go up if you don't know what you're doing (some people routinely use APIs wrongly, read Internet recipes rather than the docs that come with the Java libs, and are caught flat-footed when internals change - I guess you don't have that problem because you know your system well enough to avoid this kind of pitfall).
>

I have never programmed in Java. I have watched others do so, and I interfaced some C++ code as a library to a Java app once.

But I don’t live much in the typical commercial software world. I am a physicist (astrophysicist) and the closest I came to commercial software on / off were early versions of extended C compilers that I wrote, image analysis systems for MacDonald’s (!!?), and mostly the international war machine.

My area has mostly been signal and image processing. I have never used a database in anger either, even though I have authored OODBMS systems. I wouldn’t really know how to wrap an app around a database, or even why you would do such a thing. That probably sounds really odd to anyone younger than about 40-50 years old. I have never written a web page. I don’t understand the fascination with HTML or XML or SGML or whatever you call it. Elaborated S-expressions that don’t seem to follow their own syntax rules.

> I think Lisp-style macros are too powerful.
> You can get excellent results as long as everybody involved knows all the relevant macros and their semantics perfectly well, and for one-man teams like yourself this can work very well.
> If you need to work with average programmers, this fails. In such an environment, you need to be able to read other peoples' code, and if they can define macros, you don't really know anymore what's happening.
>

Too powerful for whom? Again, I’m lucky to be master of my own domain. I don’t have to share code with anyone. For me, the biggest errors come from incorrect algorithm choice, not coding, not typing, not library API incompatibilities. Coding I can do with my eyes closed, except for all the typos… but then even with eyes open those still happen.

My very first year in computing, 1969, was the most frustrating year in my entire life. Everything I did was called wrong by the computer. Almost drove me to the point of tears. But then one day I woke up and I was one with the machine. Been that way for now, 47 years.

>
> Problem with that is that empowering the programmer makes it harder to be 100% sure what a given piece of code does. There might be macros involved, there might be metaprogramming involved, or some kind of multiple dispatch with nonobvious defaulting rules, or a gazillion of other things that you have to be aware of.
> It's not a problem if you know your system from the inside out, but it doesn't scale well to tasks that need to be done by a team.

Isn’t that always the case, and always will be the case? Nobody can be certain how some library or application was written. You might have some pretty strong hints and hunches, but how can you be sure?

Seems like the best bet is to treat everything as untrusted black boxes. Erlang probably offers the best security model against dependencies.

If you look at any major element of code in production, it was probably written in a hurry under near unreasonable demands because hardware engineering overran their budgets and took some of yours, and the programmer may or may not have well understood his tools and language, or even if he did, he might have been daydreaming of being on the beach with his girlfriend instead of in this meat locker with the rest of you guys…

My experience has been that hardware companies produce the most gawd-awful code you can imagine. Software shops vary… take M$ for instance - the bane of my existence. Looks like code gets pushed out the door and they rely on the audience to test it. Apple looks to me like a room full of really bright young minds, with no adult supervision.

I guess if I could offer any advice to other younger programmers, it would be to push yourself to become a polyglot to expand your mental horizons of what is possible, and a historian to understand what went before you and why, so that you don’t keep repeating the same stupid mistakes we did.

I could not be a production programmer. I’m definitely too much of a cowboy and a lone wolf. Teams are anathema to me. I need deep periods of isolation to think. People who manage to perform in production coding environments must have very different personalities from me.

- DM

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wow Monads!

David McClain
Your’e welcome…

> On Apr 18, 2017, at 10:20, Bryan Richter <[hidden email]> wrote:
>
> On Tue, Apr 18, 2017 at 09:57:10AM -0700, David McClain wrote:
>> <...>
>
> These posts of yours have been incredibly interesting to me, and I just
> wanted to thank you for sharing them!


I think my point about ecosystem programming is really about the importance of immediate feedback when crafting software. You need a powerful language so that you don’t get torpedoed with your fresh ideas with lots of mandatory scaffolding. In C-like languages the goal becomes one of writing a correct line of code.

The strongly typed languages, of the FPL variety, don’t force that upon you. But you do get sidetracked by the challenge of getting that last bit of code to type check successfully. And if you aren’t already in an ecosystem with the language, even more distracted by the demands of the edit / compile cycle.

Any distractions from your idea means that, if you happened to have chosen the wrong approach, you aren’t thinking properly about that aspect because the distractions have set up a nearer term goal for you to reach. We become like hamsters on a wheel, and we feel good after doing battle successfully. But the problem is, after all that, did it work the way you hoped? And without immediate feedback, even if you have some distractions that you must put up with, you are using an extended tape measure to flip the light switch on the opposite wall.

I think Haskell does offer some ecosystems. I have one that I installed on my Mac a couple months ago called “Haskell for Mac” by Chakravarty. It seems a pretty nifty little environment, but I have only been in there for about an hour or two. Part of my own push for polygot creds.

Another one that looks possibly interesting is Shen, formerly Qi. I did a fair amount with the old Qi language, even adding / correcting the compiler system to fit my own needs. Mastering the logic system is another challenge ahead of me. I was impressed at the implementation, and the equational reasoning, which I first saw back in the 1990’s with the publication of the SML Language.

But right off the bat, Haskell will present the bigger challenge to me. There is a huge scaffold of type class hierarchy that comes in the base environment. Reminds me a bit of trying to learn the old MSVC system from yore…

- DM

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wow Monads!

Sergiu Ivanov-2
In reply to this post by David McClain

Hello David,

Thus quoth  David McClain  at 15:39 on Tue, Apr 18 2017:
>
> 1. Machine Fault failures on successfully compiled code. That’s the
> big nasty one. Provably correct code can’t fail, right? But it
> sometimes does.

A very small remark (mostly directed at novice Haskell users reading
this): code which typechecks is _not_ the same thing as _provably
correct_ code.

Code which typechecks is code in which function applications concord
with the types.

Provably correct code is code which was (or can be) (automatically)
proved to correspond to a certain exact specification.

Haskell or OCaml type systems are usually not used for writing such
exact specifications, because they are not expressive enough.  Thus, in
general, showing that Haskell or OCaml code typechecks is weaker than
proving that it has a certain property (like not failing).  (However,
passing Haskell or OCaml type checks is still stronger than passing Java
type checks.)


> And I think you can trace that to the need to interface with the real
> world.

I have the same gut feeling.

--
Sergiu

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wow Monads!

David McClain
In reply to this post by David McClain
Hi Sergiu,

Excellent point you make about type checking versus provably correct code. I probably allowed myself to be lulled by a false equivalence many times in the past, confusing one for the other under pressure to get something working. But then, how many programmers actually produce provably correct code? I can see that happening very easily in the small. But for overall large programs?

- DM


> On Apr 18, 2017, at 14:36, Sergiu Ivanov <[hidden email]> wrote:
>
>
> Hello David,
>
> Thanks a lot for sharing your opinions, I find it very interesting.
>
> Thus quoth  David McClain  at 19:26 on Mon, Apr 17 2017:
>>
>> That’s when I began migrating back over to my old standby Lisp
>> system. I live inside of my Lisp all day long, for days on end. It is
>> a whole ecosystem. There is not crisp boundary of edit / compile /
>> debug. It is all incremental and extensional. I think that kind of
>> environment, regardless of language, is the holy grail of computing.
>
> Just a small question: have you ever tried Smalltalk/Squeak/Pharo? (I'm
> in no way affiliated.)
>
> These guys seem to be quite keen on blending the edit/compile/debug
> boundaries.
>
> --
> Sergiu

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wow Monads!

Sergiu Ivanov-2

Thus quoth  David McClain  at 22:47 on Tue, Apr 18 2017:
>
> Excellent point you make about type checking versus provably correct
> code. I probably allowed myself to be lulled by a false equivalence
> many times in the past, confusing one for the other under pressure to
> get something working. But then, how many programmers actually produce
> provably correct code? I can see that happening very easily in the
> small. But for overall large programs?

According to my knowledge, as well as to the unverified remark on
Wikipedia [0], not so many people prove their software correct.  That's
probably because current formal verification methods require a lot of
effort and have trouble supporting somewhat variable end-user
requirements within reasonable time bounds.

--
Sergiu

[0] https://en.wikipedia.org/wiki/Formal_verification#Industry_use

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wow Monads!

Haskell - Haskell-Cafe mailing list
In reply to this post by David McClain
"I guess if I could offer any advice to other younger programmers, it would be to push yourself to become a polyglot to expand your mental horizons of what is possible, and a historian to understand what went before you and why, so that you don’t keep repeating the same stupid mistakes we did."

By no means a young programmer here, but am currently learning Haskell as my first functional language for fun. Occaasionally I'll lament the fact that functional programming was not part of my CS curriculum back in the mid 90's. What you say is true because at the end of the day, being a self teacher has been rewarding. Can't really call myself a polyglot though, as I tend to deep-dive into interests.


"I could not be a production programmer. I’m definitely too much of a cowboy and a lone wolf. Teams are anathema to me. I need deep periods of isolation to think. People who manage to perform in production coding environments must have very different personalities from me."

I used to, mainly C/C++. There is no "I" in team... Our personalities must be similar : )

Regards,
Andrea


Sent with ProtonMail Secure Email.

-------- Original Message --------
Subject: Re: [Haskell-cafe] Wow Monads!
Local Time: April 18, 2017 11:57 AM
UTC Time: April 18, 2017 4:57 PM
To: haskell-cafe <[hidden email]>


>
> Java :-)
> Breakage does happen, but it's rare, though the incident rate can go up if you don't know what you're doing (some people routinely use APIs wrongly, read Internet recipes rather than the docs that come with the Java libs, and are caught flat-footed when internals change - I guess you don't have that problem because you know your system well enough to avoid this kind of pitfall).
>

I have never programmed in Java. I have watched others do so, and I interfaced some C++ code as a library to a Java app once.

But I don’t live much in the typical commercial software world. I am a physicist (astrophysicist) and the closest I came to commercial software on / off were early versions of extended C compilers that I wrote, image analysis systems for MacDonald’s (!!?), and mostly the international war machine.

My area has mostly been signal and image processing. I have never used a database in anger either, even though I have authored OODBMS systems. I wouldn’t really know how to wrap an app around a database, or even why you would do such a thing. That probably sounds really odd to anyone younger than about 40-50 years old. I have never written a web page. I don’t understand the fascination with HTML or XML or SGML or whatever you call it. Elaborated S-expressions that don’t seem to follow their own syntax rules.

> I think Lisp-style macros are too powerful.
> You can get excellent results as long as everybody involved knows all the relevant macros and their semantics perfectly well, and for one-man teams like yourself this can work very well.
> If you need to work with average programmers, this fails. In such an environment, you need to be able to read other peoples' code, and if they can define macros, you don't really know anymore what's happening.
>

Too powerful for whom? Again, I’m lucky to be master of my own domain. I don’t have to share code with anyone. For me, the biggest errors come from incorrect algorithm choice, not coding, not typing, not library API incompatibilities. Coding I can do with my eyes closed, except for all the typos… but then even with eyes open those still happen.

My very first year in computing, 1969, was the most frustrating year in my entire life. Everything I did was called wrong by the computer. Almost drove me to the point of tears. But then one day I woke up and I was one with the machine. Been that way for now, 47 years.

>
> Problem with that is that empowering the programmer makes it harder to be 100% sure what a given piece of code does. There might be macros involved, there might be metaprogramming involved, or some kind of multiple dispatch with nonobvious defaulting rules, or a gazillion of other things that you have to be aware of.
> It's not a problem if you know your system from the inside out, but it doesn't scale well to tasks that need to be done by a team.

Isn’t that always the case, and always will be the case? Nobody can be certain how some library or application was written. You might have some pretty strong hints and hunches, but how can you be sure?

Seems like the best bet is to treat everything as untrusted black boxes. Erlang probably offers the best security model against dependencies.

If you look at any major element of code in production, it was probably written in a hurry under near unreasonable demands because hardware engineering overran their budgets and took some of yours, and the programmer may or may not have well understood his tools and language, or even if he did, he might have been daydreaming of being on the beach with his girlfriend instead of in this meat locker with the rest of you guys…

My experience has been that hardware companies produce the most gawd-awful code you can imagine. Software shops vary… take M$ for instance - the bane of my existence. Looks like code gets pushed out the door and they rely on the audience to test it. Apple looks to me like a room full of really bright young minds, with no adult supervision.

I guess if I could offer any advice to other younger programmers, it would be to push yourself to become a polyglot to expand your mental horizons of what is possible, and a historian to understand what went before you and why, so that you don’t keep repeating the same stupid mistakes we did.

I could not be a production programmer. I’m definitely too much of a cowboy and a lone wolf. Teams are anathema to me. I need deep periods of isolation to think. People who manage to perform in production coding environments must have very different personalities from me.

- DM

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wow Monads!

Richard A. O'Keefe

> On 19/04/2017, at 3:13 PM, Atrudyjane via Haskell-Cafe <[hidden email]> wrote:
>
> I used to, mainly C/C++. There is no "I" in team... Our personalities must be similar : )

It's hidden, but there is definitely "a me" in "team".
And then it's time for "T".  (Obscure Lisp reference.)

Someone wrote:
>>
>> > I think Lisp-style macros are too powerful.

It's true that higher-order functions can do a lot of the things people used
macros to do, and better.

However, having said "Lisp-style macros", Lisp is a tree with many branches.
How about Scheme-style macros?

>> > Problem with that is that empowering the programmer makes it harder to be 100% sure what a given piece of code does.

This is also true in Haskell.  Show me a piece of code golf with Arrows and
LemurCoSprockets and such all over the place and I haven't a clue.  Total
bewilderment.  Heck, show me *undocumented* code in a language without
macros, classes, or higher-order functions (Fortran 95? COBOL 85?) and I'll
be just as baffled, if it is big enough.  (I've been staring at some old
numeric code recently.  One page is quite big enough...)



_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wow Monads!

migmit-2

I think the problem with macros in general is that their semantics is defined purely in terms of code they generate. Not in terms of what that code actually does. As for me, I want to think about the things I need to achieve, not about the code to write.

Az iPademről küldve

2017. ápr. 19. dátummal, 6:24 időpontban Richard A. O'Keefe <[hidden email]> írta:


On 19/04/2017, at 3:13 PM, Atrudyjane via Haskell-Cafe <[hidden email]> wrote:

I used to, mainly C/C++. There is no "I" in team... Our personalities must be similar : )

It's hidden, but there is definitely "a me" in "team".
And then it's time for "T".  (Obscure Lisp reference.)

Someone wrote:

I think Lisp-style macros are too powerful.

It's true that higher-order functions can do a lot of the things people used
macros to do, and better.

However, having said "Lisp-style macros", Lisp is a tree with many branches.
How about Scheme-style macros?

Problem with that is that empowering the programmer makes it harder to be 100% sure what a given piece of code does.

This is also true in Haskell.  Show me a piece of code golf with Arrows and
LemurCoSprockets and such all over the place and I haven't a clue.  Total
bewilderment.  Heck, show me *undocumented* code in a language without
macros, classes, or higher-order functions (Fortran 95? COBOL 85?) and I'll
be just as baffled, if it is big enough.  (I've been staring at some old
numeric code recently.  One page is quite big enough...)



_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wow Monads!

David McClain

On Apr 18, 2017, at 22:05, MigMit <[hidden email]> wrote:


I think the problem with macros in general is that their semantics is defined purely in terms of code they generate. Not in terms of what that code actually does. As for me, I want to think about the things I need to achieve, not about the code to write.


Those first two sentences were a joke, eh? Macros exist to shape the language to suit the problem domain and prevent massive typos and fingers cramping up.

I played around with Sanitary Macrology, or whatever they are called, in Dylan back in the late 90’s. Frankly, I find them maddening. I much prefer the Common Lisp style of macrology. But read up on macros in Quiennec’s book, “Lisp in Small Pieces”. They exist in a kind of no-man’s land in language stages. There really isn’t any one best kind of macrology.

Back in OCaml land they used to have a preprocessor that could give you access to the AST’s from a first pass of compiling, and I made liberal use of a custom tree rewriter in order to give my vectorized / overloaded math language NML a better shape than plain OCaml syntax. That is yet another kind of macrology. And potentially just as powerful, if less convenient to use on the fly.

- DM


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wow Monads!

migmit-2
Of course not. If my language needs much tweaking to fit the problem domain, it usually means I chose the wrong language in the first place. If macros a needed to prevent TYPOS, it means the language is doomed.

Az iPademről küldve

2017. ápr. 19. dátummal, 8:52 időpontban David McClain <[hidden email]> írta:


On Apr 18, 2017, at 22:05, MigMit <[hidden email]> wrote:


I think the problem with macros in general is that their semantics is defined purely in terms of code they generate. Not in terms of what that code actually does. As for me, I want to think about the things I need to achieve, not about the code to write.


Those first two sentences were a joke, eh? Macros exist to shape the language to suit the problem domain and prevent massive typos and fingers cramping up.

I played around with Sanitary Macrology, or whatever they are called, in Dylan back in the late 90’s. Frankly, I find them maddening. I much prefer the Common Lisp style of macrology. But read up on macros in Quiennec’s book, “Lisp in Small Pieces”. They exist in a kind of no-man’s land in language stages. There really isn’t any one best kind of macrology.

Back in OCaml land they used to have a preprocessor that could give you access to the AST’s from a first pass of compiling, and I made liberal use of a custom tree rewriter in order to give my vectorized / overloaded math language NML a better shape than plain OCaml syntax. That is yet another kind of macrology. And potentially just as powerful, if less convenient to use on the fly.

- DM

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wow Monads!

Joachim Durchholz
In reply to this post by David McClain
Am 18.04.2017 um 18:57 schrieb David McClain:
>> I think Lisp-style macros are too powerful. You can get excellent
>> results as long as everybody involved knows all the relevant macros
>> and their semantics perfectly well, and for one-man teams like
>> yourself this can work very well. If you need to work with average
>> programmers, this fails. In such an environment, you need to be
>> able to read other peoples' code, and if they can define macros,
>> you don't really know anymore what's happening.
>
> Too powerful for whom?

Too powerful for teams that include sub-average programmers (by
definition, you always have a sub-average one on the team).

The issue is that you don't have enough brilliant developers to staff
all the projects in the world, so you need technology that gives
consistent results, much more than technology that boosts productivity
but is inconsistent.

 > Again, I’m lucky to be master of my own
> domain.

Exactly.

>> Problem with that is that empowering the programmer makes it harder
>> to be 100% sure what a given piece of code does. There might be
>> macros involved, there might be metaprogramming involved, or some
>> kind of multiple dispatch with nonobvious defaulting rules, or a
>> gazillion of other things that you have to be aware of. It's not a
>> problem if you know your system from the inside out, but it doesn't
>> scale well to tasks that need to be done by a team.
>
> Isn’t that always the case, and always will be the case?

Only in dynamic languages that do not give you any guarantees about what
the code is *not* going to do.
That's exactly what makes Haskell interesting: There cannot be any side
effects unless the code has IO in the type signature, which is so
awkward that people tend to push it into a small corner of the program.
The net effect is that it is far easier to reason about what a program
can and cannot do.
In the Java/C++/whatever world, unit testing achieves the same, though
the imperative nature and generally less well-delimited semantics the
effect is far less pervasive. Java stands out a bit since the language
semantics has always been nailed down pretty narrowly right off the
start, which is a first in the computing world and has been having
pervasive effects through all the language culture - Java libraries tend
to interoperate much better than anything that I read about the C and
C++ world.

 > Nobody can
> be certain how some library or application was written. You might
> have some pretty strong hints and hunches, but how can you be sure?
>
> Seems like the best bet is to treat everything as untrusted black
> boxes.

Whenever I see one of the Java libraries do something unexpected in what
I code, I tend to read the sources. It's usually easy because Java is so
dumbed-down and verbose that you can pick up enough hints.
The more advanced libraries (Spring) take longer to understand well
enough, and some (Hibernate) are so badly coded that it's pretty
non-fun, but I tend to get results, mostly because Java is so strict
that I can see what's happening.
I get into trouble whenever annotations or AOP stuff is involved, or
when too much activity is hidden away into data structures that are
being executed at a later time. Data types help me pick up on that lead
though; I'd fail miserably in a language without static typing because
all the hints and hunches are gone, and I have to go by cultural hints
and hunches which tend to diverge between projects so I'd be lost.
(Actually I'm pretty sure, I tried to get "into" Smalltalk once and it
never worked for me.)

 > Erlang probably offers the best security model against
> dependencies.

Erlang is good for handling failures that show up.
It does nothing for you if the problem is code that's subtly wrong.

> If you look at any major element of code in production, it was
> probably written in a hurry under near unreasonable demands because
> hardware engineering overran their budgets and took some of yours,
> and the programmer may or may not have well understood his tools and
> language, or even if he did, he might have been daydreaming of being
> on the beach with his girlfriend instead of in this meat locker with
> the rest of you guys…

Actualy it's not the hardware engineers nowadays (we all work on stock
hardware anyway).
It's the bean counters who are trying to cut down on the budget.

> My experience has been that hardware companies produce the most
> gawd-awful code you can imagine. Software shops vary… take M$ for
> instance - the bane of my existence. Looks like code gets pushed out
> the door and they rely on the audience to test it.

They used to be that way.
Security threats endangered their business model, so they had to change;
nowadays, they aren't that different form other large companies anymore.

 > Apple looks to me
> like a room full of really bright young minds, with no adult
> supervision.

Actually Apple is the most strictly controlled workplace in the
industry, as far as I know.

> I guess if I could offer any advice to other younger programmers, it
> would be to push yourself to become a polyglot to expand your mental
> horizons of what is possible, and a historian to understand what went
> before you and why, so that you don’t keep repeating the same stupid
> mistakes we did.

In the modern world, the bean counters found enough tools to control the
development process that you don't have much of a choice.
If you want to have choice, you now need to become a manager. Which
means no programming at all.

It takes a lot out of the profession that was attractive in the past
decades, but on the other hand it reduces project unpredictability and
increases job security. (It's still not perfect, but I doubt it ever can
be.)

> I could not be a production programmer. I’m definitely too much of a
> cowboy and a lone wolf. Teams are anathema to me. I need deep periods
> of isolation to think. People who manage to perform in production
> coding environments must have very different personalities from me.

That has been clear for a long while :-)
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wow Monads!

Joachim Durchholz
In reply to this post by Richard A. O'Keefe
Am 19.04.2017 um 06:24 schrieb Richard A. O'Keefe:
> Someone wrote:

That was me :-)

>>>> I think Lisp-style macros are too powerful.
>
> It's true that higher-order functions can do a lot of the things people used
> macros to do, and better.
>
> However, having said "Lisp-style macros", Lisp is a tree with many branches.
> How about Scheme-style macros?

I can't tell the difference anymore, I was going through Common Lisp
docs at one time and through the Scheme docs at another time and don't
remember anymore which did what. I also have to say that I didn't pick
up all the details - I was even more averse to macros then than I am
today, so I didn't pay too much attention.

The general finding, however, was what both were very, very heavy on
enabling all kinds of cool and nifty features, but also very, very weak
on making it easy to understand existing code. Essentially, each
ecosystem with its set of macros, multiple-dispatch conventions, hook
systems and whatnow, to the point that it is its own language that you
have to learn.
That's essentially why I lost interest: None of what I was learning
would enable me to actually work in any project, I'd have to add more
time to even understand the libraries, let alone contribute.

The other realization was that these extension mechanisms could make
code non-interoperable, and there was no easy way to find out whether
there would be a problem or not. This would be a non-problem for
lone-wolf or always-the-same-team we-reinvent-wheels-routinely
scenarios, but it's a closed world that an outsider cannot get into
without committing 100%.

Java does a lot of things badly, but it got this one right. I can easily
integrate whatever library I want, and it "just works", there are no
linker errors, incompatible memory layouts, and what else is making the
reuse external C++ libraries so hard.
Nowadays, the first step in any new project is to see what libraries we
need. Integration is usually just a configuration line in the build tool
(you don't have build tools in Lisp so that's a downside, but the build
tools are generally trivial when it comes to library integration; things
get, er, "interesting" if you task the build tool with all the other
steps in the pipeline up to and including deployment, but there it's
that the environments are so diverse that no simple solution is possible).

>>>> Problem with that is that empowering the programmer makes it harder to be 100% sure what a given piece of code does.
>
> This is also true in Haskell.  Show me a piece of code golf with Arrows and
> LemurCoSprockets and such all over the place and I haven't a clue.  Total
> bewilderment.

Heh, I can subscribe to that. Even finding out what Monad does took me
far too long.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wow Monads!

Joachim Durchholz
In reply to this post by David McClain
Am 19.04.2017 um 08:52 schrieb David McClain:
> I played around with Sanitary Macrology, or whatever they are called,

Maybe you remember "hygienic macros".
Basically, avoid the C preprocessor crap. I don't know what the exact
rules were, and I suspect every language community had its own
definition of "hygienic" anyway.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wow Monads!

Joachim Durchholz
In reply to this post by Sergiu Ivanov-2
Am 18.04.2017 um 23:33 schrieb Sergiu Ivanov:
> Haskell or OCaml type systems are usually not used for writing such
> exact specifications, because they are not expressive enough.

I have read statements that Haskell code still tends to "just work as
expected and intended", and see that attributed to the type system.

Seemed to be related to Haskells expressivity, with the type system
pretty much preventing the typical errors that people make.

So the sentiment was that it's not the same but close enough to be the
same in practice. Though I doubt that that will hold up once you get
more proficient in Haskell and start tackling really complicated things
- but "simple stuff in Haskell" tends to get you farther than anybody
would expect, so it's still a net win.
Just impressions though, I never had an opportunity to delve that deeply
into Haskell.

 > Thus, in
> general, showing that Haskell or OCaml code typechecks is weaker than
> proving that it has a certain property (like not failing).

That a code type checks in Haskell still gives you a whole lot of
guarantees. Such as "it doesn't have IO in the type signature so there
cannot be any side effect deep inside".
(Ironically, people instantly started investigating ways to work around
that. Still, the sort-of globals you can introduce via the State monad
are still better-controlled than the globals in any other language.)

(Aside note: I don't know enough about OCaml to talk about its
properties, but I do believe that they are much weaker than in Haskell.)

 > (However,
> passing Haskell or OCaml type checks is still stronger than passing Java
> type checks.)

Yep.

>> And I think you can trace that to the need to interface with the real
>> world.
>
> I have the same gut feeling.

I think interfacing with the outside world (still not "real" but just
bits inside the operating system and on disk) is one major source of
unreliability, but not the only one, and not necessarily the primary one.
YMMV.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wow Monads!

Richard A. O'Keefe
In reply to this post by migmit-2

> On 19/04/2017, at 5:05 PM, MigMit <[hidden email]> wrote:
>
> http://www.offcenterdesigns.net/wp-content/uploads/wp-checkout/images/i-found-the-i-in-team-t-shirt-1344970569.jpg
>
> I think the problem with macros in general is that their semantics is defined purely in terms of code they generate. Not in terms of what that code actually does. As for me, I want to think about the things I need to achieve, not about the code to write.

I find this a rather baffling comment.

Let's take SRFI-8, for example, which defines the syntax

   (receive <variables> <expression> <body>)

which the SRFI defines *semantically* (paraphrased):
 - the <expression> is evaluated
 - the values are bound to the <variables>
 - the expressions in the <body> are evaluated sequentially
 - the values of the last <body> expression are the values
   of the (receive ...) expression.

The syntax is *implemented* thus:
(define-syntax receive
  (syntax-rules ()
    ((receive formals expression body ...)
     (call-with-values (lambda () expression)
                       (lambda formals body ...)))))

but the semantics is *defined* by the specification.
The whole point of a macro such as this is for the user
*NOT* to "think about the code to write".  The code that
gets generated is of no interest to the ordinary programmer
whatsoever.

(Reflecting on the subject of this thread,
'receive' is actually pretty close to >>= .)

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wow Monads!

Richard A. O'Keefe
In reply to this post by Joachim Durchholz

> On 19/04/2017, at 7:23 PM, Joachim Durchholz <[hidden email]> wrote:
>> However, having said "Lisp-style macros", Lisp is a tree with many branches.
>> How about Scheme-style macros?
>
> I can't tell the difference anymore,

MAJOR differences.

Lisp macros: run *imperative* *scope-insensitive* macros to do source to source
transformation at compilation or interpretation time.

Scheme macros: run *declarative* *scope-sensitive* macros to do source to source
transformation at compilation or interpretation time.

>
> The general finding, however, was what both were very, very heavy on enabling all kinds of cool and nifty features, but also very, very weak on making it easy to understand existing code.

With respect to Common Lisp, I'm half-way inclined to give you an argument.
Macros, used *carefully*, can give massive improvements in readability.
Let's face it, one bit of Lisp (APL, SML, OCaml, Haskell) code looks pretty
much like another.  The way I've seen macros used -- and the way I've used
them myself -- makes code MORE understandable, not less.

All it takes is documentation.

In Scheme, however, I flatly deny that macros in any way make it harder to
understand existing code than functions do.

> Essentially, each ecosystem with its set of macros, multiple-dispatch conventions, hook systems and whatnow, to the point that it is its own language that you have to learn.

And how is this different from each ecosystem having its own set of operators (with the same
names but different precedence and semantics) or its own functions (with the same name but
different arities and semantics)?

This is why Common Lisp has packages
and R6RS and later Scheme have modules.
Yes, different subsystems can have different vocabularies of macros,
just as different modules in Haskell can have different vocabularies
of types, operators, and functions.
They don't interfere, thanks to the package or module system.

> That's essentially why I lost interest: None of what I was learning would enable me to actually work in any project, I'd have to add more time to even understand the libraries, let alone contribute.

That *really* doesn't sound one tiny bit different from trying to work on
someone else's Java or Haskell code.

My own experience with Lisp was writing tens of thousands of lines to fit into
hundreds of thousands, and my experience was very different from yours.
Macros were *defined* sparingly, *documented* thoroughly, and *used* freely.
Result: clarity.

>
> The other realization was that these extension mechanisms could make code non-interoperable,

I fail to see how define-syntax encapsulated in modules could possibly
make Scheme code non-interoperable.

> and there was no easy way to find out whether there would be a problem or not.

Scheme answer: there isn't.  OK, in R5RS there _was_ a problem that two files
could both try to define the same macro, but that's not different in kind from
the problem that two files could try to define the same function.  In R6RS and
R7RS, the module system catches that.
>
>
> Java does a lot of things badly, but it got this one right. I can easily integrate whatever library I want, and it "just works", there are no linker errors, incompatible memory layouts, and what else is making the reuse external C++ libraries so hard.

Fell off chair laughing hysterically.  Or was that screaming with remembered
pain?  I am sick to death of Java code *NOT* "just working".
I am particularly unthrilled about Java code that *used* to work ceasing to work.
I am also sick of working code that gets thousands of deprecation warnings.

I am particularly tired of having to grovel through thousands of pages of bad
documentation, to the point where it's often less effort to write my own code.

I am *ALSO* sick of trying to match up Java libraries that only build with Ant
and Java libraries that only build with Maven.  (Yes, I know about just putting
.jar files in the right place.  I've also heard of the Easter Bunny.)

> Nowadays, the first step in any new project is to see what libraries we need. Integration is usually just a configuration line in the build tool (you don't have build tools in Lisp so that's a downside,

Wrong.  There are build tools for Common Lisp and have been for a long time.
I didn't actually know that myself until I saw a student -- who was using
Common Lisp without any of us having ever mentioned it to him -- using one.



Look, it's really simple.
If programmers *WANT* to write readable code
and are *ALLOWED TIME* to write readable code, they will.
Whatever the language.
If they have other priorities or constraints, they won't.
Whatever the language.



_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wow Monads!

Richard A. O'Keefe
In reply to this post by Joachim Durchholz

> On 19/04/2017, at 7:08 PM, Joachim Durchholz <[hidden email]> wrote:
>>
>> Too powerful for whom?
>
> Too powerful for teams that include sub-average programmers (by definition, you always have a sub-average one on the team).
>
> The issue is that you don't have enough brilliant developers to staff all the projects in the world, so you need technology that gives consistent results, much more than technology that boosts productivity but is inconsistent.

To keep this relevant to Haskell, Template Haskell is roughly
analogous to Lisp macros.  It works on syntactically well-formed
fragments.  It is normally hygienic, like Scheme, but permits
quite complex transformations, like Lisp.  And macros in Lisp
and Scheme have traditionally been used to develop embedded DSLs,
which is something Haskell programmers sometimes do.  Template
Haskell can of course do amazing things that Lisp and Scheme cannot.

There are at least two claims here.
- using (not developing, just using) macros requires "brilliant developers"
- using (not developing, just using) macros "gives inconsistent results".

I am willing to concede that *writing* Lisp macros requires particularly
good programmers (because the 'implementation language' of Lisp macros
has the full power of Lisp) and that *writing* Scheme macros requires
particularly good programmers (because the 'implementation language'
of Scheme macros *isn't* Scheme but tree-to-tree rewrite rules).  In
particular, I am not yet competent to write any Scheme macro whose
implementation requires recursion, so since I'm a brilliant programmer,
people who can do that must be geniuses, eh?

It does not follow that *using* macros is any harder than using any
special form pre-defined by the language, and as a matter of fact,
it isn't.  In Scheme, logical conjunction (AND) and disjunction (OR)
are in principle defined as macros.  That doesn't make them hard to
use, error-prone to use, or in any way inconsistent.

(And yes, I *have* struggled with macros in UCI Lisp and InterLisp.
Modern Lisp is not your grandfather's Lisp any more than
modern Scheme is your grandfather's Scheme or
modern Fortran your grandfather's Fortran.  And yep, there's a
Fortran preprocessor, fpp, modelled on cpp but adapted to Fortran.
Not standard, but freely available.  And it hasn't caused the
death of Fortran yet, any more than CPP has killed Haskell.)


 


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wow Monads!

Joachim Durchholz
In reply to this post by Richard A. O'Keefe
Am 19.04.2017 um 11:42 schrieb Richard A. O'Keefe:
>
>> The general finding, however, was what both were very, very heavy on enabling all kinds of cool and nifty features, but also very, very weak on making it easy to understand existing code.
>
> With respect to Common Lisp, I'm half-way inclined to give you an argument.

:-)
As I said, I don't really know any details anymore.

> Macros, used *carefully*, can give massive improvements in readability.

Oh, definitely!
Actually this applies even to C-style macros, though they're pretty
limited what they can do before you start to hit the more obscure
preprocessor features.

> Let's face it, one bit of Lisp (APL, SML, OCaml, Haskell) code looks pretty
> much like another.  The way I've seen macros used -- and the way I've used
> them myself -- makes code MORE understandable, not less.
>
> All it takes is documentation.

Good documentation. That's where that Smalltalk system I experimented
with (Squeak I think) was a bit weak on: It documented everything, but
it was pretty thin on preconditions so you had to experiment, and since
parameters were passed through layers and layers of code it was really
hard to determine what part of the system was supposed to do what.

> In Scheme, however, I flatly deny that macros in any way make it harder to
> understand existing code than functions do.

Fair enough.

>> Essentially, each ecosystem with its set of macros, multiple-dispatch conventions, hook systems and whatnow, to the point that it is its own language that you have to learn.
>
> And how is this different from each ecosystem having its own set of operators (with the same
> names but different precedence and semantics) or its own functions (with the same name but
> different arities and semantics)?

Different functions with different arities are actually that: different.
Just consider the arity a part of the name.
Different semantics (in the sense of divergence) - now that would be a
major API design problem. It's the kind of stuff you see in PHP, but not
very much elsewhere.
(Operators are just functions with a funny syntax.)

However there's a real difference: If the same name is dispatched at
runtime, you're in trouble unless you can tell that the interesting
parts of the semantics are always the same.
Languages with a notion of subtype, or actually any kind of semantic
hierarchy between functions allow you to reason about the minimum
guaranteed semantics and check that the caller does it right. Any
language with subtyping or a way to associate an abstract data type to
an interface can do this; I didn't see anything like that in Smalltalk
(where subclasses tend to sort-of be subtypes but no guarantees), or in
any Lisp variant that I ever investigated, so this kind of thing is hard.
Now there's still a huge difference between just type guarantees (C++,
Java, OCaml), design by contract (Eiffel), and provable design by
contract (I know of no language that does this, though you can
approximate that with a sufficiently strong type system).

> Yes, different subsystems can have different vocabularies of macros,
> just as different modules in Haskell can have different vocabularies
> of types, operators, and functions.
> They don't interfere, thanks to the package or module system.

Ah. I've been thinking that macros were globally applied.

>> That's essentially why I lost interest: None of what I was
>> learning would enable me to actually work in any project, I'd have
>> to add more time to even understand the libraries, let alone
>> contribute.
>
> That *really* doesn't sound one tiny bit different from trying to work on
> someone else's Java or Haskell code.

It *is* different: Understanding the libraries isn't hard in Java.
That's partly because the language is pretty "stupid", though the
addition of generics, annotations, and higher-order functions has
started changing that. (Unfortunately these things are too important and
useful to just leave them out.)

> My own experience with Lisp was writing tens of thousands of lines to fit into
> hundreds of thousands, and my experience was very different from yours.
> Macros were *defined* sparingly, *documented* thoroughly, and *used* freely.
> Result: clarity.

Yes, I've been assuming that that's what was happening.
I still reserve some scepticism about the "documented thoroughly" bit,
because you're so far beyond any learning curve that I suspect that your
chances of spotting any deficits in macro documentation are pretty slim.
(I may be wrong, but I see no way to really validate the thoroughness of
macro documentation.)

>> The other realization was that these extension mechanisms could make code non-interoperable,
>
> I fail to see how define-syntax encapsulated in modules could possibly
> make Scheme code non-interoperable.

Yeah, I was assuming that macros are global.
It's very old Lisp experience from the days when Common Lisp and Scheme
were new fads, when Lisp machines were still a thing, and had to be
rebooted on a daily basis to keep them running.

What can make code non-interoperable even today is those
multiple-dispatch mechanisms (which may not exist in Scheme but only in
Common Lisp). Multiple dispatch cannot be made modular and consistent
("non-surprising"), and the MD mechanism that I studied went the other
route: If the semantics is a problem, throw more mechanisms at it until
people can make it work as intended, to the point that you could
dynamically hook into the dispatch process itself.
It made my toenails curl.

>> Java does a lot of things badly, but it got this one right. I can
 >> easily integrate whatever library I want, and it "just works", there
 >> are no linker errors, incompatible memory layouts, and what else is
 >> making the reuse external C++ libraries so hard.
>
> Fell off chair laughing hysterically.  Or was that screaming with remembered
> pain?  I am sick to death of Java code *NOT* "just working".
> I am particularly unthrilled about Java code that *used* to work ceasing to work.
> I am also sick of working code that gets thousands of deprecation warnings.

Sorry, but that's all hallmarks of bad Java code.

> I am particularly tired of having to grovel through thousands of pages of bad
> documentation, to the point where it's often less effort to write my own code.

Yeah, that used to be a thing.
It isn't usually a problem anymore (even Hibernate may have grown up, I
hear that the 4.x codebase is far better than the really crummy 3.6 one
that I have come to disrespect).

> I am *ALSO* sick of trying to match up Java libraries that only build with Ant
> and Java libraries that only build with Maven.  (Yes, I know about just putting
> .jar files in the right place.  I've also heard of the Easter Bunny.)

Using Ant means you're doing it in a pretty complicated and fragile,
outdated way.
Putting .jar files in the right place is the most fragile way ever, and
leads stright into stone age nightmares; don't ever follow that kind of
advice unless you *want* to fail in mysterious ways.

Maven would be the way to go, but only if your project is so large that
you have a team of build engineers anyway, i.e. with overall workforce
of 30+ persons.
Smaller teams should stick with Gradle, which uses the same dependency
management as Maven but isn't into the kind of bondage&discipline that
Maven is.

Sadly, there are still shops that don't use Maven or Gradle.
For legacy projects I can understand that, but many do it because they
don't know better, i.e. there's no competent build engineer on the team.
Those teams are doomed to repeat old mistakes, just like people who
still think that Lisp macros are global are doomed to misjudge them :-D

>> Nowadays, the first step in any new project is to see what libraries we need. Integration is usually just a configuration line in the build tool (you don't have build tools in Lisp so that's a downside,
>
> Wrong.  There are build tools for Common Lisp and have been for a long time.
> I didn't actually know that myself until I saw a student -- who was using
> Common Lisp without any of us having ever mentioned it to him -- using one.

Ah ok, I didn't know that.

> Look, it's really simple.
> If programmers *WANT* to write readable code
> and are *ALLOWED TIME* to write readable code, they will.
> Whatever the language.

Unless they want to show off how smart they are, and think that writing
code that only they can understand is testament to that.
This kind of thinking is frowned upon nowadays, but it used to be pretty
widespread not too long ago.

> If they have other priorities or constraints, they won't.
> Whatever the language.

Definitely. Even if programmers would and could to do better, external
constraints can prevent them from doing so.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wow Monads!

David McClain

On Apr 19, 2017, at 05:42, Joachim Durchholz <[hidden email]> wrote:

Yeah, I was assuming that macros are global.
It's very old Lisp experience from the days when Common Lisp and Scheme were new fads, when Lisp machines were still a thing, and had to be rebooted on a daily basis to keep them running.

Was Lisp ever a fad? I’m shocked to hear that. Seriously!

I only got into Lisp after several years of mild nagging by one of my former employees, who studied Lisp and Proof Systems for his graduate CS Degree from U.Oregon, sometime back in the early 80’s, late 70’s. Turns out everything he said was true, and more.

- DM

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
123
Loading...