3 ms·
As a student of the TU Berlin myself, I feel that this has to be taken with a large grain of salt. In the first semester you learn one functional programming la
by DasIch 12y ago
As a student of the TU Berlin myself, I feel that this has to be taken with a large grain of salt. In the first semester you learn one functional programming language, after that it's Java, C and MIPS Assembler.
The functional programming language is Opal, a language developed at the TU Berlin, it has barely any documentation, a compiler that only works on Linux and OS X, that is if it works because it has quite a few bugs, it further comes with a REPL that sometimes produces failures the compiler doesn't and tooling is non-existant.
So as a new CS student you have to learn using Linux and setup a development environment by yourself with barely any documentation to go on. You then continue learning only the very basics of programming such as what functions are, if statements, recursion, big O complexity, a little bit of parsing and though it's called differently: monads. At the end of the semester you then develop a renderer for a regular subset of HTML that includes only <html>, <head>, <body>, <title> and <p style="text-align: {left, right, center, justify};">.
On top of that the language has a couple of weird features: Every function can be used as any kind of operator if the number of arguments fits. This means that the parser has often problems figuring out precedence rules and you end up adding parenthesis around every expression just to be on the safe side.
Number literals also don't exist. There is a pre-defined set of functions which don't take an argument and produce a number such a 1-12 or so, n^10 for a few n, and a couple of 2^n for a few n. All other numbers have to be explicitly converted from strings. In practice this means you do the latter all the time so 1 turns into ("1"!).
Furthermore variables are defined by name and type. You can have two variables called foo in the same scope, if they have a different type and depending on how foo is used (Opal has type inference) one of the variables is chosen.
The prior feature is effectively necessary because Opal also doesn't have polymorphic functions. It has polymorphic "Structures". A Structure is file you can import, within that file you can define a set of variables that are polymorphic, the types of which are defined by however is importing it either explicitly or implicitly through type inference.
This is pretty much like how you might use the pre-processor in C to achieve polymorphism.
Have I mentioned by the way that a Structure is actually just a header like in C? In the Structure you only define the types of the API, the implementation is in a different file.
So a functions like map requires writing two separate files. Luckily it's in the stdlib.
Overall these features are fine, if everything works nicely but if you have an error somewhere, the compiler can emit massive difficult to understand errors, not unlike what a C++ compiler might produce for code that uses templates heavily.
The language and the choice to use that language is heavily critized by pretty much all students, functional programming however is not. In fact pretty much everyone would prefer if Haskell (which is the functional programming language closest to Opal) were used. The only reason it's not, is that the current prof for that class lead the team who developed the language.
- mpweiher 12y agoWe were lucky in that Opal wasn't ready yet. :-P But we were horrified by what we heard about it. So we were spared that particular disaster, which was and is sold using the same "unquestionable superiority" rhetoric. Instead we dealt with Hope. As in "I Hope it will finish in the next 15 minutes". "It" being a 10-30 line program. Usually it didn't, instead producing a largish coredump. Our Sun 3-50 diskless workstations didn't help, but hey, Turbo Pascal could compile + execute a hundred lines of code in a second or two on the Z80 card in my Apple II+, a computer with several orders of magnitude less CPU/memory than those Suns. Later we also used another language, I think it was Miranda. That introduced us to the joys of type inference. Magical when it works, completely inscrutable when it doesn't, especially since you don't get feedback on the cases that do work. The big problem here is not that the tools were buggy and the languages less than fully thought out, that is fine, if presented that way. The problem is the complete disconnect between rhetoric ("perfection", "everything else is steaming pile of manure") and reality (sort of the opposite). In the meantime, tools have certainly improved a lot (ghc/ghci on my MacBook Pro are quite tolerable), but the disconnect between rhetoric and reality is still there, because everything else has also improved. Consider Opal itself: an FP language (so one of the domains FP is actually good at) in active development for more than a quarter of a century by teams using magical, all-conquering, flawless-marvels-of-correctness-producing FP unicorn-technology by teams of programmers that are experts in said technology. And it is, quite frankly, a steaming pile of manure. EDIT: Hope: http://en.wikipedia.org/wiki/Hope_(programming_language) http://en.wikipedia.org/wiki/Hope_(programming_language)
- DasIch 12y agoWell you have to take into account the amount of effort, time and manpower spend on different languages and (in-)directly on different paradigms. FP hasn't been given as much attention as imperative programming languages, especially not when it comes to the important last step of language development, which turns ideas that are nice in theory into tools that are actually convenient to use. Java is a good example for how much that matters. The language is inelegant and makes it impossible to express yourself concisely nevertheless the tooling is incredibly good, so good that it makes up for quite a few surprises. A FP IDE that for example shows you inferred types and type errors while you are writing the code, would already help a lot as it could much better visualize the problem, than a compiler that has to describe an error purely with text. FP languages are not perfect, no language is but they have the potential to be much more powerful in lot of ways than imperative languages. Lisp is a good example for this although it's also a good example that such power can corrupt people to use macros in awful ways. In any case when it comes to the rhetoric especially from professors, you have to take into account that they have spent their entire life specializing on what they are doing. Of course they are excited by what they are doing and even if they aren't they have a good reason to lie to themselves consciously or not because the alternative is acknowledging they wasted their life on bullshit. They are biased and that's ok, you just have to be aware of it.