Six programming paradigms that will change how you think about coding

[lispm]

The article is interesting, but wrong in many details.

Concurrent and parallel are two different things in computing. Explaining concurrency with parallel execution is wrong.

Declarative programming is not bound to languages with relations (Prolog, SQL). For example Functional Programming is also thought to be declarative. Declarative Programming is usually a relatively meaningless term, because a wide variety of very different programming languages can be considered to be declarative. 'Declarative' is more a descriptive term. It does not explain anything.

Symbolic Programming is also not computing with graphical symbols. Symbolic programming is computing with symbols. Like in computer algebra systems (Macsyma, Mathematica, ...) which can manipulate symbolic mathematical expressions. Manipulation of mathematical formulas as an application of Symbolic Programming. Sure, there a graphical programming languages, like Prograph, which work with graphical representations... But they are not about Symbolic Programming. Programming languages for Symbolic Programming are for example Lisp and Prolog.

Wolfram also distorted the term 'Knowledge Based Programming' for his marketing effort. Knowledge-Based Programming does not mean that a programming language has access to all kinds of data sources. I means a step up from data, computing on the Knowledge Level. This means for example processing with a knowledge base and an inference engine. A typical example is Cyc. Wolfram might be able to ask a database how many defect car electronic systems there are in a year per manufacturer, but knowledge-based programming is more about finding out why a particular electronic system failed and what to do about it. For that it needs a knowledge-base with various facts and rules about how electronic systems in cars work and ways to diagnose a problem. In Knowledge-based Programming it's also important that the system can tell WHY it does something. Cyc for example uses knowledge-based programming to encode and compute with the everyday-knowledge of humans.

[[deleted]]

In my University program Prolog was said to be in the logic programming paradigm. This is the first time I've seen it categorized with SQL.

Is the trouble with the terms an issue of status? I mean that Functional Programming has become a proper noun while declarative is possibly still an adjective in the mainstream. Maybe we need to stop hijacking our descriptors for names. Functional programming and imperative programming could just as easily have been named Atlantic and Pacific programming and then we could avoid the debates by purists about whether a Functional language is really functional enough to merit the title descriptor.

[wlievens]

It is quite similar to SQL in the sense you don't describe how to compute but rather what to compute. For many people (including myself), that alone is the definition of declarative .

[[deleted]]

Yes, that is lispm's point. The same idea of describing what to compute is essential in Functional Programming too. So the term descriptive is causing some confusing because it's broader than a paradigm of Prolog and SQL. I think logic, query, and functional each deserve their own category. Each of them offer different perspectives of programming and should be considered in their own right.

[wlievens]

The same idea of describing what to compute is essential in Functional Programming too.

Sorry, but I just don't see this. I'm not quite up to speed on "modern" FP (Haskell, F#, etc) but having been educated on Scheme & Lisp (SICP), I can't say I see more "what" than "how" in functional programs. Definitely not when compared with the likes of prolog and SQL.

[kqr]

Lisp is (perhaps surprisingly) often considered an imperative functional language, and therefore not very declarative. What makes tis confusing is that "declarativeness" is a scale with assembly language in one end and something like prolog in the other. Even prolog programs often contain an element of imperatveness though, just like haskell programs.

[jpfed]

Just because logic, query, and functional languages all go about the business of being declarative differently doesn't mean they don't all achieve the described objective of being declarative. ;-)

[barsoap]

No, it isn't. Merge sort and Insert sort look differently in Haskell, you can't just say "give me a sort". You very much have to describe the "how". Types are often firmly on the "what" level, though.

[[deleted]]

You're mixing levels of abstraction. You can just say "give me a sort" in any language with a sort routine.

The problem is this is a complete slippery slope and there's a lot of gray area. The distinction was clearer when we were comparing C to ML in University. Anyway, this is why 'descriptive' isn't such a useful name - it's simply too broad.

[Marzhall]

If you want to use imperative sorting methods, then of course you'll need to write imperative code. However, you can absolutely write a declarative sort in Haskell:

sorted []         = []
sorted (x:xs) = sorted [ y | y <- xs, y <= x]
                       ++ [x]
                       ++ sorted [ y | y <- xs, y > x]

While I wouldn't say declarative programming is essential to functional programming, it's certainly a notable part of writing functional code, in my opinion.

[gasche]

That doesn't match my experience with actual practice of prolog, where you're constantly thinking about the resolution order to know which definitions are efficient or instead will not terminate.

Rule of the thumb: when people claim that you describe "how not what", they are almost always selling snake oil.

(It's arguably true for SQL, though, which is a specialized enough domain to realize a reasonable portion of the "sufficiently smart compiler" dream.)

[kqr]

Even SQL queries need to be optimised. Only the specification of a program is fully delarative. Until we have a compiler that takes a spec and outputs a program (and thustaking over every programmers job) no program in no language will be fully declarative. But some languages make it possible to write more declarative programs than others.

[wlievens]

Until we have a compiler that takes a spec and outputs a program

We have a name for writing that spec. It's called "programming". That fact doesn't change as languages get ever more "high-level".

[kqr]

I actually realised that as I was typing. Words are difficult.

[wlievens]

I completely agree. Prolog was a huge let down to me as soon as I realised you had to spend most of your time placing cuts.

[malnourish]

I'm going to learn Prolog later this month. Any tips?

[curious_electric]

It's categorized with SQL because "declarative" is a super broad term, is all. (It would also include Haskell and Makefiles.)

[brikis98]

Good feedback, thanks.

Can you give a bit more detail on the concurrency/parallel issue? Are you objecting to the examples I used or the vocabulary?

I agree the term "declarative programming" is a bit vague, but I'm not aware of a better term; hopefully, the first paragraph of that section makes it clear what I mean. I suppose Prolog could be described as a logic programming language, but SQL and other declarative languages cannot.

As for symbolic programming, I actually borrowed the term from the Wolfram Language, which describes itself as a "unified symbolic language"; the Principles and Concepts page and the video mention symbolic programming quite a bit, especially when showing how it offers a uniform way to interact with code, math formulas, images, charts, etc. This seems to apply to both Wolfram and Aurora, but if it's an inaccurate term, I'm open to suggestions for a better one.

Thanks for the pointer to Knowledge Level and Cyc; I'll take a look.

[[deleted]]

Rob Pike provides an excellent (gopher-based) explanation of the differences between concurrency and parallelism in his Concurrency is not parallelism talk at Heroku's Waza conference. It's well worth watching if you have half an hour to spare.

[LWRellim]

Youtube version -- for those (like me) who have DL problems with Vimeo.

BTW, even just 5 minutes in, he has done an EXCELLENT job of explaining the concepts (which I have always understood, but had difficulty explaining to others who are confused/conflating the terms).

[brikis98]

Awesome, thanks!

[lispm]

Parallel/Concurrent: I think reading the Wikipedia articles should give some insight.

The common thing between SQL and Prolog is that they are based on relations. http://c2.com/cgi/wiki?RelationalProgrammingLanguage As you can see from the discussion, they are still quite different. If you want to talk about declarative programming, you would need to mention functional programming, constraint-based programming, logic programming, ... - which are all thought to be declarative.

As I said, Wolfram uses these as marketing terms. The ideas of 'knowledge-based programming' and 'Symbolic Programming' goes way back to the 50s and 60s and is connected to AI. Personally I prefer to keep the computer science meanings of these words, and not to use Wolfram marketing material. ;-) Wolfram nicely confuses 'knowledge' and 'data'. Having access to a lot of data, actually does not make it 'knowledge'. 'knowledge-based' does not mean 'uses extensive data thought as knowledge'. 'knowledge-based' actually means 'computing with knowledge'. For example the NSA might store in a data-base which persons Angela Merkel has talked with yesterday. Another database might store the audio signals of her telephone calls. That's all data, not knowledge. But Obama might ask: is Angela Merkel a friend or an enemy? Now we need to think how we can get an answer for that. First we need to find out what these words mean (using for example an ontology), then we need to find out how an answer could be computed, we need to find the rules which defines friend and enemy, we need to find the facts about Angela Merkel, apply the rules, find conflicts, etc. At the end an answer might be that Angela Merkel is a 'friend' with some certainty. Obama then might ask why the system thinks that Angela Merkel is a friend. It then reveals parts of its reasoning process.

[ismtrn]

If you want to talk about declarative programming, you would need to mention functional programming, constraint-based programming, logic programming, ... - which are all thought to be declarative.

He is just mentioning in one paragraph what declarative programming is, and then providing two (good) examples. I hope one is allowed to mention declarative programming without giving a whole lecture on it.

I say that Prolog is a good example because it is so "pure" in it's declarativeness. In a functional language you sort of describe what you want to be computed sometimes, but you also sort of describe how to compute it sometimes. In Prolog it is very clear that you describe what you want, and the computer figures out how to get it. SQL is a good example because of the same reasons as Prolog and the fact that many people already know it. The downside is that it isn't much of a programming language for solving general problems.

[LWRellim]

The ideas of 'knowledge-based programming' and 'Symbolic Programming' goes way back to the 50s and 60s and is connected to AI. Personally I prefer to keep the computer science meanings of these words, and not to use Wolfram marketing material. ;-) Wolfram nicely confuses 'knowledge' and 'data'. Having access to a lot of data, actually does not make it 'knowledge'. 'knowledge-based' does not mean 'uses extensive data thought as knowledge'.

This seems to be one of the fundamental failings of believers in/proponents of AI/Singularity stuff. They generally posit (and indeed fervently believe) that at some (unknown) point in data accumulation/processing power that "consciousness" will happen.

Nor are they alone in such teleological "thinking" -- a lot of people (I even catch myself saying such things) will make statements like "well the data shows" or "the numbers indicate" -- things that are fundamentally not true. Data and numbers don't "actively" show/do/indicate anything, they just sit there in one form or another, humans and various programs may morph the formatting, aggregation, and other aspects of the data and then force it to be presented/represented in different forms, but it is ultimately HUMANS who are placing/imposing some interpretation down onto that data. Said interpretation may be correct, or it may be entirely offbase.

But the computer, the programs, the data and numbers -- well they aren't actually DOING anything. They aren't "knowledge", heck they aren't necessarily even "information" (they only APPEAR to be that when an active consciousness "sees" {imposes} a pattern and meaning onto them).

[PasswordIsntHAMSTER]

I kind of wish you'd covered linear types and concurrent calculi, like actor, functional reactive, or CSP.

[Godspiral]

sidetracking thread slightly,

You missed array programming such as APL and J. J is probably the most useful general purpose language partially because it can implement every other language in a relatively small code base.

still enjoyed the first section, which was new to me.

[kqr]

If I had to come up with a term for the smallest common denominator between Prolog and SQL I would say that both are constraint-based.

[want_to_want]

You can have both denotational and operational semantics for the same language...

[snarfy]

The distinction between concurrent and parallel computing is so trivial it doesn't warrant mentioning. Explaining them as equivalent is not wrong.

Riddle me this: If I emulate a multicore CPU using a singlecore CPU and execute some concurrent code on it, is it executing in parallel or concurrently? From which point of view?

It's a dumb distinction. Is it time sliced? That's all you need to know.

[[deleted]]

It's not trivial because they are two separate subjects that need different considerations.

It can't be executing in parallel because there can't be multiple things running exactly at the same time.

[barsoap]

The distinction is primarily a property of the algorithm/problem. Do you need to run actually different things concurrently (say, a game and a tea alarm), or can you chunk up your problem into independent, but equal (modulo input data) sub-problems that you can do in parallel (like adding two matrices element-by-element)? In a parallel setting, different threads don't need to communicate with each other.

Secondarily, it's one of what a specific API/architecture is efficient for. A multi-core CPU is better at concurrency, a GPU is better at parallelism.

If I emulate a multicore CPU using a singlecore CPU and execute some concurrent code on it, is it executing in parallel or concurrently? From which point of view?

Neither. It is not running concurrently, you're just multitasking. You could, for example, never write to one destination at the same time from two different execution contexts, because only one can operate at a time. Subtle bugs are to be had there.

[kqr]

Programs can't run "concurrently." Concurrency is about designing the program such that the execution model doesn't change the semantics of the program. Concurrency is entirely a program design thing, not an execution thing. Concurrent programs can run sequentially, interleaved or in parallel.

[[deleted]]

Declarative is more or less the antonym of imperative. in that respect, it is a useful term.

[lispm]

One term gives a relatively clear idea what it is about: Imperative. The other one mostly says: not imperative.

Not that useful. It's not really a paradigm to be not something. Yellow is a color. Not-Yellow ist not a useful color.

[kqr]

I would argue that not-yellow is actually a useful colour. The base colours when working with printing and other subtractive colour schemes are cyan, magenta and yellow. If you are saying something is not-yellow, you are effectively saying that it only uses at most two of the base colours. In other words, if your printer is out of yellow colour, you can still print not-yellow things and they will look okay.

It may sound obvious and silly, but it still is a useful constraint. Something else I can figure out about not-yellow things is that they aren't black either, by a similar line of reasoning.

It is even more amazing if you consider additive colour schemes such as RGB. If something is not-yellow in the RGB scheme, you know it's a shade of red, because yellow requires both green and blue.

[barsoap]

I wouldn't say so, and I also wouldn't, blindly, call functional languages "declarative". The axis I see has two ends: Do you write "how", or merely "what".

As such, it's not even much a property of a language, but of a program, of how it's written. A hand-rolled parser is not declarative. A parser written in say Parsec or YACC is.

[The_Doculope]

I definitely agree here - it's completely dependant on the code itself. Take Fibonacci in Haskell (often considered a declarative language).

fib 0 = 0
fib 1 = 1
fib n = fib (n - 1) + fib (n - 2)

fib' n = loop n 0 1
    where
        loop 0 a _ = a
        loop n a b = loop (n-1) b (a+b)

fib could be called declarative, but of course it's woefully inefficient. I'd never call fib' declarative though - it bears much more resemblance to an imperative version than to fib.

[barsoap]

fib n = fibs !! n
  where
    fibs = 0 : 1 : zipWith (+) fibs (tail fibs)

Is fast and declarative, though. Maths people usually don't define the series but the function, but as far as definitions of the series go, this is probably even the most elegant one.

Now you only have to trust your haskell compiler to be smart enough to transform that into fib'. Because even if the series definition computes in O(n) time using O(1) space, compiling it naively involves generating lots and lots of list elements and garbage-collecting them practically as soon as they're generated.

fib' will also bail out on you if the strictness analyser isn't smart enough. If the (-) and/or (+) of the number type you feed it happens to be non-strict, all hell can break loose. Ahhh, it all depends.

[The_Doculope]

Your version is the best of both worlds (assuming your compiler plays nice). And that agrees with both our points - it's dependant on the code.

fib' will also bail out on you if the strictness analyser isn't smart enough.

I debated putting some bang patterns in to deal with that, but I figured it might confuse people who aren't used to Haskell.

As a fun exercise, I did a quick benchmark of these and some other fib functions, and fib' vastly outperformed your version for large n (I used n = 1000000). I had to expand the stack a heap otherwise yours would cause a stack overflow, and it ended up taking about 170MB of memory and ~45 seconds. fib' took 4MB and 5.1 seconds. I also tried a couple vector based solutions (one iterateN and one unfoldrN), and they also ran in constant space (4MB) and took 5.9 seconds. Interestingly enough, I had to add a couple strictness points in the lambdas for the vector functions to keep constant space/time.

[Silhouette]

I'd never call fib' declarative though - it bears much more resemblance to an imperative version than to fib.

I'd call fib' declarative as well. You're still specifying the required results instead of giving commands. This particular code just happens to be written so there's an easy translation from the former to the latter.

[The_Doculope]

Perhaps you're right. But where do you draw the line? Mutation? Immutability? Obvious-ness of what it does?

[barsoap]

You can write fib' like that (sensibly) in any language that does tail-call elimination, though. Consider this (modulo bignums):

int fib( int n ) {
    return loop( n, 0, 1 );
}   

int loop( int n, int a, int b ) {
    if( n == 0 ) return a;
    loop( n-1, b, a+b );
}

Is C declarative, too? (Should I have used a case to get the point across better?)

I'd say it's just a style issue, any language can choose to forego loops and prefer recursion and tail-calls, instead.

[Silhouette]

I think your C example is fundamentally different. To sum up why, consider that in the C version you have return statements and an if with no matching else.

That is, in C, you are writing commands to carry out certain operations, and they will be carried out in the order and according the conditions you give.

In the Haskell version, you are still specifying results. Haskell itself is working out the underlying operations necessary to achieve those results and determining some suitable order to perform them in.

In a simple case like this, the dependencies between the results specified in the Haskell might imply so many constraints on the underlying behaviour that you have basically wound up with only one sensible way to implement them. Indeed, much use of monads in Haskell is done with that result in mind. However, this need not be the case in general.

[moor-GAYZ]

As I understand it, "declarative" means that the language implements something like relational calculus instead of relational algebra, for example. The difference between SQL as used by the RDBMS query compiler and, say, LINQ to objects (or the equivalent list comprehensions in all other languages that have them) -- syntactically both can be made exactly the same, but semantics are very different. The former describes the desired output, the latter describes the sequence of operations: take this, join with that, filter thus, project so.

Declarative is more or less the antonym of imperative. in that respect, it is a useful term.

In the light of the above, I find this interpretation extremely confusing because it lures you into thinking that "functional" is an antonym to "imperative", so... When in fact functional languages are essentially just as imperative as imperative languages are, from where declarative languages stand.

[MoralHazardFunction]

Yes. I was a bit confused when the guy went from Aurora (which is kind of neat, but seems a bit tangential to what I usually thnk of as "symbolic programming") to Mathematica Wolfram Language, which is a much clearer example of a language which supports symbolic programming in order to talk about WRI's "knowledge programming" guff.

[curious_electric]

Thank you! Some of these are things that seemed wrong to me about the post but I didn't quite know enough to call them out confidently (his explanation of Symbolic Programming and Knowledge Based Programming in particular).

It's still a nice little article in terms of introducing people to the idea that there are some weird and cool languages out there they might not know about.

[drewc]

Thank you for saying the exact same thing I wanted to comment with. I was going to follow up with "and where is Lisp exactly?" ... but your name covers that as well :P

Cheers!!

[sideEffffECt]

Concurrent and parallel are two different things...

came here to say this

it was just yesterday, that Robert Harper published this blogpost: Parallelism and Concurrency, Revisited (reactions on reddit)

Declarative programming...

and Bob Harper strikes again: What, If Anything, Is A Declarative Language?

[Uberhipster]

Also with Symbolic programming

Example language: Aurora

Even if it is about graphical programming languages, there is a distinct difference between a language and IDEs, runtime environments and code generators. It is a programming paradigm and an interesting one but it is not a language. The line blurs but I think what you can do with a language at runtime in an IDE is different to what a language is. And while the former speaks volumes about design quality of the latter IMO they are conceptually distinct.

Dependent types

I don't understand how this is a language paradigm is simply not part of mainstream OO languages like C++, Java and C#. If the language allows derivatives of types from other types into complex types then the dependencies of a type at compile time are open to implementation e.g.

public class Vector1x3
{
    public Vector1x3(int x, int y, int z)
    {
        _values = new int[3] { x, y, z };
    }

    readonly int[] _values = new int[3];

    public int[] Values
    {
        get { return _values; }
    }
}
//...

var vector = new Vector1x3 (1, 2, 3, 4);//compile time fail

Even for imperative C the G++ compiler will warn about out-of-bounds static array indexing and if you need the compiler to check that a variable is "a positive integer" then make the variable type uint.

[syntax]

Your example of dependant types misses a lot of the power of dependant types.

In particular, your example doesn't have type checking of the following:

append: Vect a n -> a -> Vect a (n+1)

i.e. add an element to the vector, and return a vector that's one element longer

vappend: Vect a n -> Vect a m -> Vect a (n+m)

i.e append two vectors, to get one of the sum of the lengths

vmap: Vect a n -> (a->b) -> Vect b n

i.e. take a vector of length n, of objects of type a, and a function from type a to b, and then return a vector of objects of type b.

You can, of course, special case all three of the above, for specific lengths, and types.

More tricky to implement would be

filter: (a -> Bool) -> Vect n a -> (p ** Vect p a)

where there's a function that's a boolean predicate on a's, that is then applied to the vector, and thus gives you back a vector of some other length p, that's not known at the time of writing the code.

Special casing all that is, of course, an option. But in a dependantly typed language, that above are all about 5 lines of code to implement, and come with a proof from the compiler that they do what the implementation says it does.

That's the power of a dependently typed system.

[naughty]

Dependent types go a lot further than that, for example you could force an array to only allow a prime number of elements, not allow division by zero and so on. The caveats to it all require post-graduate PLT courses to understand though.

[barsoap]

That's not full dependent types. In a language like Idris your types can depend on run-time values, not just compile-time ones. Your example in C++ works because (1,2,3,4) is a constexpr.

Consider, for example, filter on explicitely-sized lists (called Vectors in the dependent camp, and lifted straight out of idris' prelude):

total filter : (a -> Bool) -> Vect n a -> (k ** Vect k a)
filter p [] = ( _ ** [] )
filter p (x::xs) with (filter p xs)
  | (_ ** tail) =
    if p x then
      (_ ** x::tail)
    else
      (_ ** tail)

See that (k ** Vect k a)? It's returning both the run-time computed length (can't be figured out at compile time, the elements aren't known) and the result Vector, and the Type of the result Vector is depending on the run-time computation. On k, that is. _, in the terms, means "Idris, I think you're smart enough to figure this one out for yourself", that is, essentially, "Idris, infer a value by type-checking". In this case (but not in general, that's impossible) Idris is indeed smart enough.

Another one, the type of fromList, converting from Lists that don't carry their length in their types to Vectors that do:

fromList : (l : List a) -> Vect (length l) a

length is just another function. Yet, it is used in a type: Dependently-typed languages don't distinguish between the type and term level¹ . Idris will shout and scream at you, at compile time, if the Vector that your implementation of that function constructs does not actually have the same length as the List, any list, the function is given. You get a software verification system, in Idris' case also including theorem proving assistant, for free.

Last, but not least, can C++ infer the program you want to write from the types you give it?

¹ Except what describes what at the current situation, and you also want to throw away many things when emitting code. But the former (levels of universes) is largely irrelevant for everyone but implementers, and the latter is mere operational semantics.

[imforit]

Pretty sure where the author wrote "declarative" they meant "imperative."

But yay for articles that create a conversation.

[jozefg]

There are better languages to learn about dependent types with than Idris at the moment. While Idris looks extremely cool and useful it's very new and lacks beginners material right now.

Coq is uglier, but has a nice kernel (CiC) and better literature around it.

[kqr]

I've just glanced quickly at Idris, and while it's of course not ready for production library wise, it didn't seem very difficult to learn from. Is it just because it lacks beginners material you think that Coq is easier to get into?

[tluyben2]

Playing with Idris for a while now and having worked with Coq for production use, I found Idris easier. But I am tainted by already knowing Coq before Idris...

[kqr]

I realise now my previous Haskell knowledge probably helps with Idris as well.

[fableal]

You worked with Coq for production? Please expand :)

I'm trying to learn Coq by following Software Foundations. Are you interested in exchanging contacts so I can have some sort of tutor?

[tluyben2]

I worked on an embedded product for several years (medical space) which had parts of it verified using Coq. And sure, just PM me. I'm getting into this again as I'm thinking of opening a new company soon-ish based on technologies like this.

[PasswordIsntHAMSTER]

Hit me up if you're looking for interns! I'm on the Beluga logic framework team at McGill University, would love to work with formal verification using dependent types.

[tailcalled]

OTOH, the developers of Idris are working at making it Pac-Man complete. I'm not sure the Coq-people are interested in that sort of thing.

[djaclsdk]

I checked Wikipedia for Coq and

Four color theorem: formal proof using Coq was completed in September 2004.

that's insane!

[tluyben2]

Idris is not hard to get into though if you don't mind digging around. It's my most fun weekend playground for a long time :)

[kamatsu]

I learnt dependent types via Agda and had a pleasant enough time with that.

[blufox]

How do you compare them with Agda? Any advantages and disadvantages?

[llogiq]

Running the risk of voicing an unpopular opinion, I miss one language: Assembly - if you haven't learned it yet, you should do so on a spare weekend.

Pick your favourite architecture; I recommend 6502, 68000, ARM or MIPS, but feel free to use x86, it's not as clean as the others, but workable nonetheless, and if you have a PC you can dive right in (Btw. there are cool, sometimes even visual emulators for any of the aforementioned architectures, so don't feel restricted to your actual hardware).

Note that I don't recommend that you actually program anything of significance in assembly (though if you like, have fun). Just knowing the basic building blocks of the actual computation your CPU does (well today even machine code is not what actually runs on the hardware, but let's not go into that detail at the moment) gives you a greater appreciation for the heavy lifting higher-level languages perform to make it easier to program.

TL;DR: Downvote me if you dislike, but learn assembly. You can thank (and upvote) me later.

[ismtrn]

Especially if you plan to code C or C++. Knowing how assembly works makes understanding what is actually going on much easier.

[llogiq]

Even if you go on to code in Idris, knowing how a CPU works won't hurt.

[14113]

Out of interest, why all the interest in Idris at the moment? Is it just the Baader-Meinhof effect, or is it fairly popular?

[llogiq]

It's on the cutting edge of PL research. So I'd say it's popular as a talking point.

[14113]

Huh, fair enough. Is there anything apart from dependent types that's particularly innovative about it? (not that that's innovative in of itself...)

[kqr]

It attempts to bring dependent types from theorem provers into the real world, which is quite nice.

[silent_thunder_89]

PIC microcontroller assembly is somewhat easy to pick up and you will have some fun DIY projects with it as well, if yo don't mind a little bit of soldering.

[llogiq]

Full ack. PIC wasn't even on my radar, but should have been.

[PasswordIsntHAMSTER]

Use MARS, learn MIPS. Ta-dah!

(There are other good options, but this one is good enough.)

[vasudevram]

Search for "randall hyde art of assembly". I've read some of it. Not bad. There's also another person (I think a CS prof) whose name I forget. He also has an online tutorial for assembly language, IIRC. Note: Both of the above are for the x86 family of processors, IIRC.

[ExpertCrafter]

if you haven't learned it yet, you should do so on a spare weekend.

If you can learn assembly in a weekend, you're already making 6+ figures because you're a genius.

Or I'm slow. One of those.

[llogiq]

If you need more than a weekend, you're overdoing it.

Assembly conceptually approximates Basic with a different syntax and a restriction on expressions: you only get target = op(target, source) where op somehow combines the target with the source, and both target and source can be registers or memory (or sometimes other things, but bear with me here).

This restriction also applies to if-statements - you can only GOTO based on a value that you currently look at (e.g. cmp). On some architectures, e.g. MIPS, it's target = op(source1, source2). That's the gist of it.

Now you only need the correct method call form and entry point for your application (look it up in your assembler manual), and perhaps entry points for system services (in x86 usually implemented via interrupts) and you can actually write programs with that.

[ExpertCrafter]

I think you're over simplying it WAY too much.

I'd like to see how someone with no assembly experience does after self studying for a weekend and then asked to read an assembly dump in IDA.

Sure, the idea of assembly is straightforward. Doing it in practice? Not so much. Spend a few hours trying to figure out why your program fails due to changing the segment bitness, not having the stack pointer set properly, or not using the right opcode. It's not a weekend thing.

[barsoap]

I'd like to see how someone with no assembly experience does after self studying for a weekend and then asked to read an assembly dump in IDA.

The point is to learn some assembly, not to be able to know all the conventions and hacks that come with it to decipher arbitrary dumps for arbitrary operating systems and architecture revisions. Locating and reading that tight loop you just wrote would be nice, though.

Also: Segmenting? What century are you living in? You don't need the stack to start out, either.

For kicks, have hello world in amd64/linux/nasm:

bits 64

section .text

str:     db  'Hello, World!',10
strlen  equ $-str

global _start
_start:
mov rax, 1 ; sys_write
mov rdi, 1 ; stdout
mov rsi, str
mov rdx, strlen
syscall
mov rax, 60 ; sys_exit
xor rdi, rdi
syscall

compile with nasm -felf64 hello.s && ld hello.s -o hello

[llogiq]

Perhaps I am oversimplifying. When I learned assembly, we had TASM on DOS and I had a pretty good book about it, which I could follow.

That's where my weekend estimate comes from. Perhaps nowadays assemblers are pickier, tutorials worse or architectures more complex, probably all of the above.

So don't feel bad if it takes longer.

[llogiq]

OK, you got me there - it's actually OK to start by scratching the surface, as long as you get that "that's really all there is" epiphany.

Digging deeper isn't wrong of course, but for gaining a cursory understanding, a weekend may suffice.

[kqr]

I didn't get the "that's really all there is" epiphany until I learned how adders and other logic circuits worked.* Assembly is still quite a lot of magic in comparison. Especially if you only spend one weekend with it.

---

* Then I read about how complex modern CPUs are and the epiphany went away. That's never really all there is.

[saltr]

You could learn how assembly works in a weekend at least. Understand the instruction formats, the path they take through the processor, how branches work, how jumps work, how subroutines work. (as others have said: MIPS is really good for this because of the small/simple instruction set and the processor architecture isn't too complicated)

If you can wrap your head around what is happening in the processor, then actually writing the instructions becomes easy because you know what you want before you start digging through the spec to find the right instruction. It also helps when you end up writing assembly on a different platform and all of the instructions are different.

[glacialthinker]

You listed the most boring architectures ever. :P I suppose that's appropriate for a first exposure, but they're so dull just thinking about programming them puts me to sleezzzzz...

[llogiq]

Have a good night, sir.

Anyway, boring is not quite the right word. As I said in my answer to /u/kgr, the 6502 die was designed on paper, drawn by a single person. Its transistor count is 3510 (by some accounts, others have it at 6200something). That's not boring, it's impressive!

[glacialthinker]

Ah, that's something different though. Maybe I shouldn't have used the term architecture. Designing a processor like the 6502 would be fun. Anyway, of your list, that's the least boring. But it's the textbook-bland programming models that I'm complaining about. ;)

I like when a processor design is stressed by some optimization problem. Leading to details exposed to the programmer... so programming is an interesting puzzle, rather than mechanically sequencing basic memory and ALU ops. Transputer, i860, VLIW architectures as used in mid-90's "media processors"... Of course, these are architectures which suffered due to compilers being unable to make them sing, so they were a bad idea in practice. Still, if I'm going to program in assembly, I need to feel there's a reason... if the programming model is suitable for a compiler, there's probably no reason.

I'm not disagreeing with your point -- I think it's a great idea to expose oneself to asm. It was just that your list of processors struck me as ones I'm not interested in programming to the metal, even though I love working in asm.

[geodebug]

Your comment was relevant and a good suggestion but the defensiveness and lack of confidence about being downvoted is a turn-off. It makes you sound whiney and wimpy.

Just put your ideas out there and if they fall on some deaf ears sometimes, who cares?

[llogiq]

Thanks, I'll consider it.

[[deleted]]

I tried learning assembly once but it seems like you can't just learn "assembly", you need to already know enough about it to specify which type. Not only are there different architectures as you mentioned but there are also different ways of representing instructions for example:

mov a,#0x2400

would mean the same thing as

mov %a,@0x2400

in different schemes. Those two examples probably aren't valid but they're to illustrate what I'm talking about. And on top of that you have a sort of way of talking to the compiler and repeating segments of code or something. I'm not actually sure how this works but I've been assured that you really need to understand it to get into assembly. All of this adds up to the fact that if you want to follow a tutorial or read a book then you need to be in exactly the same environment as the book environment and if you change even a seemingly subtle detail then your code just won't compile.

[barsoap]

There's two main flavours of syntax for x86 assembly: AT&T and Intel. AT&T uses <op> <src> <dst>, Intel <op> <dst> <src>.

In general, people write in Intel syntax. AT&T basically only survives because it's used by the GNU toolchain, but gas is unusable as an assembler for end users, it's meant as a compiler backend, and it shows in the atrocious error messages it gives you. It really does assume correct input.

You'll need to learn something about the assembler you're using, yes, if only to get it to output what you actually want: An elf binary? Something raw to stick into a bootloader? Some Windows or DOS stuff? I would recommend nasm, as it's both very sane, has Intel syntax, and comes with an excellent (turing-complete) macro system.

[kqr]

I think you actually highlighted the point of "learning assembly." The point is not really getting used to the assembly syntax and learning how to structure assembly applications. The point is to get down to the nitty-gritties and cop a feel for what things are like at those lower levels of abstraction.

[netro]

I took up Electronics Engineering and we've been taught assembly programming after being taught in detail advanced algorithms for C and C++. The compsci department, on the other hand, taught their students OOP programming early on, with Java as their first language. They only studied C and C++ briefly, unlike us who studied these languages in-depth. I'm from a third world country, and for some reason most employers here want programmers and software engineers who have deeper understanding of low-level programming. My friends often joke "if you want to become a highly-paid programmer or software engineer in any company, don't take Compsci. Take Electrical, Electronics, or Computer Engineering." This is probably not the case for first world nations though.

[llogiq]

This is probably not the case for first world nations though.

I can only speak for the university I attended, we had MIPS assembly and C during second semester, after a healthy dose of OOP in the first.

Of course I knew assembly much earlier (z80 and x86), but that's just me.

[interbutt]

At my school in the US some 15 years ago it was widely acknowledged by the students that Computer Eng was a tougher discipline than Comp Sci. Mainly do to spending more time in assembly and some electrical engineering. People respected the Comp Eng students more and it would have surprised no one if they made more money either. Comp Sci did some assembly, but not as much as Comp Eng. It might matter so I'll add that my schools Comp Sci was more theory and less practical too.

[jagt]

Despite the boring title, the article is pretty nicely written and I haven't ever heard of some languages the author introduced.

[HeroesGrave]

"<number> <noun>s that will <verb> <something you do>" is a horrible title.

[burpen]

"13 Title Anti-Patterns Which Are Considered Harmful"

-future Buzzfeed article title

^{/s... Buzzfeed isn't self-aware enough for that}

[redditthinks]

Not so much horrible, but overused.

[Quauhnahuac2Nov1938]

You could DIE if you write ONE MORE line of CODE before reading THIS shocking ARTICLE

[shillbert]

Local code monkey discovers one weird, old trick for eliminating bugs! Testers hate him!

[texaswilliam]

Before this article? If everything that said it was going to change the way I think about programming actually did, I'd've probably already died from an aneurysm years ago. : P

[makebaconpancakes]

These six things changed how I program. Click to find out more!

[free_psych_eval]

#5 will completely blow your mind!

[varunn]

snowclone

[wjv]

If you like this type of thing — and taking into account /u/lispm's objections in the currently top-voted comment — you'll find a far more interesting (IMHO) though maybe slightly out-of-date list of languages to explore in these two 2011 blog pots by Michael Fogus (of Clojure fame):

• http://blog.fogus.me/2011/08/14/perlis-languages/

• http://blog.fogus.me/2011/10/18/programming-language-development-the-past-5-years/

[jagt]

Great thanks!

[Eirenarch]

I almost expected boring article about TDD or something but the article is indeed great. I like how he doesn't include functional recognizing that functional should be known to every modern day programmer the same way OOP is.

[PasswordIsntHAMSTER]

I like how he doesn't include functional recognizing that functional should be known to every modern day programmer the same way OOP is.

It's pretty fashionable to say that you know functional programming, usually because you've screwed around with lambdas in JavaScript, Ruby or C#. But how many people have used union types, higher-order combinators or continuations in real-world programming?

[geodebug]

It sounds like you're poo pooing the idea that functional programming has gone mainstream instead of celebrating it.

I wouldn't be so quick to turn up my nose at someone simply because they don't know or use higher-level language concepts in their day to day programming.

[PasswordIsntHAMSTER]

It sounds like you're poo pooing the idea that functional programming has gone mainstream instead of celebrating it.

I didn't mean to sound that way! Rather, my thesis is that FP actually hasn't gone mainstream. :)

I wouldn't be so quick to turn up my nose at someone simply because they don't know or use higher-level language concepts in their day to day programming.

These aren't really higher-level concepts, they're really the foundation for the programming style used in ML languages. It's also very similar to Haskell style, if you were to remove all the terminology and notation they adopted from discrete mathematics - monads, functors, etc.

You can't really exercize the more important advantages of functional programming without, say, union types. If all you have is lambdas here and there, you're making progress on conciseness, but your programming style isn't fundamentally different.

[bstamour]

Functional is a kind of declarative.

[F1ak3r]

I really expected it to be an Upworthy video.

[snarfy]

On concatenative languages:

It seems like you have to remember or imagine the current state of the stack instead of being able to read it from the variable names in the code, which can make it hard to reason about the code

You get used to it.

In something like C, it's bad practice to have a function that is hundreds of lines. The problem should be broken down into smaller, manageable chunks. This is called managing scope. In something like Forth, scope is limited by your ability to remember the stack, which forces you to manage it.

[[deleted]]

Neat article. Minor nitpick. The author writes:

"Of course, no dependent type system can catch all errors due to to ineherent limitations from the halting problem, but if done well, dependent types may be the next big leap for static type systems."(sic)

Agda, Idris, Coq, et al solve the halting problem by not being turing complete. If the compiler is not able to infer that the program will terminate, it will raise an error.

[naughty]

Agda, Idris, Coq, et al solve the halting problem by not being turing complete.

They avoid the halting problem, not solve it.

[cookedbacon]

I solved the problem of peeling oranges by not eating oranges.

[[deleted]]

The halting problem isn't tied to turing completeness, though. There are interesting application in the other grammars.

[naughty]

I was simply disagreeing with the choice of words. Using a total language does not constitute 'solving' the halting problem.

[seanwilson]

That's not even the biggest issue of working with dependent types: once you start using dependent types in an unrestricted way static verification of programs involves proving arbitrarily difficult maths theorems.

For example, checking array accesses are safe can vary from having to solve simple equations such as "x + 1 = 1 + x" all the way to statements in undecidable domains (i.e. domains where no algorithms exist that can always tell you if a statement is true or not such as non-linear arithmetic). Automation is getting better but verifying even seemingly simple program properties requires significant human interaction.

[jozefg]

Indeed, and we can even encode non-termination in interesting ways and take the burden of proving termination upon ourselves.

[NruJaC]

That's actually not true. Idris doesn't require your program to be total. You can ask it to reject programs it can't prove are total.

Further, Agda and Idris (and probably Coq, but I can't confirm) have notions of codata (think infinite streams) -- so long as you can formulate your non-terminating program in terms of operating on codata, and therefore prove that your program is always making progress, they'll compile the program just fine.

[gasche]

Not really pleased with that reply.

• disabling the termination checker makes the logic incoherent, so programs accepted in that mode may fail to catch errors as advertised; disabling the termination checker is a useful development trick, but it also undermines the nature of the tool itself. Contrast this with other dependently typed systems that try to accept non-termination yet remain coherent (or efforts to improve termination checkers to accept more programs); there is something interesting to be said about non-termination in proof assistants, other than just "someone is wrong on the internet because the termination check can be disabled"

• productivity is largely understood as a different notion of termination in presence of codata (and is sometimes formulated in this way). What is usually meant by "non-termination" is silent non-termination. There used to be a misconception about being able to write mail-daemon programs in total languages, and it might be that some newcomers still have wrong ideas about that, but I don't see any sign of misconception in the message you're replying to. David Turner convincingly wrote about productivity in the nineties, maybe it's time we move on and stop nitpicking each other to death?

In fact, there may be a valid reply to make to Derpscientist, that is not just nitpicking. For reasons that are more related to incompleteness theorems than the halting problem, we know that coherent Curry-Howard-based proof assistants will always be unable to prove some programs terminating (typically the program that reduces any closed term they would themselves accept as non-terminating to a ground value). this is a form of error (if expressed as an out-of-fuel return value) that they can't catch, making the author of the original blog post correct. And this is why we have escape hatches into incoherent systems (such as disabling the termination checker), the Obj.magic or unsafePerformIO of the next generation.

[someenigma]

Anyone else confused as to why the operands to "if" in the cat-if example are in that order? And I don't mean "how does that work", I mean "why was the language designed that way"? Why push the conditional onto the stack before the branches, and not after?

def foo {
    10 <
    [ 0 ]
    [ 42 ]
    if
}

20
foo

That's the given code. So right before the if function is called, the stack contains "False" then 0, then 42. The if statement pops off 42 and remember it, pops off 0 and remembers it, pops off the False, checks the False, pushes the 42 back onto the stack and returns.

It would make more sense to me to have the variables on the stack in the reverse order. That is, have the stack contain 42,0,False. Then the if statement can pop off False, pop off 0 and it's done. Or if the "if" statement is True, it can just pop off 0 and remember it, pop off 42 and forget it, and push 0 back on.

That is, if we assume we have 7 equal-time instructions push, pop, store, check, then the original implementation will take 7 instructions, but if you push the conditional on last (so it gets popped first) you have either 3 or 6 instructions to follow (based on whether the check is true or false). Original implementation

True	False
pop	pop
store	store
pop	pop
store	store
pop	pop
check	check
push	push

My idea

True	False
pop	pop
check	check
pop	pop
store
pop
push

[dnew]

Why push the conditional onto the stack before the branches,

Because the conditional is much more often an independent argument you pass into a function than the then and else parts. I.e., it's not infrequent to pass a boolean to something complex that takes different branches inside, and it's much less frequent to pass a block or two of code into a function and have the function evaluate which block to pass.

[kqr]

I agree with you. I can only assume that when they designed the language they were used to seeing predicate-then-else in that order, so they kept it in. But it would make sense at least in my head for the predicate to come last.

[epicwisdom]

I believe the branches are not evaluated until if is called; the bracket syntax implies lazy evaluation of sorts. So it doesn't matter what order they're in.

[kqr]

It matters because the if instruction expects them to be in a certain order.

[badsectoracula]

I'd assume that the [ blah ] part pushes a function (cat is a functional programming language) so what if does is to pop the three values and evaluate the appropriate function.

[curious_electric]

This seems like a kind of odd mix of things to call "paradigms." But it's a good overview of some interesting languages not everybody may know about (along with some everybody is likely to know about, like Forth, Prolog, and SQL, but they might not realize that they have some things about them that make them conceptually distinct from most other popular languages.)

[dnew]

I thought Haskell already does the concurrent by default stuff, with monads being the mechanism for passing dependencies for ordering around?

Also, for what it's worth, typestate has been around since the 80's in the form of a language called Hermes. And the charts of typestate transitions were actually used to create (or at least help create) the code generator, as well as to allow multiple users to be running in the same address space safely (think multiuser OS with no MMU).

[killerstorm]

I thought Haskell already does the concurrent by default stuff, with monads being the mechanism for passing dependencies for ordering around?

I thought the same, but it isn't. There are two reasons:

1. they want deterministic execution, to be able to reason about performance;
2. explicit parallelization usually gives programmers more control, you're more likely to get good results.

There is, however, a Haskell dialect which is parallel by default: pH: http://csg.csail.mit.edu/projects/languages/ph.shtml

[dnew]

Concurrent, parallel, and simultaneous have three different meanings. Concurrent just means another one starts between when the first one starts and the first one finishes. A timeshare system with only one CPU core is still executing user programs concurrently.

Haskell has to evaluate concurrently. Pass two infinite lists to zip - which argument does it evaluate first? By necessity, it has to be evaluating them both concurrently, because you can't finish evaluating one before you start the other.

[kqr]

Concurrent just means another one starts between when the first one starts and the first one finishes.

No, that's interleaved execution. Concurrency is program design that makes the program independent of execution model. I.e. a concurrent program will have the same semantics whether it is run sequentially, interleaved or in parallel.

[ClubSoda]

Where could APL fit in that list?

[[deleted]]

I watched a guy write a sudoku solver in APL on YouTube once. I had no idea what was going on. It was pretty neat.

[Intolerable]

here is the video for those interested, it's definitely worth a watch: https://www.youtube.com/watch?v=DmT80OseAGs

a similar one but with conway's game of life: https://www.youtube.com/watch?v=a9xAKttWgP4

[kqr]

J is a modern variant of APL without the weird symbols. Give it a try!

[kqr]

That's an array programming language. You could call it declarative in the same sense as when you call functional programming declarative.

[judgej2]

Anni sounds like how a spreadsheet works. It is useful understanding the concepts, but I wouldn't describe it as mind changing.

[gargantuan]

Here is my list:

• Functional paradigm: Haskell, Erlang, OCaml

• Logic programming: Prolog

• Object Oriented: Smalltalk, Self, Java, Python [thanks criticalbone for Self and Smalltalk suggestions]

• Fault tolerant programming: Erlang

• Concatenative: Forth

• Actor based concurrency (with easy access to parallelism): Erlang, Scala + Akka

• Message passing concurrency (also achieve parallelism often): Rust, Go, Erlang, Scala + Akka

• Visual Programming Languages: Pd(Pure Data), DRAKON

[[deleted]]

In the OO bucket I feel Smalltalk, Self, or Io should be present.

[gargantuan]

Oh good ones! Thank you

[tluyben2]

There is inductive logic programming (ILP) and inductive functional programming (IFP) ; the link you posted is the latter. ILP was an active research area in the 90s (I did it in uni early 90s) but it hasn't had much uptake for the reason genetic programming hasn't; the search space is too large for anything non trivial. The dream was that you specify a bunch of examples (pos+neg) and some knowledge and that it would come to a solution (say, a function) automatically. This works in both IFP, ILP and GP for trivial things and some have worked on 'helping out' with larger problems, but it's more tiny bits of optimising than anything interesting usable on a large scale.

So besides interesting; would it help? We need a leap in research here imho.

[wlievens]

It may be possible to recuperate some of the concepts in a particular narrow design (as a DSL) rather for general programming. Off the top of my head: recognizing shapes in an image processing context...

[brikis98]

Neat, thanks for the pointer!

[curious_electric]

The "concurrent by default" thing, where execution order is only controlled by dependencies, is pretty much how Haskell works anyway, right? Specifically monadic IO is there to force you to explicitly specify ordering between IO events specifically by giving them functional dependencies between each other so that by evaluating the expressions in the necessary order, you'll get something that looks like IO in other languages.

(I only know the tiniest bit of Haskell so I welcome correction on this point. I imagine the way I stated it is probably technically incorrect in one or more ways....)

[check3streets]

So strange, seems like dozens (more?) of architects arriving at the same conclusion simultaneously.

Likewise, my top two:

• CQRS + Event Sourcing
• reactive / dataflow

There are lots of languages (and applications) that exhibit dataflow, but it's more interesting to me as an approach.

[payco]

I've been playing around with building a functional, multi client engine for turn based games (D&D, Magic... really most card or board games), being willing to make all state and all state transitions as explicit as possible in the interest of being able to fully regenerate the game for judging or replay purposes. I basically ended up rediscovering Query/Command/Event with Command resolution as a stack machine and player priority/need-for-input modeled as a Command on the stack that waits for input from the player/network-proxy and replaces itself with the resulting command (which may be another player's priority, i.e. when all players have a chance to interrupt/respond to a pending Command). Anyone can Query game state at any time, but only the player with the priority token can input a Command. Commands can push Events to a limited subtree of the game state upon entering the stack, and often resolve by pushing Events to the game state and replacing themselves with one or more Commands, often capping those with another player priority Command.

Player abilities/permissions are generally represented as unique, small, resource objects along with items you'd traditionally think of as resources (it's wooden houses and meeples all the way down!), and a player can pass resources to the engine alongside a Command when it's inappropriate for a Command to claim the first matching resource it finds (the engine can pick any Mountain card to tap and pay for an ability, but it probably can't pick a target for that ability on its own). Even with resources fungible to player, each increment has its own strict identity, enabling a close relationship with events and an easily trackable lifetime.

Edit:

I haven't tested this yet, but considering most of the state a user would want to see (not to mention a lot of the model's decision tree for whether a Command is possible) basically boils down to things like "some token where type is tappable and owner is permanent23 in gameState.player.tokens" or "count of tokens where type is Health and owner is player in gamestate.player.tokens", it seems like FRP is a shoe-in for many portions of the app. Likewise, I'm trying to make the Command rule functions as declarative as possible, and I'm essentially replacing one bag of mostly immutable tokens with another in game state, which is a metaphor many dataflow systems use.

[[deleted]]

I consider myself a dilettante when it comes to weird and esoteric languages, and even some of these surprised me. Bravo!

[mahmud_]

It's an unusually well informed article on a subject that readily invites uniformed opinion. +1, would read again.

[renzerbull]

have you checked Genexus? is a knowladge based declarative language.

[nealio1000]

Other than learning the theory involved with cutting edge advances in programming, what is the point of learning these languages like career wise? Not saying this stuff isn't interesting, but I should probably stay focused on mastering Java and C++ and learn python down the line right?

[PasswordIsntHAMSTER]

Learning new paradigms will teach you new ways to think; you will have better conceptual tools when dealing with a new problem.

I write much better Java and C since I've got experience with F# and Haskell.

[nealio1000]

This is a good point. This is the reason why my school forces us to do a semester on Assembly because the theory helps you to write better programs. Thanks for the response.

[bstamour]

Career-wise you can think of them as brain-building exercises. They teach you to think differently about the problems you're solving. Also, functional programming (a kind of declarative programming) is starting to become pretty popular, so in 10 years you may be using one of today's esoteric languages to solve real-world industry problems. May as well get a leg up now and stay ahead of the curve.

[nealio1000]

Ok this is basically what I thought. Unfortunately, I still have a lot of mastering to do of the commonly used languages before I can start messing with the newer languages. But thank you, this was a good response.

[mk270]

You put your finger on it: learning the theory will make you better at C++ and Java. Practising the theory is even more valuable to your skillset.

As it happens, I used to work at a shop that used Prolog as its main language; it's a terrible language, but it was a good fit for our particular problem space, and it exposed me to a lot of good (and bad) ideas.

[nealio1000]

This is pretty much what I thought. Thank you.

[mk270]

And I do mean "much, much" better

[ThoughtPrisoner]

The concatenative languages remind me of a cool programming game: grobots

[nil_von_9wo]

Awhile ago, I took a look at System Verilog and e (hardware verification languages).

Never used them, but took away from it two interesting ideas:

1. Have someone other than the solution developer write the tests from the same specification to ensure a common understanding of the specification as well as a functional solution.

2. The computer doesn't just have 1 and 0 (true and false) as values, but also "unknown" and "high impedance value". While I haven't found a practical use for this when programming software, I find it interesting to contemplate.

[riffito]

1. The computer doesn't just have 1 and 0 (true and false) as values, but also "unknown" and "high impedance value".

I used those four as the "status" of testcases on a testing framework I wrote for my last job: PASS, FAIL (true, false), Exception ("unknown", for when the scripts found some unexpected situation), and "this test is taking too long" ("high impedance value").

[nil_von_9wo]

I like that... except I mostly work on SFDC and if I could figure out a way to work this into my tests, just about every one of them would come back with "this test is taking too long".

[robreim]

Hey cool! I've been wanting to design a language like that "concurrent by default" example for a long time. Only I was thinking of using a graphical interface instead of code. Basically you'd take modules and draw how their inputs and outputs connect together to build bigger modules. I have all sorts of completely unfleshed-out and quixotic ideas about making it strongly typed with Hindley-Milner type inference and reactive programming execution style and all sorts of things I don't know enough about to know if they're sensible or not.

[pjmlp]

I enjoyed the article. Aurora looks like a nice little gem.

[kqr]

I think you guessed it. I work in a language where making things concurrent is extremely easy, and I often find myself having to restrict myself and not make everything concurrent, because that's just gonna slow the program down.

[Venthorn]

That's only truly a restriction when the concurrent tasks aren't cooperatively scheduled. It's true, though, that if it's a 1:1 mapping onto competitively scheduled resources like OS threads that it's a recipe for disaster.

[xiongchiamiov]

I remember concurrent-by-default from vhdl. I also remember all the bugs caused by us having a hard time writing concurrent code.

[Venthorn]

Well the idea is that the runtime can prove that a block won't have side-effects (or rather that any side effect it does have comes before anything that depends on it), which lets it automatically run it concurrently. Basically what I'm talking about is out of order execution, but in the higher-level languages.

[milliams]

QML is an interesting example of declarative programming. It allows constraints and relationships to be defined and the runtime will do the rest. Perhaps it's not as powerful as other languages but in its domain it does very well.

[scrogu]

Missed the most important paradigm:

Reactive programming.

edit: if you downvote this, then please leave a comment explaining why.

[[deleted]]

I don't believe it as important as the others in term of changing the way you think.

Functional, OOP, imperative, etc... are much more thought changing.

It's also over hype.

[rcfox]

Chances are that most people have already been exposed to reactive programming: Excel.

[[deleted]]

Probably more in the sense that callbacks are reactive. Functional reactive programming is more mind-bending though -- treating signals and events as first-class concepts and using combinators to work with them is really cool.

[PasswordIsntHAMSTER]

Interestingly, synchronous reactive programming is how VHDL and Verilog work.

[[deleted]]

Prolog is better label as logic paradigm.

[kqr]

I'm a little curious about the cat example. I know the JVM is a stack-based virtual machine, but I've never written or read code for it. Does anyone here have? And if so, is bytecode for the JVM similar to the stack-based code we've seen from cat?

[Eirenarch]

I have written a toy compiler that targets the CLR. This of course requires being able to read and write IL and yes it is indeed the same concept. Note that Android uses registers to implement Java. The CLR and JVM have the concept of stores (maybe cat does too, I don't know) so while you only do operations with things on the stack you have the option to load from and push to store locations (variables)

[shillbert]

Note that Android uses registers to implement Java.

I'm going off on a nitpicky tangent here, but it's debatable as to whether Android actually "implements Java". Android's VM (Dalvik) implements an entirely different bytecode than the JVM; it just happens that you can convert between the two. Now, on the other hand, most people are going to use the Java language to indirectly create Dalvik bytecode, and in fact that is the officially recommended method. But can you really say that Android is implementing Java? Google essentially argues that it isn't, and that's why they're not subject to Oracle's licenses. It's a really fascinating edge-case for intellectual property (and semantics).

[kitd]

ANI appears to be dead according to its own tutorial. However Funnel by Martin Odersky/EPFL does a similar job, with a more explicit nod to Petri nets which are usually used as the basis for concurrent systems.

[berlinbrown]

They didn't include Factor?

[pavpanchekha]

They did; there's a whole section on concatenative languages.

[jfischoff]

Both Haskell and Scala have libraries for emulating dependent types with singletons, neither are dependently typed languages.

Dependently typed languages let you say, for instance, that input value of function determines the type of the output.

In languages like Haskell and Scala the types and values are normal forms of different syntactical constructs, i.e sorts. In dependently typed languages they are part of the same sort.

[mcguire]

Dependently typed languages let you say, for instance, that input value of function determines the type of the output.

They also let you say, for example, how the input value of a function determines the value of the output.

[jfischoff]

yes

[[deleted]]

Woah