Một hệ thống có thể được điều khiển 100% dữ liệu?

Sếp mới của tôi đã làm việc trong dự án này trong nhiều năm. Tôi mới đến đây được vài tuần, nhưng tôi không chắc là có thể. Anh ấy muốn thiết kế một hệ thống "điều khiển 100% dữ liệu".

Vì vậy, nếu chúng tôi đưa vào đủ dữ liệu, chúng tôi có thể xác định và tạo bất kỳ ứng dụng nào. Ít nhất tôi đã quản lý để khiến anh ấy thừa nhận một số thứ như người dùng hoặc ứng dụng nên có các giá trị được xác định trước, nhưng anh ấy thích khái niệm cấu trúc của hệ thống, giao diện người dùng và logic đều được lưu trữ dưới dạng dữ liệu.

Có một số bản demo của những điều đơn giản và về cơ bản, ông đã khám phá ra một số ý tưởng đơn giản về lập trình hướng đối tượng và hệ thống mẫu cơ bản của bạn, nhưng tôi nghĩ rằng tổng thể mục tiêu này có thể thực sự là không thể.

Tôi không biết làm thế nào bạn có thể xác định logic bằng cách sử dụng dữ liệu mà không làm cho hệ thống trở nên phức tạp đến mức bạn đang thực hiện lập trình thực tế.

Tôi nghĩ về mặt lý thuyết không phải là vì điều diễn giải dữ liệu cuối cùng cần phải trở nên hoàn chỉnh để mô tả ứng dụng nên bạn chỉ chuyển vấn đề lên một cấp độ cao hơn để không có lợi ích ròng.

Là một ứng dụng hướng dữ liệu 100% như vậy có thể?

Sếp của bạn nên đọc tác phẩm này: Bad Carma: Dự án "Tầm nhìn", một câu chuyện cảnh báo về hiệu ứng nền tảng bên trong hoặc hiệu ứng hệ thống thứ hai.

trừu tượng

Những người trong chúng ta làm việc trong Công nghệ thông tin (CNTT) đều đã từng tham gia một dự án mà điều gì đó quan trọng là không đúng. Chúng tôi biết điều đó, hầu hết mọi người đều biết điều đó, nhưng không ai có thể đặt ngón tay của mình vào vấn đề một cách thuyết phục.

Câu chuyện này là về một dự án CNTT như vậy, thất bại ngoạn mục nhất tôi từng trải qua. Nó đã dẫn đến việc sa thải hoàn toàn một bộ phận CNTT cỡ trung bình, và cuối cùng dẫn đến sự phá hủy một công ty đang phát triển trong một ngành công nghiệp đang phát triển. Công ty, mà chúng tôi sẽ gọi là "Upstart", là một doanh nghiệp truyền hình thuê bao thành công và có lợi nhuận.

Dự án xảy ra vào đầu những năm 1990, và nó là một ứng dụng nhập đơn hàng và dịch vụ khách hàng được xây dựng tùy chỉnh, gần giống với những gì hiện được gọi là Quản lý quan hệ khách hàng hoặc CRM. Các chức năng cốt lõi của hệ thống bao gồm:

• Nhập đơn hàng và hàng tồn kho
• Dịch vụ khách hàng, bàn trợ giúp
• Sổ cái, các khoản phải thu, hóa đơn và các tài khoản phải trả

Ứng dụng này được gọi là "Tầm nhìn" và cái tên vừa là lời hứa chính thức được tuyên bố cho Upstart cũng như một cái gật đầu tự hợp tác với kiến ​​trúc sư của nó. Ứng dụng này rất sáng tạo, trong đó nó được xây dựng đủ linh hoạt để phù hợp với mọi thay đổi trong tương lai đối với doanh nghiệp. Không chỉ bất kỳ thay đổi có thể thấy trước trong tương lai cho doanh nghiệp, mà hoàn toàn là bất kỳ thay đổi nào đối với doanh nghiệp, dưới mọi hình thức. Đó là một tuyên bố khá đáng chú ý, nhưng Vision được dự định là ứng dụng cuối cùng được xây dựng. Nó đã đạt được sự linh hoạt hoàn toàn này bằng cách hoàn toàn dựa trên dữ liệu, cung cấp sự trừu tượng hóa vô hạn và sử dụng các kỹ thuật lập trình hướng đối tượng là tiên tiến vào thời điểm đó.

Giống như nhiều dự án như vậy đặt ra để tạo ra một ứng dụng quan trọng, nỗ lực phát triển kéo dài hai năm, dài hơn khoảng một năm so với dự kiến ​​ban đầu. Nhưng điều đó có thể chấp nhận được, bởi vì đây là ứng dụng sẽ tồn tại mãi mãi, thích ứng với mọi yêu cầu trong tương lai, mang lại lợi tức đầu tư không giới hạn (ROI) không giới hạn. Khi ứng dụng cuối cùng đã "sống", gần như tất cả mọi người trong công ty đã đầu tư rất nhiều vào nó, theo nghĩa đen là số phận của công ty đã cản trở thành công của nó.

Tuy nhiên, trong trường hợp xảy ra sự cố toàn bộ dự án, các ứng dụng quan trọng điều hành hoạt động kinh doanh cốt lõi của các tập đoàn đa quốc gia không được phép sử dụng loại ngọn lửa nhanh được thể hiện bởi hàng ngàn công ty "dot-com" trong kỷ nguyên bong bóng Internet. Trong vòng một tháng, Vision sẽ "sống", rõ ràng với tất cả mọi người trừ những người nặng nề nhất trong quá trình xây dựng rằng đó là một thất bại.

Xem thêm

http://en.wikipedia.org/wiki/Inner-pl platform_effect

Câu trả lời là có, có thể tạo ra một hệ thống hoàn toàn dựa trên dữ liệu và vâng, đó thường là một ý tưởng thực sự tồi tệ.

Một chương trình điều khiển dữ liệu đầy đủ là một chương trình trong đó tất cả logic và cấu hình được xử lý bởi các giá trị được lưu trữ theo cách mà trong bối cảnh khác, chúng sẽ được coi là dữ liệu. Có nhiều sản phẩm 4GL được sản xuất trong những năm 1980 cung cấp khả năng tạo báo cáo, biểu mẫu, bảng và logic bằng cách sử dụng các mục dữ liệu được nhập vào nhiều biểu mẫu, được lưu trữ trong bảng và có thể truy cập thông qua báo cáo. Tôi đã từng đề cập đến các hệ thống như "vẽ bằng số" nhưng tôi thấy nó giờ đã được biết đến như là hiệu ứng "hệ thống bên trong". Tên hay.

Những người tạo ra các hệ thống này đang cố gắng (dù họ có biết hay không) để tạo ra một ngôn ngữ lập trình mới. Vì họ không có kỹ năng, họ làm điều đó rất tệ. Từ quan điểm của JVM / CLR, một chương trình Java / C # được biên dịch chỉ đơn giản là dữ liệu. Trong trường hợp này nó đã được thực hiện tốt. Trong cả hai trường hợp, lập trình viên là cần thiết để sử dụng ngôn ngữ, bất kể đó là gì.

Có một cách cụ thể để thực hiện công việc này, mà tôi biết. Bạn xây dựng bộ xương của từng thành phần bạn cần: biểu mẫu, báo cáo, bảng, v.v. Bạn cung cấp một cơ chế để định cấu hình các phần khác nhau của các thành phần này bằng cách đặt các mục dữ liệu. Đối với một tập hợp các tính năng được chọn, bạn đưa ra quyết định và đóng băng chúng vào hệ thống, và từ chối cụ thể khả năng định cấu hình các tính năng đó.

Bạn cũng thực hiện một ngôn ngữ có khả năng mã hóa các hoạt động logic. Đề nghị của tôi là sử dụng một ngôn ngữ hiện có như lua hoặc có thể là Python. Bạn nhúng các đoạn mã này bất cứ nơi nào cần hoạt động logic.

Bằng cách này, bạn giảm đáng kể số lượng văn bản cần thiết để thực hiện từng biểu mẫu, báo cáo, bảng, v.v. Hệ thống dường như được điều khiển dữ liệu, nhưng chỉ đến một điểm.

Tại thời điểm này, bạn vừa thực hiện một 4GL mới. Nếu bạn xảy ra làm điều này thành công, xin vui lòng cho tôi biết. Hầu hết mọi người thất bại tháo dỡ. Tôi sẽ là người đầu tiên chúc mừng thành tích của bạn.

Tôi nghĩ rằng bạn về cơ bản là chính xác. Một thời gian chạy ngôn ngữ đã là một hệ thống điều khiển dữ liệu hoàn toàn linh hoạt. Nó lấy một phần dữ liệu (chương trình) và sử dụng nó để xác định cách nó sẽ hoạt động trên dữ liệu khác. Nó thậm chí có thể có một lược đồ nhiều người dùng để lưu trữ mã để sử dụng lại bởi các chương trình khác (từ đường dẫn bao gồm đến quản lý cài đặt thích hợp).

"Ngôn ngữ kịch bản", nói một cách đại khái, là thời gian chạy ngôn ngữ trong đó đầu vào mã này có thể đọc được. Một trình biên dịch đặt thêm một bước giữa người dùng và thời gian chạy. Các ngôn ngữ "Trò đùa" như Malbolge và APL không cần phải có thể đọc được bằng con người dưới mọi hình thức. Nhưng tất cả đều giống nhau ở một cấp độ và dù sao con người cũng có thể đọc được không có nghĩa là tất cả người dùng tiềm năng đều có kỹ năng đọc hoặc viết nó, hoặc có thể được dự kiến ​​sẽ phát triển chúng.

Có nhiều lý do tại sao bạn thường không phơi bày thời gian chạy ngôn ngữ trực tiếp cho người dùng cuối. Cái chính là loại bỏ tính linh hoạt làm tăng sự tiện lợi.

Nếu tôi muốn gõ một bài SO, tôi chỉ muốn gõ nó. Tôi hoàn toàn có khả năng thay vì viết chương trình C ++ để xuất nó, nhưng tôi sẽ không sử dụng trình duyệt web tiếp xúc với trình chỉnh sửa chương trình C ++ thay vì hộp văn bản thông thường. Những người không biết C ++ không chỉ không sử dụng trình duyệt, họ không thể.

Nếu tôi muốn định cấu hình một số tham số nghiệp vụ nhất định thì tôi không nhất thiết phải thực hiện điều đó bằng ngôn ngữ đặc tả Turing-Complete và ngay cả khi tôi đã làm điều này có lẽ không thể phân biệt được với "mã hóa cứng" các tham số kinh doanh tương tự đó trong bất kỳ chương trình nào khác ngôn ngữ. Bạn vẫn cần xem xét những gì bạn viết có nghĩa là những gì bạn muốn nó có nghĩa. Bạn vẫn cần kiểm tra những thay đổi đó là chính xác. Nghĩa là, bạn vẫn cần kỹ năng lập trình cho bất kỳ công việc mà đều là phòng không tầm thường và không lường trước bởi một người không có kỹ năng lập trình người chuẩn bị một chuyên ngành phụ hệ thống ( "ứng dụng") để bạn có thể cấu hình ( "sử dụng").

Vì vậy, nếu bạn chuẩn bị bắt tay vào một hệ thống dựa trên dữ liệu 100%, có thể làm bất cứ điều gì được cung cấp đúng dữ liệu, bạn có hai câu hỏi để tự hỏi:

1. Chúng ta đang kinh doanh trong việc phát minh ngôn ngữ lập trình, hay chúng ta nên?
2. Ngôn ngữ lập trình mới của chúng tôi sẽ tốt hơn (cho mục đích của chúng tôi) so với ngôn ngữ chúng tôi đã có và chúng tôi sẽ hỗ trợ và phát triển ngôn ngữ đó khi cần?

Đôi khi các câu trả lời là có, và bạn viết một ngôn ngữ cụ thể theo tên miền. Hoặc thậm chí là một ngôn ngữ lập trình đa năng thực sự nếu bạn là Sun / Microsoft / Stroustrup / van Rossum / nhiều người khác. Đôi khi các câu trả lời là không và bạn có hiệu ứng "nền tảng bên trong" - sau nhiều nỗ lực và thử nghiệm và lỗi bạn kết thúc với một cái gì đó. Nếu bạn may mắn, nó chỉ kém hơn một chút so với ngôn ngữ lập trình mà bạn đã viết nó và không dễ sử dụng hơn.

Một số ngôn ngữ khó hơn hoặc dễ sử dụng hơn các ngôn ngữ khác, đặc biệt nếu chúng chuyên về một mục đích như R thì một số người dùng sẽ thấy chúng dễ dàng hơn nhiều. Những gì bạn có thể sẽ không làm, là làm cho các ứng dụng chung lập trình dễ dàng hơn về cơ bản. Tại bất kỳ thời điểm nào, có thể có một số người / tổ chức trên thế giới có tiềm năng để làm điều đó, nhưng ông chủ / công ty của bạn phải thành thật xem xét liệu có bao gồm anh ấy / bạn hay không.

Có một mẹo thường được sử dụng cho các trò chơi, đó là phơi bày các ràng buộc Lua cho công cụ trò chơi. Điều này cho phép các nhà thiết kế lập trình bằng một ngôn ngữ tương đối dễ dàng, nhưng vẫn thu hút được một lập trình viên "thực sự" khi cần thiết cho hiệu suất hoặc truy cập chức năng cụ thể của động cơ hoặc nền tảng. Các tập lệnh Lua kết quả là "dữ liệu" khi có liên quan đến động cơ. Tất cả chúng không cần bao gồm phần lớn những gì bạn gọi là "logic" trái ngược với dữ liệu cấu hình và thường thì chúng xác định khá rõ tất cả cốt truyện và môi trường, nhưng không phải toàn bộ trò chơi. Đây không phải là 100% dữ liệu và nó chắc chắn không phải là 100% không có lỗi, nhưng đó là một sự thỏa hiệp thực tế thú vị.

Tôi đã làm việc tại một công ty nơi đây là mục tiêu. Đoạn mã SQL được lưu trữ trong các bảng cơ sở dữ liệu, đọc trong thời gian chạy và được thực thi. Hiệu suất là khủng khiếp, như bạn có thể tưởng tượng, và lỗi là thường xuyên. Nó cũng không thể gỡ lỗi, không có dấu vết ngăn xếp hoặc bất cứ điều gì khác làm cho cuộc sống dễ dàng.

"Lập trình dựa trên dữ liệu" là kết quả của sự thiếu hiểu biết cơ bản về những gì chúng ta đang làm, với tư cách là lập trình viên; bất kỳ dữ liệu nào có khả năng thực hiện thuật toán xảy ra thực sự là "lập trình", ngay cả khi bạn bằng cách nào đó quản lý để trộn lẫn (mangle?) hai ý tưởng trong giao diện người dùng. Bây giờ, điều này không có nghĩa là bạn không thể kết hợp hai ý tưởng từ hướng khác, để tất cả mã là dữ liệu; đó là tiền đề đằng sau lisp, được kích hoạt bởi tính đồng âm của nó và được khai thác bởi hệ thống vĩ mô của nó. Vâng, những khái niệm này nghe có vẻ giống nhau, nhưng ý nghĩa và ứng dụng của chúng rất khác nhau trong thực tế.

Ngoài ra, điều này có thể là biên tập, nhưng những nơi tôi gặp phải muốn lập trình "hoàn toàn dựa trên dữ liệu" thực sự không coi trọng các lập trình viên của họ. Họ nghĩ về mã như một trung tâm chi phí, một cái gì đó được thuê ngoài hoặc bỏ qua.

Bạn có nghĩa là ông chủ của bạn muốn bạn viết này:

[
  {
    "statement": "Assignment ",
    "variable": "App",
    "value": {
      "type": "Function",
      "arguments": [],
      "function-body": [
        {}
      ]
    }
  },
  {
    "statement": "Assignment",
    "variable": "App.prototype.action",
    "value": {
      "type": "Function",
      "arguments": [
        "data"
      ],
      "function-body": [
        {
          "statement": "Call",
          "function-name": "console.log",
          "arguments": [
            "data"
          ]
        }
      ]
    }
  }
]

Để tạo điều này:

var App = function () {};
App.prototype.action = function ( data ) {
    console.log( data );
}

Cái đầu tiên là JSON và cái thứ hai là JavaScript .

Thanh toán bù trừ

Tôi nghĩ về mặt lý thuyết không phải là vì điều diễn giải dữ liệu cuối cùng cần phải trở nên hoàn chỉnh để mô tả ứng dụng nên bạn chỉ chuyển vấn đề lên một cấp độ cao hơn để không có lợi ích ròng.

Là một ứng dụng hướng dữ liệu 100% như vậy có thể?

Đây là nơi tôi mới bắt đầu. Với câu trả lời của tôi, tôi đang cố gắng đồng ý với bài viết gốc rằng: Có thể, nhưng bạn đã đúng, nó sẽ chỉ chuyển vấn đề lên một cấp độ cao hơn mà không có lợi ích [rõ ràng] .

Bạn có thể lập luận một cách thuyết phục, tôi nghĩ rằng, bất kỳ ứng dụng trình duyệt web nào cũng có thể được coi là 100% dữ liệu được điều khiển ¹ .

Tất nhiên, điều đó không làm cho việc xây dựng các ứng dụng trên web trở nên đơn giản hoặc dễ dàng hơn, thực tế nó làm cho chúng khó hơn nhiều.

Nói với sếp của bạn rằng anh ta đang phát minh lại trình duyệt web và cuối cùng anh ta sẽ phải phát minh lại JavaScript để xây dựng bất cứ thứ gì phức tạp hợp lý.

¹ Vâng, nếu bạn bỏ qua các plugin, JavaScript và HTML5 .

Đúng. Theo như tôi biết, một hệ thống như Mathematica , được gọi là ngôn ngữ lập trình mạnh mẽ nhưng về cơ bản là vỏ, được xây dựng dựa trên ý tưởng tương tự mà ông chủ của bạn mong đợi. Wolfram Mathematica hiện đang trở nên đủ phức tạp để có thể dễ dàng thực hiện nhiều nhiệm vụ tính toán.

Dữ liệu điều khiển là một khái niệm. Nếu chúng ta lập trình viên sẽ thao tác dữ liệu một cách đơn giản, chúng ta cần một lớp vỏ dễ dàng cho chúng ta chơi với dữ liệu. Hãy cố gắng hiểu rằng một khi chúng ta bắt đầu nói về việc học một ngôn ngữ lập trình dựa trên cú pháp, chúng ta thực sự đang học giao diện ứng dụng hoặc đơn giản là vỏ của nó. Nếu chúng ta hiểu vỏ, chúng ta có thể lái các chương trình.

Đối với 100% dữ liệu được điều khiển, nếu trình biên dịch hoặc trình thông dịch có thể hiểu được trình bao, tính toán được điều khiển. Nếu dữ liệu có cấu trúc cơ bản giống như vỏ hoặc giao diện có, dữ liệu cũng có thể được điều khiển bởi trình biên dịch hoặc trình thông dịch. Tôi nghĩ Mathematica là một lời giải thích tốt cho lý do tại sao tôi trả lời bạn với một cái có.