4 ms·

The world is moving away from imperative programming altogether, towards functional programming. Pretty much anything that can be done with control flow can be

The world is moving away from imperative programming altogether, towards functional programming. Pretty much anything that can be done with control flow can be done with data flow instead, leaving fewer opportunities for error. Data flow is a higher level of abstraction that's cleaner and easier to reason about. If anyone reading this feels like trying something new, I encourage you to learn functional programming instead of finding creative-but-safe ways to use goto statements.

chefandy 3y ago
I found elixir a fun inroad to functional programming.
bobajeff 3y ago
>The world is moving away from imperative programming altogether, towards functional programming. I think functional programming has it's advantages and it's worth learning. But no, imperative programming is still the most popular will remain so for some time.
FpUser 3y ago
>"The world is moving away from imperative programming altogether, towards functional programming." Well, no. Rational world use what makes sense for particular situation. Not silver bullet du jour that suddenly solves everyone's problem (not).
delta_p_delta_x 3y ago
> The world is moving away from imperative programming altogether, towards functional programming. I think this opinion is a bit too coarse to describe current trends. Certainly, current best practices recommend things like std::ranges, Streams, or LINQ instead of old-school for-i (or even for-each) loops, with good reason: the pipeline and map-reduce paradigms are very useful to simplify and shorten code especially when the same operation is applied throughout a data structure. This sort of operation also tends to be embarrassingly parallel, easily lending itself to performance boosts with SIMD and vectorisation. However, pure, stateless functional programming is useful only in limited contexts, and implementations tend to rely on either a GC runtime, or resorting to copying and overwriting data structures to maintain correctness and safety at the (sometimes very large) expense of performance and efficiency. Purely stateless and functional programming is extremely hard to use in overwhelmingly stateful (read: video games) applications without things slowing down to unusable levels. Update an ECS tag? Write the entire state (which can be megabytes large) all over again—no in-place updates, after all. I feel most (non-functional) programming languages are adopting FP paradigms, but will maintain their imperative core by replacing old, leaky, and error-prone abstractions with data-flow paradigms (like the for-i -> map-reduce I mentioned above).
mhitza 3y ago
I was writing a parser for a reasonable subset of HTML5 (a full parser would actually need to include JavaScript parsing as well) and there are certain states where the same character must be reprocessed under a different parser state. [1] I wrote my parser by iterating character by character (foreach) and when reaching those states that need reprocessing I found it nicer to jump to a goto label at the start of the foreach, after the state variable was updated. If anyone is aware of a purely functional HTML5 compliant parser let me know, as I'd love to steal some ideas. [1] https://www.w3.org/TR/2011/WD-html5-20110113/tokenization.html https://www.w3.org/TR/2011/WD-html5-20110113/tokenization.ht... ctrl-f reconsume
- __s 3y ago
  https://jaspervdj.be/blaze https://jaspervdj.be/blaze Haskell
  - mhitza 3y ago
    That is a HTML generator library. And as I've said, for HTML5 compliance you need to also parse JavaScript, see second sentence here https://dev.w3.org/html5/spec-LC/parsing.html#overview-of-the-parsing-model https://dev.w3.org/html5/spec-LC/parsing.html#overview-of-th... A good first smoke-test for HTML5 supporting parsers is the following html fragment <input disabled> XML-like parsers (masquerading as having "HTML5 support") will fail if tags aren't closed or self-closing, and if there are attributes without an explicit value.
spamtarget 3y ago
I think the more correct statement would be: "The world is moving away from imperative programming altogether, towards declarative programming". IMO functional programming is just a special kind of imperative programming. I think real distinction is between "imperative/functional", where you describe how to do thing, and "declarative" where you don't care about the hows, but you specify what is the end result you want to see. For example: html (declarative) "I WANT A RECTANGLE AT THIS POSITION AND SIZE": <div style="top, left, height, width">, while imperative, you exactly tell the how, like <for i> then <for j> draw a pixel at that position i,j. Making drawing a box as functional does not make too much sense, because that is a task, which does not benefit from the functional paradigm, but it does helps a lot with cardinality and null checking problems when dealing with other kind of problems. I think it is already changing into this. Basically every single framework is one kind of declarative wrapper over an imperative language, or you can say every single function library makes the way how you work a little bit more declarative (like in the box drawing demo, you can just use function to write a box. I think in 20-30 years, in a very twisted way programming will be completely declarative by you telling an AI to write a code, first at a very low level of abstraction, but in time more and more complex ways. We'll see

chefandy 3y ago

I found elixir a fun inroad to functional programming.

bobajeff 3y ago

>The world is moving away from imperative programming altogether, towards functional programming. I think functional programming has it's advantages and it's worth learning. But no, imperative programming is still the most popular will remain so for some time.

FpUser 3y ago

>"The world is moving away from imperative programming altogether, towards functional programming." Well, no. Rational world use what makes sense for particular situation. Not silver bullet du jour that suddenly solves everyone's problem (not).

delta_p_delta_x 3y ago

> The world is moving away from imperative programming altogether, towards functional programming. I think this opinion is a bit too coarse to describe current trends. Certainly, current best practices recommend things like std::ranges, Streams, or LINQ instead of old-school for-i (or even for-each) loops, with good reason: the pipeline and map-reduce paradigms are very useful to simplify and shorten code especially when the same operation is applied throughout a data structure. This sort of operation also tends to be embarrassingly parallel, easily lending itself to performance boosts with SIMD and vectorisation. However, pure, stateless functional programming is useful only in limited contexts, and implementations tend to rely on either a GC runtime, or resorting to copying and overwriting data structures to maintain correctness and safety at the (sometimes very large) expense of performance and efficiency. Purely stateless and functional programming is extremely hard to use in overwhelmingly stateful (read: video games) applications without things slowing down to unusable levels. Update an ECS tag? Write the entire state (which can be megabytes large) all over again—no in-place updates, after all. I feel most (non-functional) programming languages are adopting FP paradigms, but will maintain their imperative core by replacing old, leaky, and error-prone abstractions with data-flow paradigms (like the for-i -> map-reduce I mentioned above).

mhitza 3y ago

I was writing a parser for a reasonable subset of HTML5 (a full parser would actually need to include JavaScript parsing as well) and there are certain states where the same character must be reprocessed under a different parser state. [1] I wrote my parser by iterating character by character (foreach) and when reaching those states that need reprocessing I found it nicer to jump to a goto label at the start of the foreach, after the state variable was updated. If anyone is aware of a purely functional HTML5 compliant parser let me know, as I'd love to steal some ideas. [1] https://www.w3.org/TR/2011/WD-html5-20110113/tokenization.html https://www.w3.org/TR/2011/WD-html5-20110113/tokenization.ht... ctrl-f reconsume

__s 3y ago
https://jaspervdj.be/blaze https://jaspervdj.be/blaze Haskell
- mhitza 3y ago
  That is a HTML generator library. And as I've said, for HTML5 compliance you need to also parse JavaScript, see second sentence here https://dev.w3.org/html5/spec-LC/parsing.html#overview-of-the-parsing-model https://dev.w3.org/html5/spec-LC/parsing.html#overview-of-th... A good first smoke-test for HTML5 supporting parsers is the following html fragment <input disabled> XML-like parsers (masquerading as having "HTML5 support") will fail if tags aren't closed or self-closing, and if there are attributes without an explicit value.

spamtarget 3y ago

I think the more correct statement would be: "The world is moving away from imperative programming altogether, towards declarative programming". IMO functional programming is just a special kind of imperative programming. I think real distinction is between "imperative/functional", where you describe how to do thing, and "declarative" where you don't care about the hows, but you specify what is the end result you want to see. For example: html (declarative) "I WANT A RECTANGLE AT THIS POSITION AND SIZE": <div style="top, left, height, width">, while imperative, you exactly tell the how, like <for i> then <for j> draw a pixel at that position i,j. Making drawing a box as functional does not make too much sense, because that is a task, which does not benefit from the functional paradigm, but it does helps a lot with cardinality and null checking problems when dealing with other kind of problems. I think it is already changing into this. Basically every single framework is one kind of declarative wrapper over an imperative language, or you can say every single function library makes the way how you work a little bit more declarative (like in the box drawing demo, you can just use function to write a box. I think in 20-30 years, in a very twisted way programming will be completely declarative by you telling an AI to write a code, first at a very low level of abstraction, but in time more and more complex ways. We'll see