advocaat23

Nevertheless I heard (I should investigate this rumour) that being lazy enabled an easier integration of the IO system so there seems to be a connection between pure (i.e. side-effect free) and laziness.

Is it concerning that most Haskell optimization guides talk about adding ! to enforce evaluation? It may be a sign that pure functional programming is not quiet there in the real-time world (e.g. real-time rendering) and that some abstractions (declarative instead of imperative) break for these use-cases.

What I want to say is that you really have to know a lot about Haskell to predict a program's runtime performance which is essential in the context of real-time. In my opinion these optimizations seem a little bit hacky: unsafePerformIO is per definition hacky, she-bangs seem sometimes like guess-work and concurrency is always hard to get right (even with MVars).

I really like Haskell but do not consider it yet for latency-sensible tasks as it feels like writing unidiomatic Haskell. In particular I find it concerning that one has to exploit concurrency and parallelism for such a simple game.

Are their ambitions to make GHC (hard) real-time friendly? This will probably require a real-time GC optimized for latency. I would like to read more about this, in particular about using pure (strongly typed) functional languages in a low-level/real-time context. Would it be possible to exploit the type-system there?

Pretty nice. Writing a tetris clone targeting terminals is a fun endeavor and the easiest way to produce some moving graphics (besides Conway's Game of Life). It's also interesting to ignore curses and read and write plain bytes to the terminal and see what happens. I learned lots of nifty details about terminals there and you find pages like this:

http://www.ibb.net/~anne/keyboard/keyboard.html

Firefox@Ubuntu14. I think it works as intended by the designer it just irritates me that some images will stand still while scrolling.

Wow, again a page that messes with the scrolling experience? What's up with that? Terrible user experience.

What a crappy design. If I scroll down and there is an image, I have to scroll further (without visual indication) and then the text will float over.

I have seen this design now on multiple pages, how is this called? IMHO it is a terrible user experience.

//edit: No, really, what's the idea? It really messes up the scrolling experience.

Another approach would be to choose a client server architecture but this is probably faster done in a separate project. But the idea would be that we have something like an editor core that exposes a SMALL API (e.g. "change cursor position to x/y", "insert 'foobar'", etc.) in a well-defined protocol.

On one hand you can then implement the famous VIM UI on top of that (i.e. in the tty sense, a curses program that communicates with the server, sending stuff like "change word") and on the other hand it is really easy to make it scriptable in any language that supports sockets. Obviously the networking/parsing stuff would be hidden by a neovim <LANG$> module.

Obviously this would be a multi-process architecture but the number of processes would be really small and peanuts in a modern system. But anyway, thanks for your work!

/update: just read https://github.com/neovim/neovim/wiki/Plugin-UI-architecture so it IS the chosen architecture - never mind then!

It is true that there are systems (Lisp Machines, Oberon, Smalltalk, etc.) with a more integrated approach and there are great ideas, but what I meant with the term "IDE" is classic IDEs on Windows, Linux and OSX. These OSs are heavily UNIX influenced and for those systems I consider text tools (editors, shells, command-line tools) the easier development UI.

>A simple example is if I want to iterate through every item in a container, I'd like to just type 'for', tab, the first few letters of the container variable, tab, and have it all set up. Resharper does this, and will even name things appropriately for you (if the container is something like myInts or intList, it will name the item myInt).

Yeah, but e.g. in C++ there are many styles of for-loops. How does the IDE find out what you want to do? Different projects adopt different for styles (size_t, iterators, etc.).

>Is it myList.length(), myList.length, myList.Count, len(myList), count(myList)?

That's a legitimate question, but how does your IDE help there? I solve the problem using a

"<language> get length of list"

web-search. Can your IDE answer this question? If I just type

myList.

I will get usually a drop-down menu of all the methods. But then I have to try "c" for count, "l" for length, etc. In particular I have to assume that the size function is a method which is the case in Java, C++, but e.g. not in Python. Or does JetBrains Python version (PyCharm I think) rewrite a.length to len(a)?

My main IDE complaint is that IDEs lock you into languages, libraries and workflows. If you work with a text editor your have to know

  - the language
  - the text editor
  - your build system
  - your version control system

If you work with an IDE you have to know

  - the language
  - a text editor (e.g. remote sessions without X)
  - the build system
  - the version control software
  - the ide
  - probably a plugin that makes your ide editor behave like your text editor
  - a plugin for your language
  - a plugin for you build system
  - in general: how does the IDE's plugin system work

So I like the idea of IDEs, but for me the abstraction always fails and I struggle with its plugins. I give them a try sometimes but most of them are locked into eco-systems:

  - qtcreator: QT, C++
  - eclipse: Java
  - netbeans: Java
  - PyCharm: Python
  - Clion: C/C++

If you work with different languages, libaries and workflows it is often not trivial to make the IDE adapt (in particular, most of them have their own definition of "projects" and scatter you directory trees with hidden files) and the whole dev-setup gets more complicated. What do you do if you have to use a language that's not supported by the IDE?

The text editor abstraction feels more honest: "Look your project is a bunch of text files. I give you the following interface to explore/change this text blobs." Again, I like the idea, but good IDEs were always locked into eco-systems and these change so fast that the IDE seems always behind. I think Smalltalk had an advanced IDE but it locked you into ... Smalltalk.

I had a look at the video and it really seams nice, but for me the cost (learning yet another tool, integrating it into your workflow, dependance on yet another big-size software project) is too high.

The fancy stuff they show you are in my opinion just short-comings of C++ [activate flame-war prevention system] or not THAT important in development. E.g.

- implementing getters/setters: just make the thing public, the whole private/public bullshit is too shallow

- implementing methods: inheritance is normally used with caution and is just a small part of your application (e.g. a core that uses it); you will think about getting this abstraction right (your inheritance tree) and the time it needs typing the text to implement the methods is often small in comparison to the thinking over inheritance.

- completion: IMHO there are different modes you are in, while coding: (0) prototyping (researching the problem, reading API documentation) and (1) implementing a robust solution; In the first case, again, the time it takes you is more constrained by the thinking you do, and in the second case you probably know the API and important functions already (from the previous step) so the auto-complete is not needed anymore.

The coolest thing is the renaming which really might help you tackle one of the hardest CS things (naming things). Furthermore I would not use the Shape example as it is too far fetched from reality. It's like the "let's implement fibonacci numbers" in the FP world. And how do they manage "Makefile" only projects?

I think it's always weird how multi-dimensional arrays are implemented in most C programming books. Do you guys really use a pointer-pointer approach to represent them? Because nowadays I always allocate a flat array and just calculate the indices. E.g.

  struct dmatrix {
    size_t rows, cols;
    double *data;
  }

and then a simple

  double dmatrix_get(struct dmatrix *m, size_t r, size_t c) {
    return m->data[r * m->cols + c];
  }

is all you need? In particular I find explicit array sizes in function headers very contrived and I have never used them in serious code. Normally it's just a pointer and a length argument similar to e.g. read/write functions in the standard library.

Cool tech, but ...

I went to the About-Page and I got the following message out of it:

"We all want to spend our time dooing meaningful things so we ... bla bla ... have to make an app for that".

Come on, I think this is just bullshit. Yes, the premise is correct, people are working too much on stuff they don't like (and we have to fix that), but solving this problem via some time-managment-assistant-whatever-app (oh, there are surely some contrived ML problems to solve here) is just hilarious.

Welcome to HN! Ruby is a good idea for webdev but keep in mind that Python is also dominant in other domains of computing in particular scripting and scientific computing. So in my opinion for a beginner Python is more future proof than Ruby [activate language-flamewar-prevention-daemon] and if you later add a system-language (e.g. C) and a modern general purpose language (e.g. Haskell or Scheme/LISP) to your repertoire you are in a very good position to tackle most kinds of software development problems.

Good news! I would like to add that another advantage of Python is its usage for scientific computing (Math, Physics, Biology, ...) so students hopefully choose Python to help solving problems for their math classes e.g. using numpy and co. They can then get easiliy into IPython which is IMHO a very important FOSS project.

At my university I feel that proprietary scientific programs and CAS like Matlab, Maple and Mathematica are still the preferred problem solvers for students in the hard sciences (except CS).