holy fffff

Back to Introduce Yourself forum

meta_lim     2018-02-25 00:10:06

Holy shit. This website is broken beyond belief. Bad UX and antipatterns all over the place, like minimal length of names and titles, broken rename, disappearing error popups. Design choises are awful. Like source code submission with language selection, but without actual verification. Or request to read all input from stdin. There's no stdin in Javascript. There is in node.js. Or this textbox... No wraps.

Feels like time-travel to 1996.

WakeMeAtThree     2018-02-25 14:19:48
User avatar

The time-travel to 1996 design is by intention, and meant to be nostalgic to older websites. I personally like it. The website admin is probably busy with his life to maintain the other issues of broken links in interactive problems, but if he does get the free time, I'm sure he would fix it up.

CodeAbbey problems list is well curated, and touches on different points in a way that helped me find gaps in my knowledge. If these issues are hindering your learning, feel free to go to a website that has a more modern feel to it.

Alexander Faris     2018-03-05 13:42:56

Names

The minimal length of names appears to be linked to reward for a high ranking. In that you can have a short name if you are high enough ranked.

It is easy enough to change your name, if you are having difficulties then perhaps you should email the sys admin.

Pop-ups

Pop-ups, what pop-ups? I am blocking adverts, so the only pop-ups must be advert based ones.

Language Verification

Language verification would require executing the code in some environment, and giving it the input and then checking it against the desired output. Since not all problems can be solved with the standard libraries for each language and some problems cannot be solved in exactly the way required, this would be impossible. The site would have to attempt to emulate everyones enviroment and compiler/interpreter setup.

Language Limitations

So far I have encountered the following limitations, and and my solutions.

  • Arbitrary length arithmetic: Don’t have it so imported a third party library.

  • Modifying Strings in place: Strings are immutable in the language I am using, so with some problems, came as close as I could, or just had to construct a fresh string.

  • Arrays, I cannot always use an array in the way requested for some problems, since the language I am using doesn’t technically have arrays, only dictionaries/hash maps that act as arrays if you consistently treat them as such. Usually not a problem, but sometimes I had to be creative, (In these cases I wouldn’t have solved the problem using an array/sequence in the real world.)

All languages have their limitations. Some of the problems I have solved, would have been much easier in a language with feature “x”. But that is just the way it is, all good languages are better at some things and worse at others. It is impossible to have a perfect language in that adding a feature that one person wants, can reduced the language’s usability in another area.

I am often asked why is there no increment/decrement operators in Lua, why:

a = a + 1

Why not:

a++

The Lua compiler (it is compiles to bytecodes for a virtual machine), uses a single-pass recursive descent parser, that generates bytecode during this single pass.

If it did multiple passes, or implemented lookahead then yes, you could have these operators, but the compiler would be slower, and Lua’s selling point is speed, and a small footprint (under 300k for 64bit with all the standard Libraries on Linux). This would therefore reduce its usability in its market area. I use Lua with microprocessors running at 80MHz, yes MHz, a slower Lua would not be useful, and being able to remotely connect to these processors and interactively work with them in real time, via the Lua equivalent of the Python console, is just something I could not do with C.

Sometimes an extra feature can stab you in the back, Lua uses double precision for all numbers, so with problem #81 Bit Count I have the problem of not being able to create a 32 bit unsigned number. So I had to use a 64 bit one, convert it to a floating point, and then discard the upper bits, so that I could do a right shift and the answer will be the same as if it was a 32 bit unsigned int.

It is just the way it is, and that is why we have such a large selection of programming languages for different tasks.

Stdin Javascript

As for reading from the stdin in Javascript. I assume you not trying to do this in a web browser and are actually using a standalone version of Javascript. Some solutions:

  • Common.js has system.stdin, see: http://wiki.commonjs.org/wiki/System/1.0 a number of standalone interpreters implement it.

  • You can use the Rhino Javascript engine: https://en.wikipedia.org/wiki/Rhino%28JavaScriptengine%29 it uses Java’s input classes.

  • You could use your Unit Testing framework to output read/write to the console, such as Test Complete from Smart Bear.

  • You could look at some of the solutions here, ask other Javascript programmers, or ask at a number of similar sites to this one. Ones which also require problems to be solved by using stdin/stdout. I won’t post links to them here, as advertising them on a competing site is not really on.

Please login and solve 5 problems to be able to post at forum