9 ms·
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 yo
by zvrba 8y ago
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.
- minsight 8y agoWhen you have a good language, you don't need a good IDE.
- andrewflnr 8y agoAlternatively, 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.
- Koshkin 8y agoThis 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.)
- zvrba 8y agoWhen you have good memory, you don't need to google anything twice.
- int_19h 8y agoI'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.
- lispm 8y ago> 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.
- Koshkin 8y ago> With Lisp you can add new syntax "With Lisp you can have any syntax, as long as it looks like Lisp."
- lispm 8y agoUnless 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
- int_19h 8y agoArguably that still looks like Lisp (i.e. it's a valid S-expression). But then you also have reader macros...
- lispm 8y agoWell, 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...
- zvrba 8y agoI 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.
- wozer 8y agoAny details about EFCore regrets? Too much magic, maybe?
- zvrba 8y agoAt 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.
- LandR 8y agoCompared 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.
- prakhunov 8y agoFor 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.