ceronman

It's not production ready yet, but Kotlin Native is probably the way to go for iOS support.

https://github.com/JetBrains/kotlin-native

I wasn't there :)

I learned to program with Turbo Pascal and then moved to Delphi. While watching your introduction demo my thoughts were "this is like Delphi for the web". I've also missed something like this for a long time.

I'm definitely going to try your product!

This looks really really cool.

In the 90s we had RAD tools like Delphi or Visual Basic which allow you to create simple apps very quickly. I feel that we are missing RAD on the web these days. There are so many different moving pieces. To do a full modern web app you need to learn different languages and frameworks plus other technologies for hosting such as containers or AWS, etc. That might work for complex apps, but sometimes you just want to do something simple that you can easily design visually, use one language and hit one button to publish. I have the feeling that Anvil is moving in this direction.

And extra love for using Python :D

Static vs Dynamic typing... Why one has to win?

I don't think it's about being convinced of benefits of one or another. We need to be convinced about the drawbacks of each approach. Then we will understand that there is no silver bullet and each kind of language has strengths and weaknesses.

I love static typed languages. I love that they show me silly errors as soon as I type them on my IDE. I love that I can get auto complete and automatic refactoring tools. I love that I can easily jump from one function to another by just clicking on their names names as if they were hyperlinks.

I also love dynamic typing. I love how few lines of code you need to do some complex tasks. I love how easy is to manipulate complex structured data coming in JSON, YAML or XML forms. I love how easy is to do metaprogramming with them, how easy is to create your own DSL and make tasks like DB access a piece of cake. I love how you can just REPL into your server running in production, change things, test them and leave.

I like that we have both kind of languages. I chose static typing for some projects and dynamic for others. I hope no paradigm wins. Let us the best tool for the job.

I used to use three monitors: Two 22 inches plus my 15 inches laptop monitor. It though it was a really efficient way of working, but it had a problem: Moving was a hassle. I decided to get rid of the monitors for a while to test their value and I found out it's not such a big improvement. Now I only work in my laptop screen. I have a full mobility and I love that. I don't miss my monitors at all.

I think this exact problem is what makes currying in JS and dynamically typed languages not very practical.

In JS is even worse because of the weak typing, if by mistake you get a curried function instead of a value, JS will happily operate on it giving you things like "hellofunction () {}". When you realize that there is a problem, it would be hard to find the actual cause of the error.

I think this is the reason why dynamic functional languages such as Clojure don't use auto-currying. I a static typed world, like Haskell's this is not a problem at all.

Partial application on the other hand is very useful and practical in JS and other dynamic languages.

> Code requires a whopping 349 megabytes in order to open a 60 byte file. Atom comes in at 256 megabytes. Where Vim “only” needs 5 megabytes, which is still kind of high, but representative of an average configuration

These numbers seem off. I just tested it and my VS Code uses 39MB of memory for loading a bunch of Python files and having a few plugins activated. Where are these numbers coming from? How was this test done?

I switched from Vim to Sublime a while ago. For me Sublime feels much faster and user friendly. I'm now trying VS Code for Python, Go and Clojure. I know is not as fast as Sublime or Vim but it's really user friendly and I'm impress of how quickly the developers have been able to provide awesome functionality into their editor. That for me sounds like a fair tradeoff given that computers these days have several Gigabytes of memory.

The original PlayStation had only 2MB of RAM and 1MB of video memory. Still you could play games such as Metal Gear Solid on it :D

Python's int/long unification was done in Python 2.2 (PEP 237). Which by the way, I think it's a great feature, even if it makes it slower. That is what Python is about after all: simplicity and ease of use over performance. If you really need the max performance possible, don't use Python.

As far as I knew, the only thing that changed in Python 3 was that they renamed the long type to int, and they also removed L suffix. But from your code seems that other things have changed as well and now two structures are used for short integers. Do you know when this happened exactly and why?

Once I learned Perl I never used awk or sed again. Even for one liners with the -n -p -a options you can easily write one liners in Perl that are concise as those in Awk.

> python feels lower level than C++ to me these days.

Yes I know that C++11 has a lot of cool things, but I find hard to believe it's higher level than Python. Even for simple things, C++ code tends to be several times bigger than the Python equivalent. Yes C++ might be faster, but when you need agility, to build a prototype or a script really quickly Python is many times better than C++ (in agility)

Normally I think readability is more important than speed. But in this particular case, I think GNU is doing the right thing optimizing the code to the limit.

This is the beautiful part of Unix: small tools that do only one thing well. Programs following this philosophy are very good abstractions. They do one very well defined thing so you can use them without having to understand how they work. I have used Unix for years and I've never felt the need to read the source code for `yes`. And because they do a very small thing, even if you need to read them, the overhead of optimization is not that much, for example, the optimized GNU yes is just under 100 LOC if you remove comments and help boilerplate. Yes, it's longer than the BSD version, but it's just a matter of minutes to understands what it does.

A few thousands jobs at very poor and dangerous conditions. While the owners for the foreign companies that exploit the mines get 99% of the profits. Really bad deal.

For the Python programmers, there is also a better explanation of the same concept by Brandon Rhodes: The Clean Architecture in Python.

https://www.youtube.com/watch?v=DJtef410XaM

Both are necessary. If Team A leaves, and no more business value is produced, and the devs only care about beautiful code, the company will fail too.

Both kinds of teams are needed. Or even better, teams should not be divided like this, everyone should do their shares of both breaking things, and creating value and cleaning the mess and scaling the things.

This is a strawman argument. Nobody is saying that algorithm and data structures knowledge is preferred over pragmatism, commercial awareness and real world problem solving.

What brianpgordo is saying is that algorithms and data structures are an important quality in addition to those.

How many Google Engineers do you know?

I know quite a few of them. All of them, without exception, are incredibly brilliant engineers. You might think this is just anecdotal evidence, that's correct. But also think that Google Engineers are responsible for many top quality, world class software projects. How could that be possible without really good engineers?

Yes the interview process is tedious and can be frustrating. But negating the fact that they have some of the best software engineers in the world is just silly.

> Is regurgitating an algorithm actually a useful way to interview?

I interview developers. It depends a lot of how you ask the question. Asking "please write a quicksort on the whiteboard" is a pretty bad way of interviewing, you should not expect your candidates to memorize every algorithm invented.

However, if you explain how an algorithm works, and then ask them to write the code for it, you can check if the candidate is able to translate a description to code, which is an essential ability of any programmer.

For example: "In a quicksort, you take a random element of the list (pivot). Then you put all the elements greater than the pivot on the right part, and all the smaller or equal on the left part. Then you repeat the process on each part (left and right) of the list until you can't split anymore." Then based on this description write a simple quicksort in your favorite language, of course you can ask any clarifying questions about how the algorithm works.

I expect a competent programmer to be able to translate the description of the algorithm to code. Yes, it's true that in real world you never have to code a quicksort. But working with simple algorithm makes things easier at the earlier stages of interviewing at large companies, when you usually only have a few minutes to check if the candidate can write some code. Better, more real-world questions are asked at a later stage, when you have more time, typically on a face-to-face interview.

I like to think about Rust's memory management as static/compile-time garbage collection, as opposed to the traditional dynamic/run-time garbage collection in languages such as Java.

The process is mostly automatic because you don't have to manually free the memory you use like you do in C. The difference is that the moment when the memory must be freed is determined at compile time by Rust, while a dynamic GC has to determine this at runtime, which uses more resources but also ends up being easier to use.

The fact that Python 2 is so permissive when mixing bytes and strings I think is the fundamental reason why people think Python 3 strings are broken.

In practice what happens is that Python 3 won't allow you to mix bytes and strings at all, and it will force you decode and encode properly. Python 2 will happily try to implicitly convert to and from ascii when needed. Now, this might seem simpler at the beginning because in Python 2 you require less boilerplate code, but then later, when you have to deal with a different encoding or when you use non ascii characters, you get really weird, hard to debug problems that cause real pain. Python 3's strictness is helping you preventing these kind of cases.

I haven't used Flutter yet, and I think it's probably not production ready yet, but I think it has a lot of potential.

Regarding editor support, it's been great from the very beginning. A few years ago, the Dart Editor was a pleasure to use and nothing else in frontend development was even close, this was before vscode existed. It had integrated debugger and code completion worked really well, it's a bit sad that they decided to discontinue the editor, but these days WebStorm has all the features and more. There are also Atom and vscode plugins but I haven't tried them.

Debugging experience I think it's one of the highlights of Dart tooling. The observatory tool is great and it not only helps with debugging but also with profiling. I seriously recommend it.

More good tooling in Dart includes the package manager which is very well designed and easy to use, and the code formatter which just does the right thing.

Where it falls short: JavaScript interoperation. There is some, but very limited. They are working on it, but it's not quite there yet.

You don't always have to jump to the hype train! Yes, you don't hear much about Dart here on HN, but the project is far from dead. The most important thing is that Dart works, it's stable and production ready and it's being used in production not only by Google but also by other companies.

Dart is a very refreshing change for front-end development. No fatigue! Great tooling, nice language without surprises and optional static typing.

On the backend you get probably the fastests dynamic language out there, maybe competing only with LuaGIT.

The new Flutter for high performance mobile app development looks seriously awesome. I specially love the instant live reloading.

Dart's package ecosystem (pub.dartlang.org) seems healthy with constant updates and new packages.

I have no idea how TIOBE works, but I find weird that people accuse Google of manipulating it to promote Dart. I believe it's the opposite, Google has done very little to promote Dart, and that's why you don't hear about it very often. I believe the project deserves more promotion because it's seriously good. Give it a try one of these days!

EDIT: I do not work for Google

> This is why I'm trying hard to improve my problem solving skills by solving competitive programming problems almost everyday.

Here is another simple tip to improve your ability to recognize algorithms: Just look at the software you use every day and ask yourself how does it work.

When you make a click on your web browser, how does the browser know what element you clicked?

When you tell you StarCraft unit to move to a given point, how does the game engine know what path it should follow.

Are you using a Redis cache with an LRU eviction policy, how does that work? Why it's so fast? (hint: it's not only because it's written in C)

You know that adding indexes to your database columns makes them faster. Why? How does that work? What are the tradeoffs of the the different kinds of indexes.

When you type `ls -R` in the console, what's happening?

How is it that Google can give us the results of searching on trillions of webpages in just a fraction of a second?

It's sad to see a general sentiment here on HN against algorithms and data structures. In reality, most of the tools we use everyday use all those algorithms and data structures.

If you feel that you don't need to know about algorithms and data structures, you probably do very mechanic and simple things like CRUD software. The moment you do something slightly more difficult or at a bigger scale, you are going to need this knowledge. You simply can't be a good developer without understanding these concepts (I'm not saying that it's the only thing you need).

I completely agree with the idea that we are overestimating the impact of tools, specifically, programming languages.

I often see startups that rewrite their software one or more times just because they think that changing the tools is the key to success. They switch from PHP to Python, then from Python to JavaScript then from JavaScript to Go. It's so easy to say "We failed because X language, now we have to use Y".

The case when choosing a given language will give you a considerable advantage over choosing another one is very rare.

The worst thing is that we tend to say that languages suck while completely ignoring all the evidence of the opposite. How many times we have heard that PHP, C++ or JavaScript suck? How many amazing software projects have been built using these technologies?

On the other hand, look at the tools that self proclaim the best ones (lisp, haskell), how many big complex software projects have been built with them?

In the end they're just tools. Yes, they make a difference, but it's tiny compared with all the other pieces of the puzzle of how to build good software.

Static recompilation is not possible, even for simpler CPUs like the 6502 (NES, Apple I, etc). There are parts of the program that you will never know until you actually run it. Forget about a complex x86-64 program.

Apart from that, the complexity of all the system calls made by the program is also a huge challenge as those not always have an equivalent in the new system and are really hard to match at such a low level. It is, however, not impossible. Emulators such as Dolphin do that, also combined with dynamic recompilation.

> I don't know what recourse the PSF has but maybe they should even go all in and defend the "Python" name so as to prevent confusion and stop a potential community fracture. Just call it anything else but "Python 2.8" is not Python.

This! A thousand times! I love open source and free software. I absolutely love the fact that you can fork the code and adapt it to your needs. If you find others who like it great! But please, don't use the Python name! It will create more confusion than help. This fork with a different name is 100% fair in my opinion.

Rayon seems very similar to Java 8 Parallel Streams or C# Parallel LinQ. What are the advantages/disadvantages of the Rust approach?

Two extra advantages of vault based password managers:

1. The manager can automatically change old passwords for you. LastPass support a big set of websites, when Dropbox was hacked this was very handy. I like to change social media passwords every few months and this makes it very easy.

2. You can store passwords that you can remember if necessary. Sometimes I need to access a password for a service or a site in an environment where I don't have an easy access to my password manager, for example when I'm using a friend's phone or when I SSHd into another machine. In those cases is handy to have some passwords that you remember, but are stored in the vault just in case you forget them. I only do this for a few passwords, but it's a nice feature to have.

"Starting from Celery 5.0 only Python 3.5+ will be supported."

This is a small detail, but I'm glad that one more big Python project is dropping 2.x support. The 2/3 split is not good for the community.

Even if you design only one project. You still have to evaluate them, have a discussion, etc. That takes time. It doesn't scale to hundreds of interviews per week.