Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Keep your source code SIMPLE

medium.com

Post reply on HN
Print view View original

61–70 of 77 posts

Re: Keep your source code SIMPLE

#61

Post by Multicomp »

c256 wrote: post #55
tempguy9999 wrote: post #45

Earlier quoted context omitted.

What is 'dorky' WRT functional programming?

Offhand, I’d say “too much theoretical math in the starting and middle stages of mastering the language.” Syntax that is based around/descended from APL. Lambda calculus prominently featured in the learning process. Things like that. It’s definitely a feel argument, and thus highly subjective.

I'm not a FP expert, but I do try to use FP as much as possible and yes, I agree that there is some serious dorkiness possible with certain PLs.

Anecdote, not data, but I've found that Rust, Erlang, and F# (if MS stack) tend to be in the sweet spot of expressive enough without drowning in symbols, without being as mushy as, say, Python/Ruby/pick something.

Re: Keep your source code SIMPLE

#62

Post by BoorishBears »

adamkl wrote: post #48
BoorishBears wrote: post #34

Earlier quoted context omitted.

Imo no Lisp variant can claim to not be in the "dorkier" side of things ("dorkier" being read as "hard to approach" in my eyes). I'd say Kotlin over Clojure.

I’d suggest you watch Rich’s talk “Simple made easy”. [1] It’s one of his main points that something like a language being “hard to approach” can be overcome by spending a little effort to learn it (as opposed to sticking with something like Kotlin just because its easy to pick up because it’s familiar). The benefits of learning the unfamiliar (in his case, he’s speaking specifically about Clojure) being that it allo…

Eh, I've used languages that were "hard to approach", one of my favorites (Erlang) is one of those (I use quotations especially because learning all of Erlang's syntax takes about a day).

This is a misapplication of the presentation really. It speaks to a level above selecting a language and is really about the design of systems.

Picking up Kotlin or Clojure is not "harder to approach" by virtue of what's provided in this context, it's harder because Clojure syntax uses parenthesis.

Like that's literally it.

Clojure with the same exact constructs represented with more C-like syntax would, at the level the presentation speaks to, allow the same level of simplicity.

I think a lot of developers feel "It looks funny" is not a fair critique of a useful tool, but just look at Erlang vs Elixr. I love Erlang, much more than I like Elixr, but Elixr gained mind share in large part because it's Ruby-like.

Cognitive overhead is lower working with a language that at least "looks like", what you're used to, and more developers know C-like languages, thus a language like Kotlin is "easier to approach" but necessarily "easier" in the way the presentation talks about

Re: Keep your source code SIMPLE

#63

Post by kevingoslar »

avmich wrote: post #35

"Keep the story going. Sign up for an extra free read. You've completed your member preview for this month, but when you sign up for a free Medium account, you get one more story." Sorry, can't read behind paywall.

Agreed, sorry for the paywall. Is there a better place to post such stories than Medium?

Re: Keep your source code SIMPLE

#64

Post by ISO-morphism »

BoorishBears wrote: post #62
adamkl wrote: post #48

Earlier quoted context omitted.

I’d suggest you watch Rich’s talk “Simple made easy”. [1] It’s one of his main points that something like a language being “hard to approach” can be overcome by spending a little effort to learn it (as opposed to sticking with something like Kotlin just because its easy to pick up because it’s familiar). The benefits of learning the unfamiliar (in his case, he’s speaking specifically about Clojure) being that it allo…

Eh, I've used languages that were "hard to approach", one of my favorites (Erlang) is one of those (I use quotations especially because learning all of Erlang's syntax takes about a day). This is a misapplication of the presentation really. It speaks to a level above selecting a language and is really about the design of systems. Picking up Kotlin or Clojure is not "harder to approach" by virtue of what's provided in…

> Clojure with the same exact constructs represented with more C-like syntax would, at the level the presentation speaks to, allow the same level of simplicity.

I don't think this is true. I think it would be easier for "most people," but definitely not simpler. Easy meaning close at hand, simple meaning one strand, one braid, independent, less context necessary. Clojure syntax is the AST of the program, right there in front of you, in literal notation. There are fewer special cases, fewer moving parts interacting. C syntax requires spinning up a virtual machine in your mind and executing multiple statements. C is easier because we've already spent the time and effort to familiarize ourselves with it, but it has more complexity. Compare a 954 line ANTLR grammar for C [1] with a 261 line Clojure grammar [2].

> Cognitive overhead is lower working with a language that at least "looks like", what you're used to, and more developers know C-like languages, thus a language like Kotlin is "easier to approach" but necessarily "easier" in the way the presentation talks about.

I would agree, using Rich's definitions of simple and easy, that Kotlin is easier for the majority of developers than Clojure. This follows immediately from the definition of easy.

> This is a misapplication of the presentation really. It speaks to a level above selecting a language and is really about the design of systems.

I would recommend Rich Hickey's talk "The Language of the System" [3]. The programming language(s) used are part(s) of the system and have an effect on its design. I don't think this is a misapplication of the "Simple made Easy" presentation, I think it hits the nail on the head.

[1] https://github.com/antlr/grammars-v4/blob/master/c/C.g4 [2] https://github.com/antlr/grammars-v4/blob/master/clojure/Clo... [3] https://www.youtube.com/watch?v=ROor6_NGIWU

Re: Keep your source code SIMPLE

#65

Post by BoorishBears »

ISO-morphism wrote: post #64
BoorishBears wrote: post #62

Earlier quoted context omitted.

Eh, I've used languages that were "hard to approach", one of my favorites (Erlang) is one of those (I use quotations especially because learning all of Erlang's syntax takes about a day). This is a misapplication of the presentation really. It speaks to a level above selecting a language and is really about the design of systems. Picking up Kotlin or Clojure is not "harder to approach" by virtue of what's provided in…

> Clojure with the same exact constructs represented with more C-like syntax would, at the level the presentation speaks to, allow the same level of simplicity. I don't think this is true. I think it would be easier for "most people," but definitely not simpler . Easy meaning close at hand, simple meaning one strand, one braid, independent, less context necessary. Clojure syntax is the AST of the program, right there…

I feel like this comment is throwing semantics in a blender and pouring it out into the shape you want... but I guess that's the thing about arguing semantics, it usually devolves to that...

So I guess I'll just keep my recommendation to Kotlin and you can keep your recommendation to Clojure

Re: Keep your source code SIMPLE

#66

Post by _y5hn »

throwaway35784 wrote: post #60
_y5hn wrote: post #25

Earlier quoted context omitted.

This is instructive to new coders, on how NOT to comment.

That's what was asked for! Why on earth is the comment that properly delivers the expectation being discussed as though it's wrong ?

I noticed the downvote and upvoted, plus acknowledged the anti-pattern. Sometimes intent is lost in text.

Re: Keep your source code SIMPLE

#67

Post by kevingoslar »

taberiand wrote: post #8

My feeling is these paradigms, SOLID and SIMPLE, boil down to basically: small objects, connected minimally, though interfaces. SIMPLE appears to be leaning even more towards the functional programming side of things; I think we should probably just get it over with and accept that composition of functions operating on immutable data structures is just the right way to go.

Please note that the article merely encourages the application of some of the best practices introduced by functional programming - strong typing and more mindfulness around mutability and side effects - into all forms of programming.

Functional programming as it exists today takes these ideas to a somewhat extreme form. That has its place and value, but as experience in the real world shows, as long as it feels so mathematical, it isn't everybody's cup of tea. Hopefully, over time we find more intuitively accessible abstractions for the really useful principles that functional programming is based on.

Re: Keep your source code SIMPLE

#68

Post by iLemming »

lostgame wrote: post #2

I couldn’t agree more. Also; keep it clean . Don’t over-comment, but comment.

Write a docstring for a function before you write the body of that function. Keep it short. Don't overthink it. At this point, it doesn't even have to be syntactically correct.

If, in a brief sentence, written in plain English (or any other language of your choice), you can't explain the idea, you need to "go back to the drawing board." Resist the urge writing it in a programming language before you can explain it in English.

When you're done writing the function, go back to the docstring, revise it; in some cases, you can even remove it.

The purpose of a docstring is to help humans to quickly scan the code and discern the meaning, the idea of the function without having to read its source. Like a trailer for a movie - it should give you the general idea, but not give away the implementation details.

Think about docstrings as "type annotations" for humans. We use types and type hints "to help the compiler understand our code better" because computers do not understand plain English, but very often, we have no empathy for fellow programmers.

Re: Keep your source code SIMPLE

#69

Post by iLemming »

BoorishBears wrote: post #34
ISO-morphism wrote: post #21

Earlier quoted context omitted.

This is Clojure. It's functional, but more as a side effect of focusing intently on simple, immutable, persistent data structures and their compositions. I'd strongly recommend looking into it, along with many of the presentations by its initial author Rich Hickey.

Imo no Lisp variant can claim to not be in the "dorkier" side of things ("dorkier" being read as "hard to approach" in my eyes). I'd say Kotlin over Clojure.

That is very, very far from the truth. You obviously haven't probably tried Clojure.

I think, among all the languages being actively used in the industry (in business, not academy), Clojure perhaps can be crowned as the simplest of them all. The ingenious of Rich Hickey was to design it the way that the essentials were made simple and complicated stuff either unnecessary or pushed onto the edges of the ecosystem.

Clojure can be learned à la carte - from the basics to more advanced things. Or if you want to dive straight into more difficult topics, you still can do it, and preliminaries would be minimal.

I can argue that Clojure is easier to learn than Kotlin, Python, Javascript, or Ruby. That is not a mere opinion - I know many people for whom Clojure was the very first language. And they tried to apprehend other PLs later, and it was a confusing and frustrating experience for them.

It is easy to start with Clojure. One simply needs to be less skeptical about things that people (mostly those who are unfamiliar with the language) criticize it for:

- They say, "It is hosted on JVM. JVM means Java, and I hate Java", and therefore ignore the fact that JVM is a very robust piece of tech, and you don't need to write any Java at all to use Clojure, you don't even really need to know Java.

- They say, "JVM has a slow startup time." But once you try Clojure's REPL (which is a real REPL, unlike in other, non-lispy languages), it becomes a non-issue.

- They say, "It is a Lisp, and parentheses look scary." But once you learn structural editing idioms, it becomes so frustrating to deal with all the punctuation in other languages.

- They say, "It is dynamically typed." But once you learn Clojure.Spec you may discover that you can do things with it, that most type-systems simply can't.

I encourage everyone to try to learn some Clojure, because it is fun.

Re: Keep your source code SIMPLE

#70

Post by iLemming »

BoorishBears wrote: post #65
ISO-morphism wrote: post #64

Earlier quoted context omitted.

> Clojure with the same exact constructs represented with more C-like syntax would, at the level the presentation speaks to, allow the same level of simplicity. I don't think this is true. I think it would be easier for "most people," but definitely not simpler . Easy meaning close at hand, simple meaning one strand, one braid, independent, less context necessary. Clojure syntax is the AST of the program, right there…

I feel like this comment is throwing semantics in a blender and pouring it out into the shape you want... but I guess that's the thing about arguing semantics, it usually devolves to that... So I guess I'll just keep my recommendation to Kotlin and you can keep your recommendation to Clojure

> I feel like this comment is throwing semantics in a blender and pouring it out into the shape you want

I don't think it is, though. But it is clear that you are arguing with absolute confidence about a thing you have never given a heartfelt attempt to try first. You are debating like a medieval 13th-century mathematician that Roman numerals are elegant and more comfortable to understand, and people been using them for centuries and no need for this Indo-Arabian numeral non-sense that Leonardo, son of Bonacci so passionately keeps talking about.

I don't want to sound patronizing (I guess I'm already are, although not intentionally), but let me give you an advice - never trust your inner skepticism, fight it, dig for the answer - why are you so skeptical about it. Progress pushed forward by individuals who continuously challenge their beliefs. And from what I can see - you are not a mere consumer of progress, you too, do want to be at the front line where it is being made.

Post reply on HN