Can productivity and maintainability be improved?
Yes, using source lines of code (SLOC) as a metric, both the Erlang
DM and DCC are less than a third of the size of the C++ counterpart
(Table 2). Moreover, much of the Erlang DCC is a reusable generic
server (Table 3). The reasons for the reduced programming effort are that
coding for the successful case saves 27%, high-level communications save
22%, and automatic memory management saves a further 11% (Tables 4
and 5). These productivity results are consistent with other measure-
ments [30], and with developer folklore.

void DataMobilityRxProcessor::processUnsupVer(void)
{
  MSG_PTR msg_buf_ptr;
  MM_DEVICE_INFO_MSG *msg_ptr;
  RETURN_STATUS ret_status;
  UINT16 msg_size;

  // Determine size of ici message
  msg_size = sizeof( MM_DEVICE_INFO_MSG);

  // Create ICI message object to send to DMTX so it sends a Device Info
  // message to Q1 and Q2 clients
  IciMsg ici_msg_object( MM_DEVICE_INFO_OPC, ICI_DMTX_TASK_ID, msg_size);
 
  // Retrieve ICI message buffer pointer
  msg_buf_ptr = ici_msg_object.getIciMsgBufPtr();
 
  // Typecast pointer from (void *) to (MM_DEVICE_INFO_MSG *)
  msg_ptr = (MM_DEVICE_INFO_MSG *)msg_buf_ptr;
 
  // Populate message buffer
  SET_MM_DEVICE_INFO_DEVICE_TYPE( msg_ptr, SERVER);
  SET_MM_DEVICE_INFO_NUM_VER_SUPPORTED( msg_ptr, NUM_VER_SUPPORTED);
  SET_MM_DEVICE_INFO_FIRST_SUP_PROTO_VERS( msg_ptr, PROTO_VERSION_ONE);
 
  // Send message to the DMTX task
  ret_status = m_ici_io_ptr->send(&ici_msg_object);
 
  // Check that message was sent successfully
  if (ret_status != SUCCESS)
  {
    // Report problem when sending ICI message
    sz_err_msg( MAJOR, SZ_ERR_MSG_ERR_OPCODE, __FILE__, __LINE__,
      "DataMobilityRxProcessor processUnsupVer: failure sending "
      " device info message to DMTX");
  }
}

void DataMobilityRxProcessor::processUnsupVer(void)
{
  // Create ICI message object to send to DMTX so it sends a Device Info
  // message to Q1 and Q2 clients
  IciMsg ici_msg_object( MM_DEVICE_INFO_OPC, ICI_DMTX_TASK_ID, sizeof( MM_DEVICE_INFO_MSG));
 
  // Retrieve ICI message buffer pointer
  MM_DEVICE_INFO_MSG * msg_ptr = (MM_DEVICE_INFO_MSG *)ici_msg_object.getIciMsgBufPtr();
 
  // Populate message buffer
  SET_MM_DEVICE_INFO_DEVICE_TYPE( msg_ptr, SERVER);
  SET_MM_DEVICE_INFO_NUM_VER_SUPPORTED( msg_ptr, NUM_VER_SUPPORTED);
  SET_MM_DEVICE_INFO_FIRST_SUP_PROTO_VERS( msg_ptr, PROTO_VERSION_ONE);
 
  // Send message to the DMTX task
  RETURN_STATUS ret_status = m_ici_io_ptr->send(&ici_msg_object);
 
  // Check that message was sent successfully
  if (ret_status != SUCCESS)
  {
    // Report problem when sending ICI message
    sz_err_msg( MAJOR, SZ_ERR_MSG_ERR_OPCODE, __FILE__, __LINE__,
      "DataMobilityRxProcessor processUnsupVer: failure sending "
      " device info message to DMTX");
  }
}

  // Send message to the DMTX task
  RETURN_STATUS ret_status = m_ici_io_ptr->send(&ici_msg_object);
 
  // Check that message was sent successfully
  if (ret_status != SUCCESS)
    // Report problem when sending ICI message
    throw IciMessageSendError(
      MAJOR, SZ_ERR_MSG_ERR_OPCODE, __FILE__, __LINE__,
      "DataMobilityRxProcessor processUnsupVer: failure sending "
      " device info message to DMTX");

void DataMobilityRxProcessor::processUnsupVer(void)
{
  // Create ICI message object to send to DMTX so it sends a Device Info
  // message to Q1 and Q2 clients
  IciMsg ici_msg_object( MM_DEVICE_INFO_OPC, ICI_DMTX_TASK_ID, sizeof( MM_DEVICE_INFO_MSG));
 
  // Retrieve ICI message buffer pointer
  MM_DEVICE_INFO_MSG * msg_ptr = (MM_DEVICE_INFO_MSG *)ici_msg_object.getIciMsgBufPtr();
 
  // Populate message buffer
  SET_MM_DEVICE_INFO_DEVICE_TYPE( msg_ptr, SERVER);
  SET_MM_DEVICE_INFO_NUM_VER_SUPPORTED( msg_ptr, NUM_VER_SUPPORTED);
  SET_MM_DEVICE_INFO_FIRST_SUP_PROTO_VERS( msg_ptr, PROTO_VERSION_ONE);
 
  // Send message to the DMTX task
  m_ici_io_ptr->send(&ici_msg_object);
}

E>void DataMobilityRxProcessor::processUnsupVer(void)
E>{
E>  // Create ICI message object to send to DMTX so it sends a Device Info
E>  // message to Q1 and Q2 clients
E>  IciMsg ici_msg_object( MM_DEVICE_INFO_OPC, ICI_DMTX_TASK_ID, sizeof( MM_DEVICE_INFO_MSG));
 
E>  // Retrieve ICI message buffer pointer
E>  MM_DEVICE_INFO_MSG * msg_ptr = (MM_DEVICE_INFO_MSG *)ici_msg_object.getIciMsgBufPtr();
 
E>  // Populate message buffer
E>  SET_MM_DEVICE_INFO_DEVICE_TYPE( msg_ptr, SERVER);
E>  SET_MM_DEVICE_INFO_NUM_VER_SUPPORTED( msg_ptr, NUM_VER_SUPPORTED);
E>  SET_MM_DEVICE_INFO_FIRST_SUP_PROTO_VERS( msg_ptr, PROTO_VERSION_ONE);
 
E>  // Send message to the DMTX task
E>  m_ici_io_ptr->send(&ici_msg_object);
E>}
E>

void DataMobilityRxProcessor::processUnsupVer(void)
{
  // Create ICI message object to send to DMTX so it sends a Device Info
  // message to Q1 and Q2 clients
  IciMsg<MM_DEVICE_INFO_MSG> msg(ICI_DMTX_TASK_ID);//MM_DEVICE_INFO_OPC скорей всего можно так или иначе получить из MM_DEVICE_INFO_MSG
 
  msg->deviceType(SERVER);
  msg->numVerSupported(NUM_VER_SUPPORTED);
  msg->firstSupProtoVers(PROTO_VERSION_ONE);
 
  // Send message to the DMTX task
  IO_CHECK(m_ici_io_ptr->send(&msg), MAJOR, "failure sending device info message to DMTX");
}

M>Это, в принципе, и есть результат второй работы — high level concurrency abstracts. Единственная причина, по которой они выбрали Эрланг для дальнейших разработок — это наличие таких абстракций в языке, его промышленное качество и наличие развитых библиотек. Если бы такие же абстракции были легкодоступны в С++, они бы выбрали С++. Если бы Glasgow Distributed Haskell был бы промышленного качества, они бы выбрали его

"...Исследование попыток внести изменения в принципы работы организации показывает, что пилотные проекты, адаптированные к конкретным условиям, практически всегда оказываются успешными, тогда как навязанные третьими лицами универсальные модели, основанные на обобщенном опыте, всегда проваливаются. Причина заключается в том, что проявление лидерских качеств, раскрытие творческого потенциала, обострение мотивации и рост ответственности всегда возрастают с появлением новых вызовов и сходит на нет при многократном повторении. Если что-то принято делать определенным образом и это никак нельзя усовершенствовать, задача становится менее захватывающей и менее интригующей, чем открытие совершенно новых, неизвестных ранее путей..."

E>Что мешало разработчикам C++ проектов сразу писать в таком стиле? C++ или человеческий фактор?

DgramSize = size(Dgram),
case Dgram of 
    <<?IP_VERSION:4, HLen:4, SrvcType:8, TotLen:16, 
      ID:16, Flgs:3, FragOff:13,
      TTL:8, Proto:8, HdrChkSum:16,
      SrcIP:32,
      DestIP:32, RestDgram/binary>> when HLen >= 5, 4 * HLen =< DgramSize ->
            OptsLen = 4*(HLen - ?IP_MIN_HDR_LEN),
            <<Opts:OptsLen/binary, Data/binary>> = RestDgram,
    ...
end.

G>DgramSize = size(Dgram),
G>case Dgram of 
G>    <<?IP_VERSION:4, HLen:4, SrvcType:8, TotLen:16, 
G>      ID:16, Flgs:3, FragOff:13,
G>      TTL:8, Proto:8, HdrChkSum:16,
G>      SrcIP:32,
G>      DestIP:32, RestDgram/binary>> when HLen >= 5, 4 * HLen =< DgramSize ->
G>            OptsLen = 4*(HLen - ?IP_MIN_HDR_LEN),
G>            <<Opts:OptsLen/binary, Data/binary>> = RestDgram,
G>    ...
G>end.
G>

void
submit_deliver_base_t::load(
    oess_1::io::istream_t & in )
{
    // Считываем обязательные параметры.
    in >> m_service_type
        >> m_source_addr_ton
        >> m_source_addr_npi
        >> m_source_addr
        >> m_dest_addr_ton
        >> m_dest_addr_npi
        >> m_dest_addr
        >> m_esm_class
        >> m_protocol_id
        >> m_priority_flag
        >> m_schedule_delivery_time
        >> m_validity_period
        >> m_registered_delivery
        >> m_replace_if_present_flag
        >> m_data_coding
        >> m_sm_default_msg_id
        >> m_short_message
        // Считываем необязательные параметры.
        >> opt_params();
}

void
packet_header_t::load( oess_1::io::istream_t & in )
  {
    in >> bits( IP_VERSION, 4 )
       >> bits( HLen, 4 )
       >> bits( SrvcType, 8 )
       >> bits( TotLen, 16 )
       >> bits( ID, 16 )
       >> bits( Flgs, 3 )
       >> bits( FragOff, 13 )
       ... и так далее...
  }

E>void
E>packet_header_t::load( oess_1::io::istream_t & in )
E>  {
E>    in >> bits( IP_VERSION, 4 )
       >>> bits( HLen, 4 )
       >>> bits( SrvcType, 8 )
       >>> bits( TotLen, 16 )
       >>> bits( ID, 16 )
       >>> bits( Flgs, 3 )
       >>> bits( FragOff, 13 )
E>       ... и так далее...
E>  }
E>

{ RestOfStream, [
   String1,
   << Number:7, Num2:9 >>,      здесь разбирается бинарис длиной в два байта
   String2,
   CompoundType ] } = parse( Stream, [ string, 2, string, my_module:my_parse_fun/1 ] ),

class X{
public int x;
public int y
}
//...
 X x = func();
 System.out.println(x.y);
 System.out.println(x.x);

{X, Y} = func(),
io:format("~p~n", X),
io:format("~p~n", Y).

К>class X{
К>public int x;
К>public int y
К>}
К>//...
К> X x = func();
К> System.out.println(x.y);
К> System.out.println(x.x);
К>

К>{X, Y} = func(),
К>io:format("~p~n", X),
К>io:format("~p~n", Y).
К>

К>Всё, конечно, есть только лишь сугубо моё мнение

func() -> {X, Y}

PDU pdu = parsePdu();
if( pdu.fieldOne == SOMETHING )
  // Здесь не известно, что потребуется process()-у из pdu.
  process( pdu );
...
void process( PDU pdu )
  {
    pdu.fieldThree() ...
  }

interface X{
    void log(String className, String methodName);
}
    
static class A implements X{
    public void log(String methodName, String className){
        
    }
}

{ RestOfStream, [
   String1,
   << Number:7, Num2:9 >>,      здесь разбирается бинарис длиной в два байта
   String2,
   CompoundType ] } = parse( Stream, [ string, 2, string, my_module:my_parse_fun/1 ] ),