Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A road to Lisp: Why Lisp

scotto.me

Post reply on HN
Print view View original

311–320 of 322 posts

Re: A road to Lisp: Why Lisp

#311

Post by doug_durham »

js8 wrote: post #245
doug_durham wrote: post #232

In commercial practice DSLs are an anti-pattern. Someone will create an under-documented DSL that only they understand and move on. The following programmers have to try to decipher this strange language. It is almost always a better idea to use standard language structures and features. Code is read more than it is written.

Hate to break it to you, but every time you create a function, you're creating your own language, specific to the domain. I suspect what you're actually objecting to is a lack of referential transparency, which is a problem in many languages (including Lisp, to be fair).

I’m not referring to trivial functions nor classes. I talking about things like overloading operators, or changing the default idioms of the language. This means that a person can’t read the code without fully understanding the entire class structure. For the most part DSLs are highly personal. What one person thinks is a great formalism that make it easy to reason about the problem, to everyone else is spaghetti code.

Re: A road to Lisp: Why Lisp

#312

Post by dismalaf »

iLemming wrote: post #282
dismalaf wrote: post #280

Earlier quoted context omitted.

So if you implement a non-homoiconic language in SBCL or Racket does the REPL blow up? Is Rhombus language a psy-op?

Implementing C-like language in Lisp runtime - your interpreter reads C-like source, parses it to your own AST structs, and evaluates those. The host being homoiconic says nothing about the guest. You would have to write a guest REPL anyway (if you want one). Rhombus built on Racket, yes, means it reuses Racket's machinery: the macro expander, the module system, the compiler, the runtime. But it doesn't mean it inher…

So close yet so far lol...

Re: A road to Lisp: Why Lisp

#313

Post by psd1 »

Skwid wrote: post #208
psd1 wrote: post #193

Earlier quoted context omitted.

I would refine that: Language design has only indirect relevance to language popularity. People go where the money is, hence python. But python is widespread because there is employment in it. That adoption by employers follows a network effect, but it originally came about through the language design. Early-adopter => mainstream => long tail Adoption hinges on that jump from evangelists to the mass market, and that…

I've never much luck selling a language on cleat benefits alone, but I guess there's not many climbers in my department.

Those are track cleats, because sports metaphors drive middle management

Re: A road to Lisp: Why Lisp

#314

Post by kazinator »

timonoko wrote: post #305
kazinator wrote: post #300

Earlier quoted context omitted.

"Need" is a very tenuous word, because most of any tool stack consists of benefits. End users benefit from things that they don't strictly need . Once you start talking about what people don't need, it's hard to do it in a way such that they need Lisp but don't need macros. Sometimes "need" is about dependencies; i.e. things you "need" are provided by upstreams; you stop needing things that you made yourself. E.g. "I…

I really do not understand this whining and downvoting. In so-called real life somebody has to live with the malformed macro, whose only purpose is to beautify the code. I even made un-macrofier, which deleted all macros and replaced instances with macroexpand, because slight adjustement of code resulted mysterious errors cause by nasty macroes. And lets not talk about Common Lisp loop macro, which was probably scoop…

Nobody has to live with a malformed macro because they can just observe what code expansion it is performing and write their own which does it better. (Speaking of CL loop, some people have resorted to this solution of actually dragging an implementation of loop into their application, to avoid issues with a vendor's loop, or behavioral differences among different ones---yes, loop has this, unfortunately).

The malformed macro situation is a lot better than the situation of a malformed API function to which you don't have source code.

Anything that is formed can be malformed. DNA can be malformed, leading to malformed fingers someone actually has to live with; so let's not have fingers.

Re: A road to Lisp: Why Lisp

#315

Post by derdi »

sph wrote: post #153
throwaway81523 wrote: post #105

Earlier quoted context omitted.

Lisp generally has precise GC, which I'd say makes it light side. It's even relatively type-safe if you count runtime type-checking. Highly reliable systems are written in Erlang, which if you squint is another Lisp dialect. There's even a sexp-based version called LFE, for Lisp-flavored Erlang. Erlang's key to reliability is error recovery, rather than exceptional levels of error prevention. I do like your light sid…

> Erlang, which if you squint is another Lisp dialect Prolog disagrees. IIRC the first versions of Erlang were written in Prolog, and you can still see its influence in the syntax.

Neither use as an implementation language nor syntactic similarities make one language a dialect of another. Consider that Java is commonly implemented in C++, and its syntax was designed to be easy to learn for C++ users. Yet nobody calls it a dialect of C++, not even when squinting really hard.

Erlang's computation model is functional, like Lisp, unlike Prolog.

Re: A road to Lisp: Why Lisp

#316

Post by deterministic »

__patchbit__ wrote: post #183
deterministic wrote: post #139

Earlier quoted context omitted.

I would be very interest in seeing how "getting lisp" enables you to write software that is more successful than the C and C++ software that runs the world. Perhaps you have written software in Lisp demonstrating this? Something you can show us?

The reference text on time keeping used to be implemented in Lisp. Alan Kay says a lot of problems with C/C++ go away when using the higher math more easily expressible in Lisp and like minded languages. Jürgen Schmidhuber says the problem with computers from a mathematician's point of view are the numbers.

> Alan Kay says a lot of problems with C/C++ go away when using the higher math more easily expressible in Lisp and like minded languages

That doesn't match my experience at all. Math and numbers are in general not a problem except when (say) implementing triangle hit detection in a game (something I did) where the precision of 32 bit floats does matter.

> Jürgen Schmidhuber says the problem with computers from a mathematician's point of view are the numbers.

That is probably true if you are a mathematician. Most people aren't.

Having said that, LEAN (for example) is written in C++ and used heavily by mathematicians.

Re: A road to Lisp: Why Lisp

#317

Post by deterministic »

anthk wrote: post #207
deterministic wrote: post #139

Earlier quoted context omitted.

I would be very interest in seeing how "getting lisp" enables you to write software that is more successful than the C and C++ software that runs the world. Perhaps you have written software in Lisp demonstrating this? Something you can show us?

Go ate a big lunch from Java, C and a bit of C++ as a systems' language, which Go was designed as "C sucessor without the C++ bullshit". Even the most modern C (Plan9/9front, not what the ANSI C comitee vomits in every iteration) it's a very different beast. Still, Common Lisp it's in places where trying to build such kind of software in C/C++ would be a reciper for disasters. https://www.lispworks.com/success-storie…

> Common Lisp it's in places where trying to build such kind of software in C/C++ would be a reciper for disasters.

I personally never blame the tools. I have written fairly complex software in 68000 assembler and it (1) worked fine and (2) was highly maintainable. However it was of course much slower to modify than using a higher level language.

Re: A road to Lisp: Why Lisp

#318

Post by deterministic »

frwrfwrfeefwf wrote: post #168

[dead]

I use plenty of DSL's in my daily work maintaining 1 million+ lines of C++ code used by very large companies around the world. No macros needed or wanted. More than 90% of the production code is generated from DSL's.

Outside of C++, Haskell has many great examples of powerful DSL's implemented without macros.

The problem with macros is the compile/run time cost. I could have implemented those DSL's using C++ templates (which are Turing complete by the way) but I prefer not to.

Re: A road to Lisp: Why Lisp

#319

Post by deterministic »

frwrfwrfeefwf wrote: post #301

[dead]

> go ahead and learn common lisp macros

Lisp macros used to be the one advantage Lisp had over other programming languages. However nowadays macros are common. There are even languages that has more than one flavour of macro system (Haskell has both a typed and non-typed flavour of macros).

However I personally prefer custom code generators instead of macros. The problem with macros, for the kind of large scale systems I work on, is understanding macros with N layers of abstraction, and also the compile/run time cost of using them.

Also, you can write code generators in any language and generate code for any language. Which is a huge advantage. I (for example) use code generators that generate C++, Java, Typescript, SQL, PDF's, interface descriptions, protocol specs etc. Whatever is required by a customer or other members of the team I can generate without demanding that they use a specific programming language.

Don't get me wrong. I love playing around with macros. However I have decided not to use them for real work.

Re: A road to Lisp: Why Lisp

#320

Post by anthk »

deterministic wrote: post #317
anthk wrote: post #207

Earlier quoted context omitted.

Go ate a big lunch from Java, C and a bit of C++ as a systems' language, which Go was designed as "C sucessor without the C++ bullshit". Even the most modern C (Plan9/9front, not what the ANSI C comitee vomits in every iteration) it's a very different beast. Still, Common Lisp it's in places where trying to build such kind of software in C/C++ would be a reciper for disasters. https://www.lispworks.com/success-storie…

> Common Lisp it's in places where trying to build such kind of software in C/C++ would be a reciper for disasters. I personally never blame the tools. I have written fairly complex software in 68000 assembler and it (1) worked fine and (2) was highly maintainable. However it was of course much slower to modify than using a higher level language.

M68k asm can be easier than some C++ templates.
Post reply on HN