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

One of the Best Bits of Programming Advice I ever Got

objology.blogspot.com

Post reply on HN
Print view View original

41–50 of 94 posts

Re: One of the Best Bits of Programming Advice I ever Got

#41

Post by pestaa »

ctdonath wrote: post #13

Amazing how small linguistic changes can cause large semantic shifts. Comparable to the post's rule: in English, a few rules I've picked up are - avoid words ending in "ly" (suffix weakens concepts; suggestion from Stephen King) - never start a sentence with "I" and otherwise minimize its use - "but" negates everything that came before - avoid "to be" Any other such suggestions, in natural or artificial languages?

Is there a collection of suggestions from Stephen King? I love picking up small pieces of advice from respectable writers, and he is undoubtedly one of them.

Re: One of the Best Bits of Programming Advice I ever Got

#42

Post by philbarr »

lallysingh wrote: post #18
philbarr wrote: post #6

I generally accept the point made in the article, but what should I use in place of "Controller"? If using MVC I generally call it "ApplicationController" or "SimpleController". Should it be "Application", "ApplicationControl"...?

what do the controllers actually do? Synchronize state? Verify that constraints are met?

You're suggesting I call them "StateSynchronizer" or "ConstraintVerifier"?

Re: One of the Best Bits of Programming Advice I ever Got

#44

Post by morsch »

Kototama wrote: post #5

Even better: don't use objects at all. Use a functional programming language.

Well, he briefly touches on that: As long as you haven't joined in the Functional Monks in their Monasteries of Statelessness, programs are made of behavior and data.

I thought this was the best part of the essay (at least it made me smile).

Re: One of the Best Bits of Programming Advice I ever Got

#45

Post by dminor »

cousin_it wrote: post #33
microtonal wrote: post #21

Earlier quoted context omitted.

These methods often have side effects and that's their whole point. You don't need state and mutations, GUIs can also be programmed nicely using functional reactive programming (FRP). A nice description of FRP: http://stackoverflow.com/questions/1028250/what-is-functiona... Some examples of FRP in GUIs: http://www.haskell.org/haskellwiki/Reactive-banana/Examples

A simple counter that can be manipulated with two buttons "Up" or "Down": https://github.com/HeinrichApfelmus/reactive-banana/blob/mas... main = start $ do f counter] actuate network This doesn't look like good UI code to me. It seems to use too many advanced FP concepts that have nothing to do with the task at hand. Are you sure this is better than the OO approach? Why?

I don't know Haskell but it appears this code is just setting up a few GUI elements and defining two events and their effects.

What does good UI code look like?

Re: One of the Best Bits of Programming Advice I ever Got

#46

Post by JadeNB »

cousin_it wrote: post #33
microtonal wrote: post #21

Earlier quoted context omitted.

These methods often have side effects and that's their whole point. You don't need state and mutations, GUIs can also be programmed nicely using functional reactive programming (FRP). A nice description of FRP: http://stackoverflow.com/questions/1028250/what-is-functiona... Some examples of FRP in GUIs: http://www.haskell.org/haskellwiki/Reactive-banana/Examples

A simple counter that can be manipulated with two buttons "Up" or "Down": https://github.com/HeinrichApfelmus/reactive-banana/blob/mas... main = start $ do f counter] actuate network This doesn't look like good UI code to me. It seems to use too many advanced FP concepts that have nothing to do with the task at hand. Are you sure this is better than the OO approach? Why?

Aside from, possibly, the monadic notation—which is just that, a notation, an artefact of the implementation rather than of the idea—what are the advanced FP concepts here?

Re: One of the Best Bits of Programming Advice I ever Got

#48

Post by [deleted] »

pestaa wrote: post #40
mcherm wrote: post #15

I am unconvinced. Any absolute deserves close scrutiny, and "real nouns only" is an absolute. In this case, it fails my test. I find that many things I work with (especially huge Java libraries) tend to have convoluted and difficult-to-understand webs of classes with the most confusing pieces named things like "FooManager" or "FooController". So the author of this piece is reacting to a genuine excess. But Travis is…

I think there is a more fundamental misunderstanding in OO than bad naming convention. You are right about the usefulness of -er named objects -- but then again, are they really objects, or just functionality wrapped into a wrongly chosen language construct? Following your example, you could have implemented the strategy pattern into DatabaseConnection to freely inject functionality into the object when X happens. As…

[deleted]

Re: One of the Best Bits of Programming Advice I ever Got

#49

Post by diminish »

pestaa wrote: post #40
mcherm wrote: post #15

I am unconvinced. Any absolute deserves close scrutiny, and "real nouns only" is an absolute. In this case, it fails my test. I find that many things I work with (especially huge Java libraries) tend to have convoluted and difficult-to-understand webs of classes with the most confusing pieces named things like "FooManager" or "FooController". So the author of this piece is reacting to a genuine excess. But Travis is…

I think there is a more fundamental misunderstanding in OO than bad naming convention. You are right about the usefulness of -er named objects -- but then again, are they really objects, or just functionality wrapped into a wrongly chosen language construct? Following your example, you could have implemented the strategy pattern into DatabaseConnection to freely inject functionality into the object when X happens. As…

Most OO examples talk about commonly known external objects; yet programmers need to invent classes for objects too, because they are inventing and classifying an unclassified world. So they create Drivers, Managers etc; I agree with Travis to certain degree, but on the abstract object creation sometimes objects are identified by behavior rather than data; especially data manipulating objects; queue managers, drives ...

I sometimes think human language is not enough for programmers, and there must be an easier way to create non-existing objects; maybe similar to German language word creation.

Re: One of the Best Bits of Programming Advice I ever Got

#50

Post by microtonal »

cousin_it wrote: post #33
microtonal wrote: post #21

Earlier quoted context omitted.

These methods often have side effects and that's their whole point. You don't need state and mutations, GUIs can also be programmed nicely using functional reactive programming (FRP). A nice description of FRP: http://stackoverflow.com/questions/1028250/what-is-functiona... Some examples of FRP in GUIs: http://www.haskell.org/haskellwiki/Reactive-banana/Examples

A simple counter that can be manipulated with two buttons "Up" or "Down": https://github.com/HeinrichApfelmus/reactive-banana/blob/mas... main = start $ do f counter] actuate network This doesn't look like good UI code to me. It seems to use too many advanced FP concepts that have nothing to do with the task at hand. Are you sure this is better than the OO approach? Why?

This doesn't look like good UI code to me.

It replaces a mutable counter (that could potentially be changed anywhere in the program) by a definition of the counter that describes all possible changes it can have during its lifetime:

    counter = accumD 0 $ ((+1)
So, we have a counter that has an initial value of one. Over time, 1 can be added and 1 can be subtracted, namely when repsectively an eup or edown event occurs.

Being able to capture all possible 'state mutations' of a value in one assignment is good.

It seems to use too many advanced FP concepts that have nothing to do with the task at hand.

Which is a bit ironic, since the widgets are created in the IO monad with the 'do'-notation, which simulates imperative programming in Haskell :). A user interface should be designed with a WYSIWYG interface (Glade, Qt Designer) anyway, but that's besides the point.

Post reply on HN