HNHacker News
TopNewBestAskShowJobs

renaudpawlak

65 karma · joined December 5, 2015

submissionscomments
renaudpawlak··on I think I have LLM burnout
It looks that what you describe is partly a "burnout", partly a "sickness" of always the same LLM tricks and output (including errors). Of course LLMs tend to go back to their initial training and even if you "teach" them right, the attention mechanism make them forget things that are not often used (that's the KV-cache) even if they can be important for you (there is room for improvements here).

That said, your reaction is totally human. I personally get sick of how the LLM writes prose with always the same tricks and formulas (even if you prompt it not to). Humans need variants and novelty, that's why fashion exists. We get fed up with repetition and after seeing too much green shoes, seeing a red one is so relieving :) (quick note: I don't like fashion - I'd advocate diversity and personal styles, not fashion)

But that's also the way you work with AI that might be part of the problem. Personally, I don't review all the code the AI generates. I look at it, and I review only the code that matters. And with time on a given project I review less and less because I trust more the architecture and ability of the AI to follow it. In my settings, the AI gets confined to the existing architecture (that we define together at the beginning of the project), and has to ask for authorization to create new things (that's when I review the more). Hoping this could help to avoid burnout myself...

renaudpawlak··on [dead]
Hello HN, at LocalFlow, we have been working on a new kind of software component following lean methods, with the help of low-code tooling. I am curious to have you feedback.
renaudpawlak··on Lean Components: Putting It into Practice in Salesforce – Part 1
Hello HN, at LocalFlow, we have been working on a new kind of software component following lean methods, with the help of low-code tooling. I am curious to have you feedback.
renaudpawlak··on Ask HN: Anyone Interested in Taking over Jsweet.org?
Did not find either :/
renaudpawlak··on Ask HN: Anyone Interested in Taking over Jsweet.org?
You can take a look at https://github.com/j4ts, which contains some Java libs transpiled by JSweet to TS/JS. The AWT/Swing implementation is just a proof of concept, but some other libs are fully functional like awt/geom.

However, you have to be aware that the initial purpose of JSweet was not to port all Java libs to JS. JSweet allows the transpiler to be customized (with extensions) to map Java APIs to JS ones so that you don't necessarily need a JS runtime. It's all explained in the "Extending the transpiler" section of the core doc: https://github.com/cincheo/jsweet/blob/master/doc/jsweet-lan...

renaudpawlak··on Ask HN: Anyone Interested in Taking over Jsweet.org?
Thanks :) I hope too. The project deserves it.
renaudpawlak··on Ask HN: Anyone Interested in Taking over Jsweet.org?
Shutting down the projet and/or change the OS license to make it easier to fork is a potential option. However, I think it's worth asking if some organisation could be interested first. I believe JSweet could be more helpful if it was backed by some org that would have a use case of JSweet and maintain it for it's own purpose.
renaudpawlak··on Ask HN: Anyone Interested in Taking over Jsweet.org?
JSweet comes with a TS definition files to Java translator (.d.ts to .java). So when you have the TS definition file, you can generate the correspond Java API on-the-fly or use a pre-translated/pre-compiled definition in so-called "candies". The candies are just here for typing in Java and ensure that you have the exact same API as in TS. Then JSweet generates intermediate TS code, which is compiled against the original TS definition. This 2-step transpilation process ensures that the generated code is correct and well-typed. In the end, you can work either directly with the JS code or the TS code depending on what you need.
renaudpawlak··on Ask HN: Anyone Interested in Taking over Jsweet.org?
Yes indeed
renaudpawlak··on The 8th "Forgotten" Principle of Local First Development
In this blog post, I propose to add Eco-Designed as an 8th principle to the original 7 principles of Local First.
renaudpawlak··on Ask HN: What happened to vanilla HTML/CSS/JS development?
In a UI, you usually apply some sort of MVC pattern (Model-View-Controller), which means that you have a Model (your data, which usually comes from a server, or can be created by the user interacting with the UI), and the View, which is implemented with some HTML / DOM elements and reflects what the user sees. Then you have some sort of components (playing the role of Controllers) that are responsible (amongst other things) of syncing the Model and the View both ways (when the users interacts, with the view, it might update the data, but also, when the data changes for some reason, it might update the view).

The strength of the frameworks (React, View, Angular), is to provide a way to create well-scoped (local/small) components that take care of the Model (the data), the View (generally what is called a template), and have a built-in reactive capability that facilites the sync of the Model and the View. That reactivity is extremely powerful because it "watches" all changes of the Model and knows when a change is impactful for the View. It then refreshes the view automatically so that the user instantly sees the impact of its action or any state change in the application.

When you don't have reactivity, it is of course possible to build a UI, however, you will have to rigorously and explicitly update the view yourself. You can use an observer pattern to do so (btw, under the hood, reactivity is provided by an implicit and automated observer pattern, so that all data of the model become "observable"). In any case, when you don't have reactivity, it gets more complicated and you have to really know what you are doing because your UI code can become a big mess really easily.

You asked for an example. Imagine you have a UI with the check box and when the user checks it, it shows an input so that the user can enter some text to precise some data. In general, you can implement that behavior really easily with a reactive framework. Here is the pseudo code (not meant to be compiled).

The view: <input type="check" model="checkvalue" /><IF condition="checkvalue"><input type="text" model="textvalue" /></IF>

The model: { checkvalue: false, textvalue: undefined}

The important here is the IF tag, which depends on the checkvalue of the model. When this value is false, the text input does not show and vice-versa. It is fully automatic thanks to reactivity. If you don't have reactivity, you need to refresh the view manually when checkvalue changes, and you can imagine it can become quite messy when the view and the model get bigger :)

All that being said, reactivity, if employed poorly, can also become a mess and tigger a lot of unnecessary updates of the views. That's probably why some people complain about framework performances. Of course the role of the framework is also to give you a "frame of work"... if you go out of the frame, that's usually quite bad...

And finally, you can completely develop a small UI with no reactivity applying a MVC pattern with explicit update. That would just make the code more verbose, but IMO, it is doable if you know what you are doing. And it can probably be more efficient in some cases because you don't rely on the framework magic (you can decide in your program when to update the view).

renaudpawlak··on Ask HN: Which NoCode platforms are fine?
For the record: dLite.io is a low-code platform I have been working on to build front ends (similarly to bubble.io). It is ongoing work, but it already has many examples (and the website itself is made with dLite.io). It differentiates from others because it comes with a built-in support of the local-first paradigm. (web site: https://www.dlite.io, platform, with examples: https://plaform.dlite.io). (local-first paradigm explanation: https://cincheo.com/2021/10/03/when-low-code-meets-local-fir...) [disclaimer: I am also the author of JSweet.org, but right now my interests are moving towards low-code!]
renaudpawlak··on Ask HN: Which NoCode platforms are fine?
If you use a no-code front-end builder (like Bubble.io), I guess you could use any UI test framework to test your app. It is not the same as unit testing, but it is more global and in the end, UI tests are quite powerful to detect regressions that matter to the users.

That said, if you think that unit tests are always required, then I think that you are a victim of code complexity. Let me explain. I do believe that unit testing is good to master complexity, which often becomes out of hands with classical approches because the code is complex by itself (new lib versions popping up all the time, breaking refactoring). The thing with low-code is that it lowers that complexity by proposing more declarative approaches, which are more stable and less broken when changing versions (think of a static web page for instance, you don't really need to test it that bad although the browsers versions bump all the time).

I think that it is more important to be able to control complexity in order to avoid testing, rather than having to test "no matter what", like your reaction suggests. Plus, testing implies CI/CD and a lot of automation that are extremely complex to set up and consume a lot of resources.

I wrote a blog post about this stand-point lately https://cincheo.com/2021/10/03/when-low-code-meets-local-fir...

DISCLAIMER: I am currently working on a new low-code platform for frontend development based on the local-first paradigm. (web site: https://www.dlite.io, platform, with examples: https://plaform.dlite.io).

renaudpawlak··on Ask HN: What are you working on?
I have a web page for this :) https://cincheo.com/renaud-pawlak/ You will find all my (side) projects, including the ones in standby and failed/stopped ones. Not sure these projects all fit the "cool" criteria though! ;) Never applied to HN so far since I am not sure my projects fit.
renaudpawlak··on The other kind of JavaScript fatigue
JSweet is not a magic bullet in the Java world, because JSweet is not Java. JSweet borrows the Java syntax to have well-typed JavaScript. Of course, not all transpilers have a focus on typing and not all of them have great tooling to back refactoring (not only renaming... you have plenty of other kind of help you will get when using a good Java IDE). But the focus of JSweet is typing and tooling (through Java).

I think that Christian Maioli Mackeprang is right. Some languages focus on instant productivity. They are really good and powerful to sketch a program in a few lines of code. But this quality comes at the expense of other important features that are really important for a language/development environment. People need to consider this or we will end up with poor programming environments and languages that are great for prototyping, but that don't scale up for complexity...

renaudpawlak··on The other kind of JavaScript fatigue
I disagree. I have been developing an IONIC application with JSweet. My experience is that when I want to refactor the code (for example, just renaming the data objects because the customer changes its mind about how to name something), then you are happy to have JSweet and you can make the code up-to-date in no time. The more the application gets complex, the better it is to have a transpiler to help you update your code safely. Your Faustian deal applies more to JavaScript IMO. It is very cool at the beginning, but at some point you start wondering what happens in your code and you need to write it again from scratch because it is not maintainable any more. JSweet is not GWT. It you don't like Java, try at least TypeScript and I am pretty sure you will change your mind.
renaudpawlak··on The other kind of JavaScript fatigue
GWT is not a transpiler only. It is a framework. In GWT, the transpiler part is so little that it would be totally wrong to assume that transpilers are wrong because GWT is wrong. JSweet is like TypeScript. It just adds typing. No runtime, no lib, no framework, just a transpiler: I don't see any issues except if you consider that typing is an issue.
renaudpawlak··on Show HN: GitHub News, using a peak detection algorithm to detect trending repos
Pff. That's a vicious circle. Then trending repos will get even trendier. Social networks are largely enough to expose that kind of "noise"/"buzz". I think that a good metric to find interesting projects that are starting or are not already under the spotlight would be to use the ratio: new visitors / stargazers. Quite hard to achieve but I really think it would be more accurate (and fair).
renaudpawlak··on Oracle deprecating Java applets in Java 9
Longevity has a cost. It ends up with outdated support and APIs. Software lives and has to evolve. That's why now all software has CI and code coverage test to allow agile development, which was not really the case at the time of applets. IMO, it is a good thing to deprecate things (even to remove them) it forces programmers to be more agile. Some corporate should try to start thinking this way.
renaudpawlak··on Oracle deprecating Java applets in Java 9
Yes there is: https://dukescript.com/. But you can also think of transpiled approaches such as GWT. Personally my favorite is JSweet (http://www.jsweet.org) because you get to write actual JavaScript in Java, and I find that the canvas API and other SVG or WebGL APIs allow much more things that what was done in Java.
renaudpawlak··on JSweet: A transpiler from Java to TypeScript/JavaScript
Well it is already done in JSweet: checkout these APIs http://www.jsweet.org/candies-snapshots/ It is all compiled and deployed as Maven artifacts on our repo. And we even give access to all the JavaDocs if you follow the links to the end... checkout this Angular JavaDoc for instance: https://jsweet.org/apidocs/snapshots/org/jsweet/candies/angu...

Let us know if you are interested in collaborating on this (never hurts asking).

renaudpawlak··on JSweet: A transpiler from Java to TypeScript/JavaScript
It is different. The focus is different. JSweet focuses on TypeScript/JavaScript while GWT focuses on Java and see JavaScript as just an execution engine. Now GWT is obviously adding bridges to JavaScript, but still, it is not the main purpose. As I understand GWT, it still relies mostly on the GWT SDK and on Java semantics at runtime.

If I may add some hopefully-constructive criticism, it feels that GWT (like some other well-known Google frameworks) is trying to address too many issues at the same time... But that's my own opinion and it does not mean I don't appreciate it.

renaudpawlak··on JSweet: A transpiler from Java to TypeScript/JavaScript
I am not sure to what your question is referring to, but FYI, JSweet follows the same pace as TypeScript in terms of JavaScript generation. So it already supports most of ES6 AFAIK.
renaudpawlak··on JSweet: A transpiler from Java to TypeScript/JavaScript
Transpiling from an untyped language to a typed one would give you horrid results in most cases. The practical way would be to use TypeScript to compile your program (JavaScript programs compile fine with TypeScript) and start to manually transform your JavaScript code to add objects and types.

That said, that would be a really cool tool to have...

renaudpawlak··on JSweet: A transpiler from Java to TypeScript/JavaScript
Class initialization is handled with semantics that approach the Java ones so that it is not confusing for programmers. AFAIK it works but in case it doesn't I'd be curious to know what's wrong.

Lambdas are meant to be used like in JavaScript. It totally works. JSweet supports function references (MyClass::myFunction) and defines the JS Function object for passing plain object functions. No need for getClass(), hashCode() or equals() in JavaScript.

Regarding interfaces, the situation is quite different. JSweet does not support interfaces in the way Java supports interfaces. JSweet interfaces are mapped to TypeScript interfaces which are pure compile-time entities used only for typing (which differ strongly from Java's). That's why the code you quote will not compile in JSweet, but it does not mean that JSweet is wrong: it means that your way of understanding an interface in JSweet is wrong (unlike Java, JSweet interfaces have no runtime representation). This part requires further documentation though... JSweet is a very young project.

Generally speaking, when you program with JSweet, you have to stop thinking too much in terms of Java semantics, and start thinking more in TypeScript or JavaScript, at least for some cases. The very most of it remains close to Java and very intuitive to programmers, since IMO, Java and TypeScript are quite in the same language family.

renaudpawlak··on JSweet: A transpiler from Java to TypeScript/JavaScript
If JSweet claims about GWT are inaccurate they will be fixed. But you have to understand that JSweet is a syntax mapper to TypeScript (explained here: http://www.jsweet.org/papers-and-publications/). So they are really different techniques. With JSweet, what you see is what you get. There is a direct correspondence between the written Java code and the output TS/JS, and that for ALL the program (not only fractions of it). So we are probably not always referring to the same features and certainly not the same ways of doing things, which probably explains some misunderstanding in JSweet assertions about GWT.

JSweet is not meant to obey JLS because JSweet is "just" Java syntax. It is not Java anymore. However, some specific transformations (very few) have been implemented so that Java programmers are not confused by JavaScript runtime behavior (as explained here for instance: http://www.jsweet.org/language-specifications/#Variable_scop...).

JSweet is not meant to be at all compatible with Java legacy APIs. With JSweet, you will not even be able to access the Java Object API nor the Java String API. Instead you directly access the Object and String JS APIs. So who cares about JLS semantics then? What JSweet is trying to compile is JavaScript applications, not Java, and the examples show that it works for not-that-trival code.

In short, JSweet is for writing real JavaScript applications in a Java compile-time environment (not runtime). Nothing more, nothing less. I understand that GWT new generation it aiming somewhat at integrating JS apis too... But AFAIK, JSweet is the first project to give access to hundreds of JavaScript libraries in Java thanks to the TypeScript to Java API translator.