I graduated in 1990 in Electrical Engineering and since then I have been in university, doing research in the field of DSP. To me programming is more a tool than a job.
Languages that I do not like to use? There are few. In approximate decreasing order of disliking:
PHP & Javascript
C++
C.
Why? Because they are too much "bug prone" and the resulting software is quite often a mess to maintain.
PHP and JS are, in my opinion, the worst offenders since they try to "read your mind;" if something is not canonical (e.g., you are trying to multiply an integer and a map) they do the impossible to avoid raising an error, often converting everything in everything else with results that can be hilarious but are actually worrying if you think that most of the web is built on that. Also their "type volatility" makes the equality == non-transitive... and if your language has a non-transitive equality operator, you know that it has some serious design issues (indeed, they also provide the === as a patch). PHP also has a "too surprising" API, with many related functions using different conventions and this makes it difficult to remember how a function is to be called. This, however, is a minor annoyance that can be solved with a look to the manual (which is quite good, even if counter-intuitive to navigate at times)
C++ is a bit better since, although it is not type strict (automatic conversions happen, for example, between float and int), it is not as type-volatile as PHP and JS. Nevertheless, it grafts the complexity of OOP on the frail basis of the C. A giant with the feet of clay.
Also, the idea of C++ template is nice, but the implementation leaves much to be desired. The syntax is quite obscure and the impression it gives to me (but it is just a personal feeling) is something that has been attached at the last moment. At least it avoids the worst use of macros.
Ah, yes, the macros... (this applies both for C and C++)
They can be fine (maybe) to define constants (but I would prefer something embedded in the language and not based on pre-processing). The true problem rises when they are used to do processing (e.g., embedding loops in macros... I have been guilty of this) or even change the syntax of the language (replacing '{' and '}' with BEGIN and END is the least serious offence in this respect). The result can look cool, but it is as frail as it can be since it is based on pure text substitution.
No, macro-based pre-processing has no place in robust software.
Finally we come to C, maybe the least serious offender. What I do not like of C is that it is too much lenient and accepts code like this
1;/* At most you get a "warning: no side effect" */
Also, C is too-much low-level with the pointer arithmetic and the excessive use of pointers it requires (you need them even for read stuff from the keyboard!). Pointers always bring with them the potential of bugs, even nasty ones. Yes "dangling pointer," I am looking at you... A dangling pointer bug can require days of hunting because it can manifest itself in any place in the code (e.g., when doing a malloc if the dangling pointer caused a corruption of the heap).
In defense of C it must be said that I think that the objective was to have a language that was easy to compile and with access to low-level details, so that one could do some hand-optimization (nowadays I would leave the optimization stuff to the compiler, the processors are too complex and compilers are very good). Given these constraints, I guess that C is a good solution.
Oh, yes, ... I was forgetting.... the ternary operatorcond ? then : else. The idea is nice and sometimes it can be really useful, but the syntax is awful and it gets obscure if you have two of the nested. I prefer, for example,
(ifConditionthenThen_ValueelseElse_Value)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Languages that I do not like to use? There are few. In approximate decreasing order of disliking:
Why? Because they are too much "bug prone" and the resulting software is quite often a mess to maintain.
PHP and JS are, in my opinion, the worst offenders since they try to "read your mind;" if something is not canonical (e.g., you are trying to multiply an integer and a map) they do the impossible to avoid raising an error, often converting everything in everything else with results that can be hilarious but are actually worrying if you think that most of the web is built on that. Also their "type volatility" makes the equality == non-transitive... and if your language has a non-transitive equality operator, you know that it has some serious design issues (indeed, they also provide the === as a patch). PHP also has a "too surprising" API, with many related functions using different conventions and this makes it difficult to remember how a function is to be called. This, however, is a minor annoyance that can be solved with a look to the manual (which is quite good, even if counter-intuitive to navigate at times)
C++ is a bit better since, although it is not type strict (automatic conversions happen, for example, between float and int), it is not as type-volatile as PHP and JS. Nevertheless, it grafts the complexity of OOP on the frail basis of the C. A giant with the feet of clay.
Also, the idea of C++ template is nice, but the implementation leaves much to be desired. The syntax is quite obscure and the impression it gives to me (but it is just a personal feeling) is something that has been attached at the last moment. At least it avoids the worst use of macros.
Ah, yes, the macros... (this applies both for C and C++)
They can be fine (maybe) to define constants (but I would prefer something embedded in the language and not based on pre-processing). The true problem rises when they are used to do processing (e.g., embedding loops in macros... I have been guilty of this) or even change the syntax of the language (replacing '{' and '}' with BEGIN and END is the least serious offence in this respect). The result can look cool, but it is as frail as it can be since it is based on pure text substitution.
No, macro-based pre-processing has no place in robust software.
Finally we come to C, maybe the least serious offender. What I do not like of C is that it is too much lenient and accepts code like this
Also, C is too-much low-level with the pointer arithmetic and the excessive use of pointers it requires (you need them even for read stuff from the keyboard!). Pointers always bring with them the potential of bugs, even nasty ones. Yes "dangling pointer," I am looking at you... A dangling pointer bug can require days of hunting because it can manifest itself in any place in the code (e.g., when doing a malloc if the dangling pointer caused a corruption of the heap).
In defense of C it must be said that I think that the objective was to have a language that was easy to compile and with access to low-level details, so that one could do some hand-optimization (nowadays I would leave the optimization stuff to the compiler, the processors are too complex and compilers are very good). Given these constraints, I guess that C is a good solution.
Oh, yes, ... I was forgetting.... the ternary operator
cond ? then : else. The idea is nice and sometimes it can be really useful, but the syntax is awful and it gets obscure if you have two of the nested. I prefer, for example,