3 ms·

Sounds like a terrible idea. Haskell is written for the Haskell compiler to understand. Specifications and designs should be written in a spoken language of c

Sounds like a terrible idea. Haskell is written for the Haskell compiler to understand. Specifications and designs should be written in a spoken language of choice and maths. That's where all the high-level modelling and problem domain specification should go. Programs, on the other hand, should be written with the greatest amount of mechanical sympathy for the target platform as is necessary to achieve your engineering goals. That means we should prefer to write directly in the language understood by the platform, usually some form of assember, but where this isn't practical we write in something a little bit more complex but staying as close to that lower bound of complexity as is possible. Before people start piling on and saying, "It's not the 80's anymore you dummy, we have spare cycles and plenty of memory," think about why I have a laptop with so much power under the hood and yet it still takes almost a minute to load up a spreadsheet... long enough that I get to stare, blankly, at a splash logo while my multi-core super-computer chugs along on the code designed in such a frame of mind. Engineering is applied maths. Specifications are blueprints not implementations.

chriswarbo 11y ago
> Programs, on the other hand, should be written with the greatest amount of mechanical sympathy for the target platform as is necessary to achieve your engineering goals. That means we should prefer to write directly in the language understood by the platform, usually some form of assember, but where this isn't practical we write in something a little bit more complex but staying as close to that lower bound of complexity as is possible. This, of course, depends on what your engineering goals are. If maintainability, extensibility, portability, amenability to cheap labor, etc. are considered as engineering goals then the opposite approach makes more sense: write all software as a handful of Prolog clauses and let the search algorithm do all the hard work; gradually move to lower levels if performance is unacceptable. The fact that you're waiting a minute for your spreadsheet to load shows that the performance is acceptable: you've accepted it. If it were unacceptable, you would be spending resources (money, or time to learn/transition-to/improve) on a faster alternative like sc.
- agentultra 11y ago
  > If maintainability, extensibility, portability, amenability to cheap labor, etc. are considered as engineering goals Those don't sound like goals they sound like principles. A goal is I want to create a web server that implements the HTTP 1.1 specification that can process a stream of N bytes per second over X simultaneous connections. There are metrics, tolerances, and limits to consider. A well engineered program that considers the data first and foremost can be easier to maintain since there are fewer abstractions to consider and reason through. It can be easier to debug since the program execution and memory layout are explicitly maintained. Performance is much easier to reason about for the same reasons. It is actually easier to refactor this kind of code in my experience. We have to get out this idea that our job as programmers is to write code. It's really about solving engineering problems with computers -- real processors with caches, memory channels, interrupts, and the whole nine yards. update: To wit, for those that know me, I actually write a lot of Python code. And Common Lisp. Doesn't change a thing; you can write a Python program that is ignorant of the underlying platform the interpreter was compiled for at your own risk... "write once, run everywhere," is a nice idea but a fiction in reality... a cleverly disguised, hand-wavey fiction.

chriswarbo 11y ago

> Programs, on the other hand, should be written with the greatest amount of mechanical sympathy for the target platform as is necessary to achieve your engineering goals. That means we should prefer to write directly in the language understood by the platform, usually some form of assember, but where this isn't practical we write in something a little bit more complex but staying as close to that lower bound of complexity as is possible. This, of course, depends on what your engineering goals are. If maintainability, extensibility, portability, amenability to cheap labor, etc. are considered as engineering goals then the opposite approach makes more sense: write all software as a handful of Prolog clauses and let the search algorithm do all the hard work; gradually move to lower levels if performance is unacceptable. The fact that you're waiting a minute for your spreadsheet to load shows that the performance is acceptable: you've accepted it. If it were unacceptable, you would be spending resources (money, or time to learn/transition-to/improve) on a faster alternative like sc.

agentultra 11y ago
> If maintainability, extensibility, portability, amenability to cheap labor, etc. are considered as engineering goals Those don't sound like goals they sound like principles. A goal is I want to create a web server that implements the HTTP 1.1 specification that can process a stream of N bytes per second over X simultaneous connections. There are metrics, tolerances, and limits to consider. A well engineered program that considers the data first and foremost can be easier to maintain since there are fewer abstractions to consider and reason through. It can be easier to debug since the program execution and memory layout are explicitly maintained. Performance is much easier to reason about for the same reasons. It is actually easier to refactor this kind of code in my experience. We have to get out this idea that our job as programmers is to write code. It's really about solving engineering problems with computers -- real processors with caches, memory channels, interrupts, and the whole nine yards. update: To wit, for those that know me, I actually write a lot of Python code. And Common Lisp. Doesn't change a thing; you can write a Python program that is ignorant of the underlying platform the interpreter was compiled for at your own risk... "write once, run everywhere," is a nice idea but a fiction in reality... a cleverly disguised, hand-wavey fiction.