DEV Community: codelitically_incorrect

What is the cleanest way to format the meta tag for CSP declarations

codelitically_incorrect — Fri, 25 Oct 2019 17:27:29 +0000

What is the cleanest way to format the meta tag for CSP declarations that make it readable and easy to add too? How do you do structure it? The reasoning behind this question is the awkward syntax W3C proposed, and with the strictness of syntax, it's easy to screw up your CSP policy that then fails silently.

Poll: What is your UI Framework of choice?

codelitically_incorrect — Sat, 28 Sep 2019 17:47:38 +0000

What is your framework of choice?
React, Vue, Angular, W3C WebComponents or Other?

UPDATE: Results as of 10/2/2019 (and counting)

Angular	React	Vue	Aurelia	W3C Web Components
3	5	3	3	1

How do you count your lines of code?

codelitically_incorrect — Tue, 24 Sep 2019 17:06:38 +0000

As Javascript developers, we have to wield several technologies to get a UI built. How do you go about counting your lines of code on a per screen basis?

Do you factor in css line-count and html line-count or do you look at your line-count as being pure Javascript logic?

Mixins in ECMAScript 6 - Awkward, inconvenient, powerful.

codelitically_incorrect — Tue, 03 Sep 2019 12:21:55 +0000

(UPDATE: I am really not sure about the state of proposals for 'mixins' in ECMAScript. The information below were snippets I got from another source in 2017. I do know we are able to support traits in ES6 by way of Object.assign(..) but I was hoping it would be keyworded-in as part of the class definition syntax for future ES. )

So you've heard that ECMAScript 6 will sport "Mixins". Some languages implement this feature as "Traits" or Shared Modules. The origin of the concept, I feel, was born in the language called SELF (a Sun Microsystems experiment, see: http://www.selflanguage.org/).

In a simple explanation, traits, or mixins, is a language feature allowing classes of objects to share a common set of behaviors we call methods -- or functions, perhaps even data properties. It is NOT inheritance, but some think of it as multiple inheritance. It is an arbitrary implementation for simple code reuse when inheritance does not make sense.

For example:
In building a game, the Character, Level or Weapon classes might all posses the ability to log messages to a console for debugging purposes, so a mixin called Loggable could be used to package up a few methods to be shared across the class hierarchy. This way, classes even though not related, might share this common trait. As you see, inheritance does not make sense logically or semantically. A Person is-not a Loggable. It does not sound right, it does not read right, it conflicts with the beauty of code and clarity.

here is the Ruby representation. It's a beauty.

module Loggable
   def log (msg)
      puts msg
   end
end

class Character include Loggable
   def jump
      log("jumped")
   end
end

class Sword < Weapon  include Loggable
   def animate_blade
      log("do sword animation");
   end
end

In Scala, It's a beauty:

class Sword extends Weapon with Loggable {
   def animate_blade() { 
      log("do sword animation")
   }
}

In ECMAScript 6:

var Loggable = Base => class extends Base {
  log(s) { }
};
class Weapon { }
class Sword extends Loggable(Weapon) { }

WTF?!!!!!
It gets ugly if you wanted 2 or more mix-ins:

class Weapon { }
class Sword extends Loggable(Localizable(Weapon)) { }

I don't know. It's powerful. Definitely not a beauty!

SELF: An ancient programming paradigm

codelitically_incorrect — Sun, 01 Sep 2019 13:58:32 +0000

"Look to the real world to combine simplicity with power."
-Randy B. Smith

Uniformity. Directness. Liveliness. - 3 core principals of the SELF environment that we don't normally see in the throng of modern era programming languages. There is Material Design Principals when considering User Interface design, but what if I told you that there was an ancient language which modeled the real world we live in?

Have a look at SELF. Since then, nothing like it has seen the light. It was ahead of it's time.

Truth about Functional Programming

codelitically_incorrect — Sun, 01 Sep 2019 13:43:13 +0000

(defun save-system (system)
           (let ((op 'asdf:monolithic-concatenate-source-op)
               (c (asdf:find-component system nil)))
           (asdf:operate op c)
           (asdf:output-file op c)))

There are 2 popular paradigms of programming for organizing code today. Object Oriented Programming and Functional Programming. Lately, more and more articles are springing up, pushing you to rethink objects (you know, the logical way to simulate real world people, places or things) and starting considering functional programming.

But you need to know the bias and the drawbacks. The bias is clear, it's an academic, geek-inspired, mathematical idea that is more whimsical than practical -- to show how uber and "Lispy" it looks, how smart one is at calculus, to adorn and lift up the ego about ones intellect.

That is the bias. An ugly splash of function calls embedded inside function calls, calling other functions and never destroying or creating state with side-effects, that is the benefit. An abstract, math-like mentality of algorithms dumped into your editor and executed in almost a primitive, cave-man style procedural flow. How horrible. We came a long way from that. Why not just go back to Assembly or C?

What is scary is that these geeks are pushing functional programming as the ideal paradigm for AI/Machine Learning. Reason about the devastation.

Object Oriented Programming is on the opposite side of the see-saw. It is a paradigm that organizes reality and thought-processes by simulating the real world using tangible objects. It's that clear. It's that logical. It models the world that we interact with. Objects are composed of objects, they communicate with each other, responsibilities are clear, dependencies are seen, system parts can be replaced, enhanced or debugged. There is nothing that cannot be simulated.

The drawbacks of functional programming is self evident:

It's awkward
mathematical
almost procedural in nature
ends up relying on objects eventually (contradiction of idea)
a syntax nightmare
harder to read
difficult to debug
complex to understand
not natural

Be careful.