[cryptonector]

Haskell and friends (Elm, ..) are fantastic, and perhaps the absolute best programming languages for software engineering. Except there's a small problem: Haskell is either write-only or read-only, depending on what you're looking at. That is, beautiful Haskell code is easy enough to read, but very very difficult to write, while working code you might write may not be very readable at all. Of course, that can happen in any language, but it seems to me that Haskell leads to that sort of situation very easily. On the other hand, the nice thing about Haskell is that once your code compiles it also probably does what you want it to :)

I would stay away from dynamically-typed languages (e.g., the Lisp and Scheme families) for software engineering. Dynamic typing means more run-time errors, which means a higher support burden, which is very much what you want to lower when you're a software engineer. And this is why I like Haskell: it's statically-typed. (The main appeal of Lisp is its macro system, really. Haskell gives you the sort of power that the Lisp macro system gives you anyways, though at the cost of more compile-time processing.)

If you can't use Haskell, then your best bets are Rust and C/C++.

In any case, a software engineer almost necessarily has to be familiar with all of these, and able to use any of them. You really want a strong foundation at the lowest layers (C, and even ASM) in order to work the full stack (libraries, applications, compilers, OS). You don't have to be a full stack engineer, naturally, but it sure helps to be able to adapt to working at different layers, and for this you need a strong conceptual foundation. A lot of layers in a full stack are written in C/C++, but web front-ends involve JavaScript, which is dynamically-typed, so you'll really need to be familiar with all of these, and that's just to get started.

[zeveb]

> I would stay away from dynamically-typed languages (e.g., the Lisp and Scheme families) for software engineering. Dynamic typing means more run-time errors

Note that Common Lisp has type declarations, which can move type errors from run-time to compile-time.

ML is a nice language family if you want something which is typed and participates in the Lisp mindset.

[cryptonector]

Yes, in principle you can have a language that lets you cover the gamut from statically- to dynamically-typed code. Indeed, Haskell is such a language...

But it's not just whether the language supports it, but also:

- what is the default - what is the cultural default - the extent of type inferencing - the extent to which the compiler can generate efficient code (i.e., pass around unboxed, naked values sans run-time typing information)

CL basically doesn't go far enough. To begin with, the default is dynamic typing, and IIRC it has no type inference, though at least CL compilers can do a fair bit optimization but you'll always pay the price of some type encoding in pointer/fixed-sized-integer values' low order bits.

[dreamcompiler]

> Note that Common Lisp has type declarations, which can move type errors from run-time to compile-time.

This is a dangerous assumption. The standard does not require that Common Lisp type declarations cause the compiler to detect type inconsistencies (although some implementations might be smart enough to do so in some cases). CL type declarations tell the compiler it can remove runtime checks. They are performance optimizations. If anything they decrease type safety.

[lispm]

> CL type declarations tell the compiler it can remove runtime checks.

That's not true. To tell the compiler that it can remove runtime checks you declare the optimization quality SAFETY to 0.

The Common Lisp standard does not specify what type declarations do and what the interpreter or compiler does with it.

Some compilers will never check types. Some will use them when SAFETY is low as assertions and remove runtime checks. Some will use them as assertions both at compile and runtime.

> They are performance optimizations. If anything they decrease type safety.

That depends on the implementation and the compiler switches.

In SBCL by default it INCREASES type safety:

  * (defun foo (a) (declare (type (integer 0 100) a)) (+ a 10))
  WARNING: redefining COMMON-LISP-USER::FOO in DEFUN

  FOO
  * (foo -1)

  debugger invoked on a TYPE-ERROR in thread
  #<THREAD "main thread" RUNNING {1001950083}>:
    The value
      -1
    is not of type
      (MOD 101)
    when binding A

  Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

  restarts (invokable by number or by possibly-abbreviated name):
    0: [ABORT] Exit debugger, returning to top level.

  (FOO -1) [external]
     source: (SB-INT:NAMED-LAMBDA FOO
                 (A)
               (DECLARE (TYPE (INTEGER 0 100) A))
               (BLOCK FOO (+ A 10)))
  0]

[dreamcompiler]

You're right. The standard leaves the interpretation of type declarations in CL up to the implementation. I was coming from a CCL perspective, and I should have checked the others.

In CCL:

  ? (defun foo (a) (declare (type (integer 0 100) a)) (+ a 10))
  FOO
  ? (foo -1)
  9

It's dangerous to assume the effect type declarations will have in CL. You have to test it.

[lispm]

Even in CCL it depends on the compiler settings:

  ? (declaim (optimize (safety 3)))
  NIL
  ? (defun foo (a) (declare (type (integer 0 100) a)) (+ a 10))
  FOO
  ? (foo "bar")
  > Error: The value "bar" is not of the expected type (MOD 101).
  > While executing: FOO, in process listener(1).
  > Type :POP to abort, :R for a list of available restarts.
  > Type :? for other options.
  1 > 

Type declaration added -> runtime safety increased...

Best read the implementation manual to see how it deals with optimization values and type declarations.

[yorwba]

Apparently the solution is to check the type before you declare it: https://stackoverflow.com/questions/32321054/using-declare-t...

I assume that most CL compilers are smart enough to optimize calls to such checking functions when they occur in a context where the type has already been declared. And you can probably write a macro to make it more convenient ...

[dreamcompiler]

There's no guarantee any given CL compiler will optimize such calls away. It would probably be considered wrong for the compiler to optimize them away. Remember that type declarations mean "don't check the type, ever." They do not mean "check the type at compile time" because CL never checks types at compile time.[1]

The technique in the example can defeat the purpose in simple cases (like the example) because type declarations removed runtime type checking and then you manually added it back in.

But it's a useful technique in cases such as an inner loop from which you remove type checking inside the loop, but move it out of the loop. This is an advanced CL technique. You have to be very careful about such things as adding 1 to a fixnum in the loop and possibly overflowing it, which is exactly what you have to care about in C.

[1] modulo certain compiler quirks and the use of compiler macros, which are an advanced technique.

[lispm]

> CL never checks types at compile time

SBCL, CMUCL, Scieneer CL do.

http://www.sbcl.org/manual/#Declarations-as-Assertions

[tscs37]

You can enforce type checks by writing your own.

LISP is rather extensible. People have written Haskell-like type systems for LISP with compile-time checks.

[SomeHacker44]

My opinion: If you can't use Haskell, you should definitely use a null-free language for safety in this day and age, which means Rust and definitely not C/C++.

[pjmlp]

Let me know when I can use Rust in Android, iOS and UWP with the same level of tooling and libraries support as C++.

I want to eventually use it, but not at the price of my productivity.

[cryptonector]

Yes, but that doesn't mean that you shouldn't be able to use C/C++ as needed -- sometimes you have no choice.

[SomeHacker44]

As always, pragmatism is good. If you are good at C/C++, use it and be happy and productive. I presumed the context of this discussion, however, was wanting to use Haskell for its particular benefits, and in my opinion the null-free nature is a key benefit, which would not be achieved by using C/C++.