What are the hardest programming languages you have ever learned?

Donald Sebastian Leung on August 26, 2018

For me it was C and Haskell and for completely different reasons. Coming from a JavaScript background, I was used to the abstractions that it of... [Read Full]
markdown guide

I think Prolog was the weirdest of the bunch. Having backtracking done automatically in a language is a far from normal concept although, once you get used to that, you can implement some software in a couple lines that would take hundreds of lines in C (ex. this problem)


I confirm we've used it in university to learn Artificial intelligence (we've built a checkers AI with it), at first it looks so difficult but once you understand it, it makes some stuff more easy than what is used to looks like.


We made a reversi / othello in Prolog at my university. Some minds were twisted in order to achieve that


That's awesome - I didn't realize you could implement a solution to the Zebra problem in Prolog!


What is Prolog like as a language? Is it still used for anything non-Legacy?


I don't have much experience with it but, as I understand it, you specify rules and facts and, based on those, you execute a query.

Currently it is being used at the university I studied to automatically generate the timetable for each faculty (which class is where and when) since it fits the language very well. You have teachers that are available at a certain time interval each day, rooms that fit a certain number of people, classes that have to be before other classes and so on.

Those are your facts and rules, after which you could tell Prolog "give me all timetables". Using backtracking it will automagically find states that meet those criterias, in this case, a valid timetable.


There actually was a pretty big online course by SWI Prolog that just finished. Next one is on expert systems, but not sure when. Recent focus on AI and ML is bringing Prolog back, at least in certain domains.


I had to use Prolog in a Programming Languages course in college. I never knew something like it existed. It's actually Turing complete and people have made weirdly complex things with it, such as a text editor. But otherwise, it's basically a database/logic querying system?

All I remember is a fun fact, that in the 90s (80s?) there was a research effort in Japan called the Fifth Generation Computer Project to create a proper advanced OS similar to supercomputers with builtin AI (?) and they used Prolog. After hundreds of millions of dollars and years of intense effort, they just gave up. Everyone else just used C and then we got Windows.


You bet. These days prolog is incarnated as Erlang.


It's like sticking a brute force solver in a maze and hoping it doesn't get stuck at a dead end.

Well I think you can give it tactics, but I think in the future with parallel CPUs and then Quantum computers and smarter compilers non-deterministic programming is the future. Right now search is like Garbage Collection, Higher-order functions, and interactive REPLs was back in the 1960s with APL and Lisp; it was too slow for PCs, so a bunch of teens grew up learning to program in low-level languages and forgot that better things could be possible.


I've heard of people codegen'ing other programs from Prolog. So like generating Java boilerplate based on simple logical rules and relations. I've never seen it done, but it sounds plausible.

I heard you can do that with Agda, Coq, miniKanren, Lisp, and Idris. I guess Lisp macros are kinda simpler than general Term rewriting. By the Curry Howard correspondence type-level programming in a dependently typed language (a language in which types can depend on values) is the same as programming in a relational logic language (Prolog) although I am probably mistaken about a few things... youtube.com/watch?v=HnOix9TFy1A&t=...


Javascript. I mean, seriously, it took years for me to understand prototypal inheritace, function as a constructor, this behavior, event loop. I managed to finally comprehend the concepts right by the time es6 was out, ironically.


I feel like ES6 did such a good job of making JavaScript more consistent, to the point where even older inconsistent concepts started clicking for me because I could finally compare them to something that made sense to me.


Took me a long time to really know this stuff, too. I read a book – Principles of Object-Oriented JavaScript by Nicholas C. Zakas – several years ago and it clicked everything together that I had only known in general, disconnected ways. Maybe I should have read a book years prior, and not just a litany of tutorials :)


Good point, books are time consuming in a short-term but oh so paying in a long-term


Prototypes are IMO better than classes, much more versatile, and much simpler.


I hear ya. I used JS for web programming as a complement to PHP and when I had to use it for standalone development I didn't really feel comfy until I met Typescript. CLASS!


I went Java, Prolog, NetLogo, Haskell within one year of uni, learning C++ soon after. That may have been why I've never really considered a programming language's syntax hard to learn. Ecosystem, documentation and day-to-day use, now that's a different story.

However, it would be incorrect to consider a specific modern (non-joke) language easier than another as they have learning curves of different shapes. Python and Javascript are easy to get into, but for complex applications I'd rather have a type system to cover my back.


Typing doesn't cover your back... it wastes your time actually.

TDD does cover your back ;)


Typing saves a lot of time, as it allows for much easier, and more extensive refactoring. Because your first version will never be the final version, you will need to refactor time and time again

This is most certainly not a black-and-white issue.

It's not just the language, but how it fits our various brains.

Exactly... I used to C# before, and after I used python I see why typing isnt my friend anymore.

I just do proper tests and grow my apps super fast.

@ben While you code your brain types code anyway, as in “I expect this argument to be a string, the next one is an integer etc.”

I have no strong preference on dynamic vs static typing, there are lots of languages I like in both camps.

However, types always get specified one way or another, either during compile time or adhoc during tests and runtime.

I agree that older type systems feel more of a burden than actually useful, but the same cannot be said for Haskell, Elm or Rust.


This is the problem with C-like languages. It is a different story with ML languages. With ML languages you do not spend much time writing types because of type inference. On the other hand, you have more guarantees about the absence of errors if compiles. I write series of posts about types to show practical side of type systems dev.to/t/pragmatictypes


I think the necessity of strict typing correlates with fast prototyping vs scaled up core code.

For startups with quickly growing projects, TDD + a dynamic language is a very good way to stay fast and agile. But I've noticed that eventually you hit a point where you really want to rewrite core functionality in a stricter language to reach specific levels of safety which are extremely tedious to achieve with dynamic typing + TDD.

With Haskell, the type system is so good, that I've found that tests often don't even make sense — the type signature is pretty much guarding (and documenting) exactly what the function does.

Now that everything from python to PHP has typehints and JS has several typed dialects, I'd say: use them! You'll notice that they're going to save you in places where you thought tests were perfect.

There is a reason larger companies have come up with languages like Go, Typescript, Flow, Rust, Dart, HHVM, etc — they noticed dynamically typed code doesn't scale to the levels they needed.

I think optional typing introduced in Python 3.7 is a great addition. Like you, I now want to go back to some core elements and add stricter rules

There are ways of adding types to untyped Python code like google's pytype (static), monkeytype(dynamic) or some other library that randomly generates values into functions, runs thems, and sees what errors happen... However, at least monkeytype (its based on intercepting function calls and assuming that if you call a function with a list it must take a list object, but thats wrong because you can use any sequence). There was a talk where someone built one that randomly injected mock objects into code and given a type-inference algorithm would get the most general type (dynamically), I need to google that again, I tried building one myself too...


Others have already posted comments defending their subjective love of type systems. But there is an objective observations I would like to add:

Using a good type system, you can prove your program's correctness on type level, because it makes writing a program the same thing as formulating a mathematical proof.

With a test, all you have is a sample. If and only if your code is pure, such a sample proves you that your code works on the sampled input.

Of course (human) testing has its own strengths; for one, it can find problems in the algorithm itself rather than its implementation.

As a practical example of the value of typing (with monads) I'm going to point to the obvious NoRedInk example.

Hmm... I agree on type level correctness with you.

But, this goes onto the critical issue with TDD, most people misunderstand it and tend to talk about the code coverage metrics where it all got wrong.

Suppose you do TDD on the business rules metrics and 99% of them are well tested, meaning all the behavior your code is correct (from the business perspective)... would you really care about type level correctness?

As for the NoRedInk example, this got to do also with the TDD and it's an exceptional case IMO.

People tend to test JS frontend code, and what is JS mostly doing? it manipulates the DOM / BOM... UI stuff.

Basically UI testing is glue testing, you change the UI tomorrow, and you gotta change the tests too. It's like testing 1 + 1 = 2.

That's where elm typing is really great, you don't need to test UI, however you verify what you're doing with typing ;)


Python has optional typing with mypy and its annotations though, but I'd go for tests first not types and maybe generate the types from the tests : ). Tests can't check every code path like types, but they catch more errors overall and they are a better form of documentation.

which is easier to understand:
filter(pred: Function[A]->Boolean, seq: Sequence[A]) -> Sequence[A]
% isOdd = lambda: x % 2 == 0
% list(filter(isOdd, range(0, 6)))
[1, 3, 5]

The unit test which is the same as replacing the types with actual values, can tell you more about the function because it actually tells you what the function actually does, and the types just tell you that you take in a Sequence and return a Sequence while the example test tells you that the return value is a subset of the sequence and that it uses the pred function to create that subset. You can generate the types from the test values BTW, and its easier for someone to generalize values to types than the opposite. Also types give you a false sense of security, and they can't check that you wrote your filter function correctly because all they care about is the domain of the values not what the function ACTUALLY does.


You're making the comparison by using the most useless example of types imaginable. For a fair comparison you'd be using at least Elm's type system, but preferably Haskell's or even Agda's.


Ever? Learned Turbo Pascal as a hobby... No classroom, no internet, no tutorials... It was the late 80s. Sometimes the difficulty isn't the language but the reaources


Turbo Pascal was great. Didn't have the problems C had (pointers). And eventually took me to Delphi. Great.


What was Turbo Pascal like as a pure language? Any modern comparisons?


Turbo Pascal was pretty straight forward with functions, loops and conditionals so in that sense it has elements from a lot of modern languages. It was like C but a lot simpler to use.

I used Turbo Pascal in university. I remember implementing Runge-Kutta methods in it for solving diffential equations numerically.

Everything ran on MSDOS so the IDE and debugging experience was nothing compared to today.

The funny thing is that it was created by Anders Hejlsberg, the Danish guy who also designed C# and TypeScript.

That said for its time the IDE for Borland Turbo Pascal (and Turbo C) was pretty good.

I really liked Delphi back in the day. I think its popularity took a tank because of .NET and... web apps :-)


Very similar to C as far as I can remember.


I actively refuse to learn languages which would have a hard syntax with no obvious benefits. I have looked at both Rust and Haskell and I decided not to learn either. I can't think into "functional" languages.

The "hardest" language I've learned so far is probably VimL. It is somewhat like Tcl, but it additional supports actually editing the buffer.


What was your issue with Rust syntax?


It has too many underscores and it doesn't support global variables.

What is a global variable, in this context, and why would one use it?

A global variable is a variable that can be read and written from everything inside your application and it is awesome for saving states. Sadly, Rust does not know the concept of "static globals".

Just initialize whatever you want to share in the main function and pass it in to where it's needed?

I'm sorry if I sound dismissive, it just really doesn't sound like a good idea.
Words like implicit dependency, side effect, singleton, and not thread safe come to mind.
Why touch something that wasn't passed into your function?

It's definitely not the same, I agree.
Can you give an example of when you'd want to use one?


I think that's a shame — both Haskell and Rust certainly made me think deeply about the way I write code in other languages, inspired me to experiment and question why I follow certain patterns.

I think there's no reason to become an expert in every paradigm, but I think there are certainly direct benefits to regularly practicing with languages which seem weird to you.

Many imperative/OOP languages are adopting functional concepts as well!


Have you tried Lisp yet? I think it provides the same advantages of Haskell without limiting you to one paradigm. Maybe that's one of the reasons as well: I already know Lisp and I use it in practice...


I don't think Haskell's syntax itself is too hard, it's more that you are used to handle things iteratively, with a main function and just running command after command exactly the way you put it.

I've taken the challenge to write a simple 'ai' for a simple game and while it was difficult it gave me an interesting look at Haskell and functional programming. Over and over again I run into situations in imperative languages where I would love to use functional aspects. I'm not trying to convince you to try Haskell, because I don't know if I'll ever use it for anything like that again, but it certainly gave me another perspective at programming.


I'd say the hardest thing about PHP is that it can go wrong so easily and silently, in ways you never expect.

Types are always difficult. Sometimes variables are coerced into another type, but once you get used to it there is something like strpos('1,2,3', 3) throwing you off — "If needle is not a string, it is converted to an integer and applied as the ordinal value of a character."

It's easy to start with and readily available, but you need the docs every single time you do something "new", i.e. something you haven't done at least hundred times before.


I totally agree. If a situation like that occurs, it simply fails silently. Instead of "a character with ASCII value 3 is not in the string" we should get "error: second argument of strpos must be string."


I started learning programming by taking Harvard CS50 on EdX. That program makes you program in C for ten weeks or so, which was hard as a novice. Pointers, memory management, building your own data structures... yikes. When the course finally had a PHP project, it felt magically simple by comparison.

JavaScript is hard for me for a different reason. The paradigm just doesn't fit well in my head. Is it object-oriented? Functional? Procedural? What's the deal with prototypical inheritance? Am I returning a function, or the result of that function? Every time I have to spend extended time with JavaScript, my progress is much slower than in languages like Ruby or Python (and I've barely used Python) because I find it more difficult to reason about.


Haskell was a pain in the ass to learn, but it's my favorite languge since xD


I'm on the same page when it came to learning C. Assembly was also a huge challenge; I took a Computer Systems class at university and having to declare every last detail of how my program interacted with memory and CPU felt like a nightmare after being accustomed to Java.

In the end, I really liked learning C. Before taking Computer Systems, I hadn't really thought about computation as being limited to the resources of a computer, nor had I ever thought about how many facets there are to writing and choosing operating systems. Afterward, I found a whole new appreciation for the elegance of underlying language features like Java's garbage collector.


I'd have to point at 6502, Prolog, LISP / Scheme, and F#.

BASIC was the first language I learned. 6502 assembly was the second. 6502 was "hard" only because I was self-taught, and I was a kid.

(Learned 68000 assembly later, and my 6502 experience made me appreciate both the simplicity of the 6502, and the orthogonal expressiveness of the 68000.)

I learned Prolog while I was a linguistics major. It was very different from the procedural languages I learned. I had to do a lot of learning on how to use it. (Shout out to Dr. Kac, he's awesome!)

I learned LISP / Scheme as a computer science major, with a professor who didn't click for me. I wouldn't call them "hardest", but rather "least appreciated at the time" and I didn't like them much. I think I have better perspective these days to appreciate how powerful they are.

I learned F# a few years ago. Technically, wasn't hard... once I found a good book (after slogging through a half-dozen books that didn't work for me). It was fun! But it was mind-blowing and a very different programming paradigm than what I was used to. And coming to grips with a different paradigm like that is hard. Makes me cringe when people call C++ or JavaScript functional programming languages.

Haskell is pure FP, Scala is OO w/FP, F# is FP w/OO on the edges (the OO being necessary to fit into the .NET context).


While not the hardest really, JavaScript really gets to me sometimes. ES6 has helped but also frustrated me more (I sort of feel like changing how this operates in arrow functions just made the language inconsistent).

Coming from a languages like C++ (my first language, don't use it at work, but it's my favorite), I don't understand why they had to make JavaScript seem so similar to other languages yet so different at the same time.

Like I understand how this works in JavaScript yet when I use it everyday still, I STILL run into issues with me not using it correctly because the meaning in my mind is not what I was taught when I first learned programming.

Like I absolutely hate that in JavaScript that I pretty much have to use this.propertyName to access a class member variable when I'm already inside a member function. It's so simple yet being trained in one language and using that as the backend, then moving to JS where you have to use it differently, gets to me.

But, when I was in school I had to learn Prolog and that really threw me for a loop. I also "learned" some MIPS assembly and of course that was the hardest (making a double linked list in assembly...never again).


It's not shockingly original on this thread, but for me it was trying to do anything even remotely serious in C (as in, outside of basic, classroom-like exercises). Coming from JavaScript, it was the memory management that felt like I was swimming with sharks -- as it has been for many others.

Though I would say that's the "hardest" I've learned in terms of the challenge, I actually found myself really enthused at getting into the low-level realm of programming, and felt far more excited by the nitty gritty of C than when I learned Python not too long after. I've considered diving into Scala, but haven't taken the plunge quite yet.

I adore the learning process of taking on a new programming language, and so have just started exploring Rust, and am liking what I'm seeing so far.


First language was LISP, for programming neural networks in the early 1990's which was ok but followed by prolog for natural language processing which definitely was not. C was easy by comparison and JavaScript but never really got on with VBA or C++ for anything properly object oriented.


x86 assembly is pretty messy, but Intel Microcode (to write assembly instruction), is a whole other level.
If that does not count as programming language, Rust's complex lifetime tracking or embedded C can get really complex too.


After focusing on writing a parser in C, I was told that I had to then rewrite it in Java.

Since I had just taught myself C, to write the parser, I assumed that teaching myself Java wouldn't be much more difficult and probably easier.


It was my first taste of OOP and the contract ended before I could wrap my head around the concepts much less the differences.


I tried learning Scala early in my career (started from PHP), and I felt it was over my head. I tried for a month or so and eventually gave up. It was a nice language, but I realized over time, it just wasn't what I needed, or wanted.

Since then one that was tricky but i learned a great deal from was Erlang. I never used it full time but i loved its elegance and it taught me recursion.

Overall though, right now, having mostly used scripting languages my whole career (I did play with C# at one point though), I am learning Rust. And it is challenging. But it is also so very fun to learn. When I played with go it was tricky and odd to learn to use the type system as I wasn't used to a lower level language. But I made do. But here to feel like the type system makes more sense. Maybe that's just my experience in general. But Rust has been a very tough, but fun language to learn.


One language worth mentioning is unreal script which was a programming language for Unreal Development Kit, it's no longer used but it was so weird

int number= 2; // work, 
int number = 2; // won't work 

looks like a bug in the parser :D


Working with Verilog (a hardware-description language) in college was a real struggle for me. Even though it looks kinda like conventional code, it does not execute like conventional code, top-to-bottom. Instead it executes as hardware would, in "time-slices", which made it very difficult for me to reason about. It was really cool when I simulated a MIPS CPU entirely in Verilog, except that I could never get it working properly.


I took me a lot to get the grasp of C and also because it was the first language I ever learned. I remember that pointers and memory management was one of the toughest things I faced but one indeed that built my logic and algorithmic thinking.


Objective C always makes my eyes glaze over. I wanted to do some iOS development and that language always made me give up. I basically learned the language but never found it very easy.

There are harder languages but mostly those are the ones I haven’t bothered with.

I’ve played with Rust and basically gotten totally lost pretty quickly.

Surprisingly I messed around with Erlang and found it pretty grokable. I didn’t do anything complicated, but it doesn’t have a reputation for approachability.


In my experience, it's been more of a matter of a language being obtuse, poorly designed (aka lack of basic computer language structures and syntax) or having bad/annoying development environment design.

The most annoying I've worked with was Gupta SQL Windows. I had to learn an old version of it to support an important legacy application where I worked at the time. The files were all binary, which made compares and searches difficult to impossible. The IDE, which you had to use to do any development, was outdated and clunky. It was inadequate for the 90's much less today. Even entering a line of code required a complex set of keystrokes and it was easy to make typos and it was difficult to undo them. On top of that, the code was poorly designed since it was originally written by a mechanical engineer with no experience in software development.

So far as learning curve, I'd say it was when I was learning C++ and gaining an understanding of OOP during the mid-1990's. This was a big jump from the earlier procedural programming I had done in MASM, C and QuickBasic.


Probably Rust and Elixir for me. I felt like if I had given it a little more time, I could have gotten to an aha moment with Elixir, but needed more practice. Rust's memory management is really hard to grok and the difference between str and String was frustrating. One of the reasons I really like Go is that you get the static typing and speed of Rust, but it has a lower learning curve.


My first language in school was c++. I hated it, figured I wasn't cut out to code. Then a couple years later I started playing with some javascript and then Python. At some point I realized that I could do this, but I'm not using c++ to do it.


As a student I learned many languages and would say Java was the one I had the most trouble with and did not like so much.

I think this was because it was purely Object Orientated and coming from other languages which had primitive types and allowed both structured programming as well as OO it felt restrictive and more complex than necessary.


What was your background before Java?


HTML, Oh my god it was overwhelming I had to memorize 6 different heading tags like who does that?! It's wayyy to complex man.


surprisingly, HTML is just a markup language(hence, called Hyper Text Markup Language). The title says Hardest "programming language" to learn. you have your opinion so I just want to clarify that HTML is not hard and it's not easy.


Facts man, but I was just joking I don't consider HTML as a programming language.


As a kid, I learned BASIC and Pascal, and then in high school and college, I learned C/C++. I didn't use comp sci in my career for almost a decade. When I came back, I immediately had to learn Java and JS. They were fine. They did have some tricks up their sleeves, though.

I "get" promises. I've even kept some of my promises. I do have to admit that JS promises are still a very common stumbling block for me.

I know it's not a language...


Likely C++, and not because the language is supposed to be somehow particularly difficult, but because it's terrible.

The compilers are useless at telling you what is wrong, even when it's something super obvious to every other language's compiler on the planet. The language is full of gotchas, "oh your destructor isn't virtual so I'm not going to call it" kind of things.

Full of keywords that are pointless and don't have any sensible meaning, such as that virtual.

The language would be very nice, if it wasn't for the fact that it's near unusable due to these things. Also header files should've not survived the 80s.


For me it was apl. It wasn't so much the writing of the program, but trying to understand one that I had already written, or even worse, one that someone else had written. But that was many years ago shortly after I had learned my first language, FORTRAN. Since then I have picked up Pascal, BASIC, C, PL/M, tcl, perl, c++, Java, python and a few others, along with a number of scripting languages. A couple of them like c++ and java approached the difficulty of apl, but nothing else has been that difficult.


Back in college I really struggled with SQL! I remember trying to do things imperatively - grabbing a cursor, explicitly iterating over it, cross referencing other tables. Only after using it a bunch did I learn how to work with SQL's declarative query syntax rather than against it, and I'm much happier now!

In recent memory, Idris was the most mind-bending language I've tried out. It's capable of some really astounding feats, but wrapping my head around dependent types was really challenging. It was very rewarding though; I recommend checking out Idris if you enjoyed Haskell!


I've worked most of my time with statically typed or strictly typed languages with explicit reasoning.

Javascript gave me a lot of hell and headaches, and typescript's doing it all over again.

I find myself way more comfortable with C or rust


No one mentioned ATS so far... If you want to use Haskell-like type safety with C-like memory control using more sophisticated linear logic than Rust, try this, and know what is really difficult to learn.


I've given myself the goal of learning as many different languages as possible and actually producing projects for each language learnt. Even though I've learnt about functional programming and Prolog at school, they are still giving me trouble.

I suppose that I've been formatted by imperative languages.


Hi Gang
Fun discussion, having come a different road into programming via my Degree in Computational Mathematics from most of the programmers I know and after 30+ years in the industry utilizing a dozen or so languages pursuing an aerospace career I put my vote towards Assembly in all its specific hardware requirements glory. Because it is truly a low level language and must be engineered for each specific piece of hardware architecture in the executions flow. When this hardware is in LEO (Low Earth Orbit) refactoring becomes problematic. (We really are getting much better at it since I joined the industry in 1988). Assembly is hard to read and understand with anything but a focused attention and it isn't easy to learn even for a mathematician.
For the longest time Assembly programmers unlike HL programmers wrote our entire programs from scratch without benefit of standard libraries enjoyed by the likes of C, Ada and Modula-2 programmers of the time. I usually had to rewrite integer output routines each time due to hardware architecture issues. Finally Cal Riverside introduced the UCR Standards Library (March, 1992) for 80&86 Assembly architectures and we had some redundant subroutines available.

Finally the myth that Modern Compilers have eliminated the need for Assembly programming is just that a myth and with the current explosive growth of the Satellite and Launch business has left our industry in the lurch with a drought of qualified Assembly Programmers. When it comes down to the High Requirements and the demands to the hardware and the costs involved nothing that I've seen can ultimately replace well written and tested Assembly or the Professional Assembly Programmers that helped build our Space Based modern infrastructure.
Just my 2 cents
Thanks for all the great replies


Any assembly language is hard to learn and to grasp, but once you're immersed into it it seems to get manageable. I remember a university project where we were building a 6502 emulator in x86 assembly. In the end we wrote hangman in 6502 assembly, and while daunting at first we got it working. In my recollection, the most important part is how to split up the functionality — although I have to admit, our emulator was quite basic and not exactly rocket science.

What I've heard is that compiled C is often as efficient, if not more efficient, than assembly, because of the optimizations in the compiler. What do you think about this? And why are you using assembly — is it efficiency or something else?


if i might:
use stack
the only language extension you should care about is OverloadedStrings (see below). the rest are either syntactic sugar (RecordWildCards, ApplicativeDo) or advanced features you don't need to worry about until you need them, in which case the compiler and/or stackoverflow will let you know.
don't use String if you can possibly avoid it. it's ok for very basic stuff but honestly not worth it. use Text when you can and ByteString when you have to. the OverloadedStrings extension makes all this WAY easier.
read Haskell Proframming from First Principles. there's a reason everyone just calls it "haskellbook." i can promise you it's entirely burrito-free.
after you switch to stack you can take advantage of stackage.org, which is nicer than hackage. i also like hayoo.fh-wedel.de/ for searching for stuff.

sorry if this came off as lectury or obstreperous, it's just that haskell is a really rad language and i'd hate for you to miss out on it.


Lua. It might be because it was the first language I ever learned. But even now, having more experience with an array of languages, I still see a steep learning curve.

Specifically I learned to use it with Löve2d

It is extraordinarily not-strict. No guidelines, no rules, you basically make your own framework every time you make a program.

If you are not familiar with the basic workings of other languages, certain coding conventions, or OOP, the looseness of Lua can lead you to make some terrifying spaghetti monsters.

But, looking back at it now, I can definitely appreciate the freedom it gives you, and how it forced me to learn certain things that I may have not learned in another language.


Elixir isn't a difficult language to learn, but it's a hard one to master. I've been working with it for about a year now and I'm still lost a good 20% of the time. It just requires an entirely new mindset, which I find hard to get used to.


In 11 years, I did projects in C, C++, C#, Java, JavaScript, TypeScript, Prolog, Clips, PHP, Shell Script, Lua, BPEL?, Matlab, SQL?, PL/SQL, XQuery, XSLT.

The one I enjoyed the least was C as it is quite low level, I felt like trying to invest the wheel (even if it is a nice one, it does not make me feel happy).

I would not say that a language is harder than another, they have different philosophies and a different mindset is sometimes needed to use them properly.


It was classic ASP/VBScript. Up until then my programming experience was very limited and limited to ActionScript, because i was more of a designer.
So one day i decided to learn programming. I had a cd with ASP tutorials and the IIS server. On that day i saw that programming was my thing instead of web design, and i never looked back. I spent 6 months playing with ASP/VBScript until i found PHP and the weird .php3 file extension; i abandoned ASP completely, and eventually i abandoned PHP and ActionScript too. And i'm thankful for AS3 to have taught me OOP.


I started with turbo pascal, clipper, x51 and x86 assembly about 35 years ago. Followed by php, c, c#, VHDL and ARM assembly, which was the hardest and funniest at the same time. I never liked languages where I don't know what is going on behind the scenes, like c++, java, ... Even C# is "too much".


Prolog, partly because of how "outdated" the resources were (or used to be, I don't know, it was half a decade ago), partly because of a mischievous lecturer, and partly because of the heavy mind twist to make things work in Prolog. Follows by pure C when I was learning distribution and parallel programming calls where heavy pointers were used and it was a lot of nearly unreadable code...


Since I'm someone with a C/Go/Asm background, I've had a real hard time to understand FP and the whole thing with lambda calculus behind it. The fact that I also disliked the paradigm (since it really differs from how a computer actually works) didn't help much.

Erlang and haskell took me a while to understand due to the reasons mentioned above.

Rust gave me a hell of a headache with the borrow checker and its lifetimes.

Modern javascript was (and still is) a pain in the ass for me. I used to do some stuff with it back in 2012, before ES6. Modern JS just pisses me off, and it only gets even worse when I see that it's trying to adopt lots of FP concepts into it.


I initially started programming in assembly language for microcontrollers and resisting C because of the overhead. I soon learned that the overhead was worth the increase in productivity. It was hard to learn but well worth it.
I have subsequently learned C++ for Pc's and prefer it to, say, labview for the lower overhead and much better debugging capability. I have been writting code in C++ for several yaers now.

Method_missing is considered hard? Thats something ironic because Alan Kay when he thought of OOP he thought each object was a process or interpreter for an embedded domain specific language, and static methods are just a special case of method_missing. The problem is that people start coding in Java/C#/C++ and think that is that OOP means classes with static methods, when it originally meant (according to Alan Kay) something like Erlang, Smalltalk, or Ruby.


For me it'd probably have to be JavaScript. I always had a hard time with it, because of how messy it can get.

Plus my brain just generally has a harder time wrapping around it.


Some time ago, it was Erlang. Later this place was occupied by Haskell and Clojure. Currently It's all badly projected weird languages...


I'm not sure what you mean by "learned" as after years of experience, I'm still learning.


Prolog and Haskell, definitely... I would say Perl, but I gave up on learning Perl after a couple hours xD


Probably not strictly a programming language, but SQL got me burning in rage.


LISP.... oh the brackets (and without syntax highlighting!!!)


i see what you mean, i've also felt the same difficulty in dealing with functional abstraction reasoning, but what i found was that inherent difficulty is not by the language itself but by our cognitive biases towards it.

it seems to me there's a paradox laying in here; for one thing, we are accustomed in the real world to process and classify information and put them on well defined classes, and this seems to make much sense for survival ends as much depends on it, like the ability to recognize predators and such, but for nature the mathematical way has proven the most efficient to describe the events surrounding us, because nature abhorrents waste, it's the occam razor principle in action.

so, by this, we might come to the conclusion that the functional paradigm is the best and simpler problem solver, but if so why it seems so unnatural to us? one way to explain this apparent contradiction might be because we are accustomed to thinking that way and by the way we have learned to program in the first place, diskstra used to say whoever learned to program in basic has the mind mutilated beyond repair.

one other way to view this is by acknowledging that every problem has some amount of fixed complexity, measured in a convenient way with a proper metric, like kolmogorov complexity expressed in bits, that remains the same regardless of implementation. in a programming environment that complexity is shared between the programmer and the tools he uses to accomplish the task, that's why we are more productive the better the tools we work with. for instance, if we want to nail a nail an hammer is much more suitable than a scissor because much of the complexity of nailing is pushed to the hammer, while with the scissor all the hard work must be provided by the worker himself.

if terms of computer languages, we might simplify things by considering only the binomial between the programmer and the compiler. the same way we did for the nail, we might consider the complexity of the problem being shared between the programmer and the compiler. so, in my view, in the functional approach the compiler gets its hands dirtier, while in an imperative one the programmer as to deal with more low-level details to reach a solution; the same can be said between an high-level and a low-level language: the complexity is the same, but in a high-level scenario the compiler takes care of more implementation details for us by way of abstracting our reasoning trough some language statements. i like to think of a funcional compiler like haskell's ghc as a virtual machine for the universe's hardware, it abstracts problem solving trough a language based on the most pure abstraction modeling of nature we have conceived: mathmatics, we only can´t perceive it that way because being hunter-collector beings we are more used and exposed to an ontological rather than mechanical/algorithmic way of processing events


What is the alternative you went with?


Ruby oh Ruby. I took a couple of weeks with it and did come up with nothing. Not even sure how to deploy it. But sure the code looks cool!


Still have no idea how I managed to understand even one code snippet of assembly- but here we are today, with less headaches at that! :)


You need to have a look at the BF PL 😂


JS in Angular framework ... god it's horrible.


So you think PHP is the hardest language to learn. Really ?


I am a guy of high level business database programming. Started off with Clipper, then Delphi was my second love. PHP was the best replacement I found for web (and even some scripting) programming. It has flaws and inconsistencies but it is easy and flexible.


Mumps, its source code looked like a typewriter threw up. Like others, once I learned, I loved the language.


OCaml. It's advanced programming language so.


For me it was VHDL and VeriLog, and I got to a point were I was like stuff it and taught myself Python


I'll say Dart for me... being a Javascript, Typescript, Php developper... it's quite confusing to use dart.

It's interesting to see how subjective it is to answer that question. My opinion is that PHP's syntax and its OOP's concepts make this language one of the simplest languages to start with.


I am pretty good with python and js, but when I took C in college I was like WTF is this.

code of conduct - report abuse