Comment by zvrba | Hacker News Reader

Comment by zvrba | Hacker News Reader

I don't buy that the "privilege" of

> 1. Create a language to solve your problem; > 2. Solve your problem.

belongs mainly to Lisp and Smalltalk. Each time you define a method or a class (C#, Java, C++), you're extending and defining your "language".

I'm the leader of a 2.5-developer startup, we use C++, Java and C# for different purposes, and I have not once thought "shit, we'd be so much more productive if we used XXX instead of C# or Java" (C++ being the exception). Because the real problems are around the business domain. Understanding customer needs, wrapping our heads around Azure AD, etc, etc, etc.

The programming language has ZILCH to do with our challenges and I do not feel hampered by PL during refactoring either -- thanks to static types.

I have some regrets, and these go against frameworks we decided to use (EFCore, i.e., ORM, being the biggest regret of mine).

Programming language? Almost not a factor. I'm happy with all of the 3 we use, though I'm least productive in C++ due to the amount of ceremony needed -- header/implementation files, linkage, fixing preprocessor mess by variations of PIMPL (looking at you windows.h), slow compilation, etc, etc, etc.

If anything is indispensable for our productivity, it's a good ide and becoming comfortable with its capabilities.

> Each time you define a method or a class (C#, Java, C++), you're extending and defining your "language".

One mostly only adds new words to these languages: nouns and verbs. With Lisp you can add new syntax as a user as part of the program. This allows us to do code transformations at compile time as part of a program. This allows us relatively straight forward to generate more complex code from simpler descriptive code.

> With Lisp you can add new syntax

"With Lisp you can have any syntax, as long as it looks like Lisp."

Unless it doesn't:

    CL-USER 14 > (loop for i from 0 below 10
                       sum i into isum
                       when (evenp i) sum i into evensum of-type integer
                       else when (oddp i) sum i into oddsum
                       finally (return (* isum evensum oddsum)))
    22500

Arguably that still looks like Lisp (i.e. it's a valid S-expression). But then you also have reader macros...

Well, s-expressions are not Lisp. Not every s-expression is a valid Lisp program.

(1 * 2 ^ 3 + 1) is a valid s-expression, but not a valid Lisp program. With an INFIX macro it could be:

(infix 1 * 2 ^ 3 + 1) could be a valid Lisp program, with a corresponding infix macro.

But the Lisp syntax still is on top of the s-expression syntax...

I could do that in C# as well if I felt I needed it. Define classes representing the "syntax/AST", utility functions to build the AST and an interpreter that compiles the AST to an expression tree which in turn is an executable lambda.

It's what EFCore does, translates C# method calls into SQL statements via lambdas bound to expression trees.

So, no, LISP is not special in that regard.

> LISP is not special in that regard

It's just MUCH MUCH easier, standardized and widely used.

> easier

For routine code generation, there are even simpler T4 templates. That one gets as easy as one could want.

> standardized

So are expression trees: https://docs.microsoft.com/en-us/dotnet/api/system.linq.expr...

> and widely used

By what statistics?

> So are expression trees

But they are not easier. Pick one or two out of three.

> By what statistics?

Number of defined or used macros per lines of Lisp code.

When you have a good language, you don't need a good IDE.

Alternatively, when you have a good IDE, you don't need a good language, freeing you to optimize other concerns like ecosystem. Not defending crappy languages, just saying that argument cuts both ways.

This is like saying that if you have sharp nails you do not need a hammer. (IDEs can be, and are, extremely helpful; even simple text editors like nano or SciTE try to include some of the features normally found in an IDE.)

When you have good memory, you don't need to google anything twice.

I've noticed a curious pattern: some brand new languages have communities expressing similar sentiment initially, but then if/when the language becomes popular and IDEs for it appear, you see quite a few people being excited about simple things that those IDEs can do (and could do for other languages decades ago), like debugging or code completion.

Any details about EFCore regrets? Too much magic, maybe?

At times too much magic, like queries mysteriously failing because you have a dangling "navigational property" without a database column. That one was a hell to debug.

At other times, too little control over how the query is translated to SQL, or DB features not being exposed. With time the frustration piles up..

EDIT: I'd be OK with a light-weight ORM, like stuff these columns into these fields of that class. Leave the rest to me. Though EFCore got a bit better with support for query types so I can map classes to views / stored procedures and do the "real" work there.

Compared to writing Sql stored procs it feels really hard to write something that spits out efficient sql.

You can't run (as far as I'm aware) things like query analyzers like I can with SQL to get execution plans.

It can be an absolute nightmare to debug. Like proper hell that where you can lose a day or so over something that ends up being stupidly simple.

I hate it and would choose just doing SQL with a plain ORM anyday over ever touching EF again.

When I was using it it also had poor support for immutable types. I imagine this has got better.

For any slow performing query you can always log the raw sql that is generated and run a normal explain like always.

You should also have database profiling tools in your disposal at all times, regardless if you use an ORM or just raw SQL.

ORMs are great when used sparingly and properly. For a bunch of normal crud operations they are great because they get rid of a lot of boilerplate code.

Also as with any ORM you can always drop down to raw sql in the situations that require it.

Reply on news.ycombinator.com