Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re^2: The disadvantages of mini-languages

by metaperl (Curate)
on Feb 05, 2005 at 13:47 UTC ( #428316=note: print w/replies, xml ) Need Help??


in reply to Re: The disadvantages of mini-languages
in thread the disadvantages of mini-languages

  1. make as a language has shown itself to be inadequate. why do you think people invent things like cook, MakeMaker, Module::Build and makepp (a pure perl implementation of GNU make which extends it with Perl functionality?
  2. ditto for SQL. Why was it extended with stored procedures? Why is it necessary or far more convenient to handle complex processing client side with Perl instead of server-side with SQL.

summary: neither language provided does anything other than show that mini-languages are limited and inflexible. They make easy things easy and hard things difficult or impossible.

  • Comment on Re^2: The disadvantages of mini-languages

Replies are listed 'Best First'.
Re^3: The disadvantages of mini-languages
by hardburn (Abbot) on Feb 07, 2005 at 14:16 UTC

    Each of those has replacements. Those replacements are in the form of other domain-specific languages. In either case, the domain-specific part was not fundamentally flawed; rather, the designers had insufficient understanding of the problem domain.

    "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Re^3: The disadvantages of mini-languages
by Anonymous Monk on Feb 07, 2005 at 14:51 UTC
    make as a language has shown itself to be inadequate. why do you think people invent things like cook, MakeMaker, Module::Build and makepp (a pure perl implementation of GNU make which extends it with Perl functionality?

    I don't know cook or makepp, so I won't comment on that. MakeMaker was created to create Makefiles for a specific purpose. MakeMaker is poorly equiped to generate a Makefile for, oh, say, a Linux distribution. Module::Build was created because some people don't like MakeMaker.

    ditto for SQL. Why was it extended with stored procedures? Why is it necessary or far more convenient to handle complex processing client side with Perl instead of server-side with SQL.
    Actually, it's not. It's never necessary to do data processing in Perl. As for it being "more convenient", it being more convenient usually stems from programmer blinds - creating tunnel vision. Most programmers can only program in one type of language category very well, and Perl (iterative programming - a language category that also contains C, Java, Python and PHP) and SQL (set algebra) are vastly different categories. It usually goes "Oh, I need to do something for every piece of data. Thus I need a loop. But loops are hard in SQL. Hence I need to do it in Perl."
    Sometimes it's easier to do it outside the database. Sometimes, it's even more efficient to do it outside the database. But that happens less often than many people think.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://428316]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (6)
As of 2019-10-20 21:56 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?