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

Programming paradigms that change how you think about coding

brikis98.blogspot.com

Post reply on HN
Print view View original

21–30 of 206 posts

Re: Programming paradigms that change how you think about coding

#21

Post by lolo_ »

I think an underrated non-standard approach to programming is graphical programming. Though this approach doesn't seem to received significant uptake amongst professional programmers, there is an application called max [0] that is popular amongst musicians and artists and quite surprisingly powerful and effective.

There's an interesting article [1] on how Jonny Greenwood of Radiohead uses it extensively, in there you can see some examples of how it works - modules wired together visually.

I think there is a lot of potential for a really nice mix between text-based programming and graphical programming to work for general programming too.

[0]:http://cycling74.com/products/max/ [1]:http://thekingofgear.com/post/25443456600/max-msp

Re: Programming paradigms that change how you think about coding

#22

Post by mcherm »

cowls wrote: post #14

I read it, and how I think about coding remains the same as before I read it.

I don't think the idea was that reading the article would change how you thought about coding. I believe the point was that trying out these unusual programming paradigms would change how you thought. For the cases on his list that I have tried (declarative programming and Forth/Joy) I have found that to be true.

I would add object oriented programming (eg: smalltalk), macro programming (eg: lisp) and functional programming (eg: Haskell) to the list of things that change your thinking, but since most of the article's prospective audience has already heard of those I was happy that he stuck with paradigms that are LESS well known.

Re: Programming paradigms that change how you think about coding

#23

Post by simias »

GotAnyMegadeth wrote: post #8
simias wrote: post #6

Earlier quoted context omitted.

As I mentioned in my other comment Verilog and VHDL are "concurrent by default" since that's how hardware works anyway. If you want to experiment with them you don't need an FPGA, you can just start with a simulator such as Icarus Verilog[1] and a waveform viewer like gtkwave[2] and get a feel of the language. There are a bunch of tutorials on the net. [1] http://iverilog.icarus.com/ [2] http://gtkwave.sourceforge.ne…

Verilog is Turing complete and can do standard IO, so you probably don't even need a simulator/wave viewer.

Yeah, but using waveforms is half the fun! :)

Also, debugging verilog using only $display doesn't sound very fun...

Re: Programming paradigms that change how you think about coding

#24

Post by vkjv »

bru wrote: post #3

Some notes: - parallel and concurrent are 2 different things - the 'symbolic languages' definition seems off. Wikipedia puts it right: > symbolic programming is computer programming in which the program can manipulate formulas and program components as data So it's not "using graphs & such to program"

If you want concurrent by default, try an HDL. :)

Re: Programming paradigms that change how you think about coding

#25

Post by adwn »

simias wrote: post #2

In the "concurrent by default" section I would add the hardware description languages like VHDL and Verilog. Learning Verilog was an eye opening experience for me. It reminded me of the time I switched from unstructured BASIC to C when I was a kid. At first it seems complex and weird then suddenly it clicks and it all starts making sense.

... and then suddenly you realize what a horrible, horrible language it is. I'm not exaggerating, it isn't even well-suited for the domain it is mainly used for (i.e., designing digital hardware circuits). For example:

1) Synthesis/simulation mismatch: Your design might work in simulation but not in hardware, and vice versa. Often, this is due to X-value (representing unknown/invalid values) problems.

2) Signed datatypes: If you mix signed and unsigned values in an expression, the result is unsigned. So, if a is unsigned and has the value 4, b is signed and has the value -3, then

  (a * b)
will return 0 (false), while

  ($signed(a) * b)
will correctly return 1 (true). That's because signed datatypes are just an afterthought and weren't officially introduced until 2001, more than 15 years after the language's inception.

3) If an undeclared net is used in an module instantiation, the compiler silently creates a 1 bit net with that name. No error message, no warning. You can turn off that stupid behavior with a compiler directive, but you have to turn it back on at the end of your file, because otherwise its effects are active in all files compiled afterwards, and many third-party sources don't work correctly with this setting.

VHDL is also a bad language, but for very different reasons. And yet, alternative HDLs have a hard time getting traction, for various reasons and non-reasons.

Re: Programming paradigms that change how you think about coding

#27

Post by Xophmeister »

z3phyr wrote: post #7

Since 'functional' is not mentioned, I will assume that it is mainstream now!

The second paragraph:

> This is not your grandma's "functional programming will change the world!" blog post

Presumably because a lot of people write blog posts about how FP will change your approach. That's true but, while I wouldn't say FP is mainstream, it's well-known in circles such as ours; whereas the topics he mentions are much less run-of-the-mill. It makes for a more interesting and original read.

I notice he didn't include array-based languages, like APL and J. They were flavour of the week here a couple of weeks ago, but you still don't get much written about them and they would fit nicely in this article.

Re: Programming paradigms that change how you think about coding

#28

Post by Igglyboo »

adwn wrote: post #25
simias wrote: post #2

In the "concurrent by default" section I would add the hardware description languages like VHDL and Verilog. Learning Verilog was an eye opening experience for me. It reminded me of the time I switched from unstructured BASIC to C when I was a kid. At first it seems complex and weird then suddenly it clicks and it all starts making sense.

... and then suddenly you realize what a horrible, horrible language it is. I'm not exaggerating, it isn't even well-suited for the domain it is mainly used for (i.e., designing digital hardware circuits). For example: 1) Synthesis/simulation mismatch: Your design might work in simulation but not in hardware, and vice versa . Often, this is due to X-value (representing unknown/invalid values) problems. 2) Signed data…

I wholeheartedly agree.

I'm a CSE Major and I took a hardware design class last fall, we programmed and Xilinx FPGA using VHDL.

It was a huge change from everything I had learned before, I had no idea what a latch was and why it was bad to imply them. The thing that bothered me the most was the simulation/synthesis disconnect, the only efficient way to debug a program is by using the simulator because debugging it on the board takes a very long time when changing code. But even after you've debugged it in the simulation it might not even synthesize, which is an even harder "bug" to debug.

Re: Programming paradigms that change how you think about coding

#29

Post by swah »

adwn wrote: post #25
simias wrote: post #2

In the "concurrent by default" section I would add the hardware description languages like VHDL and Verilog. Learning Verilog was an eye opening experience for me. It reminded me of the time I switched from unstructured BASIC to C when I was a kid. At first it seems complex and weird then suddenly it clicks and it all starts making sense.

... and then suddenly you realize what a horrible, horrible language it is. I'm not exaggerating, it isn't even well-suited for the domain it is mainly used for (i.e., designing digital hardware circuits). For example: 1) Synthesis/simulation mismatch: Your design might work in simulation but not in hardware, and vice versa . Often, this is due to X-value (representing unknown/invalid values) problems. 2) Signed data…

I really enjoyed writing VHDL. I don't remember having problems with unknown values: we used only '0' and '1' for anything that's supposed to be synthesized.

(For testbenches, everything goes..)

     Value set is ('U','X','0','1','Z','W','L','H','-')
     TYPE std_logic IS ( 'U',  -- Uninitialized
                         'X',  -- Forcing unknown
                         '0',  -- Forcing 0
                         '1',  -- Forsing 1
                         'Z',  -- High    impedance
                         'W',  -- Weak    unknown
                         'L',  -- Weak    0
                         'H',  -- Weak    1
                         '-'); -- Don't care

     SIGNAL stdLogicName : STD_LOGIC:='0';
     stdLogicName

Re: Programming paradigms that change how you think about coding

#30

Post by notduncansmith »

jameshart wrote: post #10

This is a substantial piece of writing with information many here would find interesting; putting it behind a buzzfeed list style headline does it a disservice. One step short of calling it "Six weird programming paradigms that will blow your mind".

My first thought was "How this 36-year-old mom learned to code with one neat trick!"
Post reply on HN